An email agent needs a stopping rule, not just a goal.

An AI email agent should stop when the requested outcome is complete, when continuing would cross an explicit boundary, when the evidence needed to choose is missing, or when the next action creates an external effect the agent does not have authority to own.

The ability to continue is not evidence that continuing is the right thing to do.

The rule must be executable outside the model. Recipient count, spend, elapsed time, retries, data freshness, permissions, plan version, policy results, and tool effects should be measured by the application. The model can explain the situation and propose a next move. It should not quietly redefine the boundary that stopped it.

Goals are attractive because they point forward. “Recover dormant customers” sounds decisive. “Increase revenue” sounds measurable. “Launch the campaign” sounds finite. But each can support an unlimited number of actions unless the system also defines enough, too much, too uncertain, too late, and not mine to decide.

A capable agent can always find another segment, generate another variation, query another data source, or retry one more time. This persistence looks useful until it widens the audience to make a target easier, spends more than the value of the outcome, changes a promise to improve response, or mistakes a delivery timeout for permission to send again.

Anthropic's guidance on building agents explicitly includes stopping conditions such as iteration limits, and its recent work on trustworthy agents describes the agent loop as continuing until the task is done or human input is needed. OpenAI's agent guide likewise recommends human intervention when failure thresholds are exceeded or an action is sensitive, irreversible, or high stakes. The shared idea is simple: autonomy includes knowing when not to spend the next action.

A stopping contract turns an open-ended request into a bounded operating plan. It belongs beside the goal, not in a safety appendix added after launch. The contract should answer five questions.

This contract extends the autonomy budget. The budget says how much discretion exists. The stopping contract says what state transition occurs when any part of that discretion is exhausted.

1. 01

   The outcome is complete

   The accepted plan version executed once and the provider returned a durable identifier. More activity would be duplication, not progress.

2. 02

   Intent is missing

   The request leaves a consequential preference unresolved: which audience, which offer, which sender, or whether a new follow-up is acceptable.

3. 03

   Authority ends

   The next tool, recipient class, data source, spend level, claim, or external effect lies outside the caller’s granted scope.

4. 04

   A budget is exhausted

   A recipient, cost, token, time, retry, novelty, or risk allowance has reached its declared limit.

5. 05

   The plan changed materially

   Audience logic, exclusions, content, links, sender, schedule, or downstream automation no longer matches the reviewed digest.

6. 06

   Evidence is weak or stale

   Counts disagree, consent state is old, suppression data cannot be read, a provider result is ambiguous, or the model cannot distinguish people from scanners.

7. 07

   The environment says no

   A policy check fails, a provider rejects the action, an incident flag is active, or a connected system is degraded beyond the safe operating envelope.

Systems often collapse every interruption into an error. That makes a good pause look broken and a real failure look negotiable. Give the run distinct terminal and resumable states.

A timeout is especially dangerous because it says nothing about the external outcome. The provider may have accepted the send even though the response never arrived. Move into an unknown state, reconcile by idempotency key or provider identifier, and remember that a retry is not permission to send twice.

Natural language is good at describing a goal. It is a poor place to hide execution state. Keep the model inside a deterministic state machine whose transitions are visible to the application.

Evaluate stopping rules before the proposal, before the tool call, and after the result. The first check catches a run that should already be done or blocked. The second protects the boundary about to be crossed. The third decides whether the observed result completed the work, requires reconciliation, or changed the conditions for the next step.

“Be careful” is not a stopping rule. Neither is “ask if the campaign seems risky.” Write thresholds against facts your application can observe and policies your team can own.

The numbers above are examples, not universal defaults. A password-reset system and a promotional broadcast have different risk, urgency, and consent models. The durable practice is to make the thresholds explicit, versioned, and testable against your own operating envelope.

Asking for help should not dump a transcript on the nearest person. Preserve the work already done and present the smallest decision that can safely unblock the run.

Show the goal, current plan version, exact stopping rule, observed value, blocked next action, affected scope, last trustworthy evidence, and available choices. If the audience grew beyond a threshold, ask whether to keep the approved audience, authorize the larger one, or revise the rule. Do not ask, “What should I do?”

The same applies to approval. A reviewer needs the diff from the state they trusted, not a new summary written by the agent that wants to proceed. Once answered, bind the response to a new plan version and re-run every relevant preflight check.

MCP gives clients and servers a standard way to expose tools and request additional user input. The current tools guidance says applications should keep a human able to deny tool invocations. The 2026-07-28 protocol revision also introduced multi round-trip requests, allowing a tool call to return an input-required result and resume with explicit responses.

That transport is useful, but it does not decide when a 100,000-recipient send should pause. Your email system still needs to calculate the audience, enforce consent and suppression, compare the plan digest, check the caller's scopes, evaluate budgets, and classify the next effect. Tool annotations are context, not authority.

In practice, expose narrow tools through the Moosewave MCP layer: prepare a plan, preview an audience, render a version, run preflight, request approval, execute an approved version, and inspect receipts. A single unrestricted “run marketing” tool erases the boundaries the agent needs to see.

A stop without a receipt becomes folklore. Operators need to know whether the agent finished, exercised good judgment, hit a policy boundary, encountered bad data, or merely gave up.

Store the concrete evidence and transition, not hidden model reasoning. The receipt should support operations, evaluation, incident response, and a later explanation to the person who owned the decision.

Teams often evaluate only task completion. That rewards an agent for pushing through ambiguity and treats a prudent pause as failure. Add stopping behavior to the scorecard.

Test missed stops and unnecessary stops. Seed runs with an expanded audience, stale consent, a changed link, exhausted budget, conflicting counts, repeated timeout, prohibited sender, expired approval, and a novel tool. Then test routine reads and low-risk drafting to make sure the agent does not ask for permission every thirty seconds.

Track the stop rate by rule, false-stop rate, missed-boundary rate, time to human resolution, percentage of handoffs that include enough evidence, override outcomes, repeated incidents, and whether resumed runs honor the decision they received. NIST's AI RMF emphasizes continuous governance, measurement, documentation, and safe failure beyond knowledge limits. Stopping quality is one concrete way to operationalize that discipline.

Moosewave keeps the goal, plan, budgets, permissions, approvals, tool calls, and receipts in one connected run. The agent can inspect audiences, draft and render content, simulate automations, run preflight checks, and analyze outcomes without pretending each step has the same impact.

Before an external send, Moosewave resolves the current audience and exclusions, verifies the approved version, checks delivery policy and limits, and either executes the bound action or produces a decision-ready stop. Afterward, analytics and receipts reconcile what actually happened rather than letting the agent infer success from its own intention.

You can follow the complete sequence in the interactive demo, explore how desktop and mobile stay connected in the Moosewave ecosystem, or inspect the tools available to Claude, Codex, and other compatible clients on the MCP page.

• Anthropic, Building effective agents. Agent loops, environmental feedback, checkpoints, and iteration limits.
• Anthropic, Trustworthy agents in practice. Human control and deciding when to pause rather than assume.
• Anthropic, Measuring AI agent autonomy in practice. Evidence on human interruption and agent-initiated stops.
• OpenAI, A practical guide to building agents. Layered guardrails, failure thresholds, high-risk actions, and human intervention.
• NIST, AI Risk Management Framework Core. Governance, human oversight, continuous measurement, and safe failure.
• Model Context Protocol, Tools, and the 2026-07-28 specification overview. Human denial paths and input-required tool results.

Sources checked 22 August 2026. Thresholds in this article are illustrative and should be adapted to the organization, channel, jurisdiction, and use case.