Most of the individual pieces covered elsewhere on this blog — provisioning an inbox, reading its history, treating inbound content as untrusted — come together in a single recurring pattern: an agent that checks its own mail periodically, decides what each message means, and takes action on what's actually worth acting on. This post walks through that pattern end to end.
Decide upfront whether this agent needs near-real-time reaction or can tolerate some latency. For time-sensitive triage, register a webhook_url at inbox creation and react to pushed message.received events; for a lower-urgency background job, poll GET /api/inboxes/{slug}/messages on a reasonable interval instead. See Polling vs Webhooks for the full tradeoff.
Don't let a single LLM call both read raw message content and immediately decide to take a powerful action based on it. Split triage into two distinct passes: a classification pass that reads a message and produces a structured judgment (is this urgent, what's it about, does it need a reply), and a separate action pass that only runs for messages that pass the first filter, with the fewest capabilities it needs to do its job. This mirrors the mitigation covered in Prompt Injection via Email: A Real Risk for AI Agents — narrowing what a single untrusted-input-reading step can trigger directly.
A triage pass should be comfortable saying "I'm not sure" or "this needs a human" rather than forcing every message into a confident category. For an inbox receiving a mix of ordinary human replies and automated notifications, expect genuine ambiguity — a triage agent that always picks an action, even uncertain ones, tends to compound small misclassifications into real mistakes over time.
Since neither receive channel currently verifies sender authenticity (see SPF, DKIM, and Why Agent Email Needs Them Too), a triage agent shouldn't grant elevated trust to a message just because its from field matches an expected address. For anything where the stakes of misidentifying a sender are real, build in a second check — a shared reference included in the message body, a confirmation round-trip, or routing to a human for anything claiming unusual authority.
Record what a message said and what the triage pass decided before the action pass runs, not just after. If an action turns out to be wrong — an agent replied to something it shouldn't have, or missed something urgent — having a clear record of what the inbox actually contained and what the agent concluded from it is the difference between a quick fix and a genuine mystery.
A minimal version of this loop: a webhook fires on new mail, a classification call reads the message and the inbox's recent context (via the messages endpoint) and produces a structured judgment, and only messages flagged as actionable trigger a second, narrower call that might draft a reply through the drafting endpoint or escalate to a human. None of the individual pieces here are exotic — the pattern is really just applying ordinary input-validation discipline to a channel (email) that doesn't enforce much of it on its own.