Beyond the Harness

Most of what we call AI engineering today is the construction of a harness: a fixed scaffold through which agents are steered. We fix the roles, the order in which they run, the tools each may call, the format of every hand-off. The approach is reliable, reproducible and auditable, and for the great majority of well-defined engineering problems it is exactly right.

Two developments will strain it. The first is that models keep getting better, often faster than the scaffolding around them, so that a harness carefully built in one month is partly obsolete the next. The second is that AI is moving out of the sandbox and into contact with the real world: robotics, multi-modal perception, markets, institutions, and the messy press of many humans and other agents at once. In that setting a fixed harness is not obviously the optimal way to engineer, because the problem will not hold still long enough to be wired.

This essay develops an alternative I will call adaptive engineering, in which the harness is allowed to emerge from the interaction of agents rather than imposed on them in advance. The argument runs in three parts: the current discipline and where it breaks; what the real world is actually made of; and what engineering looks like once we let the structure emerge.

The current discipline

What a harness is

A language model, on its own, does very little useful work. It is stateless, it predicts the next token, and it knows nothing past its training cut-off. A harness is the apparatus we build around that engine to turn it into something that acts: the system prompt, the project brief loaded into context, the tools it may call, the permissions that fence those tools, the memory that persists across turns, and the loop that lets it try, observe, and try again.

Figure 1. The harness sits between a stateless engine and a finished outcome. Every element of it is specified before the run begins.

Harnesses differ along a familiar set of properties: orchestration, roles, permissions and rules, memory and persistence, sequencing, tool access, routing, communication protocols, observability. Claude Code, Cursor, Codex, Cline, Goose, LangChain and Pi are all harnesses, and what distinguishes them is less their feature lists than the design philosophy underneath: a stance on what is important enough to engineer, and what can be left to the model. That question, what to fix and what to leave free, is the one this essay keeps returning to.

The fixed harness, or Taylorism for AI

The dominant answer today is to fix almost everything. Roles are assigned, the sequence is set, tool access is scoped, outputs and hand-offs are defined in advance. The result is recognisably Taylorism, scientific management applied to agents: an assembly line on which each agent has one job, a fixed place in the sequence, and a defined hand-off to the next.^[1]

Figure 2. The fixed harness as factory line: efficient and certifiable, but engineered in advance and hard to vary.

The factory line earns its place. It delivers four things that matter: accuracy, speed, reproducibility, and behaviour you can certify. Because the harness is fully specified, variation is minimal, though never zero, since a language model sits underneath. It is auditable, so you can inspect exactly what changed and when. And it preserves linear causality: when something breaks, you can trace the effect back to its cause and repair the station that failed.

For closed, deterministic problems this is the right tool, and most engineering problems are of that kind. Payroll, tax, regulatory filing and the bulk of product features are well-defined and stable, with a clean temporal separation between problem and solution. They can be decomposed into parts and each part solved on its own. That is analysis in its purest form, and fixed harnesses are excellent at it. If the problem fits inside the factory, build the factory.

Where the fixed harness fails

The difficulty is that the factory's virtues are bought, and the currency is one you do not miss until you need it.

Reliability is purchased by suppressing the very variance that novelty requires. Determinism and emergence pull in opposite directions: every guardrail, evaluation and fixed code path that makes an agent predictable also shrinks the space it is permitted to explore. The result is optimised output and a hard ceiling on novelty. You can have reliability or emergent organisation from a single architecture, not both, and the factory chooses reliability.

There is also the obsolescence already noted. The scaffolding you build to compensate for a model's weakness becomes dead weight the moment the model no longer has that weakness, which is increasingly a matter of weeks.

A deeper limit has a name. In 1956 the cybernetician W. Ross Ashby formulated the law of requisite variety requisite variety: only variety can absorb variety.^[2] A controller can regulate a system only if it commands at least as much variety as the system it controls. A fixed harness has a finite, written-down repertoire; the real world has more variety than any such repertoire can hold. So whenever the agents meet conditions the author did not anticipate, the harness has no response, and a human must intervene to extend it.

That intervention is where the approach degrades. Each unforeseen case becomes another rule bolted on, and the more of the real world the harness meets, the more rules accumulate, until the harness is more complicated than the problem it was built to solve and no one on the team fully understands it. The scaffold has quietly become the structure.

The natural question, then, is how much of the work we are now pointing AI at is in fact a moving problem. To answer it we need to be clearer about what the real world is made of.

What the real world is made of

Two ways of seeing

