Why AI Agents Need Contracts, Not Just Prompts

The industry learned to write prompts before it learned to govern agents, and that order of operations is now a problem. A prompt is an instruction: do this, in this style, with this goal. It is a genuinely useful way to direct a capable system, and I am not going to pretend otherwise. But somewhere along the way the prompt got mistaken for a control mechanism, and it is not one. A prompt describes what you want the agent to attempt. It says nothing about what the agent is permitted to do, and in an enterprise those are entirely different questions.

I made a version of this argument earlier about output quality: the prompt is not the product, because quality comes from context, data, and verification rather than from the wording of the request. The governance version is sharper. When an agent can act, use tools, touch data, and produce effects, the wording of its instruction is not what protects the organization. What protects the organization is an explicit statement of authority: what this agent may do, on what, with what evidence, and under whose accountability. That statement is a contract, not a prompt, and the difference is the whole subject of this essay.

Consider the asymmetry. A creative writing tool governed by a clever prompt that goes off-script produces a bad paragraph. An enterprise agent with access to systems that goes off-script initiates a transaction, exposes data, or triggers a downstream action that other systems treat as authorized. In the enterprise, authority matters more than creativity, and the mechanism of control has to be built for authority. A prompt was never built for that.

What a prompt cannot do

Be concrete about the gap. A prompt does not define the boundary of an agent's authority; it describes a task inside an unstated, unbounded space of possible actions. It does not specify which data the agent may access or which tools it may invoke; it assumes whatever access the runtime happens to grant. It does not state what evidence the agent must produce to support what it did. It does not say when the agent must stop and escalate to a human. It does not create an audit trail. And it does not answer the question that matters most when something goes wrong: who was accountable for this action.

Those omissions are invisible in a demo and catastrophic in production. They are the same omissions I described in Expert Judgment as a Control Layer, where a human glancing at output is not the same as governing it. Governing delegated machine work requires standards, evidence, authority, and escalation as explicit mechanism. A prompt supplies none of them, which means an agent governed only by a prompt is, from the enterprise's point of view, an actor operating with undefined authority and no record. No organization would let a human employee operate that way. It should not let an agent.

A prompt tells an agent what to attempt. A contract tells the enterprise what the agent was allowed to do.

What a delegation contract answers

A delegation contract is the missing mechanism: an explicit, inspectable statement of the authority under which an agent acts. It is not a prompt with more words. It is a different kind of object, one built to be read by the enterprise as much as by the agent, and it answers the questions a prompt leaves open.

Who is the principal, the named party who authorized this agent and is accountable for what it does. What is being delegated, the specific work and its intent. What authority is granted, stated as an enumerated scope with the default set to deny, so that anything not explicitly permitted is forbidden rather than assumed. What data and tools are in scope, and with what permitted operations. What evidence the agent must produce to support its decisions. When the agent must escalate, the conditions under which it suspends its own action and routes the decision to a human. What happens on violation, the behavior when the agent hits a boundary, which for consequential work should fail closed rather than proceed. And who remains accountable throughout, so that responsibility never disappears into the software.

State those things explicitly and you have something an enterprise can actually govern: authority that is bounded, evidence that is required, escalation that is defined, and accountability that is owned. Leave them implicit in a prompt and you have none of it, however good the prompt.

A concrete expression, honestly framed

This is not purely a thought experiment. The Agent Delegation Contract, an open specification R2 Advisory maintains, is one concrete attempt to express exactly this: a machine-readable contract that states an agent's principal, authority, constraints, evidence requirements, escalation conditions, and violation behavior, so that delegated machine work can be bounded and audited. I will be honest about its maturity. It is an early, working draft, not a settled industry standard, and it composes above the identity and policy infrastructure enterprises already run rather than replacing it. The point of naming it here is not to sell it. It is to show that the need is concrete enough that people are building formal answers to it, and that the shape of those answers is a contract, not a better prompt.

The deeper reason this matters is that a contract is only a promise until something enforces it. A statement of authority the agent can ignore, or that no system checks, is documentation, not control. A delegation contract defines permitted action. Cybersecurity enforces permitted action. That single division of labor is why the next arc of this series turns from agents and contracts to identity, provenance, autonomy risk, and trust architecture. If agents need contracts, then security is no longer only about keeping intruders out. It becomes the layer that governs what authorized machine actors are allowed to do: identity for non-human actors, provenance for the information they act on, and fail-closed control when they reach the edge of their authority. A prompt tells an agent what to attempt. A contract tells the enterprise what the agent was allowed to do. Security is what makes the contract true.