A support agent that replies by email has two halves: reading whatever arrived, and drafting a reply. Both are straightforward to wire up with a single inbox. The part that actually determines whether this is safe to run unattended is what happens to the inbound content before it ever reaches a drafting call.
At its simplest:
GET /api/inboxes/{slug}/messages, using the read token issued at provisioning.POST /api/inboxes/{slug}/send, using a purpose brief built from the question’s content.See how AI agents receive email for the two channels that content can arrive through, and building an agent that triages its own inbox for sorting incoming questions before deciding whether — or how — to reply at all.
Whatever arrives in a message body was written by whoever sent it, and nothing about the delivery channel marks it as safe. If the agent's next step is handing that body straight into a model as part of a drafting prompt — "reply to this" with the raw inbound text pasted in — it is exposed to the same risk as any other system that feeds untrusted text into an LLM: instructions embedded in the message trying to redirect what the model does next. Why you should treat inbound email as untrusted input and prompt injection via email both cover this in depth. The short version for a support agent specifically: separate the question's content from any instructions about how to respond, and never let text pulled from an inbound message control what the agent does beyond answering the question in it.
Rather than pasting the full inbound email into purpose verbatim, extract what the reply actually needs to address and put that in the brief:
{
"to": "[email protected]",
"purpose": "answer a billing question about a duplicate charge",
"tone": "helpful and direct",
"key_points": ["duplicate charges are refunded automatically within 5 business days", "no action needed from the customer"]
}This has two effects: it keeps the brief under control (purpose is capped at 2000 characters, so a long inbound thread needs summarizing anyway), and it means whatever the customer wrote never gets a direct, unfiltered path into the drafting model's input. See designing prompts for reliable AI-drafted email for more on brief construction generally.
Not every inbound message should get an automatic reply. A triage step — even a simple one, like checking for keywords that suggest a refund request, a legal threat, or account access trouble — is worth running before the drafting call, with a path to hold the message for a human instead of answering it. An agent that replies to everything indiscriminately will eventually draft a confident, well-written answer to something it should have escalated instead.
Each reply is a $0.01 send call, same as any other drafted send, and returns 202 Accepted while delivery happens on a background queue — see queued delivery explained. There's no per-seat cost for the support agent sitting idle between questions; it only costs money when it actually answers one.
For provisioning the inbox this agent runs against, start with provisioning an inbox in one API call or the API quickstart.
A cheap keyword pass over the inbound subject and body, run before the drafting call, is enough to catch a meaningful share of cases that shouldn't get an automatic reply:
const escalate = /refund|chargeback|lawsuit|legal|cancel my account/i;
if (escalate.test(inboundMessage.subject + " " + inboundMessage.body)) {
// hold for a human instead of drafting a reply
} else {
// proceed to the drafting + send call
}This isn't a substitute for real classification if the volume justifies something more thorough — it's a cheap first filter that costs nothing to run and catches the cases where an automatic, confidently-worded reply would be the wrong move.
If an inbound question arrives in a language other than the one the agent defaults to, tone is the field to steer that — something like "reply in the same language the customer wrote in, formal register" — rather than trying to engineer language detection separately. The drafting call still only takes the same four or five fields; there's no separate language parameter.
A support agent that only pays $0.01 per reply, with no cost for the messages it reads or the time it spends idle between questions, has a very different cost profile from a seat-based support tool licensed per agent per month regardless of volume. Pay-per-call vs subscriptions covers that comparison directly, and it's a particularly clean fit for a support queue where volume is naturally uneven across the week.
This pattern replies to questions it can answer from a brief; it isn't a ticketing system, doesn't track open/closed status, and doesn't handle attachments. If a support workflow needs any of that, it needs to live in whatever system orchestrates the agent — DimeBox's job here is specifically the send and receive of the actual email, not case management around it.