The next trust problem in AI agents is not only whether the model behaves. It is whether the capability the agent uses has been inspected before it enters the workflow.
That sounds small until the agent starts doing real work. A human can usually tell the difference between a tool they understand and a mystery shortcut someone pasted into a process. Agents cannot make that distinction unless the operating system gives it to them. They can call a skill, follow an instruction bundle, invoke a connector, retrieve a document, or apply a rule without knowing whether that capability is current, owned, limited, safe, or even meant for the situation in front of it.
This is where the market is moving now. The first wave of agent governance focused on model behavior and runtime guardrails. That was necessary, but it left a quieter layer under-governed: the capability layer. If an agent is going to borrow a skill, that skill needs a receipt.
A capability receipt is the operating record attached to a thing an agent is allowed to do. It says what the capability is for, who owns it, what it depends on, what it is not allowed to do, what evidence it requires, which authority it carries, and when the agent must stop. Without that receipt, the business is not governing a capability. It is trusting a bundle.
The skill layer is becoming a trust layer
NVIDIA put a useful marker down on May 19 with its post on verified agent skills. The important phrase was not the product name. It was the reason for the product: scaling agents with “structural transparency and operational integrity requires more than runtime guardrails.”
That sentence names the shift. Guardrails around execution matter, but they do not fully answer what entered the workflow in the first place. NVIDIA’s verified skills are described as portable instruction sets that are cataloged, scanned, signed, and documented with a machine-readable skill card. The skill card records ownership, dependencies, limitations, risks, mitigations, and verification status.
That is not just developer housekeeping. It is a new expectation for agent operations. If skills are going to move across coding tools, registries, enterprise platforms, and internal workflows, provenance becomes part of safety. The agent should not merely know that a capability exists. The organization should know where it came from, what it is supposed to do, what was checked, and what changed after publication.
The practical lesson is simple: a capability without a receipt is an uninspected tool in the hands of a nonhuman worker.
That does not make the capability bad. It makes it incomplete. In a small demo, incompleteness hides because the human operator knows the boundaries. In production, the human context disappears. The agent sees an available move and takes it. If the limits were only in someone’s head, the system has already lost the plot.
Retrieval is not applicability
A second signal appeared in VentureBeat’s May 21 piece on enterprise agents that fail because they forget what they learned. The strongest line came from the discussion around decision context: “RAG retrieves documents, not decision context.” Another operator named the same problem as the “gap between retrieval and applicability.”
That gap is where a lot of agent failures are born. Retrieval can find a policy. It does not automatically tell the agent whether the policy is still current, whether it applies in this jurisdiction, whether an exception supersedes it, whether a newer operating rule takes priority, or whether the task is the kind of task the agent is allowed to touch.
Humans handle that mess with context, memory, judgment, and escalation. They know that a pricing exception expired, that a supervisor changed the rule last week, that one customer has a special contract, or that the documented process is not the process used in the field. An agent needs those distinctions represented explicitly. Otherwise it can retrieve the right-looking document and still do the wrong thing with confidence.
This is why capability receipts and decision context belong together. The receipt says what the capability is and when it is allowed to operate. Decision context says which facts, rules, time bounds, and exceptions apply to the current situation. One governs the tool. The other governs the situation. A production agent needs both.
Most failed pilots are not failing because the model cannot read. They fail because reading was mistaken for authority.
The receipt should be boring on purpose
The right receipt is not a giant compliance artifact. It should be boring, legible, and close to the work.
For each agent capability, the receipt should answer eight questions:
- What is this capability’s job?
- Who owns it?
- What inputs is it allowed to use?
- What systems or dependencies does it touch?
- What limits, exclusions, or known risks does it carry?
- What evidence must be present before the agent can use it?
- What authority does it grant: draft, recommend, change, send, spend, approve, or escalate?
- What condition makes the agent stop?
Those questions are plain enough for an operator and precise enough for an engineer. That is the point. If only the technical team can understand the capability, the business cannot govern it. If only the business can describe it loosely, the system cannot enforce it. The receipt is the handshake between operational intent and machine execution.
Take a sales agent that can update CRM opportunities. The capability receipt should not say “CRM updater.” That is too vague. It should say the agent may update stage, next step, and contact notes when the source is a current email thread or call transcript. It may not change price, probability, close date, contract status, or owner without human approval. It must show the source evidence beside the proposed change. It stops if the source conflicts with an existing signed agreement or if the opportunity is above a named value threshold.
That receipt does not slow the agent down. It tells the agent where speed is safe.
Now take a legal navigation assistant. A vague capability might say it can help self-represented litigants prepare forms. A real receipt would separate general navigation, document organization, procedural reminders, jurisdiction-specific information, and legal advice boundaries. It would specify escalation points, source requirements, disclaimers, and stop conditions. That matters because access-to-justice tools are now being judged not only by availability, but by whether outcomes improve. LawNext’s May 21 analysis of Claude’s legal and access-to-justice push asked the correct hard question: do these tools measurably help people, or do they simply make legal-sounding help easier to access?
The receipt is not the whole answer, but it is part of the operating discipline that makes an answer possible.
Capability governance beats agent theater
Agent theater celebrates motion. The agent opened the tool, found the document, wrote the reply, moved the card, updated the record, or drafted the form. It looks alive, so the room relaxes.
Production cannot relax there. Production has to ask what capability was used, whether the capability was current, whether it applied to the situation, what authority it carried, what evidence it saw, and where the execution trail points if something goes wrong.
This is where Stephen’s operating view is sharper than normal AI commentary. The useful unit is not “an agent.” The useful unit is a defined job moving through a governed workflow with measurable output, clean routing, safe authority, and review where it matters. Capabilities are subordinate to that job. They are not magic powers. They are work instruments.
A business that treats capabilities as magic powers will keep bolting on controls after the fact. It will add dashboards, logs, admin panels, review queues, and policy pages. Some of that will help. None of it replaces knowing what the agent was allowed to do before it did it.
A business that treats capabilities as work instruments can govern earlier. It can require receipts before execution. It can test capabilities before they are reused. It can retire stale skills. It can assign owners. It can keep authority narrow. It can make review visible at the decision point instead of after the mess.
The capability receipt is small, but it changes the posture. The question becomes less “Do we trust the agent?” and more “Which inspected capabilities is this agent allowed to use in this situation?”
That is the question production teams can actually answer.
The protocol
Before adding another agent to a workflow, map the capabilities it will borrow. Do not start with the model. Start with the work.
Name the job. List the actions required to complete the job. For each action, name the capability the agent needs. Then attach a receipt to each capability. If the receipt cannot be written clearly, the capability is not ready for production use. It may still be a prototype, but it should not be treated as governed operating capacity.
The protocol is deliberately plain:
- Define the agent’s job in one sentence.
- Break the job into capabilities.
- Write a receipt for each capability.
- Attach decision context: what applies, when, and under which exceptions.
- Set the authority level for each capability.
- Put the stop condition beside the work.
- Log the execution trail in a way a responsible human can inspect.
- Revoke or revise stale capabilities instead of letting old instructions keep circulating.
This is not anti-autonomy. It is how autonomy becomes usable. The capability remains powerful because the business knows what it is. The agent becomes safer because authority is attached to inspected work, not ambient access.
The next durable agent systems will not be the ones with the longest tool list. They will be the ones where every meaningful capability can show its receipt before execution.
Stephen Nickerson.
Built for operators who need AI agents they can test, trust, and improve.