Your Agent’s First Email Workflow: An Inquiry With a Human Handoff

A useful first email job for an AI agent is small enough that a person can tell whether it was done well. “Handle our inbox” leaves too many decisions unstated. “Help a customer understand our published setup options, then pass a request for a commitment to a person” gives the team a workflow it can inspect.

I would start with a customer inquiry because it includes more than generating a message. Someone asks a question, the agent needs an approved source, the business may need to review the answer, and the next reply can change what should happen. That is enough to learn something useful without turning the first project into an entire sales operation.

The example below is a proposed pilot. It is not a report of a customer deployment or a claim that Mailrun supplies the business rules, approvals, or handoff process described here.

Write the Assignment Before Connecting the Agent

Imagine a service business that publishes a short guide to its setup options. The agent's assignment is to explain those options using that guide and collect the information a human needs for the next step. It cannot offer a discount, promise a start date, or amend an agreement.

Put the assignment on one page:

These are design choices for this example. The application needs to implement them; putting them in a prompt does not establish an enforced approval step.

Keep the source set small and relevant to the role. For a rehearsal, use invented business details and correspondence. For real work, the information owner should approve what the agent can access. An entire shared drive is not a sensible default just because the agent can search it.

Understand the Path an Email Takes

In Mailrun's bring-your-own-agent model, Mailrun provides the communication identity and your application runs the agent. The developer docs describe both HTTP API and MCP connections. Those are ways to connect the tools; neither decides your business policy or supplies your approved answers.

The same docs describe notifications when mail arrives. The application then retrieves the message through authorized access. In that arrangement, receiving a notification and preparing a response are separate steps. The application still needs to connect the incoming message to the relevant conversation and decide what work is allowed.

For the proposed pilot, I would have the application present the original question, the proposed answer, and the supporting passage together for a person to review. Keep the reviewed recipients and content tied to the send decision. The reviewer should not need to guess which source the agent used or whether a saved draft changed after approval.

Mail transport is another distinct step. An SMTP server's successful acceptance of message data transfers responsibility for delivery or relay; it does not show that a person read the answer. RFC 5321, Section 6.1 explains that handoff. For an API connection, use its documented response meaning. In a rehearsal, check the controlled recipient mailbox separately from the application's submission record.

Rehearse Three Ordinary Questions

Use mailboxes your team controls or has explicit permission to test. Agree in advance on who may approve a test send and where it can go. Then walk through a few invented inquiries that exercise different parts of the job.

A question the guide answers. Ask which setup options are available. The proposed reply should accurately reflect the current guide, without adding a promise about timing or suitability that the guide does not make. The reviewer should be able to locate the supporting passage easily.

A question the guide does not answer. Ask for a special arrangement that is absent from the source. A useful result identifies what is missing and prepares a handoff. It does not fill the gap with a plausible policy or send a confident answer merely to finish the task.

A request that needs a commitment. Ask whether the business will guarantee a start date. Even if the agent can find a general planning note, this example reserves commitments for a person. Check that the proposed handoff preserves the actual request and reaches the responsible person.

An incoming message can ask for an exception, but it cannot rewrite the agent's assignment. Treat its text as correspondence to evaluate, including when it claims that someone has already approved a change. Confirm any authority through the business's trusted process. Microsoft's guidance on agent access and tool controls is a useful reference for the implementer responsible for enforcing those boundaries.

Make the Handoff Useful to the Person Receiving It

A handoff that says “needs human review” leaves the next person to reconstruct the work. For the start-date request, include the original question, the relevant conversation, what the approved information does and does not establish, and the decision needed.

Keep that packet inside the authorized workflow and include only what the recipient needs. Do not copy mailbox credentials or unrelated conversations into a ticket or chat message. Name the person or team receiving the handoff and record that they accepted it. In this pilot, creating a notification alone does not count as completing the task.

The workflow also needs to know when the person takes over. I would pause the agent's outbound work on that conversation until the human owner explicitly returns it. Otherwise, a helpful human reply and an already prepared agent reply could compete. Ask the implementer to demonstrate how the application records that ownership change, including any waiting work.

For the human recipient, the aim is a clear next action: answer the specific question, ask for missing information, or explain that the business cannot make the requested commitment.

Decide What You Learned Before Adding Another Job

After the rehearsal, read each conversation from arrival through its final disposition. Record whether the answer was supported, whether the reviewer needed to correct it, whether the message reached the controlled mailbox, and whether a handoff had an accepted owner. Keep unresolved cases visible rather than counting them as completed work.

A successful rehearsal supports a decision about this workflow under these conditions. It does not demonstrate autonomous operation across the rest of the inbox. Before introducing real correspondence, also check the separate email-permission tests and the handling of automated replies and delivery reports.

For a first Mailrun evaluation, start from the Free option in Agent Identity checkout, confirm the current package inclusions, and connect the agent you intend to use. This email exercise does not assume a phone number, custom domain, or a particular sending allowance.

Choose the next expansion from the cases you observed. You might improve the setup guide, clarify who accepts handoffs, or add another well-defined question the agent can help with. That gives the project a reason to grow based on useful work, rather than the number of messages the agent can produce.