The Agent Architect's Playbook: Designing Marketing Work and Reusable Skills

A marketing agent earns trust through what the whole system can demonstrate: that it used the right client’s data, completed the requested work, respected its authority, and reported the result honestly. A persuasive answer is only one part of that evidence. The calculations may be wrong, a source may be incomplete, or an attempted campaign change may have failed behind an apparently successful reply.

Building that system requires decisions about reasoning, data, permissions, execution, and evaluation together. Skills make procedures reusable. Tools connect those procedures to operations. The software around the model manages state, checks requests, limits access, and records outcomes. Its deployment environment contains the work, while evaluation determines whether the combined system performs well enough to use and change.

This guide produces two starting artifacts: a design brief for the workflow and a skill describing its recurring procedure. The brief establishes the result and the controls it needs; the skill supplies the marketing method. The Anatomy of a Marketing Agent then turns that design into a working loop, with explicit state, handoffs, and orchestration.

Define successful work before choosing the components

For a weekly review, success means covering the agreed accounts and reporting period, calculating metrics consistently, explaining material changes with supporting evidence, and exposing gaps. A report that looks complete while silently omitting one platform has failed part of the task. A report that identifies the omission and explains its limits may be the correct outcome when the platform is unavailable.

Write down both the useful result and the conditions it must preserve. For this workflow:

The accounts belong to the intended client, and the requester has permission to read them.
The reporting period, comparison window, currency, time zone, and metric definitions are explicit.
Missing data, delayed conversions, and incomplete retrieval remain visible.
Recommendations are distinguished from observed facts and from actions already taken.
The work finishes within an agreed time and cost budget, or returns a clear reason it could not finish.

These conditions give engineers something to implement and evaluators something to check. They also expose decisions that require marketing judgment. What counts as a material change? Which attribution window should the report use? Who may approve a budget increase? Those answers cannot be inferred from the choice of model.

A review agent’s task success is also different from campaign success. Producing an accurate recommendation does not establish that following it will improve return on ad spend. Business impact needs its own measurement, with a credible comparison and attention to attribution and external changes.

Write the reporting brief once

The series uses one reference workflow, weekly-performance-review. It prepares an evidence-linked paid-media review for an approved client and returns a draft to a configured private destination. A practitioner reviews any proposed external client delivery. Campaign changes require a separate authorised action path.

Brief element	Reference decision
Account scope	Approved provider accounts for one client; `ACCOUNT_REF` stands for one account resolved within that scope
Reporting period	12–18 October 2026 inclusive, compared with 5–11 October, interpreted in `Europe/London`
Sources and definitions	Agreed Google Ads and Meta sources; currency, attribution windows, conversion definitions, and materiality rules come from reviewed reporting configuration
Retrieval result	Status, account and period, source coverage, metric definitions, values where usable, and retrievable evidence references
Report	Scope and source status, findings with supporting figures, hypotheses, limitations, and proposed investigations
Delivery	Checked private draft; external delivery follows the configured practitioner-approval policy
Failure	Missing values stay missing; partial retrieval stays partial; conclusions unsupported by the available evidence are withheld
Ownership	Named workflow, data, release, and operating owners; explicit time and cost limits

The dates make the examples concrete; a scheduled job resolves its completed week from the same reporting timezone. Different platforms can use different conversion definitions. Preserve those definitions and compare only compatible measures rather than forcing them into one total.

The tool guide develops the retrieval contract and the illustrative marketing report command. OpenClaw binds this procedure to an agent and destination. Portable Intelligence packages the same skill for teammates. These are design examples to implement and test, with no campaign results implied.

Give the whole system a clear division of responsibility

An agent system has several cooperating responsibilities. They need explicit owners, even when one application implements several of them.

Responsibility	What it owns in the weekly review
Model reasoning	Interpret the request, choose useful analyses, form hypotheses, and explain evidence
Harness	The software around the model: context, workflow state, tool calls, retries, budgets, cancellation, and stopping
Skills	Reusable procedures and domain guidance for recurring work
Operational data and tools	Verified account identities, metric definitions, source records, and supported operations
Validation and policy	Check data and requests; enforce account access, limits, approval, and result requirements
Execution environment	Run code and tools within defined filesystem, network, resource, and credential boundaries
Observation and evaluation	Record actual runs, investigate failures, and measure behavior across controlled tasks

The model can decide which comparison would help explain a trend. The provider or account service verifies which advertiser an identifier belongs to. Policy determines whether the read is allowed. A calculation service computes the agreed measure. The final explanation preserves the evidence and any uncertainty.

Reasoning, execution, controls, and feedback form one agent system.

This division leaves room for model judgment without making confidence a substitute for evidence or permission. A more capable model may find a better analysis or need fewer tool calls. The client boundary still applies.

Assign the implementation responsibilities

The brief needs a runtime that carries its client scope, source status, remaining budget, and completion state across calls. Context and memory must retain the source, age, and limitations of saved information. Neither a client preference nor cached data establishes current permission.

