Burgess: What a Builder Can Promise

Promises imply control.

Jul 28, 2026

When an organisation first lets agents write production code, it reaches for the vocabulary it already owns, and the vocabulary is the vocabulary of command. The agent is given a task. The task is an instruction. The instruction is an obligation, and the obligation is enforced the way obligations have always been enforced in software: through a controller that issues orders, monitors compliance, and raises an alarm when the order is not met. This is how we have run machines for seventy years, and it works for machines that do exactly one thing. It breaks the moment the thing you are coordinating has enough autonomy to act on its own account. A fleet of agents is not a thermostat. It is closer to a workforce, and you cannot run a workforce on obligations alone, because an obligation is a claim one party makes about another party’s behaviour, and no party controls another party’s behaviour. The whole apparatus of command rests on a fiction, and the fiction holds only until the system is under enough load to test it.

Mark Burgess spent twenty years working out why distributed systems built on command go brittle, and the answer he reached is the most useful idea available for the question of who, or what, now builds your software. Burgess is a physicist who became a systems researcher, and the tool he is best known for, the configuration engine CFEngine, ran on a principle that sounded eccentric in the 1990s and looks prophetic now: a machine cannot be told what to do; it can only be persuaded to converge on a state it has agreed to hold. Out of that practical work came Promise Theory, a formal account of how autonomous agents cooperate without a central authority forcing them to. It was written for servers. It turns out to be the precise grammar for a world in which some of your builders are people, some are agents, and the line between giving an instruction and making a promise is the line that decides whether the system holds together. This is the foundation the question of identity now stands on, because the old answer, that the builder is a person and you manage people, no longer covers the field.

1. An Agent Can Only Promise What It Controls

Start with the single rule that the whole theory unfolds from, because everything else is a consequence of it. An agent can only make promises about its own behaviour. It cannot make a promise about anything outside its own locus of control, and any statement that appears to do so is not a promise at all; it is a wish wearing a promise’s clothes.

A web service can promise to return a response within fifty milliseconds. It cannot promise that the network will deliver the response to you, because the network is not within its control. A team can promise to ship an interface that behaves to a specification. It cannot promise that the team downstream will use the interface correctly, because the downstream team’s behaviour belongs to the downstream team. The rule sounds almost trivial when you state it. Its consequences are not, because almost every coordination failure in a large organisation is a promise made about behaviour the promiser did not control, accepted as though it were binding, and discovered to be empty at the worst possible moment.

Burgess’s word for what command does is *imposition*. An imposition is an attempt to specify another agent’s behaviour from outside. You can issue impositions all day; the language permits it and management culture encourages it. What you cannot do is make them true. An imposition only changes the world if the agent it is aimed at chooses to make a promise that corresponds to it. The order does not move the agent. The agent’s own promise moves the agent, and the order is merely an input the agent may or may not honour. Command, in this account, is not a force. It is a request with the volume turned up, and turning the volume up does not add control you never had.

This lands hard the moment your builders include agents. You can instruct an autonomous coding agent to follow your security policy. The instruction is an imposition. Whether the policy is followed depends entirely on whether the agent’s actual behaviour, the thing inside its locus of control, converges on the policy. If it does not, you have not been disobeyed in the way a person disobeys. You have discovered that the imposition was never a control in the first place; it was a hope you had mistaken for a mechanism. The agent kept the only promise it was ever capable of keeping, which was a promise about itself, and that promise did not match what you wanted.

2. Promises Are Voluntary, and That Is Their Strength

The second principle is the one that offends managers, and it is the one that makes the whole thing work. Every promise is voluntary. An agent promises because it elects to; the promise originates inside the agent, not outside it. There is no such thing as a promise extracted under command, because the moment you extract it under command you are back to imposition, and imposition does not bind.

The instinct is to treat voluntariness as a weakness. Surely a system you can order around is more reliable than a system that merely agrees to cooperate. The instinct is exactly backwards, and Burgess’s argument for why is the heart of his contribution. A system coordinated by voluntary promises is more resilient than a system coordinated by command, because each agent is responsible for keeping its own promises, and an agent can only be reliably responsible for what lies within its own control. When you build coordination out of promises, you build it out of commitments each party can actually honour. When you build it out of commands, you build it out of obligations no party fully controls, and you have manufactured fragility while believing you manufactured order.

