AI writes the reply. You make the call.

A customer needs Order #4817 by Friday. The AI drafts a calm, polished reply promising exactly that — but nobody has confirmed when it will arrive. Good wording can't substitute for a verified fact or a person with authority to make a promise. Try the inbox example below, then follow the draft, review and escalation steps through the rest of the guide.

What "AI Email Reply" Actually Means (and What It Doesn't)

The phrase gets used for at least three different things, and conflating them causes real problems.

A generator is a one-shot tool: paste in a message, get a suggested reply, copy it into your email client. An AI email response generator is useful for occasional drafting but has no memory of your inbox, your customer history, or your tone.

A reply assistant is a step further — a sidebar or plugin that suggests drafts while you're in your inbox. Still requires you to open every email and evaluate every suggestion manually.

An agent is different in kind. It lives inside your email workflow. It reads inbound messages as they arrive, retrieves relevant context (past threads, CRM records, invoice status), writes a draft reply anchored to that context, presents the draft for human approval, and then either sends it or escalates based on what you decide. Automatic email reply approval becomes a workflow, not an afterthought.

This article is about the third kind. The useful part is not the writing — it's the reading, the routing, and the guardrail.

How the Draft–Approve–Send Loop Works

Here is the sequence traced step by step through a fictional support scenario.

Step 1: The agent reads the thread

A message arrives: "Hi, this is Marcus at Thornfield Supply. We placed order #4817 two weeks ago and still haven't received a shipping update. We need this by Friday or we'll have to cancel."

The agent doesn't read this email in isolation. It reads the thread history, checks whether order #4817 appears in connected systems, and notes the tone — deadline pressure, cancellation threat. Under the hood, this is the Gmail API's thread ID and In-Reply-To header doing the work. The agent retrieves the full thread, not just the latest message, so it can write a reply that fits the conversation rather than starting cold. The Gmail API guide to creating and sending drafts documents how replies attach to existing threads using RFC 2822 References and In-Reply-To headers — a technical requirement, not just a courtesy.

Step 2: The agent drafts a reply

Using a language model — in 2026 this means something built on the OpenAI Responses API, since the Assistants API was sunset on August 26, 2026 — the agent composes a draft that references the actual order, acknowledges the deadline, and proposes a specific next step.

A fictional draft might look like this:

To: marcus@thornfieldsupply.example
Subject: Re: Order #4817 — shipping update

Hi Marcus,

Thanks for following up. I can see order #4817 from two weeks ago. I'm checking current shipping status and will have a confirmed update to you by end of business today. If we can't meet Friday I'll let you know immediately so you can make alternate arrangements.

I've flagged this internally as urgent.

[Your name]

Note what the draft does not do: it doesn't promise Friday delivery, invent a tracking number, or apologise on behalf of a logistics partner. Those would require facts the agent hasn't confirmed. The draft holds space for a human to verify before anything goes out.

Step 3: The draft surfaces for human review

This is the architectural decision that separates a useful agent from a liability. The draft appears in Slack as a card with three options:

• Approve & send — the agent calls drafts.send via the Gmail API, the draft is transmitted and automatically deleted from the drafts folder, and a sent message is created with a new message ID
• Edit in Gmail — the agent writes the draft to the inbox using drafts.create, the reviewer opens it, edits freely, and sends manually
• Escalate — the draft is discarded, the thread is flagged to a named person, and the agent attempts no further reply

The Gmail API documentation is explicit on the mechanics: a draft cannot be edited once created but can be replaced; when drafts.send is called, the draft is deleted and a new sent message is created. The human approval step isn't just a safety promise — it's enforced by the architecture. The agent cannot send without calling that endpoint, and that call requires a deliberate human action.

Step 4: Escalation paths for sensitive threads

Not every email should reach the draft stage. A well-built agent has routing rules that short-circuit the loop and send the thread directly to a person without attempting a reply.

Common escalation triggers:

• Legal language — "dispute," "solicitor," "claim," "liability"
• Missing context — order reference not found in any connected system
• Tone signals — explicit threat to go public, or repeated contact after a previous resolution
• Categories you define — anything from a named account tier, a complaint category, or a VIP sender list

When escalation fires, the agent posts a flag in Slack: "Thread from Marcus at Thornfield Supply contains a cancellation threat and an unresolved order reference. No draft prepared. Assigned to [name]." Then it stops. It doesn't try a simpler reply. It doesn't fire a holding message. Silence and a flag are the correct output here.

Splice Work's finance agent uses the same principle on payment emails: if it cannot read payment status, it sends nothing and flags the row rather than drafting from stale data. The finance agent page describes this as a design decision, not a setting — the agent is structurally incapable of guessing when the data isn't there.

Tone Controls: What You Set, What the Agent Follows

A reasonable concern is that AI-drafted replies will sound like AI-drafted replies. Tone is configurable, but the configuration has to be deliberate.

You can specify:

• Formality level — brief and direct vs. warm and explanatory
• Signature and sign-off style — exactly as your team writes them
• Topics the agent never addresses — pricing negotiation, refund amounts, delivery guarantees
• Length constraint — one paragraph maximum, or a structured reply with numbered steps

The agent follows those rules in every draft. What it can't replicate without instruction is your specific voice on an edge case it has never encountered — which is exactly why Edit in Gmail is always available, and why the approve/escalate decision stays with a person.

What Stays With a Person

This is worth being explicit about, because the automation often gets oversold.

The agent handles: reading threads at scale, retrieving context from connected systems, drafting replies to predictable categories of email, routing to the right decision point, and logging every action.

A person handles: deciding whether a draft is accurate before it sends, writing replies to threads outside the agent's defined scope, resolving disputes, negotiating anything, and owning the customer relationship.

The AI for repetitive tasks post on the Splice Work blog makes a useful point about approval rules: Beep Beep (Splice Work's outbound email agent) uses campaign-level approval, while the finance agent requires approval for each individual send. The right rule depends on the workflow, and it should be written down before the build starts.

For an inbound reply agent, you might set:

• One approval per reply for anything customer-facing
• Auto-send allowed for internal digests or notification-only messages
• Escalate always for threads matching defined keywords or sender categories

Those rules belong in the agent's documented instructions, not buried in code where nobody can audit them.

One important boundary to be clear about: Beep Beep handles outbound prospecting campaigns and flags interested replies for a human to take over — it doesn't manage inbound email replies. When someone replies with interest, Beep Beep posts the conversation in Slack and hands off. It doesn't negotiate, price, or continue a human conversation on your behalf. That distinction matters when you're thinking about what "AI email reply" covers and where your own build needs to start.

A Review Checklist Before You Approve Any Draft

Run through these before clicking Send:

• Does the draft reference the actual thread, or does it read like a generic response?
• Are any facts (order numbers, amounts, dates) confirmed in a connected system?
• Does the tone match what you would write to this specific customer?
• Are there commitments in the draft you're not ready to make?
• Did the draft miss anything the thread raised?
• Should this have been escalated rather than drafted?

If you're correcting more than one or two issues per batch, the agent's instructions or context retrieval need adjustment — not the approval step itself.

Exercise: Map Your Own Inbox

Pick one category of email your team handles repeatedly — support questions, invoice inquiries, booking requests. Write down:

1. What information the agent would need before drafting (thread history, CRM record, payment status, open orders)
2. What a good reply looks like in the normal case — write a fictional example yourself, the way you'd actually send it
3. What would make you escalate instead of draft — name three specific triggers
4. Who receives the escalation flag and what they do next

That four-item list is the core of an agent's instructions. If you can write it clearly, the workflow can be built around it. If you can't, the ambiguity will surface in the agent's output rather than in your planning.

Before/After: Context-Blind vs. Context-Aware

Here is the same inbound email handled two ways. The input is the Marcus message from earlier.

Without context retrieval (generator-style output):

Hi Marcus, thanks for your email. We've received your inquiry and will look into it shortly. Our team will be in touch within 2–3 business days.

Nothing in that reply shows the agent read the message. It doesn't reference order #4817, acknowledge the Friday deadline, or indicate any urgency has been registered. A customer who reads this assumes they've been added to a queue.

With context retrieval (agent-style output, held for approval):

Hi Marcus, I can see order #4817 placed two weeks ago. I'm checking current status now and will have a confirmed shipping update to you by end of business today. If Friday is at risk I'll let you know immediately so you're not left waiting.

The second draft cost the same amount of compute. The difference is that the agent read the thread, retrieved the order reference, and reflected the actual situation back to the customer — then held the draft until a human confirmed the facts were right before it went out.

That's what the approve step is for. Not to slow things down, but to catch the moment where "order #4817 confirmed" turns out to mean "no record found" and the draft needs to become an escalation instead.

Where Custom AI Solutions Fits

The draft–approve–send loop described here is the kind of workflow Custom AI Solutions is built to deliver.

The problem: your team handles a predictable category of inbound email, and you want an agent that reads the thread, retrieves context from your connected systems, drafts a reply, holds it for a human decision, escalates sensitive threads, and logs every action — without you building the infrastructure.

What the Custom AI Solutions page describes, based on verified content: agents that "read what arrives (a call, an email, a PDF, a Salesforce record), decide what to do, and act through the systems' APIs"; an approval step in Slack or email before anything customer-facing goes out; a full audit trail; connectors to Gmail, Slack, Salesforce, and others; and source code and credentials owned by the customer at the end. (splicework.ai/services/custom-ai-solutions/)

What stays with a person: every send decision, escalation judgment, and anything outside the agent's defined scope. This is a bespoke build scoped per engagement, not a self-serve product you activate.

If you want to describe the inbox workflow you're thinking about, the contact page asks you to describe the job the way you'd describe it to a new hire: which system it starts in, where it should end up, who does it today. That framing tends to surface the approval rules and escalation triggers before the build starts — which is exactly where they belong.

The point isn't to automate Marcus's email so nobody has to think about it. It's to make sure Marcus gets a reply that read his actual message, that a human verified before it went out, and that the agent handled the forty other Marcus-shaped emails in the queue while your team focused on the three that genuinely needed judgment.