The Anatomy of a Marketing Agent: From Request to Verified Outcome

A question such as “why did conversion rate drop last week?” crosses several systems before it becomes a useful answer. The agent needs the right account, a consistent definition of conversion rate, comparable periods, and evidence about what changed. It may need to investigate tracking, traffic mix, campaign settings, and landing pages. Its explanation must distinguish a supported finding from a plausible hypothesis.

Giving a model access to analytics tools makes that investigation possible. Making it dependable requires the parts around the model to work together. A retrieved report can be incomplete. A saved account reference can be stale. A second agent can lose an important qualification when it summarizes the first agent’s work. Each handoff can preserve the meaning of the task or quietly change it.

The Agent Architect’s Playbook defines the reporting brief and reusable review skill. A review can surface a conversion-rate decline that needs a separate investigation. This guide follows that question through the runtime: who owns each handoff, which state must survive it, and what changes when several agents participate. Its practical output is a set of handoff requirements and an orchestration choice.

An agent is a working loop inside a larger system

For this guide, an agent is a system in which a model chooses steps toward a task, uses available operations, observes their results, and decides what to do next. A predefined workflow can also contain model calls, but software determines more of its route in advance. These approaches can coexist: a fixed reporting pipeline may call an agent to investigate an unexpected result. Anthropic’s Building effective agents offers a useful distinction between predefined workflows and model-directed execution.

There is no universal requirement that every agent have persistent memory, a persona, or a skill file. Those are design choices. A short investigation may need only the current request, tools, and working state. A recurring client workflow may benefit from saved preferences and reusable procedures. Adding components is justified when they help the task, rather than because an agent definition lists them.

A handoff contract specifies what crosses from one owner to the next. Use the responsibilities in the brief to identify these contracts:

Handoff	Information that must survive	Receiver’s responsibility
Request to harness	Client, user, question, periods, metric definitions, allowed operations	Establish a bounded active job and expose unresolved ambiguity
Harness to tool	Trusted caller, resolved target, requested fields, limits, job identity	Check current permission and validate the operation before dispatch
Tool to working state	Source, values, freshness, coverage, evidence references, failure status	Retain incomplete and failed reads alongside successful evidence
Working state to findings	Calculations, source references, hypotheses, unresolved questions	Distinguish supported findings from possible explanations
Findings to delivery	Original question, checked figures, limitations, permitted destination	Release only the outcome allowed by the report’s acceptance and delivery policy
Parent to child and back	Task scope, tools, shared budget, deadline, evidence, completion status	Preserve authority, cancellation, disagreement, and missing results

These are logical contracts rather than a requirement for six separate services. One application can implement several owners. The important property is that each receiver checks the information it relies on instead of inferring success from the previous stage’s fluent response.

Follow the investigation across its boundaries

Following the conversion-rate question through the system makes each handoff visible.

Resolve the question and the permitted scope

The agent first needs to know which client’s conversion rate, which accounts, and which periods are relevant. “Last week” also needs a reporting time zone. If the conversation already supplies a verified account, the harness can carry it forward. If a name matches several allowed properties, clarification may be necessary.

The account service verifies identity and ownership; authorization determines whether the requester may read the data. A user’s choice resolves their intended target, while the backend still checks access before retrieval. Your Marketing Agent Needs a World explains the campaign, account, requirement, observation, and finding records behind these handoffs. The runtime must preserve their relationships as the investigation moves between components.

Define the measure before comparing it. A warehouse conversion count, an advertising platform’s attributed conversions, and an analytics event count may describe different things. Record the numerator, denominator, attribution window, and reporting period. A percentage drop in aggregate conversion rate can arise from a change in traffic mix even if individual channels are stable.

Gather evidence without erasing its limitations

The agent can choose useful capabilities: retrieve rates by channel and device, inspect tracking changes, review campaign change history, or check landing-page availability. The tools return evidence with source, scope, time range, and completion status. The harness records failed or pending requests alongside successful ones.

A useful evidence record answers: what population does this cover, how current is it, were all required pages retrieved, and which definitions apply? A request that returned some rows is different from a complete dataset. Missing conversion data is different from zero conversions. If a source is unavailable, the agent should narrow its conclusion or return a partial investigation.

Calculations belong in tested code where exact results are required. The model can decide which breakdown to investigate and explain the result, but a calculation service should compute the agreed rate and comparison. A business alert threshold describes materiality; it does not automatically establish statistical significance or causation.

Turn observations into findings, then check the answer

The agent may observe that mobile traffic increased, that a tracking event stopped arriving, or that a landing-page change coincided with the decline. Those observations support different claims. Timing alone can justify further investigation; it rarely proves that a specific change caused the result.