Consider two ways to make a hundred services behave. In the first, a central controller holds the desired state of every service and pushes commands outward, correcting each deviation as it sees it. This is command, and it has a single point whose failure takes down the coordination of the whole. In the second, each service holds its own promise about the state it will maintain and converges on it locally, advertising what it promises so that others can decide whether to depend on it. This is promise-based coordination, and it has no centre to fail, because the intelligence lives at the edges where the control actually is. The second system is harder to draw on a slide and far harder to break in production. Resilience is not a property you add to a coordinated system. It is a property of where you put the responsibility, and voluntary promises put it in the only place that can carry it.

For a fleet of autonomous agents this stops being theory and becomes operational reality within a week of deployment. You will be tempted to run the fleet from a central policy engine that commands each agent’s behaviour. The fleet will work in the demo and fail under load, because the central engine cannot hold enough control over a hundred agents acting in a changing environment to correct them faster than they drift. The configuration that survives is the one where each agent makes and keeps its own promises, advertises them honestly, and is depended upon only for what it has actually promised. The same is true, and has always been true, of teams of people. Burgess’s achievement is to show that it is the same fact in both cases, and to give it a notation precise enough to design with.

3. The Fictitious Coupling Is Where Systems Break

Now the failure mode, because an idea about coordination is only worth as much as the specific way it tells you things go wrong. When you impose an obligation from outside and the system behaves as though that obligation were a real dependency, you have created what Burgess calls a *fictitious coupling*: a connection the system believes in but that nothing in the system actually maintains. Fictitious couplings are the dark matter of brittle architectures. They do not appear on any diagram, because no one drew them deliberately; they accreted out of impositions everyone assumed were promises. And they hold the system’s stability hostage to commitments no agent ever made.

A team depends on another team’s service being available, a dependency no one ever promised because no one was asked to. A scheduled job assumes a file will be present because it has always been present, not because any process promised to put it there. An agent’s output is consumed downstream as though it were validated, when nothing in the agent ever promised validation; the imposition “the output will be correct” was treated as a promise the agent had made, when in fact the agent only ever promised to generate plausible output. Each of these is a fictitious coupling, and each is invisible until the day the unpromised behaviour does not occur, at which point the failure propagates through couplings no one knew were load-bearing, because no one knew they were there.

The discipline Promise Theory imposes is therefore a discipline of honesty about dependency. A real dependency is one where the thing you depend on has actually promised the behaviour you are relying on, and has advertised that promise so you could decide to depend on it. Everything else is a fictitious coupling waiting to be discovered. The work of building a system that does not surprise you is, in large part, the work of converting fictitious couplings into real promises: finding the places where you rely on behaviour no one committed to, and either getting the commitment or removing the reliance. This is unglamorous, and it is most of what reliability engineering actually consists of, and Promise Theory is the only framework that gives it a name and a method.

Free making sharpens this to a point. When code was expensive, dependencies were few and deliberate, because each one cost something to build and someone had thought about it. When an agent can generate a thousand lines that quietly assume a dozen behaviours nothing has promised, fictitious couplings breed faster than anyone can audit them. The generated code looks complete. It compiles, it runs, it passes the happy path. What it conceals is a thicket of assumed behaviours, each one an imposition the surrounding system never agreed to honour, each one a coupling that will become visible only when it fails. The maintenance burden that free making imposes is, seen through Burgess, a burden of unaudited couplings: abundance is cheap to generate and expensive to keep precisely because every generated artefact arrives wrapped in dependencies no one promised and everyone will inherit.

4. A Promise Is a Testable Claim

Here the identity question meets the frame this whole inquiry turns on: that a build is a test, an experiment with a result that can disconfirm. A promise is the unit that makes this exact. A promise is a claim about behaviour, and a claim about behaviour can be checked against behaviour. Either the agent did what it promised or it did not. There is no third state, no partial credit, no “it depends on what you meant.” The precision is the point. A promise is a hypothesis stated so clearly that reality can return a verdict on it.

