Every company has an inbox nobody wants to open on Monday morning. In it you find a customer who has been waiting for an answer since Friday, three newsletters, an automatic notice from the billing system, a payment receipt in PDF and a résumé. Someone has to read it all, separate what matters, reply, forward to the right team and archive. It is repetitive, slow work that is easy to put off, and it is exactly the kind of work an AI Agent does well.
But before putting an AI Agent to answer email, there is something almost every implementation overlooks: email is not a chat. The rules that work on WhatsApp or in a website chat produce, over email, week-long conversations to solve what should take two messages.
This guide explains how to design an agent for the pace of email, which kinds of inbox are worth automating and how, what the agent must never do, and why the best way to start is for it to send nothing.
Table of contents
- Why email is not a chat
- The three outcomes of every email: reply, escalate or close
- Start with drafts
- Five inboxes, five different jobs
- Before the agent: what should never arrive
- How to get it running
- The summary
- Keep reading
Why email is not a chat
In a chat, one question per turn works: the customer answers in seconds and the conversation moves on. An agent that first asks for the order number, then the purchase email and then a photo of the product solves the case in a couple of minutes.
In email every round trip costs hours, sometimes days. The same agent, with the same one-question-at-a-time logic, turns a two-email case into a five-email thread that lasts a week. The customer feels they are being given the runaround, and they are right.
That is where the channel's most important design rule comes from: a good email agent asks for everything it is missing in a single email. If it needs three pieces of information to solve the case, it asks for all three together, and explains why.
The other differences follow from that one:
- One email per turn. If the agent has three things to say in a turn, they go out in a single email, complete and self-contained. Never three emails in a row.
- In the same thread. The reply stays in the customer's thread, with the subject handled by the platform, instead of opening a new conversation each time.
- In the customer's language. The agent replies in the language of the email it receives.
- No talking to other robots. Automatic replies and system notices don't trigger an answer. An agent that replies to an "out of office" and gets another "out of office" back can end up in an endless exchange.
- It steps aside when a person joins. As soon as someone on the team takes the conversation, the agent stops intervening.
The three outcomes of every email: reply, escalate or close
Every time the agent processes an email it ends in one of three outcomes, and they are worth thinking through separately because each has a different cost of error.
Reply. The normal case: the agent answers in full and the thread waits for the customer.
Escalate. Some matters exceed the authority of any automated agent: a legal claim, suspected fraud, a return outside the policy, an authorization. There the agent tells the customer in a short email and leaves the case open for a person to take. Escalating well is worth more than replying well, because replying to something that should have been escalated is the error that ends in a serious problem.
Close. When the matter is solved, the case is archived on its own. If the customer replies days later, the conversation reopens and the agent picks it up with the full context.
What holds the three outcomes together is truthfulness: the agent only states what is written in the policies you gave it and in its knowledge base. Anything not there, it asks for or escalates. It does not make up deadlines, prices or exceptions. If it says things it shouldn't, it is almost never a model problem: it is missing context. That is why it pays to have the knowledge base in place before connecting the channel, and to understand the three knowledge layers of an AI Agent.
Start with drafts
The decision that most reduces the risk of an email implementation is a single one: don't let the agent send anything at first.
In AsisteClick, every department that receives email has a selector with three service modes:
| Mode | What it does |
|---|---|
| Reply | The agent answers the email and the customer receives its reply. |
| Draft only | The agent tags, routes and captures data, and leaves the proposed reply as a draft in a private note. It sends nothing to the customer. |
| No AI Agent (human support) | The channel's original state: email lands in the inbox and a person handles it. |
In Draft onlymode, the conversation reaches the inbox with the customer's email collapsed and, below it, the reply the agent would have sent. Whoever reviews it has three options: Edit to adjust it before sending, Send to send it as is, or Discard to set it aside. The discard is recorded in the conversation.
For the first few days you see exactly what the agent would have answered, on real email and without anything going out. It is the best possible test, because no hand-made set of examples looks like what actually reaches an inbox. When the drafts are convincing, you switch to Reply: it is a selector, nothing has to be rebuilt. And if something doesn't work, you can go back to No AI Agent at any time.
How to read the drafts of the first week
Draft mode only helps if the drafts are read with judgment. Four questions are enough for each one:
- Is it correct? Does it state anything that isn't in your policies or your knowledge base?
- Is it complete? Did it ask in a single email for everything needed to move forward, or will it force another round trip?
- Should it have escalated? Did it answer something a person should have taken?
- Would you send it as is? This is the question that decides when to switch to Reply.
When a draft goes wrong, the temptation is to rewrite the prompt. It almost always pays to look at the knowledge base first: an agent that makes up a delivery time does so because the real one wasn't written anywhere. To understand why it answered what it did, you can review the conversation in AI Observability. And one test not to skip: send an email the agent should not be able to solve, to confirm it escalates instead of improvising.
Five inboxes, five different jobs
"Automating email" is not a single task. The support inbox, the accounting inbox and the HR inbox receive different things and need different agents. AsisteClick has five templates written for the pace of email; each one is a starting point you adjust afterwards.
Email Agent: the general case
It answers each email in full and self-contained, one email per turn, in the customer's thread. It resolves with your policies and your knowledge base, escalates what exceeds its authority and archives what is solved. It is the template for an inbox with one main topic, such as sales inquiries or order support.
Email Triage: for the inbox that gets everything
Many companies have a generic address, like info@ or contact@, where anything arrives. The triage agent doesn't resolve: it classifies and distributes. It sorts each email into six types (sales, support, accounting, HR, spam or other) and each type does something different:
- Sales, support, accounting and HR go to the department you chose, tagged and open for a person to take.
- Spam is archived without any reply. It isn't rudeness: answering a spammer confirms the inbox exists and is active.
- Other stays open and unassigned.
The agent only sends a short three- or four-line acknowledgment; the request is solved by whoever receives it. And the type is saved in a variable that can be shown as a column in the inbox and used as a filter. That is half the value of triage: besides distributing the email, it lets you see how it is distributed. It also looks at attachments: a scanned invoice goes to accounting and a résumé to HR even if the body of the email says nothing.
Technical Support by Email
This is where the ask-for-everything-at-once rule pays off most. A technical diagnosis needs several pieces of data (model, version, what was tried, which error appears) and asking for them one by one is the recipe for an endless thread. This template asks for everything missing in a single email, resolves with known issues and the knowledge base, and escalates what exceeds it with everything it already found out, so the person who takes it doesn't have to ask again.
Accounting by Email
The accounting inbox receives proofs of payment: transfers, invoices, receipts. Someone has to open every PDF to know what it is about. This template opens the attachment and transcribes the receipt into the case: number, issuer, tax ID, date and amount. Whoever takes it sees the data without opening the file.
What it doesn't do matters just as much: it doesn't confirm payments or approve anything. It extracts and organizes; the decision still belongs to a person.
Job Applications by Email
It opens each résumé and summarizes it: experience, specialty, last position and education. And it has a rule written on purpose: it shortlists, it doesn't reject. Every application stays for a person to see. An agent that filters candidates on its own makes a decision that isn't its to make, and one nobody can audit afterwards.
The five templates share a principle worth carrying into any agent you build: AI extracts, organizes, classifies and proposes; it doesn't decide what belongs to a person. Approving a payment, rejecting a candidate or granting an exception are not tasks to automate, and that is exactly where many AI agent implementations fail.
Before the agent: what should never arrive
A support inbox receives far more than inquiries: newsletters, advertising, system notifications, automatic notices. Each one opens a conversation someone has to close by hand, and it also skews the reports: the "support" volume includes hundreds of emails that never came from a customer.
The solution isn't asking the agent to ignore them. It's making sure they never arrive. Inbound email filters discard those emails before the conversation exists, and they work whether or not an AI Agent is handling the channel.
Each filter is a condition on a field of the email (the sender, the subject, the body or any part), with an operator (contains, doesn't contain, starts with, ends with, is exactly or is not exactly) and a text. They are per department: each address has its own. The platform shows the rule written in one line, for example:
If the sender ends with @newsletter.empresa.com y the subject doesn't contain invoice → Discard
That "and" has a consequence worth being clear about: all the conditions in a filter must be met at once, so the more conditions you add, the less email it discards. If you want to discard two different things, create two filters.
There are two channel rules to know before creating the first one:
- What is discarded isn't saved anywhere. It doesn't go to archived items or to a folder, and it can't be recovered. Each filter's discard counter is the only trace.
- Only new email is filtered. Replies inside a conversation that is already open are never discarded, even if they match a filter. If a customer is already talking to you, nothing they write gets lost.
That is why filters are written with care:
- Start with the sender. It is the most precise field: a newsletter's domain doesn't look like a customer's.
- Be wary of "any part". The word "invoice" in the body of a newsletter also appears in the complaint of a customer who didn't get theirs.
- Avoid short, loose words, like "info", "payment" or "test", which show up everywhere.
- One filter per thing you want to discard. It is easier to read, pause and delete.
- Check the counter after 24 hours. A filter that discards much more than expected is eating good email. When in doubt, Pause turns it off without losing its configuration.
A useful side effect: the AI Agent never sees a discarded email, so it doesn't count it as usage either.
How to get it running
You don't need to change email providers or migrate the inbox. In AsisteClick each department has a unique address generated by the platform, and what you set up is forwarding from the inbox you already use: in Gmail, from the forwarding settings; in Outlook, from the mail forwarding options; on a corporate mail server, with a rule set up by your IT team. The inbox is still yours.
With the channel receiving email, getting started takes four steps:
- Create the agent. The quickest way is to start from one of the five email templates. If you build it from scratch, it needs two skills: AI Agent (LLM), which makes it conversational, and Email Agent, which enables it for this channel.
- Assign it to the department in Setup → Support channels → Email. It's one agent per department; if a single inbox has to distribute to several areas, that is the job of the triage template.
- Choose the mode. Start in Draft only.
- Test with an email sent from an external inbox, and with another one the agent shouldn't be able to solve.
The email channel is included from the Business plan for human support. For an AI Agent to handle it you need the IA Plus plan; the details are in plans and pricing. The full step-by-step is in the guide Email channel handled by an AI agent, and the one on Inbound email filters covers the edge cases.
If you'd rather not do it alone, our team takes care of it: we build the agent with your policies and your knowledge base, leave it in draft mode on your real email and stay with you until the drafts come out the way you would send them. You can see the channel in detail at AI Agent for email.
The summary
An AI Agent can take the most tedious inbox work off your team: reading, classifying, transcribing receipts, summarizing résumés, answering the repetitive and escalating the rest. For it to work, it has to be designed for the pace of email (everything in a single email, in the same thread), know when a decision isn't its to make, and work on an inbox cleaned of whatever was never an inquiry.
And the way to start is the least spectacular one: with the agent writing drafts nobody receives. A week of reading them tells you more about whether it is ready than any demo.
Frequently asked questions
Can an AI Agent answer customer service email?
Yes. An AI Agent can read every email that reaches a department, answer with the company's policies and knowledge base, tag, escalate to a person what exceeds its authority and archive what is solved. The key is designing it for the pace of email: asking for everything missing in a single email, replying in the same thread and not answering automatic replies.
What is Draft only mode?
It is a working mode of the email channel in which the agent does all its work (tags, routes and captures data) but sends nothing to the customer: it leaves the proposed reply as a draft in a private note, with the Edit, Send and Discard options. It lets you see for a few days what the agent would have answered on real email, risk-free, before switching to Reply.
Does the agent read attachments?
Yes. The accounting template opens the attached receipt and transcribes number, issuer, tax ID, date and amount into the case, and the job applications template summarizes the résumé. The triage agent also classifies by the content of attachments: a scanned invoice goes to accounting even if the body of the email says nothing.
What happens to newsletters and automatic emails?
They are discarded with inbound email filters, before they open a conversation. Filters are per department and built on sender, subject or body. What is discarded isn't saved anywhere, so it's best to start with senders you are certain you don't want. In addition, the agent doesn't reply to system notices or automatic replies, to avoid an endless exchange with another robot.
Do I have to change email providers?
No. Each department has a unique address on the platform and you set up forwarding from the inbox you already use, whether Gmail, Outlook or a corporate server. The original inbox is still yours.
What doesn't the email agent do?
It doesn't approve, confirm payments or make decisions that belong to a person. The accounting template extracts the data from the receipt but doesn't mark it as paid, and the job applications template shortlists without rejecting anyone. Whatever exceeds its authority, like a legal claim or a policy exception, it escalates with the case open.
Keep reading
- The 3 knowledge layers of an AI Agent — where the agent gets what it can state
- AI Agent and human collaborator: the roles in your support — when AI answers and when a person steps in
- Why AI agents fail in customer service — the process mistakes worth avoiding from the start
- Omnichannel customer service — email as one more channel in the same inbox
- Invoices and receipts by email: AI that reads, never pays — the accounting template in depth: "not legible" and invoice fraud
- Classify emails with AI: sort and measure your info@ inbox — the triage template in depth: routing, silence with spam and measurement