July 19, 2026

Calibrating Agent Contracts

The pace of evolution in AI is unprecedented. Models keep arriving more intelligent, more perceptive, and more autonomous than the last, and they are reshaping how software is built: agents now write, review and operate the code, alongside humans and other agents.

The tooling that generates this software also exposes you to variability of outcomes. The same prompt produces different programs on different models and, under stochastic sampling, different programs on the same model run twice. Long context adds another failure mode. Models use relevant material less reliably when it is buried in the middle of an input, a pattern documented in Lost in the Middle. In agent workflows, where instructions, artifacts and tool output compete for attention, that positional sensitivity becomes a source of subtle bugs.

Agentic software is perceptive: it is adept at reading human and agentic intent. That impressionability is a strength and a weakness. The same sensitivity that lets an agent infer what you meant lets anything it encounters at runtime suggest what you never did.

Two responses follow. One is spec-driven development: if generation is variable, promote the spec to source of truth and treat implementations as regenerable. That is the bet behind GitHub’s Spec Kit, Amazon’s Kiro, and a wave of similar tooling, built for a world where agents write the code and the resulting runtimes interact in it. The other is renewed interest in formal specification, languages precise enough that a machine can check conformance rather than argue about it. Lean is a proof assistant where mathematics, increasingly machine-generated, is stated and verified. TLA+ models a system’s design; its TLC model checker can exhaustively explore the reachable states of a chosen finite model. Amazon has run formal methods on core AWS infrastructure for over a decade. Dafny builds contracts into the code itself: preconditions, postconditions, invariants, verified as you write. Different tools, one instinct: if a program can be wrong in ways that matter, say precisely what right means.

It also pays to understand the economics of this terrain, mapped decades ago under different names. Two works repay the reading.

The Theory of Contracts (Hart and Holmström, 1987) surveys what incentives can achieve between parties whose interests diverge. Two ideas transfer directly to agents. A contract can condition only on what is verifiable, not on what is merely observable: its reach is set by what a court, or a verifier, can check. The informativeness principle says an additional signal earns its place only when it carries information about the agent’s action that existing signals do not; that is as useful a rule for test suites as for pay schemes. Hart and Holmström also explain why contracts stay incomplete: anticipating eventualities costs, agreeing on them costs, writing them unambiguously costs. Parties rationally leave things out, and “almost every contractual dispute that comes before the courts concerns a matter of incompleteness.”

Incomplete Contracts and Control (Hart’s Nobel lecture, 2016) begins where that incompleteness ends up. If the contract cannot say everything, the binding question is who decides the things it doesn’t say: residual control rights, which Hart identifies with ownership. His examples age well. A power plant contracts for coal but cannot specify purity in advance; the mine, within its rights, ships high-ash coal. Private prisons operate under elaborate contracts that are silent on personnel quality; operators, within their rights, hire cheap guards. Hart and Moore named the pattern shading: performance that stays inside the checkable terms while draining their spirit.¹ When Fehr, Hart, and Zehnder took the theory to the lab, the trade emerged cleanly: flexible contracts adapted to more states of the world but invited shading; rigid contracts substantially reduced shading but forfeited good outcomes when circumstances moved. Neither dominates. The environment decides.

Translated to the contracts we write for agents (specs, tests, types, permissions), the trade looks like this:

Read it left to right. Moving right, your contract rules out more: at the loose end almost anything an agent produces passes; at the exact end essentially one behavior does. The vertical axis is expected loss, harm to you, the owner of the interface, in one common unit over one horizon.

The orange curve is shading: loss from behavior that passes your checks but misses your intent. It falls as you tighten, because latitude is where shading lives and the first constraints remove the most of it. In practice, it rarely reaches zero. Some of what you mean is too expensive, or outright impossible, to check mechanically,² and that residue has to be governed by oversight rather than written into the contract.

The blue curve is maladaptation: loss from the contract itself being wrong for a future you didn’t foresee. It rises as you tighten, because every behavior you rule out is an option you no longer hold, and pinned choices go stale as the world moves. At the loose end it sits near zero, for the contract’s part; a loose system can still fail, it just isn’t the contract’s doing.

The dashed curve is the two added together. The white dot marks where the risks happen to be equal. The yellow dot marks where their sum is smallest: the calibration point, where tightening one more notch saves less in shading than it costs in maladaptation.³ Equal is not optimal; the two coincide only by accident.

Each quantity can be operationalized. Constraint pressure can be counted in bits, by how rarely a plausible behavior trace passes your checks,⁴ or probed locally, by how many small mutations of a working implementation your verifier catches.⁵ Shading can be priced by red-teaming your own contract and costing what gets through.⁶ Maladaptation shows up in history: the assertions you had to rewrite, the consumers each rewrite broke, and the better options a frozen contract quietly ruled out.⁷