This is why the model fits building so well. When a component promises an interface and fails to keep it, the component has not committed a governance violation to be escalated and apologised for. It has run a test and returned a result, and the result is information you needed and now have. The promise was the hypothesis; the build was the experiment; the broken promise is the disconfirmation, and disconfirmation is the most useful thing a build produces, because it changed your mind before the customer changed it for you. An organisation that treats a broken promise as a failure to be punished will learn to hide broken promises. An organisation that treats it as a result to be read will learn what its system actually does, which is the only knowledge worth having.

Promise Theory also tells you what makes a promise testable, and it is exactly the discipline that vague specification lacks. A promise must be about observable behaviour within the promiser’s control, advertised clearly enough that another agent can decide whether to depend on it. “The service will be reliable” is not a testable promise, because reliability is not an observable state and the boundary of the claim is undrawn. “The service will return a valid response to a well-formed request within fifty milliseconds, for the request shapes in this schema” is a testable promise, because every term in it can be checked and the edge of the claim is visible. The work of making a system promise well is the work of making its claims sharp enough to fail. This is the same discipline that turns a specification from a wish into an artefact reality can answer, carried now from how the build describes itself to who, or what, is doing the building.

5. The Builder Is Now Mixed, and the Model Was Built for It

Every prior thinker who held this ground held it for humans. The questions about the builder were human questions: is this person capable, do they have judgement, has the apprenticeship pipeline that forges judgement stayed intact. Those questions have not gone away, and they sharpen rather than soften, because an agent gets a builder most of the way and leaves the last, hardest portion exactly as hard as it ever was. The edge cases, the integration, the security, the behaviour under real production load: AI delivers a builder to the eighty-percent line and abandons them at the cliff, and the cliff is where competence used to be proved. Software has always been an apprenticeship trade, where judgement is forged over years doing precisely the work an agent now absorbs, and the threat to the pipeline of senior judgement is real and worth naming plainly. A senior who must now supervise work they did not write needs more judgement than ever, sourced from an apprenticeship the new tools are busy hollowing out.

But the reason Burgess governs this ground, rather than a thinker about human craft alone, is that the subject of the question is no longer only human. Some of what builds is an agent, and an agent is an autonomous thing that takes inputs, acts on its own account, and produces outputs you did not write and must now trust or verify. A theory of who can build that only describes people cannot carry a field in which half the builders are not people. Promise Theory can, because it was never about people in the first place. It is about autonomous agents of any substrate, and its definition of an agent, something with a locus of control that can make and keep promises about its own behaviour, fits a coding agent and a senior engineer with the same precision. The questions become symmetrical, and the symmetry is the gift. What can this builder actually promise, given what lies within its control? What is it being asked to promise that lies outside its control, and therefore cannot bind? Where are we depending on a behaviour nothing has committed to? You ask these of the human team and the agent fleet in the same breath, and for the first time you have one model that answers both.

6. What an Agent Cannot Promise

The symmetry has a sharp edge, and the edge is where the discontinuity between human and agent builders cuts deepest. An agent can promise. It can promise an interface, a latency, a behaviour, a refusal to act outside its bounds, and it can keep those promises as reliably as any component ever has. What it cannot do is have anything at stake in the keeping.

A promise between people carries more than the behaviour it specifies. It carries relatedness; the promiser cares, in some degree, whether the promise holds, because the promiser is bound into a web of others who will be affected. A human builder who breaks a promise feels something, even if only the small friction of having let a colleague down, and that feeling is load-bearing, because it is part of what keeps promises kept when no one is watching. An agent feels nothing. It keeps its promise when its behaviour converges on the promise and breaks it when it does not, and it is entirely indifferent to which occurs. It has no relatedness, nothing invested, no stake in the outcome beyond the mechanics of its own execution. The promise is real; the caring is absent.

This is not a sentimental complaint, and it is not an argument against agents. It is a structural fact, and it has a structural consequence everything that follows is built to address. Because the agent has nothing at stake, it cannot generate the energy a team runs on; it cannot share a mood, cannot renew the symbols a group organises itself around, cannot care whether the thing it built was good. Everything a team draws from caring about the work together must, in an agent-heavy configuration, be supplied deliberately by the humans, because the agents categorically cannot supply it. Promise Theory lets you draw the line with unusual precision, and the line is this: the agent can be trusted to keep what it promises, and can never be trusted to care that it did. Design as though both halves are true, because both halves are true, and the configurations that fail are the ones that noticed the first half and forgot the second.