There are two accounts of what the world is made of, and which one you hold determines what you count as good engineering.

The first is the reductionist, analytical view, the one most of us were trained in. To understand a whole, take it apart and study the parts. Things are stable; change is something that occasionally happens to stable things; relationships are secondary, mere plumbing between the components that matter. This is the metaphysics of the factory, and of nearly all the software we have shipped. You make components, wire them together, and the product holds still until you deliberately change it through a release.

The second is the systems, or relational, view, and for the problems we are now aiming AI at I think it is the truer one. It reverses the order: the world is not made of things but of processes and relationships, and those come first. What we call a stable thing is usually a slow pattern in an ongoing flow. An organism is more like a flame than a crystal. A flame looks like an object, yet it is a pattern held together moment to moment by a process; stop the process and the thing was never there.

Seen this way, emergence emergence is everywhere: simple local rules giving rise to order that nobody designed. The standard illustration is a flock of starlings. No bird intends a flock. Each follows roughly three local rules, stay close to your neighbours, align with them, avoid collision, and out of those local interactions comes the murmuration: a coordinated, living pattern that cannot be understood by isolating one bird, because no single bird contains the flock.^[3] The flock lives in the relationships, not the parts.

Both accounts are correct, depending on what is under study. The expensive error is not choosing one over the other; it is reaching for the wrong one. We make category mistakes.

Messes, not problems

Russell Ackoff named the category we keep missing. Practitioners, he observed, are rarely handed neat, separate problems. They are handed dynamic situations composed of many interacting problems that will not sit still.

That is Ackoff, writing in 1979.^[4] A mess is not a collection of separate parts but a system of relationships in motion, and it cannot be decomposed into tidy boxes and solved box by box, because the boxes keep reshaping one another while the work proceeds. This is precisely the situation a fixed harness handles least well.

Complicated is not complex

It is worth being exact about two words we use interchangeably, because they call for opposite strategies.

A complicated system, a jumbo jet or a mechanical clock, is made of passive parts in stable linkage. The parts do not change their behaviour in response to one another. It can be taken apart, analysed, planned and predicted. It is hard, but knowable, and the appropriate move is to analyse, then plan, then execute.

A complex system, a flock, a market, a cat, an organisation, differs in kind rather than degree. Its parts are adaptive and react to each other, so its behaviour emerges and cannot be derived from the pieces. The appropriate posture is not analyse-then-plan but probe, sense, and respond, a stance drawn from the complex domain of Snowden's Cynefin framework.^[5]

Figure 3. Two kinds of system. The factory is correct for the left-hand world; adaptive engineering is only for the right-hand one.

Here is the single most expensive mistake in modern work, stated plainly: treating a complex problem as though it were a complicated one. When ambitious efforts fail, they often fail not for want of execution but because of a category error committed before any code was written. A factory was brought to a forest. Robotics, multi-agent systems, and anything touching real markets, real institutions or many people at once are forests, and as AI leaves the sandbox a growing share of our problems will be too.

The anatomy of a complex adaptive system

If that is the terrain, it is worth setting out what a complex adaptive system complex adaptive system is made of, because the engineering discipline that follows is built directly on these properties.^[6]

Figure 4. The ingredients of a complex adaptive system.

It begins with many diverse agents, different from one another rather than clones, because diversity is the fuel. They act through local interactions: no agent sees the whole, each responds only to whoever is adjacent, exactly as a bird aligns with its neighbour. They learn recursively, adapting, then adapting to the results of their own adaptation, in a loop. And they co-adapt, changing with respect to one another and to their environment, so that everything is moving in response to everything else and nothing holds still.

Out of that local, adaptive, looping interaction comes emergence: genuinely new patterns, new organisation that nobody designed and no single agent contains. And yet such systems do not fly apart into chaos. They tend to settle into attractors, stable states they are repeatedly pulled back toward, which produces a characteristic tension: constant change at the local level, recognisable stability at the level of the whole. Nobody steers, and yet the system organises itself. That is both the mystery and the opportunity.

Adaptive engineering

Everything to this point has lived inside one frame: the human engineer decides the structure in advance. That is the factory, and for complicated, predictable problems it is the right method. The moment AI meets a world that is complex rather than merely complicated, we need a different idea of what good engineering is. The case rests on the two assumptions named at the outset: that models will continue to outpace the scaffolding we build for them, and that AI will increasingly act in the real, physical and social world rather than a sandbox.

