The Agent Card Is the New Control Document

A production agent with no control document is an anonymous actor holding production credentials. That is the default state of nearly every agent running in a company today.

• Adoption is effectively universal: roughly nine in ten organizations use AI in at least one function.
• Agents in production sit in the single digits.

The gap is not about capability. It is about governance, and it has a specific shape. The company 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 agent work, what each of its fields controls, why it must be configuration rather than knowledge in someone's head, 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 earlier inventions made complex systems governable, and both did it the same way: they attached a control document to the unit of work.

The org chart made human accountability visible. Before it, large organizations had people doing things. After it, every role had an owner, a scope, a reporting line and a clear point where authority started and stopped. It did not make people more capable. It made who answers for what something anyone could see, which you need before you can hand off 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 each part carried its own origin and its own proof.

Autonomous software work has neither. An agent reads systems of record and takes actions against them, and the company's only record of what it is and what it may do is usually the memory of the person who built it. That is the state before the org chart and before the bill of materials: capability without visible accountability.

The agent card is the missing control document, and the comparison holds exactly. It makes an autonomous actor traceable, scoped and auditable, the way the bill of materials made a part traceable 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 company 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 records its decisions about one agent.

The two questions have almost nothing to do with each other:

• The first depends on model quality and prompt design, and since the frontier model is a commodity, every competitor can clear it on the same terms.
• The second depends on 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 companies 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 approve production. The card is not paperwork added to a working agent. It is what turns "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 kind of facts a data sheet records for a part. Every field does real work: each closes a specific way pilots fail on the way to production.

Three of these fields are themselves named, versioned items 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. A reviewer reads one document and knows what proof, what controls and what value claim stand behind the agent.

4. Configuration, not knowledge in someone's head: the manifest

The most important property of the card is that it is a file. It is versioned, comparable line by line, readable by anyone with access and independent of the person who wrote it. Knowledge in someone's head does not survive a reorg, a resignation or an audit request. Configuration does.

Below is the agent card for a Month-End Closer agent working 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, and it serves the CFO in record-to-report.
• It is high risk, because it can post journals.
• It can run on either of two providers, routed to the cheapest one that clears the eval bar.
• It can draft a journal but cannot post one without human sign-off, and a material adjustment escalates.
• It produces journal entries, reconciliation evidence and an exception report.
• It is measured on close days and the audit-adjustment rate, with named attribution methods.

None of that required finding the engineer. The two human_approval triggers are the whole line between an agent that drafts the close and one that commits it to the ledger. In a world where that knowledge lives in someone's head, that line is a comment in a script 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 move between states is a reviewable event rather than a quiet deploy.

The gates between states are the point.

• An agent cannot enter an enterprise pilot without a baselined value card.
• It cannot enter production without a passing eval pack and a live control pack.

The card makes those conditions explicit and checkable, instead of a judgment call in a deploy meeting.

Underneath the lifecycle, every component versions on its own: prompt, skill, model, tool, data product, policy and eval pack. A model swap, a tighter segregation-of-duties 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 exactly the silent change that breaks a control environment, and the card exists to prevent it.

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 item. The agent card is the second kind, and it does four jobs documentation never does.

• Ownership. A named human is accountable for the agent's behavior and its value claim. No agent reaches production without an owner on its card, which removes the orphaned-automation failure: 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 piece together what the agent did from logs and memory; they read the evidence ledger the control pack required. The card is what makes "the agent posted this entry" a statement with a paper trail behind it.
• Change management. Versioned fields and gated lifecycle moves mean nothing reaches production without passing its eval pack and clearing its approvals. A change is a diff against an earlier version of the card, reviewable like any other controlled change. That is the difference between an agent that drifts silently and one where every change is an event.
• The precondition for value and scale. The value card is a field on the agent card, so 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 money to scale. That one dependency turns a pile of experiments into a managed portfolio. Every agent in production carries a baseline, a target and an owner, and the board can back the portfolio because every line in it is measured.

This is why the card is the document that makes an agent ready for the enterprise. 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 approve the same agent, because each of them can read, in one place, the answer to the question they are accountable for.

7. The view ahead

As agents move from the single digits toward routine production, the agent card becomes the document procurement, audit and finance all ask for by name, the way a data sheet is the first thing an engineer asks for 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 readable by a reviewer who never met the builder.
• Expect "an agent in production with no card" to become an audit finding, in the same category as an unsegregated duty or an unreconciled account.

The card is also the link 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. 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.