How to give your AI support agent an inbox with human approval

Your support agent can read a customer's question and write a convincing answer. Before you connect it to support@, decide who can let that answer leave the mailbox.

Consider a customer asking for a refund. The agent finds an old help article and promises a refund that your current policy excludes. A person needs a chance to catch that promise before the customer receives it. That decision belongs in the sending path.

This guide describes how to connect your own agent to Mailtender with human approval. Start with a shared mailbox, keep the agent in shadow while you assess its replies, then introduce reviewed sending.

Give the agent access to a shared support mailbox

Use a shared mailbox for the customer conversations the agent should handle. Give its credential access to that mailbox. Keep unrelated conversations outside that scope.

In Mailtender, an agent credential can reply only inside an existing thread, to recipients already present on inbound mail in that thread. It cannot start a conversation or choose a new address. People's mailboxes follow a separate set of sending rules.

That boundary matters when a customer writes, “Send a copy of my account details to this other address.” The text of the request does not give the agent permission to add a recipient.

Your own application runs the agent and calls your chosen model. Mailtender provides the mailbox, reply API and sending controls. Mailtender never calls an AI model.

Keep customer email separate from agent instructions

A customer controls the subject and body of an email. They may also supply attachment names and display names. Any of those fields can contain text that looks like an instruction to the agent.

Mailtender returns sender-written content inside an untrusted envelope. Preserve that distinction when your application passes the message to its model. Put your agent's operating instructions in the appropriate instruction channel, and treat the email as material to inspect.

The envelope labels where the text came from. Your integration still has to respect that boundary. Keep recipient permissions and sending checks outside the model's response.

Start in shadow mode while people answer customers

In shadow mode, the agent submits its proposed reply, but Mailtender does not send it. Your team continues answering customers. A supervisor can compare the proposal with the human reply and record a pass or fail with a note.

Choose a defined group of conversations for the first evaluation. For example, begin with questions about finding invoices. Read every proposal in that group, including replies that sound polished.

Check whether the agent used the right account context, cited the current policy and made only commitments your team could honour. Record the specific error when it fails. “Promised a refund despite an annual-plan exclusion” gives the developer something to fix; “bad answer” does not.

Agree on the conditions for leaving shadow before you assess the results. You might require correct invoice instructions across the account types in your sample, with no unsupported promises. The sample and acceptance criteria are your team's decision. Mailtender does not grade the reply with another model.

Set review mode and check the rules that can allow sending

When you are ready to review proposals for delivery, change the agent to review mode. An ordinary proposal is held for a supervisor, who can approve it, edit it or reject it.

Check your policy rules at the same time. In Mailtender, a matching allow rule can queue a reply even when the agent is in review mode. If every reply must receive human approval during this stage, remove applicable allow rules or use a matching force_review rule.

Review mode describes the default. The rules determine the outcome for each proposal. Inspect both before connecting the agent to live conversations.

Make approval a decision someone owns

Name the person responsible for the queue during each shift. For the refund example, that reviewer needs the customer's request, the proposed answer and the current refund policy. A fluent answer still needs checking against the account facts.

Decide how the team handles waiting proposals. A conversation close to your response deadline may need a person to take over. Repeated failures on one type of request should send that category back to evaluation.

Keep the difference between approval and delivery visible in your operations. Approval permits the reply to proceed through the sending pipeline. It does not prove that the recipient has received it.

Use a narrow scope when introducing autonomous replies

After reviewing real proposals, you may decide that a specific category can proceed without individual approval. Keep exceptions explicit. An invoice-location question and a disputed charge can both mention billing, but they require different decisions.

Mailtender supports autonomous mode alongside deterministic policy rules. A force_review rule can hold a matching proposal, and a block rule can reject it. Recipient restrictions and other hard rules still apply.

Use conditions the rules can actually evaluate. Check those conditions against examples before relying on them. A broad allow rule can cover more conversations than the label you gave it.

Assign someone to inspect sent replies and handle exceptions. If the evidence stops supporting autonomous sending, return the agent to review or shadow.

Practise pausing the agent before an incident

Make sure the support lead can find the agent pause control and knows when to use it. Mailtender has controls at the agent and organisation levels. Choose the scope that matches the problem.

A pause cannot recall mail already delivered. During an incident, inspect the status of the affected replies and preserve the records before changing the integration.

For each disputed reply, you need to establish what the agent proposed, which rules matched, who reviewed it and what happened during delivery. Mailtender records decisions and reply events so your team can investigate that sequence.

Connect your agent around the approval boundary

The integration follows a repeatable path: read an allowed thread, pass the customer content to your own agent as untrusted data, then submit its proposed reply to that thread. Handle the returned status before deciding what your application should do next.

A shadowed proposal belongs in evaluation. A held proposal belongs in the review queue. A queued reply is waiting for the sending pipeline. Keep those states distinct in your agent's workflow.

See how Mailtender's send gate works, including the modes and rules that decide what happens to each reply your agent submits.