What is an agent action capsule?

An agent action capsule is a proposed unit of exchange for agentic systems: one signed object containing an intended action, the identity of the agent requesting it, the constraints it must run under, and the provenance of how it came to be. A system that receives a capsule can verify all of that locally, before execution, without trusting whoever delivered it.

The term describes an emerging pattern rather than a published standard. Think of it the way engineers thought about the container before Docker: the pieces existed, the packaging did not.

Today an agent's tool call is a JSON blob interpreted by whatever receives it. Inside a single vendor's stack that is tolerable, because one operator controls every hop. Across organizations it collapses. The receiver cannot tell whether the parameters were altered in transit, whether the requesting agent is who the payload claims, or whether the action was ever authorized at its origin. Logs on each side disagree, and after an incident nobody can produce the authoritative record of what was actually requested.

Transport security does not fix this. TLS protects the pipe, not the object. The moment an action is stored, queued, forwarded, or replayed, channel guarantees evaporate.

The capsule idea composes several proven techniques rather than inventing new cryptography:

• Signed envelopes: DSSE and in-toto attestations bind a signature to a payload and its type, so verification travels with the object
• Capability tokens: Biscuit and UCAN carry permissions and delegation chains inside the credential, with attenuation on every hop
• Content provenance: C2PA demonstrated industry appetite for signed manifests describing how a digital object was produced
• Workload identity: SPIFFE-style identities give the signing agent something verifiable to sign as

A workable capsule format needs a small, boring core. The plausible fields:

• Action: a typed operation and its full parameters
• Subject: the verifiable identity of the requesting agent
• Constraints: expiry, spend limits, allowed targets, required approvals
• Provenance: the task, model, and policy context that produced the intent
• Authorization: the decision or delegation chain that permits the action
• Seal: signatures over all of the above, in a format verifiers already speak

Real design work remains. Should constraints be a closed vocabulary or an extensible one, and who resolves disputes about semantics? How do capsules handle actions whose parameters are large or streaming? What does revocation look like for an object designed to be verifiable offline? The answers will come from whoever ships the reference implementation and the test suite.

A format war is plausible here, and format wars are won partly on naming. The team that owns the plain-language name for the object starts that contest ahead.