Keep findings linked to the evidence used, identify coverage gaps, and label hypotheses that need testing. Check reported figures against the calculation results and confirm that the answer addresses the original question. If the system cannot support a conclusion, “not established” is a legitimate result.

Ending the investigation is a harness decision as well as a language decision. The job may be complete, blocked, partially complete, cancelled, or timed out. Record that status and its reason. A final paragraph saying “all clear” must not conceal that the only relevant tool failed.

Keep a recommendation separate from an effect

The agent might recommend checking a tag, reviewing a landing-page deployment, or changing a bid. The analysis has not performed those actions. A later request to apply a campaign change enters a different execution path with current state checks, policy limits, approval where required, and post-action verification.

Retries need particular care. If a platform accepted a change but its acknowledgement was lost, blindly sending the request again can repeat an effect. Use the provider’s supported repeat-protection mechanisms and reconcile actual state before retrying. Record partial execution explicitly; reversing a setting cannot reverse impressions or spend that already occurred.

The secure marketing-agent architecture develops that controlled write path in detail.

Choose reasoning, memory, and skills for the job

Model selection should follow evidence from representative tasks. Compare the candidate configurations on tool use, analytical quality, instruction following, cost, and time to an acceptable result. Context capacity matters, but a larger window does not repair inconsistent definitions or missing source data. There is no general basis for assuming model differences are negligible or that one architecture always compensates for a weaker model.

Memory also contains several different kinds of information:

Information	Useful purpose	Required discipline
Conversation context	Preserve the current question and clarifications	Keep it attached to the correct user and client
Workflow state	Track completed reads, pending work, errors, and remaining budget	Preserve status across retries, restart, and cancellation
Reference knowledge	Metric definitions, brand rules, approved procedures	Record source, version, owner, and applicable scope
Saved preferences	Adapt explanation and report format	Keep preferences separate from policy and permissions
Cached observations	Reuse earlier data when appropriate	Preserve freshness and completeness; refresh before consequential use

A summary can help continuity, but it can also omit an important qualification. Keep access to the underlying evidence, and avoid saving a model’s conjecture as an established client fact. Persistent memory changes future context; it does not, by itself, train the model or prove that the system has learned a causal relationship.

Skills supply recurring investigative guidance. An anomaly-investigation skill might require checking metric definitions, tracking changes, channel mix, and source coverage before forming an explanation. A budget-pacing skill could describe the appropriate comparisons and escalation conditions. A creative-testing skill could specify how to distinguish experiment results from untested ideas.

Those procedures guide the agent’s judgment. The harness and tools still enforce budgets, access, and execution conditions. A skill asking the model to score its own clarity can improve a draft, but a self-awarded score is weak evidence that the answer is complete or correct.

Tools and MCP provide connections, not universal authority

A tool is an operation the model can request, such as retrieving an analytics report, querying a warehouse, or preparing a draft. Its contract should state required inputs, allowed scope, returned evidence, possible side effects, and failure behavior. The implementation must validate the request independently of the model’s description of it.

MCP standardizes parts of how AI applications discover and use external tools and resources. It can reduce integration duplication, but an MCP server still needs provider-specific code, credentials, permissions, and operational maintenance. Some tools are built into the runtime; others use direct APIs, command-line interfaces, or scripts. Skills do not have to call tools through MCP. See the MCP documentation.

The active agent follows a skill and requests operations; the skill file is not a separate process that authorizes or executes them. Similarly, an MCP connection does not prove that a particular client account is permitted. Carry identity, permission context, and evidence metadata through the adapter and enforce them at the appropriate backend boundary.

Adapt a coding runtime without inheriting unnecessary access

A coding agent can be a useful starting runtime because it already supports tool calls, files, code execution, and reusable instructions. Specializing it for marketing requires a capability and deployment decision as well as a new role description.

First define the task and required operations. For the investigation, these might be read-only analytics queries, approved warehouse queries, and local calculations. Add source definitions and investigative skills, then configure the host’s supported installation and permission mechanisms. Validate each integration against its current documentation and actual availability. A plausible-looking package name or configuration snippet is not evidence that a connector exists.

A project instruction file can explain the role:

# Marketing analysis workspace

## Purpose
Investigate performance changes for the active client using approved data.

## Procedure
- Confirm account scope, metric definitions, and comparison periods.
- Use the relevant investigation skill.
- Preserve source coverage, failures, and uncertainty.
- Distinguish observations, explanations, and proposed actions.

## Delivery
Return evidence-linked findings, limitations, and next steps.