Give tools bounded operations and interpretable results, then assign an owner to each required check. The Anatomy guide traces those handoffs through a conversion-rate investigation. Here the design decision is which responsibilities the workflow needs and what evidence their implementation must produce.

For the review, tested code calculates the agreed metrics while the model investigates and explains changes. Two metrics moving together can suggest an investigation without proving that one caused the other.

Use skills to encode the parts that recur

A skill packages instructions for a recognizable task. It helps the agent know when a procedure applies, which inputs it needs, and what a good result contains. It is one part of the architecture, supported by tools and controls that exist independently of its instructions.

The six marketing patterns remain useful starting points:

Skill pattern	Example	What the surrounding system must support
Data retrieval and analysis	Weekly Google Ads and Meta review	Authorized account resolution, complete retrieval, consistent calculations
Campaign and creative generation	Placement-specific copy and creative directions	Approved brief and brand sources, format checks, review before publication
Experiment planning	Lifecycle subject-line or cadence test	Explicit hypothesis, primary measure, assumptions, sample needs, stopping rule
Quality and compliance review	Policy checks, landing-page review, tracking validation	Current rule sources, reproducible exact checks, expert escalation for ambiguity
Reporting and narration	Executive update or channel deep dive	Evidence-linked findings, clear coverage, uncertainty and limitations
Asset production	Resize, localize, prepare, and publish assets	File validation, access limits, approval, and confirmation of delivery

Start a skill by defining its outcome, trigger, required inputs, procedure, failure behavior, and output. The Agent Skills specification defines a folder with a SKILL.md file containing metadata and instructions, with optional supporting scripts, references, and assets. Runtime-specific features and tool availability still need testing in each intended host.

Here is the reference skills/weekly-performance-review/SKILL.md for this series. Keep the core procedure stable; host configuration supplies the actual tools, permissions, and destination.

---
name: weekly-performance-review
description: Prepare an evidence-linked paid-media performance review. Use for weekly or period-over-period campaign review requests.
---

# Weekly Performance Review

## Required inputs
- Client and approved provider account references
- Reporting and comparison periods, timezone, and currency
- Reviewed metric definitions, attribution, and materiality rules
- Permitted draft destination and applicable delivery-review policy

## Workflow
1. Resolve accounts within the authorised client scope.
2. Retrieve both periods through approved reporting capabilities.
3. Record source, dates, definitions, freshness, coverage, and failures.
4. Calculate changes and efficiency metrics using tested definitions.
5. Investigate material changes; separate findings from hypotheses.
6. Submit figures, evidence, coverage, and claims to report validation.
7. Return the checked draft, limitations, and proposed next steps
   through the permitted delivery path.

## Failure handling
- Clarify material account, date, or definition ambiguity.
- Preserve partial, unavailable, and stale results explicitly.
- Keep missing values distinct from zero; do not invent figures.
- Withhold comparisons that lack compatible inputs or coverage.
- Do not claim statistical significance from a percentage change alone.
- Stop at recommendations; this skill cannot change campaigns.

The validation step needs a metric checker, evidence references, and acceptance rules behind it. Review supporting scripts and version the package with its dependencies. Host-specific installation and tool bindings belong beside this procedure, so another host can reuse it without inheriting an inappropriate account or destination.

Validate facts and results; enforce guardrails at the boundaries

The series uses these terms consistently:

Term	Meaning
Validation	Check whether a particular input, evidence record, plan, or result meets its requirements
Guardrails and policy	Constrain access and operations within current permissions and limits
Evaluation	Measure how reliably a system version performs defined tasks across controlled trials
Observability	Record what happened in actual runs so outcomes and failures can be investigated

Verification establishes a claim with evidence, such as confirming account ownership or recording a test result. Human approval is a decision by an authorised person; a successful validation or favourable evaluation score does not supply that approval. Some checks support several purposes, but each must have an explicit owner.

For a marketing workflow, checks belong at several points:

Boundary	Check	Failure behavior
Before retrieval	Client ownership, account identity, permission, dates, supported fields	Deny unauthorized access; clarify genuine ambiguity
After retrieval	Required columns, units, pagination, freshness, source coverage	Mark incomplete or reject calculations that lack valid inputs
Before an action	Exact target, current state, policy limits, approval, expiry	Block or request the appropriate approval
Before delivery	Figures match source calculations; claims cite evidence; omissions remain visible	Repair, qualify, or withhold unsupported conclusions
After an action	The platform reflects the intended effect	Reconcile the result, report partial execution, or begin recovery

A schema can prove that a report has a client_id field. It cannot prove that the identifier belongs to the authorized client. A tool returning successfully cannot prove that it retrieved every required page. Design the authoritative check for each consequential fact.

Use code for exact, verifiable conditions and model assistance for judgments that require interpretation. For example, software can check character limits and recompute ratios. A model can flag an unsupported explanation or assess whether a summary answers the brief. Expert review remains necessary for material ambiguity or policy exceptions. A model judge’s favorable score must never grant platform permission.

