An email agent’s autonomy is a budget, not a switch.

A permission defines what an agent may do. A budget defines how much it may do before another decision is required. The distinction sounds small until the permitted action is “send email,” “change an audience,” “spend an incentive,” or “keep trying until the provider answers.”

Permission opens the door. A budget decides how far the run may travel beyond it.

Give one run explicit allowances for recipient exposure, money, elapsed time, tool side effects, distance from an approved baseline, and unresolved risk. Reserve those allowances before consequential work. Consume them as effects become real. When a limit is reached, stop before the next effect, explain the ledger, and ask for a fresh decision.

This is not a metaphorical “be careful” instruction inside a prompt. It is product state enforced by the systems that own the audience, money, tools, and send. The agent can reason about the budget. It cannot reason its way around it.

Teams often ask whether an agent should be autonomous. That is like asking whether a company card should be enabled. The useful questions are: for which purchase, from which vendor, up to what amount, before what date, with whose receipt, and what happens when the transaction looks unusual?

“Human in the loop” is not much better. A person who approves a vague goal at the beginning is technically in the loop. So is a person who receives an alert after 400,000 messages have gone out. Neither phrase tells us where authority changes hands, whether the person can still stop the consequence, or what exactly was approved.

The better model is a lease. A workspace grants a finite mandate to one run: pursue this outcome, inside these permissions, with these allowances, until this time. A lease expires. It can be revoked. It does not become larger because the task is going well, and a successful earlier run does not silently renew it.

Our preceding field notes make the pieces explicit. Permissions and approvals define authority. A campaign plan defines the proposed work. Durable memory preserves the right state. The autonomy budget now limits the distance between the approved plan and the next human choice.

One global number hides the consequence. Ten read-only lookups are not equivalent to ten audience writes. A modest model bill is not equivalent to customer credit of the same value. A message sent to one internal seed address is not equivalent to a message sent to one person who revoked consent.

These meters do not collapse neatly into points. Keep them separate so a large allowance in one dimension cannot cancel a zero in another. Unused model spend cannot purchase the right to use a new sending domain. Spare time cannot excuse a missing approval. The most restrictive active boundary wins.

Email cost is usually quoted per message, but the human consequence begins with exposure. A thousand messages to a consenting internal test list are a different act from a thousand promotional messages to customers whose expectations are uncertain. The meter needs both quantity and class.

Reserve the maximum eligible population before generation or scheduling. Bind the reservation to the exact audience definition, exclusions, market, purpose, and snapshot rules. Re-resolve volatile suppression immediately before sending, but never let a larger re-resolved audience expand the reservation. More eligible people should mean fewer are selected or the plan returns for approval.

Useful sub-budgets separate known lifecycle recipients, new acquisitions, inactive contacts, sensitive cohorts, and internal addresses. A standing password-reset workflow may receive a high budget for requested transactional messages while a new re-engagement idea receives a small exploratory budget, or zero until reviewed.

Frequency belongs here too. A campaign can fit its own volume ceiling while pushing a person beyond the workspace’s weekly contact policy. Recipient-level caps are shared state, not a local counter an agent can reset by starting another run.

Provider fees, model inference, enrichment, paid assets, coupons, credits, and shipping incentives all spend different kinds of value. Record the currency and owner of each one. “Under budget” is meaningless if a cheap model call can issue an expensive customer credit.

Reserve the plausible maximum before the action. Consume the actual amount when it becomes known. Release the unused reservation when the run closes. If an acknowledgement is ambiguous, keep the amount reserved while reconciling rather than assuming the action failed and spending it again. That is the same discipline behind idempotent transactional email.

Time is not merely a timeout. Give the plan an approval expiry, a permitted execution window, a maximum wall-clock duration, a retry count, and freshness limits for the facts it depends on. A launch plan approved at noon may be invalid after inventory, pricing, consent, or quiet hours change.

Long-running work should checkpoint at meaningful state boundaries rather than keep an invisible reasoning loop alive. If the run waits for a person, provider, or scheduled window, store the frozen plan and remaining allowance, then release compute. Time spent waiting should not become permission to improvise.

A tool-call budget of twenty sounds precise and says almost nothing. Reading twenty aggregate reports may be harmless. One export, delete, DNS change, audience overwrite, or send can be irreversible. Tool identity, arguments, and effect class matter more than the raw count.

Enforce the price on the server that performs the effect. A model cannot be trusted to announce that its next action is risky, and tool annotations are hints rather than authority. The operation owner knows whether the call is read-only, reversible, idempotent, open-world, or externally visible.

Connected integrations should keep their own meters. A CRM read allowance should not become a commerce write allowance merely because both tools appear in one conversation. Narrow scopes set the outer permission; per-run effect budgets set the inner distance.

The dangerous move is often free: changing the audience query, making a stronger claim, substituting a link host, adding a locale, using a new From identity, or rewriting a protected footer. A financial meter will miss every one.

Define the approved baseline as structured fields, not a screenshot. Then classify changes. Editing a subject line inside an approved template region may be permitted. Changing a price, guarantee, domain, legal disclosure, audience purpose, or unsubscribe behavior should cross a novelty boundary and invalidate the old approval.

