DRAFT v8. Time to stand up the pipeline: 5 minutes, not an hour. Section heading and paragraph updated. Stale 'wired both in an afternoon' line in the API section also fixed.

How to Build a Customer Support AI Agent (Working Example With a Real Inbox, 2026)

Customer support is one of the highest-value places to run an AI agent. Every inbound message is a scoped task with clear success criteria (did the customer get their answer). Every reply is training data. And every hour of triage the operator saves is a real hour back in the day.

Yet most published AI support agent examples run against a fresh inbox on a new subdomain. That is not the pipeline that ships in production. A real business runs support from one email address, that address has months of history, and the operator wants the agent to work from that same address without changing the customer-facing branding.

This post walks through a working customer support AI agent that runs against a real business inbox. The business is a small SaaS with a paying customer base. The agent runtime is a coding-capable AI agent on a cloud server (Claude Code, OpenClaw, Codex, Hermes, or a custom loop all fit; the operator's pick does not matter for the shape). The mail transport is MailBridge. Every reply the customer receives goes out from the same address they wrote to, signed by the same DKIM key, threaded in the same conversation.

The problem shape

The operator runs a WordPress plugin business. Support arrives at hi@.com. Volume is small (single digit new threads per weekday, spikes on release days). Answers are technical (WordPress version, plugin logs, license lookups) but repeat often (about half the threads have been asked before in some form).

The operator does not want an AI to send unsupervised replies. The operator does want the AI to draft, so that a 20 minute inbox session becomes a 5 minute review session.

The three hard constraints:

Replies must send from hi@.com. Not from support@.com. Recipients trust the source address. The domain has years of DKIM reputation. Sent replies must appear in the mailbox's Sent folder so a human looking at the mailbox has the full record.
The operator wants to approve every send. This is a preference, not a technical requirement. The same pipeline sends automatically if the operator flips one config flag. This operator likes the safety of a human-in-the-loop for now. The approval must take one word in a chat.
The agent must see attachments. WordPress users send screenshots of admin panels and PHP error logs. Without the attachment, the agent cannot answer.

The review surface is a Telegram chat with the agent on a cloud server. Any coding-capable agent runtime works (Claude Code, OpenClaw, Codex, Hermes, or a custom loop). New mail arrives in the chat as a message. The agent proposes a draft. The operator replies "send" to send it, "discard" to drop it, or something like "shorter, and mention the docs link" to iterate. That is the whole interaction. It works from a phone in a queue at the coffee shop.

The pipeline

customer email
   |
   v
[hi@<their-domain>.com IMAP mailbox]
   |
   | (MailBridge polls every 5 min)
   v
[MailBridge worker] ---- signed webhook (HMAC-SHA256) ----> [operator's review agent]
                                                                     |
                                                             (the agent drafts a reply)
                                                                     |
                                                                     v
                                                             [draft proposed in Telegram chat]
                                                                     |
                                                             (operator replies "send")
                                                                     |
                                                                     v
                                                    [POST /api/v1/connections/:id/send]
                                                                     |
                                                                     v
                                                    [MailBridge submits via source SMTP]
                                                                     |
                                                                     v
                                                    reply lands in customer's inbox +
                                                    appears in Sent folder of hi@<their-domain>

The only third-party service in the loop is MailBridge. The agent runs on a cloud server the operator controls. The Telegram bot is the operator's own. The mailbox is the operator's own.

The MailBridge API surface used

Two endpoints. That is the whole surface.

Inbound. MailBridge POSTs each new message to a webhook the operator picks. The payload is a signed JSON body with the full message and attachments. Any HTTPS endpoint can receive it.

Outbound. One POST /send call submits the reply through the source mailbox's own SMTP. The reply carries the source domain's SPF and DKIM, appears in the Sent folder, and threads correctly for the recipient.

That is it. The operator wired both in a few minutes (see the setup prompt below). Full field list, HMAC verification, and code samples: MailBridge API reference and Agent email setup walkthrough.

What the agent does with the inbound

The webhook posts the new message into a Telegram chat where the agent is the operator's partner. The agent reads the message, pulls the sender's prior thread history from a small local store, references the operator's product knowledge base, and proposes a draft reply in the same chat.

The operator reads the draft on a phone. Replies "send" if it is right. Replies "discard" if it is wrong. Replies with instructions ("shorter", "mention the docs link", "flag this for me to write manually") if it needs iteration. The agent does one of: call POST /send, drop the draft, or rewrite and re-propose.

For an operator who does not want the human step, the same pipeline calls POST /send on the first draft. The Telegram chat is a feature of this operator's setup, not of the pipeline.

The prompt is a plain markdown file the operator owns and edits. It contains voice guidelines, product facts, common gotchas, and rules for when NOT to draft (billing questions, security issues, refund requests). The agent flags those threads as "human required" and does not draft.

Standing up the pipeline (about 5 minutes)

The pieces above (a webhook receiver, a Telegram bridge, a small store for thread history) sound like real infrastructure work. In 2026, they are not. You give the setup prompt below to any capable coding agent (Claude Code, OpenClaw, Codex, Hermes, or your usual stack) and it scaffolds, deploys, and tests the whole pipeline. Answer four questions along the way. Total time: about 5 minutes.

Paste this into a fresh coding-agent session in an empty repo:

I want to build a customer-support AI agent that reads inbound mail from a
mailbox connected to MailBridge (https://mailbridge.app/docs/api/) and lets
me review and send replies from a Telegram chat with you as my partner.

Scaffold, deploy, and test:

1. A webhook receiver (Cloudflare Worker preferred; Fly.io or a Python
   script + ngrok as fallbacks). It verifies the MailBridge HMAC signature
   and forwards new messages into a Telegram chat via a bot I control.

2. A small local store (SQLite file is fine) that keeps the last N messages
   per thread so you have conversation context on your next turn.

3. Message handling: when a customer email arrives, you propose a draft
   reply in the Telegram chat. When I reply "send", you POST to
   https://my.mailbridge.app/api/v1/connections/<CONN_ID>/send with the
   draft. When I reply "discard", you drop it. When I reply with
   instructions, you iterate.

Ask me for:
- My MailBridge API key
- The connection ID for the mailbox
- Whether I already have a Telegram bot token and chat ID, or want you to
  walk me through creating one
- My preferred deploy target for the webhook receiver

Then write the code, deploy it, and send a test message so I can verify
the loop end-to-end.

Under the hood the receiver is about 80 lines of TypeScript. The Telegram bridge is another 30. The state file is a sqlite3 schema of two tables. Your coding agent writes all of it. That is the point.

For readers who want to inspect the shape before running the prompt: MailBridge API reference, Agent email setup walkthrough.

What works

Draft-then-approve is faster than write-from-scratch, even when the operator edits. Reading a draft and correcting it is faster than reading the inbound and writing.
Threading works. Customers see a normal reply from hi@.com. There is no visual signal that a draft passed through an agent.
Attachments are readable end-to-end. Screenshots go into a vision model. Logs go into text extraction. The agent references specifics from the attachment in the reply.
The operator owns the prompt file. Corrections tighten the prompt over time. Failure modes shrink over months.

What does not work (be honest)

Zero-shot correctness is not enterprise-grade. The operator still edits a meaningful fraction of drafts. The value is speed, not autonomy.
The agent needs the operator's product knowledge. A generic agent invocation without a curated knowledge base drafts polite but content-free replies. The runtime does not matter; the prompt file does.
Billing and security threads still need a human first draft. Rules-out lists are a permanent part of the prompt, not a bug.
Send-through-source-SMTP requires a password-authenticated source mailbox. OAuth-authenticated sources (Gmail, Microsoft 365) cannot send via the API today. Support for Microsoft Graph send and Gmail API send is on the roadmap.

What replaces vs augments the human

Replaces:

The read-and-mentally-index step for each new thread.
Pulling the customer's prior interactions from memory.
Drafting the boilerplate that opens most replies ("Thanks for the note, that error is usually...").

Augments (not replaces):

Judgement calls about tone.
Any thread where the answer is "we broke something."
Approval of the send (for this operator; full automation is a config flag away).

The reference architecture is not proprietary

Every piece of this is composable from public parts:

Any password-authenticated IMAP mailbox (Fastmail, Zoho, Hostinger, cPanel, most shared hosting) works as the source.
Any HTTPS endpoint can receive the inbound webhook. Any HTTP client can dispatch the outbound send.
Any agent runtime with tool use can draft the reply. Claude Code, OpenClaw, Codex, Hermes, LangChain, CrewAI, n8n, or a bare Python script all fit the same shape.
The review surface (a Telegram bot in this case) can be Slack, Gmail drafts, a purpose-built UI, or a plain command line. Or nothing at all if the operator wants full automation.

MailBridge is the transport layer that makes the source-address-preserved shape possible. If a hosted transactional API were an acceptable substitute, this article would not exist.

Try it

Get a MailBridge API key, read the agent email setup walkthrough, and wire your first inbound webhook. First mailbox is free during the beta. Rate limits are sized so a support-agent workload fits inside the free tier.

For the higher-level frame on giving AI agents email access (comparison against AgentMail, AgenticEmail, Postmark inbound), see How to give your AI agent access to email.