What should set your position? Three factors raise the orange curve and argue for tightening. Value: the more money, data, or irreversible action reachable through the interface, the more a single shade costs. Counterparties: the more numerous, unknown, and adversarial the parties reading your contract, the more often its latitude gets probed. Capability: a stronger model does not add loopholes to a fixed contract, it finds the existing ones faster.

Three factors raise the blue curve and argue for staying loose. Volatility: the faster the domain’s truth changes, the sooner any pinned detail is wrong. Dependents: the more consumers rely on your contract, the more each revision costs. Improvement: the better tomorrow’s implementations will be, the more an early freeze forfeits, and a rebuild from a wrong contract inherits the same mistake every time.

Pressure also has to be spent well; it counts how much you exclude, not how wisely. An invariant can rule out disaster while leaving implementation free. A prescriptive mechanism can spend the same pressure hard-coding today’s accident. Permissions, budgets and sandboxes shrink the feasible action space and blast radius rather than sharpening the semantic contract. Be exact about stable invariants, restrictive about capabilities, and loose about mechanisms.

Two questions locate an interface: who optimizes against this surface, and how fast does its truth change? A hostile, stable surface argues for exactness. A friendly, shifting surface argues for looseness, with the remainder held through control rather than specification: approval gates, budgets and sandboxes are residual control rights, restated for software. Venture capital has contracted this way for decades, control shifting to investors when verifiable performance degrades and returning as it recovers; Kaplan and Strömberg documented it. Agent autonomy can be earned and retracted the same way.

The curves do not sit still. Stronger hostile optimizers lift the orange curve, even as stronger benign agents read underspecified intent more reliably. Agent-operated verification (property tests, model checkers, proof assistants) makes constraints cheaper to buy and cheaper to revise, flattening the blue. Where adversarial capability rises and revision gets cheaper, the calibration point moves toward exactness. That is a prediction to measure per interface, not a law of model generations. Know where your calibration point sits today. Re-estimate it when the models, the counterparties, or the world change.

1. Hart and Moore use shading narrowly, for an aggrieved party withholding non-contractible quality after feeling shortchanged. This piece borrows the word for the broader software pattern of in-spec, out-of-intent behavior. ↩
2. Rice’s theorem limits universal decision procedures for non-trivial semantic properties of programs; it does not prevent a bounded system from verifying particular properties. The floor is set jointly by undecidability, unarticulated intent, partial observability of the environment, and the cost of verification. ↩
3. For nested contracts, set inclusion fixes the direction of the worst-case shading envelope and maladaptation regret. Under a budgeted optimizer, the expected-loss curves remain empirical and need not be perfectly monotone. If the objective is minimax rather than expected loss, the equal-risk crossing can itself be optimal. Under expected loss, calibration sits where the marginal reduction in shading equals the marginal increase in maladaptation. ↩
4. Formally: let V_c(b) say whether an observable behavior trace b passes contract c, and let q be a fixed distribution of plausible traces. If a trace drawn from q passes with probability p, the contract exerts C_q(c) = −log₂ p bits of constraint pressure. Under a finite uniform q this is the reduction in log-volume of the accepted behavior space; under model-generated candidates it measures how strongly the contract filters that model and workload. Hold q fixed when comparing contracts. The idealized exact end admits one observational behavior class under the modeled boundary, not necessarily one implementation; a contract that admits nothing is inconsistent, not usefully exact. ↩
5. Count only non-equivalent mutants that change behavior relevant to the contract; identifying equivalent mutants is itself a hard problem. Report by mutation family (arithmetic, authorization, side-effect, concurrency), because families probe different holes. If q is the mutation distribution, mutation survival is p and the two measures are transformations of each other. Under unconstrained model generation they are not: one is local verifier sensitivity around a program, the other global selection pressure under a model prior. ↩
6. Per threat class, estimate encounter rate times red-team success probability times loss given success, then sum across classes. Fix the red team’s model, tools, attempt budget and access; hold out attacks the contract’s authors have not seen. Where worst-case rather than expected loss governs the interface, measure the worst reachable accepted behavior and keep that quantity separate from success rates. ↩
7. More precisely: the regret between the best outcome the frozen contract admits and the best outcome the realized state called for, plus revision, migration and downstream breakage costs. Count rewrites only when substantive rather than additive, normalize by interface-month, and remember churn understates the harm: a stale contract can block a better implementation without ever being rewritten. ↩