7. Designing for Promises Instead of Commands

What changes, concretely, when you stop coordinating by command and start coordinating by promise? The shift is less in the technology than in where you place responsibility and how honest you are about dependency, and it shows up in three habits worth naming.

The first habit is to make every dependency a promise or remove it. Walk the couplings your system relies on and ask, of each, whether the thing you depend on has actually promised the behaviour you are relying on. Where it has, document the promise as the interface contract it is. Where it has not, you have found a fictitious coupling, and you have two honest options: get the promise made and advertised, or stop relying on the behaviour. There is no third option that does not leave a brittleness in place. This audit is dull and it is the single most valuable thing you can do to a system you intend to keep.

The second habit is to push promises to the edge, where the control actually lives. Resist the instinct to coordinate a fleet of agents, or a set of teams, from a central engine that commands their behaviour, because the centre cannot hold enough control over autonomous parts in a changing environment, and it becomes the single point whose failure takes the coordination down. Let each agent and each team make and keep its own promises, advertise them, and be depended upon only for what it has promised. You will lose the comforting illusion of a single throat to choke and gain a system that does not seize when the centre stutters.

The third habit is to demand that promises be testable, which means demanding they be sharp. A promise stated vaguely cannot be checked and therefore cannot be kept in any sense that matters; it is a fictitious coupling in the making. Insist that every promise an agent or a service or a team makes is a claim about observable behaviour within its control, advertised clearly enough that another party can decide whether to depend on it. The discipline of sharp promises is the discipline of a system that can tell you the truth about itself, and a system that can tell you the truth about itself is the only kind you can safely build at the speed free making now permits.

8. The Handoff: From Who Builds to How They Relate

Promise Theory settles the identity question and, in settling it, hands the next question over fully formed. The builder, human or agent, is an autonomous thing that makes and keeps promises about behaviour within its own control, and the model gives you one grammar for both. But the model also marks, with unusual clarity, the exact place it stops being sufficient. An agent can promise everything except to care, and caring is not a private feeling; it is generated between people, in the occasions where a group is bodily present, attending together, sharing a mood. The agent’s structural inability to supply that energy is not a gap in Promise Theory. It is Promise Theory pointing precisely at the thing the next thinker exists to explain.

So the question moves from who builds to how the builders relate, and specifically to where the energy comes from that makes a group of builders more than a set of agents executing in parallel. A team is not a collection of promise-keepers, though it must be that too. It is a group that generates something between its members that no member could generate alone, and that something is exactly what the agent, with nothing at stake and no body to be present with, cannot contribute. To understand how a building team produces and renews that energy, and why an agent-heavy or remote-only configuration can hit every output metric and still go quietly lifeless, the field turns from Burgess to a sociologist who spent his career on the mechanics of human ritual. The locus of control told us what each builder can promise. What a group of builders generates between them, no locus of control contains, and that is the next thing to understand.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Audit one dependency until you find the lie

Take a single service, pipeline, or agent your organisation depends on, and trace one dependency it relies on but you have never examined. Ask the only question that matters: has the thing you depend on actually promised the behaviour you are relying on, or have you simply assumed it because the behaviour has always happened?

Follow the chain. The service depends on a database being reachable; did the database promise reachability, or did someone assume it? The agent’s output is consumed downstream as validated; did the agent promise validation, or did it only ever promise to generate plausible output that someone decided to trust? Keep pulling until you find a coupling no one ever committed to. You will not have to pull far.

When you find it, you have found a fictitious coupling: a dependency the system believes in but nothing in the system maintains. Now do the unglamorous thing. Either get the promise made and advertised, so the dependency becomes real and testable, or remove the reliance, so the system stops betting on behaviour no one committed to. Do not leave it as it is, because as it is, it is a failure waiting for the day the unpromised behaviour does not occur.

Run this once, deliberately, on a system you care about, and you will see your architecture the way Burgess sees it: not as a diagram of components, but as a web of promises, some real and some fictitious, and you will know which is which. Then make it a habit, because under free making the fictitious couplings breed faster than ever, and the only defence is the discipline of asking, of every dependency, whether anyone actually promised it.

Organisational Prompts

Discussion about this post

Ready for more?