This is instructional guidance, not an enforceable permission configuration. Make the host and backend restrict account access and available operations separately. Give the worker controlled local storage and script execution only if the task needs them. Use current product documentation for installation and tool configuration rather than assuming one file or command works across every runtime.

Test the resulting specialization: the agent should use the approved metric definitions, select relevant tools, report unavailable evidence, and stop at recommendations. It should also be able to complete legitimate work without repeatedly asking users for information the system can verify itself.

Make validation and guardrails part of the working path

The shared terminology distinguishes validation, guardrails, evaluation, and observability. Here their ownership matters: a tool validates returned records; policy checks access; the harness preserves status; the delivery gate checks the completed answer. A handoff must not turn “some data returned” into “investigation complete.”

For the conversion-rate investigation, validation includes checking data types, units, calculation inputs, retrieval coverage, and support for reported claims. Guardrails enforce client access, permitted queries, resource limits, and any restrictions on exports or changes. Protecting a number’s format and protecting the client’s data are different checks.

Enforce exact conditions in code where possible. Use a model-based reviewer for open-ended questions such as whether an explanation answers the brief, with expert review where ambiguity or consequences warrant it. A reviewer agent may share the first agent’s blind spots. Its confidence does not establish factual correctness or grant approval to publish or spend.

If a final check is mandatory, the application needs a delivery gate that verifies the required evidence before releasing the artifact. A prompt asking the model to remember that check is a softer control. Be explicit about which behavior is enforced and which is requested.

Keep limits proportional to the workload. Fixed examples such as a universal daily spend cap or a percentage-change alarm are not safe defaults for every client. Define limits by client, operation, and likely impact, and assign an owner who can change them. Approval should resolve a real policy or judgment requirement, rather than compensate for missing routine data checks.

Choose orchestration by the dependencies in the work

A single agent can use several skills and call independent tools concurrently when the harness supports it. Multiple agents can help separate context, tasks, or access, but they also introduce coordination cost and more opportunities to lose evidence. Partial failure is possible in either design.

Three patterns are useful, and they can be combined.

Sequential pipeline

A campaign-development workflow can move through research, strategy, creative production, quality review, and distribution. Each stage receives a defined artifact and produces one for the next stage. This can be a fixed software pipeline, a sequence of agents, or a mixture.

The handoff needs more than prose. A creative stage should retain the brief version, supported product claims, asset requirements, and unresolved questions. A quality reviewer can request revision or provide review evidence. Publishing still requires the organization’s actual authorization path; a favorable review message does not create it.

Parallel fan-out

For creative exploration, several workers might develop different message angles from the same approved brief. A consolidator removes duplicates, checks constraints, and explains a shortlist. It can judge fit to the brief; it cannot know which option will perform best without appropriate campaign evidence or testing.

Use parallelism when the branches can make useful progress independently. Define how many workers may start, what each can access, when work ends, and how to handle a missing result. Three variants generated by one agent may be enough for a small request. More workers should earn their additional cost through measured usefulness.

Hub and spoke

The conversion-rate investigation could use an analytics worker to inspect data and traffic mix, an operations worker to review tracking and campaign changes, and a creative worker to inspect relevant asset changes. The supervisor decides which branches are useful and reconciles their evidence. It must not turn a failed operations check into a claim that no operational problem exists.

Each child needs a task, allowed scope and tools, output requirements, budget, deadline, and return status. The supervisor cannot delegate more authority than it has. Enforce limits across the whole job as well as per worker, propagate cancellation, and assign one owner for shared files or campaign effects.

Anthropic’s multi-agent research account describes practical delegation and coordination challenges. Its findings concern that research system; they do not establish a universal advantage for marketing swarms. Compare any proposed multi-agent design against a simpler baseline on the task you actually need.

Three applications of the same boundaries

The original marketing use cases remain useful as designs to evaluate, rather than promises of performance gains:

Application	Possible division of work	What must survive the handoff
Content intelligence	Research, editorial planning, personalization, performance review	Source quality, approved claims, audience scope, publication permission, experiment results
Paid-search optimization	Keyword analysis, creative review, funnel investigation, change proposals	Metric and attribution definitions, account identity, current settings, approval, verified effects
Account-based marketing	Account research, scoring, message drafting, channel planning	Data provenance, permitted use, account/contact identity, outreach policy, approval requirements

Qualified leads, campaign efficiency, and account engagement are business outcomes to measure separately. More coordinated activity is not evidence of improvement in those outcomes.

Deploy the workers and the controls deliberately

Map each logical worker and shared control to the deployment boundary chosen in the brief. A single worker can use a restricted process, container, or VM; several collaborators may share an environment when its trust boundary permits that sharing. Record which files, credentials, and task state cross between them.

