The Contract Keystone

An agentic component is like a function in that it exposes an input/output interface. The analogy is genuinely useful: both let a caller reason about a component without reopening its implementation. The important difference is how much of the interface the surrounding system can declare and enforce.

• A function declaration can make mechanically expressible parts of the contract structural: parameter names and types, return types, and—in richer systems—selected invariants. A compiler or runtime may enforce those declared parts. Semantic intent still exceeds the declaration and needs tests, assertions, or review.
• An LLM-facing contract is often prose addressed to a probabilistic reader. It is persuasion, not enforcement. The model can read a beautifully documented contract and still hand back something off-spec — confidently, fluently, plausibly. The boundary is aspirational until something checks it.

A declaration makes the mechanically expressible contract visible; an enforcement mechanism makes selected clauses structural. An LLM-facing seam begins with more of its contract in prose, so verification moves as many clauses as possible from promise toward enforcement.

An acceptance criterion is what makes re-dispatch governable in the first place. You can only "throw it away and re-run" if you have something to check the return against. No legible expectation → you can't tell a bad result from a good one → you can't verify → you can't safely re-dispatch. The silent, instinctive version of this — verifying a sub-agent's output and re-running when it looks wrong — was already depending on an implicit contract the whole time. Naming the contract turns instinct into a tool you can hand someone.

Contract documentation, validated seam, and re-dispatch are not three separate patterns. They are one move seen from three angles:

• Write the contract to make intent legible (the spec).
• Check the return against it because the reader is probabilistic (the assertion).
• Choose a recovery after a failed check. For an effect-disciplined dispatch, discarding can be cheaper than repairing. Re-dispatch is one tactical option, not the proof that the seam is safe.

You have reconstructed an assurance ladder around a reader that can ignore the declaration: prose → structured shape → deterministic clauses → probabilistic residue → human judgment. Only the mechanically enforced clauses become guarantees; the rest gain measured assurance.

Why the check doesn't regress

The contract makes checking possible; a second premise makes it affordable: verification asymmetry (../verification-asymmetry.md). The verifier may be the same kind of probabilistic reader as the producer. The loop becomes useful only for clauses where checking a candidate against a documented spec is materially easier and measurably more reliable than producing it. One level is enough only when the checker terminates deterministically or its measured residual risk is acceptable. The two are sibling premises: the contract is the possibility condition of checking, the asymmetry its affordability condition.

Why the discard is safe

Re-dispatch's economics assume throwing a run away costs nothing but the tokens. That is an engineering achievement, not a given: a dispatch that wrote files, called an API, or committed state before returning off-spec has already changed the world, and "discard" would silently mean "keep the mess." Effect discipline (../effect-discipline/effect-discipline.md) is the third premise: dispatches that may be discarded must be pure, idempotent, or isolated — and effects that escape those guarantees are either compensated at the seam they landed on, or gated before they happen rather than validated after. The contract makes checking possible, the asymmetry makes it affordable, effect discipline makes the recovery move legal.

The keystone is the argument, not another pattern: it owns how the three premises compose, not the premises themselves. The practice of writing a contract belongs to ../contract-documentation/contract-documentation.md, which this node generalizes; the applied loop belongs to ../../verification/validated-seam-redispatch.md; and each premise's own failure boundary belongs to that premise's node. Where the asymmetry fails — intent the clauses can't cover, verifiers that can't discriminate, absence-claims that invert the gap — assurance runs out with it; that boundary lives in the asymmetry node.

Every other pattern leans on it. Deferral, externalization, heavy agents — they all create a seam between components. A seam becomes more trustworthy as its load-bearing expectations are made explicit and pushed toward checking at the rigor its consequence warrants. The contract isn't one foundational principle among many; it's the substrate that makes the others safe to compose.

This is an argument assembled from three premises rather than a standalone empirical claim: each premise is grounded in its own node, and whatever revises one of them revises the composition here. What the keystone stands on directly is the instinct named above — practitioners already verify a sub-agent's output and re-run when it looks wrong, and that move already depends on an implicit contract. Each premise names the result that would revise it: a seam where the verify-and-re-run move is routinely safe with no legible expectation to check against would break the possibility condition; a seam where checking is no easier than producing breaks the affordability condition; a discarded run that already changed the world breaks the legality of the recovery. No Duck Left Behind holds those three roles at one return seam: declared shape, deterministic assertion, bounded redispatch.

• No Duck Left Behind — a sorter omits one duck and duplicates another; a deterministic census rejects the manifest with a bounded error report; the fresh return passes.

• Generalizes ../contract-documentation/contract-documentation.md.
• Applied, concrete form: ../../verification/validated-seam-redispatch.md.
• Most directly load-bearing for ../../context-engineering/mechanisms/cost-relocation/subagent-offload/heavy-agent/heavy-agent.md (the return contract) and ../../verification/fresh-context-trials.md (the assertion).

Design by Contract (Meyer, Object-Oriented Software Construction; Eiffel): preconditions, postconditions, and invariants declared at an interface. The spec/assertion/recovery split is Meyer's obligation table with the enforcement removed — an agentic contract documents what a compiler used to check.