Uncertainty is different from novelty but often travels with it. Missing inventory, conflicting consent state, stale profile data, an unexplained volume jump, or a provider anomaly should spend a risk allowance. Do not turn model confidence into authority. A fluent guess at 0.93 is still a guess if the required source is absent.

The ideal stop is specific: “The eligible count rose 18% after approval because the segment refreshed; 1,842 recipients are outside the reserved exposure budget.” That gives a person a real choice. “The agent needs help” does not.

The budget must survive retries, concurrent workers, and lost acknowledgements. Store a task identity, plan digest, policy version, granted ceiling, reservations, committed effects, releases, expiry, and the identity that can increase or revoke it. Never keep the only counter in model context.

1. 01

   Grant

   Create a lease below workspace policy, tied to one immutable plan and expiry.

2. 02

   Reserve

   Atomically hold enough allowance before a consequential operation begins.

3. 03

   Commit

   Attach the real external receipt to the reservation exactly once.

4. 04

   Reconcile

   If the response is uncertain, inspect durable state before retrying or releasing capacity.

5. 05

   Close

   Release unused reservations, preserve the compact receipt, and expire further action.

A reservation is not a result. A provider may reject a send, accept it, or accept it while the response disappears. Keep the run boring: use idempotency, reconcile with receipts, and make another worker observe the same ledger. Agentic systems do not repeal distributed-systems failures.

An agent that cannot be interrupted is not more autonomous. It is less operable. Every long or consequential run needs a cancellation path, checkpoints at safe boundaries, and a compact explanation of what remains.

Stop before a side effect whose allowance is missing. Do not partially send an audience merely because the first batch fit unless partial execution was explicitly part of the plan. Do not “finish the current thought” after revocation. Policy and kill switches are checked at execution, not politely queued behind the model.

Asking should name the exhausted meter, the proposed increment, the reason, and the changed consequence. A person can then reduce the work, change the plan, grant a one-time increment, or end the run. The agent must not phrase expansion as the obvious default.

Resume from a signed checkpoint: plan version, completed effects, receipts, remaining budget, current policy, and facts that must be refreshed. Do not paste the old transcript back into a new context and hope the same boundaries reappear.

Suppose a marketer asks: “Bring back customers who went quiet after their first order.” Before generating copy, the system turns the request into a plan and a lease.

Now drafting becomes the cheap part. The agent can inspect the permitted evidence, propose the audience and message structure, and show the exact plan. Approval signs the plan and lease together. If tomorrow’s refreshed segment contains 12,600 eligible people, the system selects at most the approved 12,000 or asks. It does not redefine “up to 12,000” as “about 12,000.”

Open the Moosewave product walkthrough to see the same sequence from goal to plan, approval, execution, and evidence. Nothing in the walkthrough sends or changes a live campaign.

Log the amount granted, reserved, committed, released, and expired for every meter. Record which boundary stopped the run, what changed, who granted an increment, and whether the resumed plan produced the intended result. This is the evidence needed to tune policy.

Useful operating measures include handoff rate by workflow, near-budget runs, repeated approval expansions, stale-plan stops, duplicate-effect prevention, time to resolve a stop, and the gap between estimated and actual exposure or spend. Pair them with real outcome evidence: delivery, complaints, conversions, incremental lift, and customer replies.

Do not reward an agent for consuming its allowance. A run that answers the question after three reads should not invent seventeen more. Nor should a low handoff rate become the goal; a sensitive workflow may be healthy precisely because it asks often. Budgets support good decisions. They are not a game score.

Review the pattern, not one anecdote. Frequent stops at the same harmless boundary may justify a narrow policy change. Frequent requests to expand audience, claims, or write access may reveal a badly scoped workflow rather than a stingy limit.

The Model Context Protocol can expose resources, tools, authorization, and long-running tasks through a consistent interface. Current authorization guidance uses protected resources, resource indicators, and least-privilege scopes. Task guidance adds cancellation, expiry, concurrency limits, monitoring, and audit expectations.

These are useful outer boundaries. A token intended for one MCP server should not become a bearer pass for every resource. A task should not live forever or escape the requestor’s authorization context. A person should be able to review and deny sensitive model or tool work.

Protocol scope does not know the business consequence. A generic campaign.schedule tool cannot decide whether 500 recipients are ordinary for this workspace, whether the incentive exceeds the owner’s ceiling, or whether a new claim invalidates approval. The Moosewave MCP layer carries the scoped request; the product services that own audiences, templates, sending, and analytics enforce their meters.

This separation makes MCP more useful, not less. A compatible client can help plan and coordinate work while the same budget applies whether the request began on desktop, mobile, the web, or another authorized agent host.

Moosewave begins with a goal, not a blank send button. The agent resolves permitted context, proposes a structured plan, and shows the meters that would govern it. Audience exposure, exclusions, message structure, sender identity, schedule, integrations, cost, checks, and approval stay attached.

Approval freezes the plan and grants a smaller lease under workspace policy. Execution reserves the relevant allowance, refreshes volatile facts, commits each effect once, and leaves receipts. If a boundary changes, the run stops with a specific explanation. The operator can reduce, revise, approve, or end it from the same connected ecosystem.

The product can feel fluid without making authority invisible. An agent can move between campaign, audience, automation, integration, and measurement state while every irreversible edge retains a meter. The nice part is not that the agent acts forever. It is that it can complete useful work inside a boundary everyone can see.