A virtual machine supplies a separate operating-system environment; a microVM is a lightweight form. A sandbox restricts execution access and can use different underlying mechanisms. AWS documents isolated session microVMs as well as longer-lived environments for collaborating agents; Anthropic describes filesystem and network restrictions for command execution. These are different isolation arrangements to assess, with no universal requirement for one machine per agent. AgentCore Runtime, Anthropic sandboxing.

For a client-facing service, bind the session to the authenticated user and client. Restrict file access, network destinations, CPU and memory use, execution time, and tool permissions. Separate one client’s working files from another’s. Collaborators sharing a filesystem also share some failure and disclosure risks, even if their agent prompts are different.

Keep provider credentials in a controlled broker or executor where feasible. At a remote tool boundary, carry the authenticated caller and client scope with the request; a sandbox around the local worker does not constrain the remote service automatically.

Define what persists across turns, restarts, and environment reuse. Saved plans and evidence may be valuable, but a resumed session must recheck expired authority and stale data. Clean up temporary exports and revoked grants according to their retention rules. Test cancellation and recovery using the deployment arrangement you intend to operate.

An agent factory can assemble a versioned model configuration, skill bundle, tool set, policy profile, and runtime image. Provisioning that bundle should also attach an owner, permitted scope, evaluation evidence, and release status. A newly generated worker configuration needs the same promotion checks as a hand-written one. For hosting examples with different isolation models, see AgentCore Runtime and Anthropic’s sandboxing discussion.

Evaluate the interactions, then inspect production outcomes

Component tests matter: the metric calculator should compute correctly, the account service should enforce ownership, and the tool adapter should preserve errors. System evaluation asks whether those parts combine into a useful and authorized investigation. Individually passing components can still produce an incomplete answer when a supervisor loses a failure status.

Build a task set that exercises ordinary work and the boundaries above:

Test case	What the complete system must demonstrate
Complete comparable data	Correct calculations and evidence-linked findings that answer the question
Same-named properties under different clients	Correct scope enforcement and clarification only when needed
Tracking source unavailable	Visible gap and bounded conclusions, without invented reassurance
Different metric definitions or missing rows	Reconciliation or an explicit limit on comparison
Retrieved text attempts to redirect the workflow	No unauthorized reads, exports, or changes
Cancelled, repeated, or interrupted work	Appropriate stopping and recovery without duplicate effects
A child agent fails or contradicts another	Failure and disagreement remain visible in the combined result

Use the evaluation method from the Playbook: recorded configurations, repeated trials, checked graders, and separate quality and boundary measures. For this investigation, add handoff assertions: a failed tracking read stays failed in the supervisor’s answer; a child cannot replace the client’s account; disagreement remains visible.

Compare one agent with orchestration on the same tasks and budgets. Measure whether delegation improves the investigation, how much evidence is lost in consolidation, whether cancellation reaches every child, and how shared limits behave. Allow valid alternative routes while enforcing permission before access and approval before effects. Anthropic’s evaluation guide explains the distinction between recorded interactions and actual outcomes.

Production observation closes the loop. Link each job to its client scope, version, tool requests and results, findings, validation decisions, approvals, and observed effects. Capture errors and denied operations, not only successful paths. Restrict sensitive evidence separately from ordinary performance telemetry; “log everything” is not an appropriate data-retention policy.

An operator should be able to reconstruct which handoff lost a qualification or substituted an identity. Preserve a regression case for that failure and rerun it when the model, supervisor, context rules, or worker configuration changes. The maintenance guide describes how to turn that evidence into a reviewed repair.

Build the smallest complete investigation

Start with one authorized property, a defined conversion measure, two comparison periods, and a read-only analysis path. Supply the necessary reference context and a narrow investigation skill. Implement the data checks, result requirements, and deployment limits that make the path complete. Then test successful, ambiguous, unavailable, and unauthorized cases before widening scope.

Expand when evidence identifies the next need: another source, a better tool, saved state, a separate worker, or an approved action path. Human practitioners remain responsible for strategic choices, exceptions, and decisions whose consequences warrant their judgment. The architecture should make those decisions easier by showing what is known, what is uncertain, and what the system actually did.

The handoff design should state each producer, consumer, scope, evidence, completion status, and failure route. The tool guide takes the next boundary in detail: how a requested operation reaches a provider through MCP, CLI, or both.

Further reading

• The Agent Architect’s Playbook
• Secure Marketing Agents
• The Deterministic Core
• Anthropic: Building effective agents
• Anthropic: Demystifying evals for AI agents
• Anthropic: How we built our multi-agent research system
• Agent Skills specification
• Model Context Protocol documentation
• AI Skills Guide repository