The harness becomes the output rather than the input. You stop authoring the scaffold and start authoring the conditions under which a scaffold grows itself, one fitted to the problem the agents actually meet, which may not be the problem you imagined at the start, and which may have to change mid-engineering. What results is not a static structure but a self-organising, continually evolving multi-agent system.

How a harness emerges

The clearest way to see the claim is to watch a structure appear from nothing. It is less a procedure than a sequence one observes.

Figure 5. From a field of undifferentiated agents to a new level of organisation, with no structure imposed from above.

Phase 0, a field of agents. Begin with many agents that are, at first, undifferentiated and roughly identical, but capable of three things: interacting, learning, and changing. Crucially, roles, sequence and tool access are not assigned. In the factory those are the first decisions; here they are the ones we decline to make. The agents simply sit in the problem space and begin to interact.

Phase 1, coupling. They start exchanging work, at first only a hand-off here and there. But sustain the coupling and a threshold is crossed. percolation Once each agent has on average about one connection, the scattered fragments abruptly join into a single connected network.^[7] One moment, fragments; the next, a system. The engineer's lever is no longer the roles but the rate of coupling.

Phase 2, differentiation. Adaptation now takes hold. Two agents doing the same thing in the same place are redundant, and the environment rewards anything that breaks the tie. A small difference, who arrived first, who returned a slightly better result, is amplified by feedback until the two are no longer interchangeable. The uniform pool fractures into niches. An agent's identity, note, was not assigned to it; it is a position taken relative to the others. Specialisation emerges.

Phase 3, groups. Once agents differ, they stop connecting at random. Those that work well together interact more, and interacting more binds them tighter, so the network grows clusters: dense bonds within, sparse bonds between. The first boundaries appear, and the system, not the engineer, has drawn them. The clusters are emergent containers, and the harness has begun to exist.

Phase 4, order without a governor. Inside a cluster, as the same agents interact repeatedly, the same hand-offs begin to happen the same way and a convention crystallises: a division of labour, norms, protocols. The system has produced governance without a governor, conventions arising from local coordination with no central authority. This matters because it means the structure can continue to adapt in a decentralised way as the problem shifts, without waiting for instruction.

Phase 5, a new order. From all that local interaction, a new level of organisation has emerged, and the stable groups become the building blocks of the next level up. What remains is not the harness an engineer would have drawn but a stable attractor pattern fitted to the environment in which it grew.

The engineer is relocated, not removed

None of this implies dismissing the engineer and waiting for agents to produce genius unsupervised. That is a misreading worth heading off directly. The engineer does not disappear; the emphasis of the work moves, into three activities.

Exploit the model's capability. The approach is only viable because frontier models are now good enough to be entrusted with the three capacities that constitute a complex adaptive system. They can interact: sense what neighbours are doing, exchange messages, and model how others will act. They can learn: generate variants, keep what works and discard the rest, continuously and in the field rather than waiting for an offline retrain. And they can change: revise not only what they do but what they are, their role, goals and self-model, specialising into the niches others leave open. That third capacity is the deepest and the most dangerous, because it is where value drift can take hold.

Engineer the constraints. Left wholly alone, agents that interact, learn and change will produce as much chaos as order. Since the resulting structure cannot be dictated, you instead shape the field of play. A constraint is the rules of the game: it shapes what can happen without deciding what does. You write the rules; you do not play the game or pick the winner. Three questions are worth asking of any constraint:

• Does it enable or govern? An enabling constraint creates new moves, a shared language, a market, a scoreboard. A governing constraint closes options, a speed limit, a locked door. Enabling says "you now can"; governing says "you may not".^[8]
• Is it a wall or a goal? To stop a system flying apart you can build a wall around it, a container that permits anything inside, or give it a shared goal to orbit, a coherence that holds the parts together with no fence at all. Usually you want some of each.
• How fast? This is not a rule but a tempo. Rather than switching everything on at once, open one small, reversible thing, observe, then widen. The rate of coupling is the dial.

Sense and respond. Once structure begins to form, the work is to read the patterns, amplify the healthy ones, and dampen the harmful ones before they harden. The role is closer to an ecologist than an architect: working with what grows rather than dictating it.

A continuum, not a binary

In practice this is not an either/or. It is better understood as a continuum running from the purely fixed harness, imposed, centralised and closed, to the fully adaptive one, emergent, distributed and open. Most tools sit somewhere along it, and where they sit follows from their design philosophy rather than from one end being superior.

Figure 6. The fixed-to-adaptive continuum. Adaptive engineering is the right-hand pole, not a verdict on the rest.

