Monowai

writing - ai & contracts

Agents propose, contracts permit

Agents write plausible code, and plausible is not correct. The discipline that decouples teams - a contract agreed at the seam and verified by the pipeline - is the same discipline that makes an agent's output safe to ship. Probabilistic reasoning in the middle, deterministic contracts at both ends. Trust the artefact, not the author, human or agent.

Mike Holdsworth · Singapore

An agent is probabilistic. Delivery needs to be deterministic. What sits between them is the context you supply, and that essay was mostly about what happens when the context is missing: the model reaches for the median and amplifies whatever structure it finds. This one is about the half of the context you already own, and have been publishing for years without calling it that. The contract.

Same prompt, different code each run. That is not a defect to be engineered out; it is what a probabilistic engine is. It means human review cannot scale to the speed the engine produces at, and it means the question is not "how do I make the agent right" but "what decides whether the proposal ships". In every organisation I have worked with, something already decides that for the humans. Where it is a person, it does not scale. Where it is a contract and a pipeline, it already does.

Three layers, and the one you already own

Stand the stack up and it has three layers, each one making the layer above it safe to speed up.

  • Agreements - shared meaning, settled at the seams. What a Client is, where the boundaries fall, who owns which domain - versioned like code. This is the layer Harmony was built on: a taxonomy argued once, at design time, before a line of service code existed.
  • Automation - deterministic; it verifies. The contracts run as stubs, the pipeline checks every change against them, and a breaking change fails before merge. This is what turned Harmony's test specs into assets teams trusted.
  • Agents - probabilistic; they propose. Plain-English access, generated queries, generated applications, reasoning over the agreements rather than over the codebase.

Under all three sits the bedrock: version control, continuous delivery, automated testing, code review. A decade of DORA evidence behind every layer above. No new tools and no new methodology - the stack aims the practices you already trust at the seams between teams, and then at the seam between a team and its agents.

Discipline compounds. Confusion accelerates. If the agreements are assumed rather than agreed, the automation has nothing to check against, and the agent above it proposes freely against a seam that only exists in a wiki page and a few programmers' heads.

The ontology is the contract you have been publishing

The word arriving from the AI side for this is neurosymbolic: probabilistic reasoning inside, logical constraints outside. Frank Coyle's framing at the AI Engineer World's Fair was that agentic systems need an ontology - a formal statement of what things are and how they relate - because the model cannot be trusted to hold one consistently on its own. New word, same artefact. The ontology is the contract you have been publishing all along.

Look at what a contract in a central repo already is. It is the agreement between every producer and every consumer, not the opinion of one implementation. Its documentation is what feeds the agent, so the agent reasons over the agreement rather than over whichever codebase it happened to be pointed at. It is the long-lived asset: implementations evolve or get replaced, the contract endures. And permission against it is binary - the proposal verifies against the contract, or it does not ship.

That last property is the whole argument. A review by a person is a judgment, and judgments vary with the reviewer and the hour. Verification against a contract is a decision the pipeline makes the same way every time, which is the only kind of decision that survives being made at agent speed. Trust the artefact, not the author. The author might be a graduate, a contractor, a senior engineer having a bad week, or a model. The artefact is checked the same way regardless, and that is what makes the delegation safe rather than hopeful.

Contracts are the index to your organisation

Here is what that looks like when it runs. On the Harmony programme we had a federated graph over the domain services, and its schema was documented from the contracts. Put an agent in front of that schema and ask it, in plain English, for the client's name and addresses. The agent's only knowledge is the documented schema; it emits the exact query, ready to run, with an explanation attached. Feed that deterministic query and the architectural guidelines into a second step, and a working interface comes out the other side, verified by the same pipeline as everything else.

Probabilistic reasoning in the middle. Deterministic contracts at both ends. The objection that GraphQL is too hard retired itself: the agent absorbs the query language, the business asks, the graph answers. And it is not a GraphQL story. The pattern holds over any contract catalogue - a graph schema, OpenAPI, events. If it is documented, it is indexable, and if it is indexable, an agent can be scoped to it and to nothing else.

This is the same shape as the spec harness that reviewed every contract pull request: a MicroContext whose whole world is our standards and contracts, never the codebase. No catalogue? Do not start there. Start with the catalogue.

Two terms worth keeping apart. The agentic economy is the world outside your walls: agents transacting across organisations against whatever has been published well enough for a machine to read. The agent estate is the set you run inside them. Both run on agreements. The contracts you publish are infrastructure for the first and the permission boundary for the second, and they are the same documents.

Where the time came from

No one asked us to build the query assistant or the spec review. The practices freed the time, so we built them. That is the dividend the hallway conversations about AI tooling tend to skip: automation removed the toil of repetitive manual work and regression firefighting, and the reclaimed capacity became the AI tooling. Effective continuous delivery engineering is the accelerator. Things get done in the doing.

It runs the other way too, and it is worth being honest about it. A team that has not automated its integration does not have the capacity to build the tooling that would make agents safe, and does not have the contracts that tooling would check against. Start with agents there and you get the amplification problem in its purest form: more proposals, no way to permit them, and the review load landing on the same people who did not have time before.

Monday morning

Three moves, one week, in this order.

  • One contract. Pick a single producer-consumer pair, preferably a troublesome one. Agree the contract and its examples this week. This is the agreements layer, and it is the one that needs people in a room.
  • One pipeline. Lint, verify backward compatibility, publish a stub. A day's work with today's tooling, and it is the automation layer: from here on, a breaking change fails before it can break a team.
  • One MicroContext. An agent scoped to your standards and contracts, never the codebase. Spec review on every pull request is the obvious first one, because you were doing it by hand and the definition of good was already half written down.

Every win de-risks and funds the next seam. Proof beats mandate, every time. And before you delegate anything wider, seven questions apply - the contract is what answers the first two.

The agent proposes. The contract permits. Every contract you publish is infrastructure for the agentic economy, and a boundary your own agents cannot cross unchecked.

Contracts earn trust, and position you to move with certainty in a probabilistic world.

References & further reading

← All writing