If the review develops into a bid-change workflow, bind approval to the exact proposed effect. Recheck current state before execution, prevent repeat requests from applying the same effect twice, and verify the result afterward. Restoring a bid can reverse a setting; it cannot recover spend already incurred. The secure marketing-agent reference architecture develops that execution path in more detail.

Be precise about what the runtime actually enforces. If a required final check is only an instruction, document and test that limitation. Where an application must guarantee that an unvalidated report cannot be released, place an acceptance gate in the delivery path rather than relying exclusively on the model to remember a final step.

Specify deployment and delegation in the brief

Specify permitted files, network destinations, credentials, CPU, memory, time, and storage before release. Decide whether isolation follows the client, session, task, or trusted collaborating group. Anatomy’s deployment section compares sandbox and virtual-machine arrangements. The brief should state the boundary the job needs and how to test what the deployed worker can actually reach.

Record what survives a restart, how interrupted work resumes, and when temporary data and credentials are removed. Keep platform credentials behind narrow capabilities where possible. Execution isolation and business permissions remain separate requirements.

If an agent factory provisions workers, each generated configuration needs an owner, version, authority, and evaluation evidence. If a swarm divides the work, define child scopes, shared-state ownership, aggregate budgets, deadlines, and cancellation. The Anatomy guide owns the orchestration patterns and their failure cases; the brief should explain why that extra coordination is needed.

Define the evaluation plan before expanding the role

Evaluation asks how reliably a particular system version performs defined tasks under controlled conditions. It covers the model, harness, skills, tools, policies, and environment together. A workflow that passed once is useful debugging evidence; it gives little basis for estimating consistency.

Anthropic’s evaluation guidance distinguishes a test task, repeated attempts, the recorded interaction, and the final outcome. It describes code-based, model-based, and human graders, and separates capability evaluations from regression checks. For marketing, the practical consequence is to inspect the report or platform state as well as what the agent says it accomplished. Model-based grading needs calibration against expert judgment.

For the weekly reviewer, build cases from the actual requirements and failures:

Case	Evidence of an acceptable outcome
Complete data from both platforms	Correct accounts, dates, definitions, calculated figures, and supported findings
One platform times out	Available findings remain useful; missing coverage is explicit; no complete-review claim
Missing conversions or zero spend	Calculations follow defined handling; missing values are not silently replaced by zero
Two similarly named advertisers	Correct verified scope or a necessary clarification; no guessed account substitution
Retrieved text requests an unauthorized export	No forbidden data access or export occurs
A write is denied or an acknowledgement is lost	No false success claim, blind duplicate effect, or automatic scope widening
A delegated worker exceeds its deadline	Work stops within the system’s limits and the combined result identifies the gap

Use machine checks for known values, scope, required evidence, and actual effects. Use a clear scoring guide for analytical usefulness: does the explanation answer the question, distinguish evidence from hypotheses, and help a practitioner decide what to inspect next? Let channel experts judge representative cases and calibrate any model grader against those judgments.

Run repeated trials from clean test state with a known configuration. Record failures, variation, cost, and latency. Keep difficult capability cases alongside regression cases for behavior already accepted. Grade valid outcomes flexibly: a different analysis sequence may be better. Enforce ordering where it protects a real invariant, such as authorization before data access or approval before a write.

Test the evaluators too. Known-good outputs should pass; deliberately incorrect figures, fabricated sources, hidden omissions, and wrong-client results should fail the relevant checks. Keep some cases separate from the examples used to tune the skill, and add incidents as new regression cases after removing sensitive data.

Avoid a single average that lets a polished report offset an unauthorized action. Report quality, completion, critical boundary violations, operational reliability, cost, and time separately. The release owner should define the required evidence and acceptable thresholds before seeing the candidate’s scores. Passing a finite test suite supports a release decision; it cannot establish that every future run will be correct.

Specify the evidence operators will need

Each job should connect its request and client scope to the system version, source coverage, tool outcomes, validation decisions, approvals, and delivery or campaign effects. Include failed and denied operations. Store only purposeful evidence, with access and retention appropriate to its sensitivity.

The brief should name who can stop work, revoke access, investigate partial effects, and approve a repair. A missing or failed probe cannot support an “all clear” finding. The OpenClaw guide makes those operating duties concrete; the maintenance guide develops the path from an incident to a checked repair and a reviewed harness improvement.

Hand off a brief and a reusable skill

A deployable version includes more than a skill file. Record the model configuration, harness and tool versions, skill bundle, policy version, dependencies, environment image, and evaluation configuration. This makes a regression traceable and allows the team to restore a previous configuration. Reverting software does not automatically reverse external campaign effects.

The design handoff is ready when the team has a reporting brief, the reusable skill, named owners for controls, an evaluation plan, and a versioned release description. Anatomy is the next step: deciding how the runtime carries those requirements through an actual investigation. Pilot within the approved scope before adding broader access or autonomous changes.

The same discipline applies to creative generation, experiment design, compliance review, and asset production. The required evidence changes with the task. The architectural question stays consistent: can the team explain how a request became a result, which facts and authority supported it, and what demonstrates that the system works well enough for its intended role?

Publication history

Originally published by Performics Labs Newsroom.