Route support@ to an agent, not a queue
Customers already know how to send an email — point support@ at an agent instead of a person, and let it read the thread, ground its answer, and know when to stop.
The short version
- A dedicated support address, not a shared mailbox a human also reads, is what makes escalation a real event instead of a vibe.
- Retrieval is your code, not Inboundr's — the product hands over a clean thread, and grounding the answer is what makes the agent useful.
- Money, access, empty retrieval, and repeat contact are gates in code, evaluated the same way every time — never left to the model's judgment.
- Push a support address to a webhook by default: the customer who just emailed is watching for movement.
The loop, in one picture
A customer emails support@. Everything from there is one repeating loop, ending in a gate:
Give it its own address
Route the agent into a dedicated address, not a mailbox a person also reads. Mixed in with human traffic, there’s no clean signal for what the agent resolved versus what it skipped, and escalation becomes a hope instead of an event. Push it to a webhook rather than polling — a customer who just emailed is watching for movement, and how fast their ticket gets picked up is the product here.
Ground the answer, don't recall it
Inboundr hands over a clean thread. Whether the answer is actually true is entirely your retrieval step — search your docs and past tickets, pass what you find into the prompt, and require the draft to cite it rather than recall your product from memory.
No citation, no resolution
Empty retrieval means the knowledge base has nothing on this question. That’s a reason to escalate, not an invitation to guess — a confident wrong answer costs more than no answer.
Decide what needs a human
Draw the fork above in code, not in the prompt, so it can’t be talked out of a rule:
draft = model.answer(thread, context, account)
if draft.action in ("refund", "cancel", "change_plan") \
or context.empty or is_repeat(thread) or is_angry(thread):
escalate(thread, draft) # a person decides
else:
resolve(thread, draft) # filed to the ticket, answer attachedWiring it up
- Create the address, routed to a webhook endpoint.
- Check SPF/DKIMbefore trusting anything account-specific — match the sender’s domain, never the display name.
- Run retrieve → draft → gate → route on every message. The build-an-agent guide has the full API reference.
Two tickets, two outcomes
How do I reset my password?
Locked out after changing devices, tried the usual link…
Resolved automatically
Cites the reset article. No account access involved.
Charged twice this month — refund the second one
Same amount, same day, only needed one of them.
Escalated to a human
Draft ready — a person applies the refund, not the model.
Same pipeline, same address. The split between them was a rule, not how convincing either email happened to be. For the general argument on handing an agent an inbox at all, see Give your AI agent an email address.