"The agent does the work" is where most explanations of agentic marketing stop, and it is exactly where the interesting part begins. What does the agent actually do between receiving "audit our site and rank the fixes by revenue impact" and delivering a cited report? This article walks one mission through its full lifecycle - the same lifecycle every mission on this platform follows - because each stage carries a specific guarantee, and knowing where the guarantees live is how you know what to trust.
This is the execution-layer companion to the complete AI marketing agents guide: that piece maps the territory, this one dissects the engine.
The unit of work
A mission bundles four things that travel together: an objective in plain language, a budget reserved against a ledger, a working memory that accumulates evidence, and an audit trail that records every step. The bundling is the point. Because the budget belongs to the mission, cost has a hard ceiling per piece of work. Because the memory belongs to the mission, evidence gathered in step two is available in step nine without re-fetching. Because the trail belongs to the mission, "why does the report say this" has an answer you can pull up rather than reconstruct.
Compare this with a chat session, which shares the conversational surface but none of the structure: no reserved budget, no gates, no guarantee that a claim traces to a source. The mission is what makes agent output operational - something a team can act on and an auditor can reconstruct.
Stage one: objective intake
Missions arrive from wherever work happens - the console, Slack, a forwarded email, the API, a schedule. The first thing a well-built agent does with an objective is restate it: what it understood, what it plans to deliver, what it will assume. For "find accounts researching our category this week", the restatement pins down the category definition, the account count, the delivery target and the format - and if any of those assumptions is wrong, the correction costs one message instead of a finished deliverable aimed at the wrong goal.
Intake is also where scope earns its boundaries. An objective that would exceed the mission's cost cap gets flagged at the start - "this sweep at full depth exceeds the budget; here is what fits" - because discovering the ceiling mid-run wastes everything spent before the stop.
Stage two: planning and budget reservation
The reasoning model decomposes the objective into steps and selects capabilities from the tool registry: keyword pricing, firmographic lookups, ad-library pulls, contact verification - whichever the objective demands. Two properties keep planning honest. First, the registry is an allowlist: the agent chooses among tools it was granted, with scopes and meters attached, so a plan cannot include "and then access the production database" any more than a program can call a function that does not exist. Second, the plan prices itself: the mission reserves its worst-case cost against the ledger before the first tool fires - the reserve-then-settle pattern documented in Designing budgets for autonomous agents.
0tool calls before the budget is reserved
Stage three: execution and the sandbox rule
Execution is a loop: call a tool, read the result, update the working memory, decide the next step. The adaptivity people find impressive lives here - a thin result widens the search, a surprising result reroutes the plan - but the rule that makes execution trustworthy is duller and more important: models reason about numbers; they do not produce them. When a mission ranks five hundred accounts or sums a month's search-term waste, the arithmetic runs as code in a sandbox over the actual tool output. The model writes the program and interprets the result; the computer does the computing.
Stage four: verification and gates
Before delivery, two checks run. Evidence linking: findings must cite the tool output that produced them, so "their ad volume doubled" carries the library pull it came from. And consequence gating: any step that would spend money, publish content or contact a human is intercepted and parked - with its exact arguments - in an approval queue, the design detailed in Approval queues that keep autonomy fast. The parked call is the real call: approving executes precisely what was reviewed, not a paraphrase of it.
The gate placement follows one principle: reads are safe and run free; writes are consequential and wait. That single line, enforced in the tool layer rather than in prompt instructions, is most of what "safe autonomy" means - our guide to governing autonomous AI agents covers the rest.
Stage five: delivery and settlement
The deliverable lands where the team already works: rows written into the CRM, a document in the drive, a formatted reply in the Slack thread that asked, a webhook to your own system. Delivery includes the evidence - citations inline, the trail attached - and settlement closes the loop financially: actual cost replaces the reservation, and the unused remainder releases. The mission record now holds objective, plan, every call, every cost and the deliverable - which is what makes measuring agents a query instead of a survey.
How missions fail, and how failure is contained
Missions fail the ways distributed work always fails: a vendor times out, a source returns nothing useful, a budget ceiling arrives mid-plan. Containment is the design goal. Budget exhaustion parks the mission safely with the work already completed, rather than dying silently. Retries are idempotent - a re-run finds its previous writes instead of repeating them, the property the metering article explains - so a network blip never becomes a duplicate outreach email. And degradation is ordered: when the full depth does not fit the budget, the mission trades freshness and coverage in a declared order instead of failing opaque. The worst case, by construction, is a known cost and an explicit gap - which is the property that lets you schedule missions and stop watching them.
Frequently asked questions
What exactly is a mission?
One objective bundled with a reserved budget, a working memory, and an audit trail, executed end to end by an agent and closed with an evidence-backed deliverable and cost settlement.
How does the agent know which tools to use?
It plans against a registry of granted capabilities, each with scopes and metered pricing. The registry is an allowlist: tools outside it cannot appear in a plan, which bounds what any mission can possibly do.
Can the model make up numbers in a deliverable?
Not in a well-built system: statistics are computed by code in a sandbox over actual tool output. The model writes and interprets the computation; it never supplies figures from memory.
What happens when a mission hits its cost cap?
It parks safely with the work completed so far and reports the gap, rather than failing silently or overrunning. Budgets are reserved before execution, so the ceiling is enforced by the ledger, never advisory.
What stops an agent from sending something embarrassing?
Consequential actions - sends, spends, publishes - are intercepted at the tool layer and parked in an approval queue with their exact arguments. Approving executes precisely what was reviewed.
Sources
- Anthropic - Building effective agents (the plan-act-verify loop)
- Model Context Protocol - how tool registries expose capabilities to agents
Every playbook on this blog ships as a runnable mission.
Open a workspace and the playbook library is waiting - describe the outcome and the agents carry it end to end, on your plan's monthly credits.