How it works
An agent-run contract turns an open-ended instruction into an enforceable execution boundary. The harness creates the contract before the run begins, binds it to the run identifier, and checks actions and state transitions against it. The contract should be structured data, even if part of it is rendered as prose for the agent.
A useful contract records:
- Outcome: the observable state the run is expected to produce.
- Scope: the files, systems, records, and subtasks that are in bounds.
- Authority: the tools, credentials, operations, and approval levels available to the run.
- Limits: budgets for time, iterations, tool calls, cost, or affected resources.
- Stop conditions: events that end, pause, or invalidate execution.
- Completion evidence: artifacts and checks required before success can be reported.
- Escalation path: what the harness does when the agent cannot continue safely.
The harness, not the model, owns enforcement. A model may interpret the objective and propose actions, but deterministic controls should reject operations outside the contract. The runner should also record amendments. Quietly widening scope midway through a run makes the original contract useless as an audit and recovery boundary.
Why it matters in an agent harness
A prompt tells an agent what work appears desirable. A run contract tells the harness what execution is acceptable. That distinction matters once the agent can modify files, call services, spend resources, or delegate work.
The contract limits blast radius by connecting each permission to a defined outcome and scope. An agent asked to update one dependency, for example, should not inherit authority to publish a release merely because both actions are technically available through the same tool surface. The contract gives the harness a reason to deny the second action without asking the model to police itself.
It also makes completion legible. “Done” should not mean that the agent produced a confident final message. It should mean that required artifacts exist, relevant checks passed, and the resulting state matches the declared outcome. If the evidence is incomplete, the run can end as failed, blocked, or awaiting approval instead of being mislabeled successful.
Run contracts improve recovery as well. A durable runner can compare a resumed execution with the original scope, remaining budget, completed checkpoints, and unresolved obligations. Without that record, resumption risks repeating side effects or continuing under permissions that no longer fit the task.
The contract also creates an evaluation unit. Operators can compare intent, permitted actions, the execution trace, and final evidence. That reveals more than output scoring alone: it shows whether the system completed the right work through an acceptable path.
Agent-run contract vs control contract
The two contracts operate at different lifetimes. A control contract defines the standing rules of a harness or workflow. An agent-run contract instantiates those rules for one execution.
| Decision axis | Agent-run contract | Control contract |
|---|---|---|
| Lifetime | One identified run | Multiple runs or a workflow version |
| Contents | Concrete outcome, scope, limits, evidence, and escalation | General policies, invariants, and permitted state transitions |
| Inputs | Task, operator intent, current state, and applicable policy | System design and operating policy |
| Change handling | Amend explicitly or start a new run | Version and roll out as a policy change |
A control contract might require approval before any production write. The run contract records whether this run includes production access, which approval satisfies the rule, and whether that approval has been granted. Keeping the layers separate lets policy remain stable while each delegation stays narrow and inspectable.
The Rifty take
We treat the run contract as the boundary between delegated judgment and retained operator control. We optimize for narrow authority, explicit completion evidence, and visible escalation, accepting some setup cost to avoid ambiguous success. If a material permission or outcome changes, the contract should change visibly before execution continues.
Common failure modes
- Prompt-only contracts: the model receives constraints, but the harness does not enforce them at tool or state-transition boundaries.
- Outcome without evidence: the contract names a goal but provides no artifact or verifier that can establish completion.
- Broad inherited permissions: the run receives every capability available to the worker rather than the minimum authority required for its scope.
- Unbounded recovery: a resumed run repeats external side effects because completed actions and idempotency requirements were not recorded.
- Silent amendments: retries, delegation, or operator interventions expand scope without producing a new contract version.
- Success by narration: the runner accepts the agent's final message instead of checking artifacts, state, and required evaluations.
- Missing escalation semantics: the contract says when to stop but not whether the resulting state is failed, blocked, awaiting approval, or safely resumable.
- Contract-trace mismatch: permissions are declared correctly, but tool calls cannot be attributed to the run that exercised them.
Frequently asked questions
Should an agent-run contract be written in prose or structured data?
Use structured data as the authoritative form, with prose generated for model and operator context when useful. Scope, permissions, limits, status, and evidence requirements need stable fields that the harness can validate. Free-form prose may explain intent, but it should not be the only enforcement surface.
Who is allowed to change an agent-run contract after execution starts?
Only a designated control path should amend it, usually through operator approval or deterministic workflow policy. The agent may request a change and explain why, but it should not grant itself more authority. Record the amendment, its authorizing event, and the point from which it applies.
How does a run contract prevent an agent from exceeding its permissions?
The harness checks each consequential action against the contract before execution. Tool access, credential scope, resource targets, and approval requirements should be enforced outside the model. The contract provides the decision inputs; tool hooks, sandboxes, and workflow guards provide the actual prevention.
What should happen when the completion evidence is inconclusive?
The run should finish with an explicit non-success state or follow its defined escalation path. It must not convert uncertainty into success because the agent believes the task is complete. Preserve the artifacts, checks, unresolved conditions, and resumable state so another decision can be made safely.