Triaging a shared inbox with an agent
Four mailboxes, one queue. Rules sort what they can, a model labels the rest, and the agent writes drafts that a person approves before anything sends.
- Rules first, model second
- Drafts wait in a queue
- Every label is auditable
The short answer
- Threads from every connected mailbox arrive in one queue. Regex rules classify first because they are cheap, deterministic and explainable; an LLM fallback labels only what the rules missed.
- The Inbox agent drafts a reply and stops. The draft waits in the approval queue with the thread, the classification and the cost visible, and you approve, edit or reject it.
- Two classes run in auto by default and both are safe ones: classifying a reply, and suppressing a contact on an unsubscribe or a bounce. Anything that leaves the building is review.
Trigger to logged
What happens to one message, in order.
- 1
Trigger: mail arrives over IMAP
Gmail, Outlook or cPanel mailboxes sync into the same thread list. Nothing is moved or deleted in the mailbox itself.
- 2
Rules classify first
Pattern rules you wrote assign a category. Out-of-office, unsubscribe requests, bounces and known vendor noise are the obvious wins here, and they cost nothing to run.
- 3
A model labels the remainder
Threads the rules did not match get an LLM classification. It applies a label only; it does not act on the thread.
- 4
Automatic consequences fire
An unsubscribe writes to suppression. A reply pauses the cadence for that contact. Both run in auto because both are reversible and both are the behaviour you would want anyway.
- 5
The agent drafts where a reply is wanted
The Inbox agent writes a draft grounded in your knowledge base, and it waits. The queue shows the thread, the evidence, the confidence and what the draft cost.
- 6
A person approves, edits or rejects
Approve sends it. Edit-then-approve sends yours. Reject records a reason that feeds the agent's next run. Every one of those is written to the audit log with the actor named.
What gets configured
Six settings, and the reason each one exists.
| Object | What you set | Why |
|---|---|---|
| Mailboxes | IMAP and SMTP details per account, credentials in the vault | One queue only works if every mailbox is in it, and seats are unlimited so nobody is left out |
| Categories | Regex rules and their labels | Deterministic, explainable and free to run, which is why they go first |
| LLM fallback | On or off, and the model class | It labels the residue rather than every message, which keeps the cost proportionate |
| SLA and snooze | Response targets and snooze behaviour | A shared inbox fails on the threads nobody owned, not on the ones nobody could answer |
| Knowledge base | Your facts, terms, service area and voice | A draft grounded in your own material argues from what is true rather than from what sounds plausible |
| Agent mode | Off, draft, review or auto per agent | Every agent ships in review. Moving one to auto is a decision, never a default |
Where it stops and a human starts
Sending stops with a person. Any external send is review in the default policy table, and the Inbox agent has no path around it. That is the point of the queue rather than a setting to be discovered later.
Judgement stops with a person too. A model that labels a thread as interested is guessing from language, and the label is a filter for attention rather than a verdict on a lead. Read the thread before you treat the label as a fact.
Moving the agent to auto stops with a person. The sensible sequence is a week in review, reading the drafts you rejected and why, and then promoting the low-risk classes only. Confidence below the threshold falls back to review even in auto mode.
Questions
- Why not let the model classify everything?
- Cost and explainability. A rule that catches every out-of-office message is free and you can read why it fired. Handing that to a model is paying for a guess at something a pattern already answers.
- Can the agent send a reply on its own?
- Not by default and not without you changing the policy deliberately. External sends sit in the review class, and the kill switch on the Agents page stops every agent at once.
- What does an agent see that a person does not?
- Nothing extra. A scoped MCP token carries the same channel, profile and area limits a person has, so an agent cannot read past its owner's access.