Two distinctions keep the placement honest. The first is between vertical and horizontal intelligence. Vertical intelligence makes an individual agent smarter; horizontal intelligence concerns how a group of agents coordinates. The two are orthogonal, and the thesis here is horizontal: because adaptability and agility are coordination problems, the higher-leverage point is not any single agent's capability, which is what frontier models supply and will keep improving without our help, but the rules of interaction between agents. The second distinction is between systems that are adaptive at design time, easy for an engineer to reshape and extend before a run, and systems that are adaptive at runtime, reorganising themselves while running in response to the task. They are not the same claim.

Two harnesses near the adaptive end show why the distinctions matter. Hermes describes itself as a self-improving agent that creates its own skills from experience and learns over time, which is a genuine and significant step in the adaptive direction; but it largely makes a single agent smarter through a learning loop, which is vertical intelligence. Pi is a deliberately minimal, maximally extensible harness, fully customisable in the engineer's hands. It is strongly adaptive at design time and makes almost no claim to be adaptive at runtime; it is not a self-organising multi-agent system, and does not present itself as one. Neither is a counterexample to the thesis. Both help locate it.

The factory and the forest

The two disciplines are best compared property by property, which also makes clear why the right-hand column reads like biology rather than engineering.

"Better", in a fixed harness, means optimising toward a metric you have set. In an adaptive one it means co-adapting as the landscape itself moves underneath you, the Red Queen Red Queen condition, in which you run to stay in place because everything around you is running too.^[9] A factory optimises; a forest survives.

Failure modes of the adaptive approach

It would betray the argument to present only the upside. Adaptive engineering is neither obviously better nor remotely benign, and "release a swarm of agents and intelligence will appear" is a fantasy rather than a method. Its failure modes are real, and several are more troubling than anything the factory suffers.

Emergence tends toward stable, not toward good: a self-organising system will happily settle into a harmful attractor and, once there, prove hard to dislodge. Without genuine selection pressure, adaptation degenerates into drift. There is a monoculture risk, since agents built on similar models trained on similar data vary less than the diversity the whole approach depends on. There is legibility collapse: as adaptability rises, the ability to explain why the system did what it did falls, and the two appear to trade off directly. And there are two that should give any serious engineer pause. Irreversibility: complex systems lock in, and a stable bad equilibrium can outlast a good one. And the accountability gap: in the factory a failure has an owner, a station, a line, a person; in an emergent system a failure may have only a shape, harm produced by a pattern that no single agent authored and no one chose. For most of what software is asked to do, especially anything safety-critical, that is disqualifying, which is precisely why the factory is not going anywhere. Reproducibility, auditability and a clear chain of responsibility are not bureaucratic luxuries; in medicine, in finance, in regulated work, they are the product.

So this is not a replacement but a second discipline for a second kind of problem, and much of the craft lies in knowing which problem is in hand: the factory for the complicated and the closed, the forest for the messy, the shifting, the genuinely novel, the work that changes faster than a release cycle can follow.

The limiting factor

As models continue to improve and AI engineering moves further out of the sandbox and into the actual world, the physical and social environment, the press of many humans and many other agents adapting at once, the discipline will be forced to rethink itself around continual production rather than discrete releases: software that is never quite finished because the problem it addresses is never quite still.

In that world the limiting factor stops being the strength of the model. It becomes the adaptability of the harness. We have spent the frontier era treating intelligence as the scarce resource, the quantity to maximise and the bottleneck to break. Intelligence is becoming abundant. What stays scarce is coordination: the capacity of a system to reorganise itself, mid-run, without a human reaching in to redraw the wiring every time the ground shifts. That capacity is horizontal, decentralised, and exercised at runtime rather than designed in advance.

Which means the engineer's role is changing underneath us, from the author of a machine to the cultivator of a system: choosing the soil, the constraints and the selection pressures, and then exercising the genuinely difficult discipline of not reaching in to arrange the branches by hand. The factory taught us that good engineering is control. The forest asks whether we can still be good engineers when the most important things are the ones we have chosen not to control. That is not, in the end, a question about our tools. It is a question about us.

Related reading:

• Incerto: Antifragile by Design - Why resilience and antifragility differ, and why systems that gain from disorder are built differently
• The Fundamentals of Systems Theory - Feedback, emergence and boundaries: the grammar underneath this argument
• The Systems Paradigm - Linear versus non-linear causality, and the shift from parts to patterns
• Trade-offs Thinking - There are no solutions, only trade-offs: the factory and the forest are one more instance