Keep send_email out of your agent tool policies
The structural argument for draft-only email pipelines: every viable MCP path supports a draft-only tool policy, so the agent's tool policy should explicitly exclude send tools. The human-from-Drafts-folder loop becomes structurally enforced, not policy-on-paper. Principle post applicable to any Auxot agent that produces email content.
Plus: the case for why every email-drafting MCP path (Gmail official, Composio Outlook, Pipedream Gmail) should be wired without send tools enabled. Cross-cuts the three email tutorials and the content-review pipeline.
| Audience | Admins · Developers · Everyone |
|---|---|
| Time | ~5 min |
| Prerequisites | Familiarity with [Define a tool policy](/tutorials/define-a-tool-policy) and the agent-tool-call model. Helpful but not required: the platform-specific tutorials ([Wire Gmail drafts through Google's official MCP](/tutorials/wire-gmail-drafts-through-googles-official-mcp), [Lock Outlook drafts via a draft-only tool policy](/tutorials/lock-outlook-drafts-via-a-draft-only-tool-policy)). |
| You'll end up with | A clear principle for any email-producing agent: the tool policy excludes send tools by design; the human reviews the draft in the mail client and clicks send. Applied consistently across every Auxot email workflow. |
When a tutorial shows italic text in quotation marks, it usually mirrors a label or helper string inside Auxot. Product copy changes between releases — if something reads differently in your workspace, trust what you see on screen.
Callouts with a Worth knowing gold accent are meant as must-read context before you move on. Blockquotes that open with Tip are lighter, optional depth.
Why this matters
The argument for letting agents send email autonomously is “the human reviews everything anyway, so what’s the difference between draft-and-click-send and send-and-recall?” The argument against is the asymmetry of the failure: a wrong draft is a non-event (the human deletes it before clicking send); a wrong send is a customer-facing incident that requires apology, escalation, and a careful review of what other emails the agent might have shipped.
Every viable Auxot email-drafting MCP path supports a draft-only tool policy. Google’s official Gmail MCP does not request the send scope at all. Composio Outlook exposes send tools but the policy excludes them. Pipedream Gmail and other community wrappers expose mixed surfaces; the policy still constrains them. There is no MCP path where draft-only is impossible.
The principle: the structural gap between “agent finished” and “email goes out” should be load-bearing in the design, not load-bearing only in the human’s memory of “I should review the draft before sending.” Drafts-folder review is structural because the email cannot leave the Drafts folder without a manual send. Send-with-review is procedural; it works until the day someone forgets.
This is the cross-cutting principle behind the platform-specific tutorials. The structure is the same regardless of MCP.
Nothing ships from Drafts: you read, you send.
The principle
Send tools have asymmetric failure modes
The cost of a wrong draft: zero. The cost of a wrong send: a customer-facing incident. The asymmetry is structural, not statistical. Even a perfect agent would still create wrong drafts occasionally; the question is whether those wrong drafts become wrong sends.
Every MCP path supports the draft-only constraint
There is no email MCP in May 2026 where draft-only is technically impossible. Google’s official Gmail MCP does not include send scope. Composio Outlook supports send but allows policy-level exclusion. Pipedream Gmail similarly exposes the surface and accepts policy constraints. The constraint is always available; the question is whether the team configures it.
The Drafts folder is the structural review gate
A draft in Drafts requires a manual send to leave. The user opens the mail client, reviews the draft, clicks send. The mail client is doing the gate-keeping; Auxot does not need to add a human-step on top. The gate is the natural one the user already knows.
Policy excludes send tools by name AND by parameter
Some MCPs expose a single tool that handles both draft and send via a send-now parameter. The policy must constrain the parameter shape, not just the tool name. Otherwise the agent has a path to send by setting a flag.
The principle survives MCP swaps
If a team migrates from Composio Outlook to a future Microsoft first-party MCP, or from Google’s official Gmail MCP to a community wrapper, the policy discipline is the same: exclude send tools by name; constrain send-flag parameters. The wiring changes; the constraint does not.
Go deeper
The “but what about quick replies?” objection
The classic objection: “I want the agent to handle simple replies (acknowledgments, scheduling confirmations, declines) autonomously because reviewing every draft is friction.” The response: the asymmetric failure cost applies even to simple replies. A wrong autonomous reply to a high-stakes lead, a customer’s spouse who emailed about a death in the family, a journalist asking for comment, is the same incident as a wrong autonomous reply to a routine prospect. The volume math (1% of replies cause incidents) does not work when the incident is unrecoverable.
The right answer for high-volume reply work is to make the draft-and-send loop faster, not to remove the human step. A Slack ping when a draft is ready, a one-key shortcut in the mail client to send, a daily batch-review at a fixed time. The discipline is “human always sends” with the friction reduced; not “the agent sends when confidence is high.”
The “what if the agent confidence is 99%” objection
Agent confidence is not calibrated against the failure cost. A 99%-confident agent that sends 1000 emails per day produces 10 wrong sends per day. If even one of those is a customer-facing incident, the team is doing customer apology work daily. The confidence number is doing nothing for the asymmetric-cost problem; the structural gate is.
The “but my CRM also has a send-email tool” extension
CRMs (Salesforce, HubSpot, Pipedrive) often expose send-email tools as part of their MCP surface. The same principle applies. The CRM-side tool policy should exclude send-email tools; the agent uses the CRM to draft activity notes (see Lock CRM writes to a single custom field), not to send email directly. The customer-facing email path goes through the dedicated email MCP (Gmail or Outlook) with the draft-only policy; CRM is for the system-of-record write, not for outbound communication.
The “what about scheduled sends” question
Scheduled sends (the agent drafts a send-at-2pm-tomorrow message) are still sends from the policy’s perspective. A scheduled send leaves Drafts at 2pm tomorrow without human intervention; the structural gate is gone. Treat scheduled sends as a separate category and exclude them from the agent’s tool policy. If the team needs scheduled mail, use a human-driven scheduling workflow (the human reviews the draft, schedules from the mail client) rather than wiring schedule-send into the agent.
The “approval queue inside Auxot” alternative
Some teams ask: “instead of draft-only, can I add an Auxot human-step that gates sends?” The answer is yes, technically; in practice, the Drafts-folder review is more reliable. The Auxot human-step is a separate UI to monitor, a separate notification stream, a separate inbox of pending approvals. The user’s mail client is where the user already lives. Routing the review through Drafts uses an existing habit; routing it through an Auxot queue adds a new habit. Habits are load-bearing in this kind of pattern.
When the principle relaxes
Internal-only email to the same Auxot user (the agent drafts a summary to the user’s own address; technically a send, practically a self-message) is a degenerate case where the asymmetric failure cost does not apply, the worst outcome is the user’s inbox getting a duplicate. Even in this case, the discipline is worth preserving for consistency: the user reads the summary in their normal inbox-review flow, not in a separate Auxot panel.
What’s next
- → Wire Gmail drafts through Google’s official MCP. The Gmail-side application of this principle.
- → Lock Outlook drafts via a draft-only tool policy. The Outlook-side application, where the policy is more load-bearing because Composio Outlook exposes send tools.
- → Set up your Monday morning briefing. A daily briefing that drafts and waits for human send.
- → Triage and follow up on inbound leads. Lead replies on the draft-only path.
- → Set up a content review pipeline. Content review that lands social posts in Buffer’s queue and email drafts in Gmail Drafts.
- → Define a tool policy. The mechanism that makes the send-exclusion structural.
Reference
- The principle: every email-producing agent should have send tools excluded from its tool policy. The structural review gate is the Drafts folder, not an Auxot human-step.
- The asymmetric failure cost: wrong drafts cost nothing; wrong sends cost customer incidents. Volume math fails when the incident is unrecoverable.
- MCP path coverage: Google’s official Gmail MCP (no send scope by design), Composio Outlook (send tools blocked by policy), Pipedream Gmail / other wrappers (send tools blocked by policy and send-flag parameters constrained). No MCP forces send.
- Policy mechanics: exclude tools by name (any tool with “send”); constrain parameters (any draft tool that accepts a send-flag must reject the flag).
- Cross-system reach: the same principle applies to CRM-side send tools, scheduled sends, and any other path that ships email without a human click.
- Where this principle relaxes: internal self-messages where the failure cost is zero. Preserve the discipline anyway for consistency.
- What this principle is not: a slow-down. The discipline is “human always sends” with the friction reduced to the minimum (one click in an already-open mail client), not “human reviews everything in a separate Auxot UI.”