# Build an email support agent

Source: https://developer.nylas.com/docs/cookbook/agents/email-support-agent/

A support agent sounds like a triage agent with extra steps — but it isn't. Triage decides what to *do*; support decides what to *say*. Saying the wrong thing in a customer-facing reply is the kind of mistake that ends up on a slide deck. The pattern in this recipe defends against that with two gates: a confidence threshold on knowledge-base matches, and a risk tier that escalates anything legally or commercially sensitive away from the agent entirely.

## The five-step loop

1. Poll the support inbox for unread messages.
2. Read each one, extract the question.
3. Match against the knowledge base; get back a confidence score.
4. Risk-tier the ticket and route accordingly.
5. Draft a reply if the tier allows it; queue everything for human review.

The agent never hits send.

## Confidence gating

Confidence comes from your KB lookup (typically a vector search over articles + a re-ranker). The agent uses the score to decide what to do:

| Confidence | Action |
| --- | --- |
| `>= 0.85` | Draft directly from the matched article |
| `0.60 – 0.85` | Draft conservatively, *cite the article inline* so the reviewer can verify |
| `< 0.60` | Don't draft. Flag for manual review with a "best guess" KB article attached |

The two-tier draft (confident vs. citation-required) is what keeps the reviewer's job manageable — they trust the high-confidence drafts, scrutinize the medium-confidence ones, and write the low-confidence ones from scratch.

## Risk tiering

Independent from confidence:

- **Low** — password resets, FAQ-shaped questions. Draft → human approves.
- **Medium** — refund requests, account changes, anything affecting billing. Draft → human approves with extra scrutiny.
- **High** — legal threats, regulatory matters, fraud reports. Skip drafting. Escalate immediately to a real person with full context attached.

Risk doesn't care about confidence: a high-confidence KB match for a refund question still goes through human review. Compounding mistakes is what produced the [Air Canada chatbot refund ruling](https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416) — never let an agent commit your company to anything without a human in the loop.

## Skill configuration (Manus pattern)

If you're running this on Manus, the agent is configured through a `SKILL.md` rather than code:

```markdown
# Support agent

## Reply style
- Replies are under 120 words.
- Cite KB articles inline: [KB-1234](https://kb.example.com/1234).
- Match the tone of the inbound message.

## Drafting rules
- Always show the draft before sending. Never auto-send.
- If confidence < 0.6, do not draft — flag for human.
- Refunds, account changes, legal threats: never draft. Escalate.

## Polling
- Check the support inbox every 10 minutes.
- Process at most 5 tickets per cycle while the agent is in shakedown.
```

The "always show the draft before sending" rule is the load-bearing constraint. Don't remove it.

## Drafting code (subprocess version)

If you're rolling this yourself instead of using Manus, the loop looks like:

```python
def handle(msg):
    question = extract_question(msg)
    article, conf = kb.search(question)

    if classify_risk(msg) == "high":
        escalate_to_human(msg, reason="high-risk topic")
        return

    if conf < 0.60:
        flag_for_review(msg, article)
        return

    draft = generate_draft(msg, article, cite_inline=(conf < 0.85))
    queue_for_approval(msg, draft, article)
```

`queue_for_approval` is the choke point. In production it usually drops the draft into a Slack channel or an internal review tool, not directly into the support inbox.

## Scaling tips

- **Start with `--limit 5`.** Process five tickets per cycle while you're tuning the KB matcher and the risk classifier. Bump to 20 once the false-positive rate is acceptable.
- **Group similar tickets.** If the agent sees three "where's my receipt?" tickets in a row, batch them — same KB article, same draft template, one reviewer pass.
- **Mind KB drift.** Tickets the agent can't confidently match are the strongest signal of where to write new KB articles. Track them.

## Things to know

- **Polling, not webhooks.** Support inboxes typically have multiple recipients; webhook fan-out gets complicated. Polling every 5–15 minutes is simpler and the latency is acceptable for support contexts.
- **Human-in-the-loop is non-negotiable.** Even at 99% accuracy, the 1% that makes legal commitments destroys trust faster than the 99% builds it.
- **Audit everything.** For support, you'll want a complete record of which articles were matched and which drafts were sent — log every classification, lookup, and approval decision to your own store.

## Next steps

- [Email triage agent](/docs/cookbook/agents/email-triage-agent/)
- [Reach inbox zero](/docs/cookbook/agents/inbox-zero/)