One Contract, Every Model: Engineering an Operating Standard for AI Coding Agents

Skip to content

Blog<br>One Contract, Every Model: Engineering an Operating Standard for AI Coding Agents

July 13, 2026 · 14 min read<br>I want to share a piece of engineering I did recently that changed how I think about working with AI coding agents. It started from a naive question I asked out loud: "can I make Sonnet and Opus behave like the frontier model?" It ended somewhere more useful than the question deserved.<br>The short version: you cannot make a smaller model as capable as a larger one. That's weights, and no prompt moves weights. But capability is not the only thing that separates a good agent turn from a mediocre one. The other half is *doctrine*: how the agent communicates, when it stops, how it proves its work, how deeply it analyses before deciding. And doctrine is completely portable. You can write it down once, apply it as a system-prompt layer, and every model tier, the expensive one and the cheap one alike, starts operating to the same contract.<br>This post is the thesis and the blueprint. Everything here is adaptable to your own stack; I'll point out where the reusable pattern lives versus where my specifics are just illustration.<br>The problem, stated honestly<br>I run a fairly heavy codebase: a blockchain-based financial protocol, twenty-plus backend microservices, several Next.js frontends, smart contracts, and a Kubernetes cluster. I drive most of the work through Claude Code with a fleet of specialised sub-agents. On any given day, an architecture agent runs on the most capable model, an implementation agent runs on a mid-tier model, and a fast research agent runs on a small one. Three different intelligences, one codebase, one set of standards.<br>The friction was never that the cheap model was dumb. It was that the cheap model behaved differently. It would declare a task "done" without running the test. It would open its final message with a wall of implementation detail instead of the answer. It would make a change from a single grep instead of tracing the blast radius. It would stop mid-task and ask a question it could have resolved itself. The expensive model did these things right by default; the cheaper one needed to be told.<br>For a long time I treated that as an unavoidable tax of using cheaper models. That was the wrong frame. The behaviours I wanted were not intelligence. They were conduct. And conduct can be specified.<br>The core idea: doctrine is not capability<br>This distinction is the whole thesis, so let me be precise about it.<br>Capability is what the model can figure out: the hard reasoning, the novel synthesis, the ability to hold a large problem in mind. It lives in the weights. A prompt cannot add it. Anyone selling you a "system prompt that makes GPT-3.5 as smart as GPT-5" is selling you nothing.<br>Doctrine is how the model conducts itself around whatever capability it has: the communication contract, the bar for calling something done, the discipline of tracing a change end-to-end before committing to it, the rule about not stopping while there's still work you can do. None of that is intelligence. All of it is specifiable in text. And critically, when a capable model already does these things, it's because it was trained toward them, which means the same behaviours can be instructed into a less capable model, closing most of the visible quality gap even though the underlying intelligence gap remains.<br>So the goal was never "make the small model smart." It was: make every model, whatever its tier, honour one operating contract. A mid-tier turn that leads with the outcome, backs every completion claim with evidence, traces before it decides, and doesn't stop early is, by every externally observable measure, a frontier-standard turn. You reach for the genuinely bigger model when the task's correctness ceiling demands the extra capability, not for basic professional conduct, which you can standardise.<br>Writing the standard down<br>The artifact at the centre of all this is a single document I call the Operating Standard. It's about a dozen sections, and it encodes the contract as enforceable behaviour rather than vibes. The load-bearing pillars:<br>Lead with the outcome. The final message is the reader's first look at the work: it opens with the answer, then supports it. Readability beats brevity: you shorten by cutting detail that doesn't change the reader's next move, never by compressing into fragments and arrow-chains. Everything the reader needs lives in that last message.<br>Prove completion with artifacts. No "should work," no "looks good." Every done / fixed / passing claim carries a commit hash, verbatim test output, an exit code, or a file listing. The orchestrator re-runs the acceptance command itself before it trusts a completion claim. It does not take the agent's word.<br>Decide depth-first, never from a hunch. Trace a cross-cutting change through every layer it touches before deciding: schema, data...