Who Should Get Autopilot? Setting an Email Autonomy Policy

Who should get AI email Autopilot access is the one policy question that decides whether the technology pays off or blows up in the first quarter. Autopilot — the mode where an AI agent sends email under your identity without a human clicking send — is a real operational lever, hours back per person per week. It is also a real hazard, because a bad send to a customer cannot be recalled from their inbox. This guide is a decision framework so that the answer is a policy, not a temperament.

The right answer is not seniority, not a founder's vote of confidence, and not an org-wide toggle. It is a per-user, per-message-type promotion based on role risk, reversibility, tenure, and a demonstrated approval-accuracy threshold — with an immutable audit log, per-action undo, and a defined rollback in place before the first user graduates. Everyone starts in Copilot. No one earns the lift for the whole inbox at once.

The short answer#

Four criteria decide whether a specific person should be allowed to let the agent send under their identity, on a specific class of message. Use them together — no single one is enough on its own — and apply them per message type, because the same person can be safe on internal replies and not yet safe on customer-facing threads.

• Role and mailbox risk. What is the worst outcome of a wrong send from this inbox? A support reply that misquotes a policy is a bad day. A misworded reply from a legal, finance, HR or executive-signature inbox is a lawsuit, a regulatory letter, or a story on the internet. High-risk mailboxes do not graduate the highest-risk message types, ever.
• Message-type reversibility. Internal replies to a teammate are cheap to correct. External sends to first-time correspondents, bulk sends, replies containing commitments, invoices, contracts, and anything to a regulated recipient are one-way doors. Autopilot goes to reversible classes first, one-way doors last (or never).
• Tenure and system familiarity. A user who has been in Copilot for at least a few weeks — who has corrected a bad draft, used undo, and read their own audit trail — understands what the agent does with their context. A brand-new hire has not, and their first weeks are exactly when the agent's Personal Context brain is still empty.
• Demonstrated approval accuracy. The agent's Copilot behaviour is measurable per user, per message class: how often the user accepts drafts as-drafted, edits lightly, rewrites heavily, or rejects outright. A user whose accepted-with-light-edits rate on a class of message is high and stable over a rolling two-week window has earned the promotion for that class — and only that class.

Criteria that actually matter#

Every autonomy policy that survives a year applies the same four filters, in this order. Skipping any of them is how teams end up either paralysed by review or embarrassed by a send they cannot recall.

Role and mailbox risk decides which mailboxes are eligible at all. A shared support@ mailbox handling refund requests within a documented policy is a low-risk candidate. A finance@ mailbox that sends invoices, or a legal@ mailbox that references active matters, is not — regardless of tenure or approval history. Some inboxes are structurally wrong for autonomous send and staying honest about that is what keeps the rest of the policy trusted.

Reversibility decides which message types graduate first. An internal reply to a teammate that turns out wrong gets a two-line correction and no one is upset. An external reply that commits to a price, a deadline, or a scope reaches a customer's mailbox and, from that moment, is a fact about your company. Autopilot belongs on reversible classes early, on external-but-routine classes middle, and on commitments and first-time correspondents late or never. This is why a single org-wide toggle is the wrong shape of control.

Tenure and approval accuracy work together. Tenure without measurement is folklore — a user has been here six months, so they must be safe. Measurement without tenure is misleading — a new hire looks accurate for two weeks because they have not yet touched the messages that stress the agent's context. Require both: weeks in Copilot with a stable, high accepted-as-drafted rate on the specific class you are promoting.

Scoring table: who graduates, and to what#

The table below turns the four criteria into a per-person, per-message-type score. Run it once per user per class — internal replies, routine external replies, high-stakes external replies — and only promote when all four filters clear. The point of the scoring is not the sum; it is that every column has to pass on its own. A stellar approval rate does not compensate for a regulated mailbox.

Read the table as a checklist, not a rubric to average. Autopilot is a permission, and permissions do not average — a user either has the standing to send a class of message under agent authorship or they do not. The scoring makes the reasoning explicit so a manager can point to why a person got the lift and why a specific class stayed in Copilot.

Worked example: a 25-person team, six weeks in#

A concrete pass through the criteria makes the sequence real. Picture a 25-person company on a mix of Google Workspace and Microsoft 365 mailboxes, six weeks after the rollout, with everyone still in Copilot by default. The head of operations owns the promotion decision. Here is what they graduate, what they hold, and what they never touch.

1. 1

   Confirm the preconditions before promoting anyone

   Verify undo is on, the audit log is exported to the security team's log store, the rollback runbook exists, and the offboarding hook revokes tokens on separation. If any one of these is missing, no promotions this week — configure and try again next cycle.

2. 2

   Sales AEs: promote internal replies only

   Three account executives have four to six weeks in Copilot with a high accepted-as-drafted rate on internal Slack-style replies to teammates about calendar and CRM updates. Promote them to Autopilot on the internal-reply class alone. External replies to prospects stay Copilot, because a commitment on price or scope in a customer's mailbox is a one-way door.

3. 3

   Support: promote acknowledgements and routine triage replies

   Two support engineers have consistent Copilot accuracy on acknowledgement replies ("we've got this, expect an update by X") and routine triage responses drawn from the documented policy. Promote on those two classes. Any reply containing a refund, credit or SLA commitment stays Copilot with a required approval, no exceptions.

