Every production agent needs a control document, and most have none.
Other kinds of work already have one:
- The org chart made human accountability clear: every role has an owner, a scope and a reporting line.
- The bill of materials and the data sheet made a physical part traceable: every component has a supplier, a spec, a tolerance and a test.
Autonomous work running against live systems has nothing like it. That gap is exactly why nine in ten enterprises have adopted AI while only single-digit percentages have agents in production.
An agent without a control document is an anonymous actor with production access. The document that fixes that is the agent card.
What separates a demo from a capability you can deploy
A pilot proves an agent can do the work once. A card is what makes the company willing to let it do the work ten thousand times, against systems of record, with a CFO's name on the result.
The difference is not model quality or a clever prompt. It is whether these facts are written down where change management and audit can read them:
- who owns the agent,
- what it is for,
- what it is allowed to do,
- when it must stop for a person,
- what evidence it leaves,
- how it is tested, and
- what value it claims.
If those live only in the head of the engineer who built it, they will not survive that engineer's next sprint, let alone an audit. Written configuration does. The agent card is that configuration: the one record that turns a clever automation into a governed capability the company can fund, audit and scale.
The agent card's fields
The card records the same facts a bill of materials records about a part, adapted for autonomous work. Each field guards against a specific way things go wrong.
| Field | What it controls |
|---|---|
| Owner | Accountability: a named person answers for the agent's behavior and its value claim |
| Purpose | Scope: the one job it does, so scope creep is visible and can be reviewed |
| Persona | The seat it serves (CFO, CIO, operator, builder), which sets the bar for its outputs and review |
| Process | The value stream it works in (L2C, S2P, F2F, P2P, R2R), so its impact maps to an area the business already manages |
| Provider / model | Works with any model: switch providers as the market moves without rebuilding the workflow |
| Tools | The exact actions it can take, and the ones it cannot: the limit on how much damage it could do |
| Data products | The trusted, sourced and dated inputs it reads, not whatever it can reach |
| Risk tier | How tight the controls are, how deep the approvals go and how often it is reviewed |
| Human-approval triggers | The actions that stop for a person before they commit: posting, payment, material change |
| Outputs | What it produces and where it lands, so the people downstream know what to trust |
| Eval pack | Golden cases, policy tests, grounding tests, adversarial cases and regression tests: the proof it still works |
| Control pack | Approvals, segregation of duties, evidence capture, restricted actions, audit trail |
| Value card | Baseline, target, value lever, owner and how results are attributed: the basis for funding |
The eval pack, control pack and value card are real, named pieces of the harness, not descriptions. The card is where an agent states which ones it carries.
Configuration, not tribal knowledge
The card is a file, versioned alongside the agent. Here is the card for a Month-End Closer running record-to-report:
agent_id: koko.r2r.month_end_closer
owner: controller@enterprise.com
persona: CFO
process: record_to_report
risk_tier: high # touches the ledger; posts journals
provider_options: # works with any model; route to the cheapest that clears the bar
- anthropic/claude-sonnet
- openai/gpt-tier
tools:
- ledger.read
- subledger.reconcile
- journal.draft
- journal.post # gated below
data_products:
- gl.trial_balance
- subledger.ap_ar
- close.checklist
human_approval:
required_for:
- journal_posting
- material_adjustment
outputs:
- close.journal_entries
- close.reconciliation_evidence
- close.exception_report
value_levers:
productivity: { baseline: close_days, target: -2_days }
risk: { baseline: audit_adjustment_rate, target: down }
eval_pack: r2r.month_end.v4 # golden closes, policy tests, adversarial entries
Read it once and you know who owns it, what it touches, what it cannot do without a person, and how its value is measured, without having to find the engineer.
The two human-approval triggers are the line between an agent that drafts the close and one that commits it. Drop the card and those triggers become a code comment nobody audits.
How a card moves from draft to retired
The card follows the agent through its life. It records which stage the agent is in and what changed to get there:
- Draft: fields proposed, owner assigned, not yet able to run.
- Demo: runs once in a sandbox to prove the task is possible.
- Beta: runs on real data under close supervision while its tests take shape.
- Enterprise pilot: runs in one business unit under the full control pack, with a value baseline set.
- Production: runs at scale, with approvals live, evidence flowing and value tracked against target.
- Retired: switched off, with the card kept as the audit record of what it did and why it stopped.
Every part is versioned on its own: prompt, skill, model, tool, data product, policy and eval pack. A model switch, a tighter policy or a new test case is a new version of the card, not a silent change in production. Change management gets a diff; audit gets a history.
Why it is a control document, not documentation
Documentation describes a system after the fact. A control document governs it before the fact. The agent card does four control jobs at once:
- It fixes ownership. A named person answers for the agent, so no automation is left with production access and no owner.
- It makes the agent auditable. Every consequential action leaves evidence a reviewer can trace.
- It enforces change management. Nothing reaches production without passing its tests and clearing its approvals.
- It is the precondition for funding. No card, no value card; no value card, no scale funding. That rule turns a pile of experiments into a managed portfolio a board can back.
The question is no longer "can an agent do this task?" It is "can we let this agent change a production result, prove it stayed within its limits, and show what it was worth?" The card is the only place that answer can be written down, and the only thing that makes the next layer, value, fundable.
This is the second piece of The Harness Era, an eight-part series. The full-length analysis, with the complete card, the reasoning behind each field and the lifecycle gates, is linked below. Next: Why CFOs Should Fund Agents Like Value Streams, on how the value card turns AI spend into an owned asset that compounds.