Dispatch

An agent that watches your inbox, calendar, chats, and bills, and only interrupts you when there's a real decision to make.

Comment

Inspiration

Every day brings the same small, repetitive decisions: reply to this email, fix this double-booked meeting, remember this bill is due, move an outdoor plan before it rains. None of these need a human's judgment exactly — they need a human's approval. Most AI agent products either force you to babysit a chat window, or take actions autonomously and hope you're fine with it. We wanted something that sits quietly in the background and only interrupts you for the one thing that actually matters: saying yes, editing, or saying no.

What it does

Dispatch watches Gmail, Google Calendar, chat platforms, and payments, and for anything actionable it drafts the resolution and surfaces it as an Action Card — a proposed reply, a proposed reschedule, a proposed new calendar event, a proposed cancellation. Nothing is ever sent, moved, paid, or scheduled without an explicit human Approve or Edit first. Approve one, edit another, decline a third — and Dispatch quietly learns: correct the same field twice and it starts pre-filling that value on future cards.

The flagship flow: an email arrives asking to schedule a meeting. Dispatch doesn't draft a reply — it recognizes the intent, parses the proposed time, and offers to create the real Calendar event instead. One approval and it's actually on your calendar.

How we built it

The core is a Strands Agents SDK orchestrator. Every connector (Gmail, Calendar, Weather, plus mock Email/Payment/Telegram/Slack/SMS for zero-setup testing) exposes a plain poll(), wrapped as a Strands @tool. The orchestrator agent calls those tools, reasons over the results with Gemini, and returns strict structured output deciding what to propose — never freeform text. A deterministic scheduler handles routine polling for free; the LLM is reserved for where reasoning actually adds value (deciding what's actionable, drafting language, detecting meeting requests).

A FastAPI backend serves both a zero-build static web frontend and a native Flutter macOS app over REST + WebSocket, so cards appear live with a notification tone and a slide-in animation on both. The same orchestrator is also deployed standalone to Amazon Bedrock AgentCore Runtime, independent of the rest of the stack, with its Gemini key held in AgentCore Identity. The full application is hosted on Amazon ECS (Fargate) via an Express Gateway Service, behind an ALB, pulling its image from ECR, logs in CloudWatch.

Challenges we ran into

Two fights stood out. First, the (now-deprecated) AgentCore starter toolkit bundled a broken version of uv that produced deterministic hash mismatches on dependency downloads — we proved it wasn't a network or account issue by curl-ing the exact same file and matching PyPI's official hash byte-for-byte, then switched to the new official @aws/agentcore CLI, which built cleanly. Second, our ECS Express Gateway Service silently refused to launch any tasks — the default canary deployment strategy kept computing a desired count of zero, and it took digging into service events to find the real cause: a task execution role trusting the wrong principal (ecs.amazonaws.com instead of ecs-tasks.amazonaws.com). Fixing the trust policy immediately unblocked it.

Accomplishments that we're proud of

A genuinely dual-surface, human-in-the-loop agent — not a chatbot wrapper — with a real approval gate that's structurally impossible to bypass (the Execution agent only ever reads approved/edited cards, never pending), running both on Bedrock AgentCore and as a fully hosted AWS service judges can try live.

What we learned

Reasoning is expensive and unnecessary for most of the pipeline — the deterministic scheduler and connectors do almost all the work, and the LLM is only invoked for the handful of decisions that actually require judgment. That split kept the system fast, cheap, and easy to reason about.

What's next

Wiring up real Google OAuth on the hosted AWS demo (currently local-only), adding real Slack/Telegram/SMS integrations in place of the mocks, and extending the learned-preferences system beyond simple field pre-fill toward a fuller model of each user's approval habits.

Built With

Share this project:

Updates

Submission history