4. 4

   Ops / EA: promote scheduling and confirmations

   One executive assistant has weeks of high accuracy on scheduling and meeting-confirmation replies. Promote on that class. The exec's mailbox itself stays Copilot for anything the assistant cannot pre-authorise — the standard is not the assistant's accuracy, it is the mailbox's downstream reach.

5. 5

   Finance, legal, HR and the founder inbox: no Autopilot, any class

   These mailboxes never receive Autopilot on customer-facing classes in the first year. The failure mode is not "the agent looked awkward"; it is "the agent committed to a number, a policy, or a promise that survives in an inbox we cannot reach." Copilot with mandatory approval stays the model here, indefinitely.

6. 6

   Publish the list and the reasoning

   Post the promotion decisions somewhere the team can see — who, which class, why. This is not surveillance; it is the paper trail that stops the next argument being "why does she have Autopilot and I don't?" Every promotion has a written reason and every non-promotion has a written path to earning it.

7. 7

   Re-score every fortnight for the first quarter

   Run the scoring table again every two weeks. Some users' accuracy drifts; some message classes turn out to be higher-consequence than they looked; the agent's context grows. A rolling review keeps the policy honest as the situation changes, and it is the cheapest incident prevention on offer.

The point of the example is not the specific classes — those depend on your business. The point is that the promotion decision is per person, per class, published, and reviewed. That shape survives a year. "We turned Autopilot on for the team" does not.

Red flags that mean the person is not ready — or the class is not#

Some patterns look like edge cases in the first month and turn out to be the shape of the whole risk. If any of these apply, do not promote — no matter how senior the person or how much they want it. The right answer is to hold and revisit, not to override.

• The user rejects or heavily rewrites the same class of draft repeatedly. This is a signal the agent has not learned that class from their Personal Context yet, not a signal to send unattended.
• The mailbox handles regulated content — health, financial advice, legal matters, employment decisions — and the class being promoted touches any of it. Regulated mail is not a place to discover an edge case.
• The user is inside their first 30 days at the company, or has just changed roles. Tenure at the company matters less than tenure in the role whose context the agent is meant to reflect.
• The team lacks a rollback plan. If you cannot describe, in one sentence, what happens the moment an autonomous send goes wrong, you are not ready to graduate anyone. Undo the message; freeze the mode; open the audit trail; notify the recipient if warranted.
• The vendor does not offer per-action undo or an exportable audit log. This is a product-shape problem, not a permission problem — and no amount of policy compensates for a missing control.
• There is pressure to promote the whole team on one date so "the AI rollout ships." A launch date is a marketing artifact; a permission policy is not. Promote in cohorts as accuracy earns it, not in a wave that suits the calendar.
• The user asks for Autopilot because approving drafts is tedious, not because their pattern is stable. Copilot fatigue is real and worth solving — but the solution is faster keyboard flow and better drafting, not skipping the human on messages that have not yet earned it.

None of these red flags is a permanent disqualifier. They are all reasons to hold this cycle and revisit next cycle. The written promotion path — what a person needs to do to earn Autopilot on a specific class — is the useful artifact; it turns "not yet" from a rejection into a plan.

What we'd pick and why (honest)#

Disclosure before the recommendation: we build AI Emaily, so read this section knowing we sell the tool we are about to describe. The concession further down names where a different shape of tool is the better fit — an argument that concedes nothing is one you should discount.

For a team that wants the four-filter policy above to be enforceable at the product level, AI Emaily is the tool we would pick, and here is exactly which reader we are right for. Every user starts in Manual or Copilot (approve-before-send). Autopilot is a gated, per-user, per-scope opt-in — not a global toggle — with per-action undo, an immutable audit log, and a defined rollback. There is no training on user mail with the model providers we route through. Autopilot's exact scope and coverage are what we ship today and what we are actively expanding; the honest way to describe it is that the trust ladder — Manual, Copilot, gated Autopilot — is real and shipping, and the range of message types you can safely delegate widens as we harden each class. If that ladder matches how you want to run the rollout, the AI Emaily homepage explains the model and pricing is a seven-day free trial on Pro or Autopilot (card required, $0 if cancelled before day seven) — no permanent free tier, and the trial is not per-seat on the Team plan.

Where we are not the tighter choice, said plainly: if your policy is "a human clicks send every time, on every message, without exception, forever," then a tool whose product shape has no autonomous-send mode at all removes the temptation from the design. A drafting-only assistant — one that writes suggestions inside a client that never sends autonomously — enforces that policy at the architectural level rather than trusting a toggle. Superhuman's AI assistant is closer to that model. We ship both approve-first and gated Autopilot, deliberately, because we think the ladder is the right shape for most teams. If yours is the team that will never want the top rung, a client that does not build the top rung is the more honest match.

For the team in between — the ten-to-two-hundred-person company that wants a real ladder rather than a binary, with the four-filter policy above enforced in the admin panel and not in a spreadsheet — the shape we built AI Emaily around is the shape this guide describes. Start everyone in Copilot, promote per user per class as the criteria earn it, and keep the audit trail and rollback ready before the first graduation, not after the first incident.