How it works
A control contract turns operator intent into observable execution rules. It sits between an agent’s open-ended reasoning and the harness mechanisms that permit, record, limit, or reject actions. The contract should bind four things: allowed behavior, enforcement points, acceptance evidence, and recovery behavior.
A practical control contract usually defines:
- Entry conditions. Required inputs, validated state, credentials, and approvals before execution begins.
- Execution boundaries. Permitted tools, resources, write scopes, budgets, stop conditions, and escalation rules.
- Observable events. The decisions, tool calls, state changes, errors, and approvals that must be recorded.
- Acceptance requirements. The artifacts, verifier results, or state transitions required before the run can report success.
- Recovery behavior. How to interrupt, retry, resume, compensate, or declare an unknown outcome without hiding uncertainty.
The contract does not need to live in one file. Parts may be enforced through schemas, permission checks, workflow state machines, tool hooks, and artifact validators. What matters is traceability: an operator should be able to connect each requirement to an enforcement point and each reported outcome to evidence. A prose policy with no enforcement path is guidance, not a control contract.
Why it matters in an agent harness
An agent can produce a plausible result while violating the operating conditions that made the work safe. It may use the wrong credential, write outside the intended scope, skip an approval, exceed a budget, or claim completion without producing the required artifact. Output review alone will not reliably expose those failures.
A control contract makes the harness responsible for execution integrity. The model may choose a path, but the harness decides whether that path is authorized and whether its result is acceptable. This separation improves several engineering properties:
- Control: permissions and limits are checked at the point of action rather than left as prompt instructions.
- Observability: required events and evidence are known before the run starts, which makes missing telemetry detectable.
- Reversibility: state-changing operations can require checkpoints, idempotency keys, or compensating actions.
- Failure containment: a failed verifier or ambiguous provider response can stop progression before uncertainty spreads downstream.
- Evaluation: runs can be judged against stable requirements instead of vague impressions of output quality.
The contract also prevents success from becoming a model-authored opinion. If completion requires a saved artifact and a deterministic validation result, a confident final message cannot substitute for either one. This is especially important in long-running workflows, where partial progress, retries, and external side effects can leave the system in a state that is neither cleanly failed nor safely complete.
A useful contract is narrow enough to enforce. If it says the agent must “act safely” or “use good judgment,” the critical policy still lives inside an ambiguous phrase. The harness needs concrete boundaries: which actions require approval, which errors are retryable, which state is authoritative, and which evidence closes the run.
Control contract vs guardrail
A guardrail is one mechanism used to constrain behavior. A control contract defines the broader operating agreement that those mechanisms must enforce and prove.
| Design question | Control contract | Guardrail |
|---|---|---|
| Primary concern | End-to-end execution obligations | Preventing or detecting a specific class of behavior |
| Scope | Entry, execution, acceptance, inspection, and recovery | Usually one boundary, check, filter, or policy |
| Success semantics | Defines what evidence permits completion | May only allow, block, or flag an action |
| Failure handling | Specifies stop, retry, escalation, or recovery behavior | Often reports a violation to the surrounding harness |
This distinction changes implementation. Adding a tool filter may reduce risk, but it does not define what happens after the filter blocks a call, whether partial side effects must be reconciled, or what the run may report. Those decisions belong in the control contract.
The Rifty take
We optimize for contracts that make invalid success difficult to represent. We accept some extra state, validation, and logging because silent ambiguity is more expensive than a visible stop. If a requirement cannot be observed or enforced, we either add the mechanism or remove the claim that the harness guarantees it.
Implementation checks
- Name the authoritative workflow state and reject conflicting copies.
- Map every permission rule to a concrete enforcement point.
- Define required artifacts and validation evidence before execution starts.
- Distinguish retryable failure, terminal failure, interruption, and unknown outcome.
- Record approvals, tool calls, state changes, and verifier results with run attribution.
- Require checkpoints or compensating actions for consequential writes.
- Test interruption between side effects and state persistence.
- Confirm that missing evidence cannot be converted into success by a final agent message.
- Version the contract when acceptance or recovery semantics change.
Frequently asked questions
Is a control contract just a system prompt?
No. A system prompt can describe expected behavior, but a control contract connects requirements to observable enforcement and acceptance mechanisms. Critical limits should survive prompt failure or model disagreement through permission checks, state transitions, tool hooks, validators, and explicit recovery rules in the surrounding harness.
What should happen when an agent violates the control contract?
The harness should block the invalid transition, preserve the available evidence, and apply the contract’s declared failure path. Depending on the violation, that may mean retrying, requesting approval, compensating for a completed side effect, or ending with an explicit failed or unknown outcome.
How detailed should a control contract be?
It should be detailed enough that consequential requirements have unambiguous enforcement and evidence, but no broader. Specify permissions, limits, success conditions, state ownership, and recovery semantics. Avoid encoding stylistic preferences or every implementation detail unless violating them would change safety, correctness, or recoverability.
Can a control contract change while a run is active?
Only through an explicit, recorded policy. Applying new rules mid-run can invalidate earlier approvals, permissions, or acceptance assumptions. A safer default is to bind each run to a versioned contract, then require a deliberate migration, restart, or operator-approved transition when the contract changes.