FrictionForge

• 

  A screenshot of the FrictionForge system in action.

Inspiration

Juggling contract work across multiple AI-evaluation gig platforms meant tracking task deadlines, pay rates, and eligibility notices scattered across separate inboxes with no unified view. FrictionForge started as a fix for that exact personal problem: a background agent that handles the busywork instead of me manually checking each platform.

What it does

FrictionForge intercepts task-assignment emails as they arrive, extracts structured task data with Gemini 3.5, and independently verifies that extraction with a second adversarial agent before trusting it: flagging anything unclear instead of guessing. Confirmed tasks are logged to a cross-platform pay ledger, get a calendar reminder before their deadline, and receive a drafted (never auto-sent) reply. A daily digest summarizes what's due and what's been paid, and a live dispatch console shows the whole system working in real time.

How we built it

The system runs as a set of Google ADK agents on Cloud Run, triggered asynchronously through Pub/Sub rather than polling. Gmail push notifications trigger ingestion, which pulls real message content via the Gmail API; extraction and verification run as two independent Gemini 3.5 agents. Confirmed results write to Firestore, which backs both the pay ledger and a Calendar/Gmail draft action layer. Instead of a standard linear pipeline, the architecture is event-sourced. In other words, each stage writes to a shared shift log and reacts to relevant events rather than being called directly by a central controller, which the dispatch console visualizes as a live monitoring feed.

Challenges we ran into

The biggest one was matching real Gmail push behavior: notifications only ever carry an emailAddress and historyId, never the actual message content, so ingestion had to be rebuilt around fetching data rather than receiving it. Getting the verifier agent to correctly attribute the right deadline and pay amount out of emails containing multiple unrelated dates and dollar figures also took real tuning — early passes occasionally seized on the first number in the email rather than the one tied to the actual task.

Accomplishments that we're proud of

The accomplishments that I am rather proud of consists of the extractor–verifier split actually working. What it does involves catching ambiguous and adversarial emails and routes them to review instead of silently guessing, which is the difference between a system you can actually trust unattended and one that just looks automated. The event-sourced dispatch architecture also gives per-task traceability end to end, from the moment an email lands to the action taken on it.

What we learned

As this was one of my more ambituous Hackathon projects due to the amount of time I had to spend revising and changing the scope and structure, I can say I learned something very, very interesting. Treating extraction and verification as separate, independent agents produces meaningfully more reliable output than a single call with a good prompt: the same principle behind structured human evaluation rubrics, applied to the agent's own outputs. We also learned the real constraints of the Gmail push API firsthand, which shaped the ingestion design more than anything planned upfront.

What's next for FrictionForge

What I would consider for FrictionForge's future is looking back on any areas of current model and implement any new features that potentially improve its usability. One of the ideas I currently have in mind includes a lightweight Gemma pre-filter to cut cost on obvious non-task emails, explicit prompt-injection defenses on ingested content, and broader platform coverage beyond email-based notifications.

Built With

• fastapi
• firestore
• gemini
• gmail-api
• google-adk
• google-calendar-api
• google-cloud-pub-sub
• google-cloud-run
• google-cloud-scheduler
• google-cloud-trace
• javascript
• nextjs
• opentelemetry
• python
• react
• vertex-ai