Email agent hand-off contract: the plain-Dutch playbook

It's 4:47pm on a Friday in Utrecht. The founder of a twelve-person agency has a tab open with our hand-off contract, a coffee that went cold an hour ago, and a small problem. On Monday morning, an AI agent will start answering email on her domain. She wants to know exactly what she is signing.

So do we. Of the fourteen email agents we have deployed in production, none of them shipped without this document. Not the simple ones that route invoice questions. Not the harder ones that draft replies to journalists. The contract is not there to protect us legally (it does, but barely). It is there because writing it forces us, the client, and the agent itself to be explicit about what kind of authority we are handing over.

This is a walk through what is in that contract, why we wrote it in plain Dutch, and what we changed after agent number eight cost a client a one-week delay on a launch.

What hand-off actually means

When we say "deploy an email agent on your domain," we mean three things at once. The agent has a mailbox of its own, something like agent@client.nl with a real MX record. It has read access to a shared inbox like info@client.nl. And it has authority to write replies, either as drafts a human approves, or as fully automated responses inside a defined scope.

Each of those three privileges has a different blast radius. A misrouted draft is awkward. A wrongly auto-sent reply that contradicts your invoicing terms is expensive. The contract exists to put those blast radii on paper before they become incidents. The hand-off contract is the client-facing version of the same fence that any sensible engineering team would put around an autonomous process: explicit perimeter, named owner, written failure modes.

Article 1, scope of authority

The first article spells out what the agent may write, in what domain, on whose behalf. We use four levels.

• Level 0: reads only. No outbound mail. Used during the first two weeks.
• Level 1: drafts in the human's drafts folder. Outbound requires a manual click.
• Level 2: auto-sends inside a fenced scope (e.g. "questions about invoice status, from existing customers only").
• Level 3: full autonomy inside a topic area. Reserved for agents that have run six weeks at Level 2 with zero corrections.

Most of our deployments live at Level 2 for the entire first year. One is at Level 3. Two are still at Level 1 by client preference. None go from Level 0 to Level 2 in less than four weeks.

This is the article clients spend the most time on. It is also the one where plain Dutch helps. Mag de agent autonoom antwoorden op vragen over factuurstatus van bestaande klanten? is a question someone non-technical can answer.

Article 2, voice

The agent writes in the client's voice, not ours. We capture this with three artifacts: ten real past replies the client wrote themselves, three replies they would never send, and a short paragraph describing the brand's relationship with formality.

An actual clause, lightly anonymised:

"De agent schrijft in jij-vorm, ondertekent met 'Team {Bedrijf}', en gebruikt nooit het woord 'graag'."

Voice clause, client contract, 2026

That last one is real, from a client who has a personal grudge against the word graag. The agent honours it. We test for it in our staging suite before every deploy.

Article 3, escalation

Every agent has at least one human address it can hand off to, and a written list of triggers for doing so. Triggers we have used in production:

• Anything that mentions legal, lawyer, advocaat, klacht.
• A second reply from the same sender within twenty-four hours.
• A sentiment score below a threshold.
• Mentions of kapot, down, or fout in a subject line for the support agent.
• Anything that mentions a competitor by name.

The contract lists the triggers and the human address. It also lists the maximum response time on an escalation, because an agent that escalates silently into a black hole is worse than no agent at all.

Article 4, data access and retention

This is the GDPR article. We list every inbox the agent reads, every CRM table, every file share. We name the legal basis for processing each one. We name how long the agent keeps message bodies in its own logs (default thirty days, redacted after seven). We name what the agent is forbidden to write to its own long-term memory: customer addresses, phone numbers, bank details.

We reference Article 22 of the GDPR on automated decision-making for clients who want to dig into the legal frame. The Dutch DPA has been consistent that complex AI systems do not get a transparency pass just because they are complex. The contract is part of how we stay on the correct side of that file.

Article 5, logging and audit

Every outbound email the agent sends, plus every escalation, plus every silent drop, is written to a structured log the client can read. We provide a one-page dashboard. The contract specifies what the dashboard must show and how long the records are retained.

A single log entry looks like this:

event: outbound_reply
timestamp: 2026-06-02T14:33:09+02:00
to: klant@voorbeeld.nl
in_reply_to: "<abc@voorbeeld.nl>"
authority_level: 2
scope_matched: invoice_status_existing_customer
draft_id: drf_8a92
reviewed_by: null   # null means auto-sent inside scope
content_hash: sha256:c9d3e1...

The contract requires that reviewed_by, scope_matched, and authority_level exist on every entry. When something goes wrong six months from now and someone asks "why did the agent send that," three fields in a log file are the answer.

Article 6, the kill switch

One email address, one shared keyword, one Slack command. Any of them stops the agent within sixty seconds. The contract names who has the authority to pull it, and what happens to in-flight drafts when it is pulled.

We have had the switch triggered once. A founder pulled it because she did not like the way an early reply phrased a refund policy. The agent stopped, the drafts queue surfaced for human review, and we shipped a fix that evening. The contract made that a ninety-second decision instead of a ninety-minute negotiation.

Article 7, who pays when it goes wrong

This is the article our lawyer cares about most and clients care about least. We cap our liability at the value of the engagement. We exclude indirect damages. We carry insurance. We have not had to invoke it.

What clients actually want from this article is a clear answer to one question. If the agent sends a reply that misquotes a price by a factor of ten and the customer holds them to it, who eats the loss? The honest answer is the client does, because the client controls Level 2 scope. The contract makes that explicit so the client tightens the scope before they sign it, not after they get the angry email.

Why plain Dutch

We tried English first. We tried legalese. We landed on plain Dutch (with English versions for international clients) for three reasons.

First, the people who actually have to enforce the contract, the operations manager, the office lead, sometimes the founder herself, are reading on a phone at 8pm. They do not have a lawyer in the chair next to them.

Second, plain language forces precision. De agent mag namens jou herinneringen sturen aan klanten met openstaande facturen onder €5.000 is harder to write than "the agent may pursue collections within defined parameters," but it is vastly harder to misunderstand. Every legalese phrase we replaced surfaced a scope question we had been quietly hand-waving.

Third, plain language is auditable. When a regulator asks how you decided what your agent was allowed to do, you can hand them the document and they can read it.

What we changed after agent number eight

Agent eight was for a media agency that ran weekly editorial newsletters. Our scope clause said the agent could "reply to subscription-related questions." A long-time subscriber wrote in saying she was cancelling because of the agency's editorial position on a political story. The agent replied politely confirming her cancellation. The founder found out a week later when she saw the unsubscribe in the dashboard and went to follow up personally. She was furious. The reply was technically inside scope. It also missed a relationship she had been building for two years.

We added a new clause that week. Every contract since names a list of correspondents, by name, by domain, or by tag in the CRM, who are always escalated, no matter what. We call it the no-agent-ever list. Every client now writes one before we go live. They usually have between three and twenty entries.

The general lesson: scope clauses written in advance always undercover the relationships that matter. Plan for the client's no-agent-ever list and you absorb a category of failure before it happens.

The smallest first step

If you are thinking about putting an agent on your own inbox, write a one-page document before you write any code. Four headings: what it may read, what it may write, who it escalates to, who can turn it off. Show that page to the person who currently answers that inbox. If they cannot sign it, you do not have a contract yet. You have a wish.

When we built the customer-support email agent for a Dutch payments client, the thing that actually saved them three weeks of back-and-forth was the no-agent-ever list, not the model. If you want to see how the seven-article version reads in production, our work on AI agents is a good place to start.