A production agent with no control document is an anonymous actor holding production credentials, and that is the default state of nearly every agent running in an enterprise today. Adoption is effectively universal — roughly nine in ten organizations use AI in at least one function — while agents in production sit in the single digits. The gap is not a capability gap. It is a governance gap, and it has a specific shape: the enterprise can prove an agent works once, in a demo, but cannot say who owns it, what it is allowed to touch, when it must stop for a human, what evidence it leaves, or what it is worth. Those are the facts a control document records. For autonomous work, that document is the agent card.
This is the long-form case behind the second essay in the series: why the card is the unit of deployable agentic work, what each of its fields controls, why it must be configuration rather than tribal knowledge, and how it carries an agent from draft to retirement under change management and audit.
1. The precedents: every governable system got a control document first
Two prior inventions made complex systems governable, and both did it the same way — by attaching a control document to the unit of work.
The org chart made human accountability legible. Before it, large organizations had people doing things; after it, every role had an owner, a scope, a reporting line, and a place where authority started and stopped. It did not make people more capable. It made who-answers-for-what visible, which is the precondition for delegating consequential work at scale.
The bill of materials and the data sheet did the same for physical parts. A component on an assembly line is not trusted because someone remembers building it; it is trusted because it traces to a supplier, a specification, a tolerance band, and a test result. The data sheet is the contract: this part does this, within these limits, verified this way. Manufacturing scaled because the part carried its own provenance and its own proof.
Autonomous software work has neither. An agent reads systems of record and takes actions against them, and the enterprise's only record of what it is and what it may do is, typically, the memory of the person who built it. That is the pre-org-chart, pre-bill-of-materials state — capability without legible accountability. The agent card is the missing control document, and the analogy is exact: it makes an autonomous actor sourceable, scoped, and auditable the way the BOM made a part sourceable and the org chart made a role accountable.
2. What separates a demo from a deployable capability
A pilot answers one question: can this agent do the work? A deployable capability answers a harder one: will the enterprise let it do the work ten thousand times, against production systems, with a named executive accountable for the result? Everything between those two questions is the harness, and the agent card is where the harness's decisions about a given agent are recorded.
The distinction matters because the two questions have almost nothing to do with each other. The first is a function of model quality and prompt design — and the frontier model is a commodity, so every competitor can clear it on the same terms. The second is a function of ownership, permissions, approval gates, evidence, tests, and a measurable value claim. None of those live in the model. They live in the card, or they live nowhere.
This is why so many enterprises are stuck: they bought the thing that answers the first question and skipped the thing that answers the second. They have agents that demo well and no document that would let a controller, a CIO, or an audit lead say yes to production. The card is not paperwork bolted onto a working agent. It is the artifact that converts "works once" into "can be deployed, governed, and funded."
3. The agent card's fields, and what each one controls
The card records, for one agent, the same class of facts a data sheet records for a part. Each field is load-bearing — it closes a specific failure mode that, left open, is where a pilot dies on the way to production.
| Field | What it records | What it controls |
|---|---|---|
| Owner | The named human accountable | Orphaned automation — every agent answers to a person, not a team alias |
| Purpose | The single job it does | Scope creep — a one-line purpose makes expansion visible and reviewable |
| Persona | The seat it serves (CFO, CIO, operator, builder) | The review bar and output standard the agent is held to |
| Process | The value stream it acts in (L2C, S2P, F2F, P2P, R2R) | Impact attribution — work maps to a domain the business already manages |
| Provider / model | The model(s) it may run on | Vendor lock-in — model-agnostic routing as the frontier moves and prices fall |
| Tools | The exact actions it can and cannot take | Blast radius — the hard boundary of what the agent can do to production |
| Data products | The trusted, sourced, dated inputs it reads | Grounding — the agent reads vetted data, not whatever it can reach |
| Risk tier | The control intensity it is governed at | Proportionality — approval depth and review cadence match the stakes |
| Human-approval triggers | The actions that stop for a person | Irreversibility — commits, payments, and material changes get a human |
| Outputs | The artifacts it produces and where they land | Trust downstream — consumers know what the agent emits and where |
| Eval pack | Golden cases, policy tests, grounding tests, adversarial cases, regression | Silent drift — proof the agent still does the job after any change |
| Control pack | Approvals, segregation of duties, evidence, restricted actions, audit | Auditability — every consequential action is traceable after the fact |
| Value card | Baseline, target, value lever, owner, attribution method | Fundability — the agent carries a measurable thesis, not a usage stat |
Three of these fields — eval pack, control pack, value card — are themselves named, versioned artifacts in the harness, not adjectives. An eval pack bundles the golden cases, policy tests, grounding tests, adversarial cases, and regression suite that prove the agent behaves. A control pack bundles the approvals, segregation-of-duties rules, evidence capture, restricted-action list, and audit trail. A value card bundles the baseline, target, value lever, owner, and attribution method. The agent card is where an agent declares which of each it carries, so a reviewer reads one document and knows what proof, what controls, and what value claim back the agent.
4. Configuration, not tribal knowledge: the manifest
The single most important property of the card is that it is a file — versioned, diffable, readable by anyone with access, independent of the person who wrote it. Tribal knowledge does not survive a reorg, a resignation, or an audit request. Configuration does. The manifest below is the agent card for a Month-End Closer agent operating in 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 general ledger; can post journals
provider_options: # model-agnostic; route to cheapest model that clears the eval bar
- anthropic/claude-sonnet
- openai/gpt-tier
tools:
- ledger.read
- subledger.reconcile
- journal.draft
- journal.post # gated by human_approval below
- close.checklist.update
data_products:
- gl.trial_balance
- subledger.ap_ar
- close.checklist
- prior_period.close_pack
human_approval:
required_for:
- journal_posting # nothing hits the ledger without sign-off
- material_adjustment # threshold-crossing entries escalate
outputs:
- close.journal_entries
- close.reconciliation_evidence
- close.exception_report
value_levers:
productivity:
baseline: close_days
target: -2_days
attribution: pre_post_cycle_time
risk:
baseline: audit_adjustment_rate
target: reduce
attribution: control_test_pass_rate
eval_pack: r2r.month_end.v4 # golden closes, policy tests, grounding tests, adversarial entries, regression
control_pack: r2r.high.v3 # SoD between draft and post, evidence ledger, restricted actions, audit trail
lifecycle: production
version:
prompt: 7
skill: 3
model: pinned@sonnet
tools: 2
data: 4
policy: 3
eval: 4
Read it once and you know: a controller owns it; it serves the CFO in record-to-report; it is high risk because it can post journals; it may run on either of two providers, routed to the cheapest that clears the eval bar; it can draft a journal but cannot post one without human sign-off, and a material adjustment escalates; it emits journal entries, reconciliation evidence, and an exception report; and it is measured on close days and audit-adjustment rate with named attribution methods. None of that required finding the engineer. The two human_approval triggers are the entire line between an agent that drafts the close and one that commits it to the ledger — and in a tribal-knowledge world that line is a comment in a script that no auditor will ever see.
5. The lifecycle: draft to retired, on the card
The card is the unit of lifecycle. An agent is always in exactly one state, the card records it, and every transition is a reviewable event rather than a quiet deploy.
| State | What is true | What the card requires to advance |
|---|---|---|
| Draft | Fields proposed, owner assigned, not executable | A complete card and a named owner |
| Demo | Runs once in a sandbox to prove the task is possible | Evidence the task succeeded once |
| Beta | Runs on real data under heavy supervision | A forming eval pack; supervised runs logged |
| Enterprise pilot | Runs in one business unit under full control pack | Control pack live; value card baselined |
| Production | Runs at scale, approvals live, evidence flowing | Eval pack passing; value tracked vs target |
| Retired | Decommissioned | Card archived as the durable record of what it did |
The gates between states are the point. An agent cannot enter enterprise pilot without a baselined value card, and cannot enter production without a passing eval pack and a live control pack. The card makes those preconditions explicit and checkable instead of a matter of judgment in a deploy meeting.
Underneath the lifecycle, every component versions independently — prompt, skill, model, tool, data product, policy, eval pack. A model swap, a tightened SoD rule, or a new adversarial case is a version bump recorded on the card. Change management gets a diff it can review; audit gets a history it can replay. The alternative — editing a prompt in production with no record — is precisely the silent change that breaks a control environment and that the card exists to prevent.
6. Why it is a control document, not documentation
Documentation describes a system after it is built, for the convenience of whoever reads it next. A control document governs the system before and during operation, and is itself a controlled artifact. The agent card is the second kind, and it does four control jobs that documentation never does.
Ownership. A named human is accountable for the agent's behavior and its value claim. There is no agent in production without an owner on its card, which eliminates the orphaned-automation failure mode — the script someone stood up, forgot, and left holding production access.
Auditability. The control pack and the declared outputs mean every consequential action leaves traceable evidence. An auditor does not reconstruct what the agent did from logs and memory; they read the evidence ledger the control pack required. The agent card is what makes "the agent posted this entry" a statement with a paper trail behind it.
Change management. Versioned fields and gated lifecycle transitions mean nothing reaches production without passing its eval pack and clearing its approvals. A change is a diff against a prior version of the card, reviewable like any other controlled change. This is the difference between an agent that drifts silently and one whose every modification is an event.
The precondition for value and scale. The value card is a field on the agent card, which means an agent cannot be funded as a value stream until it has a card to carry the value card. The rule is blunt and it compounds: no agent card, no value card; no value card, no scale funding. That single dependency converts a pile of experiments into a managed portfolio — every agent in production carries a baseline, a target, and an owner, and the board can underwrite the portfolio because every line in it is instrumented.
This is why the card is the document that makes an agent enterprise-ready. It is not the smartest part of the stack and it is not the hardest to build. It is the part that lets a CFO, a CIO, and an audit lead all say yes to the same agent — because each of them can read, in one place, the answer to the question they are accountable for.
7. The forward view
As agents move from single digits toward routine production, the agent card becomes the artifact procurement, audit, and finance all ask for by name — the way a data sheet is the first thing an engineer requests before designing a part in. Expect the card to standardize: a common schema for owner, purpose, tools, data products, risk tier, approvals, eval pack, control pack, and value card, portable across the harness and legible to a reviewer who never met the builder. Expect "uncarded agent in production" to become an audit finding, the same class of exception as an unsegregated duty or an unreconciled account.
The card is also the seam to the next layer. Once every agent carries a value card as a field, funding stops being a debate about usage and becomes a portfolio decision about value streams — baselines, targets, owners, and attribution, managed the way a CFO already manages revenue, margin, working capital, productivity, and risk. The org chart made people governable; the bill of materials made parts governable; the agent card makes autonomous work governable — and the moment it does, the conversation moves from can this agent run to what is this agent worth, which is the subject of the next piece.