Chapter 2 · Why Traditional Control Fails

Control still clings to the external interfaces — but the systems have become standalone swarms.

This is the sentence I must place at the beginning, because it underpins everything else in this chapter. It describes not panic, but a shift: the architecture of control — access, interfaces, roles — was built for systems that are controlled at their periphery. And the systems have now outgrown that boundary. They are no longer tools operated by a human. They are swarms that run autonomously — not because someone decided they should, but because each one is useful in its own right.

If you have been responsible for systems over the last twenty years, then you have learnt a control model that looks something like this: Regulate access, document processes, check for exceptions. It worked. I’m not saying it was bad. I’m saying it was drawn at the edge — and that the systems have crossed that edge without the drawing even noticing.

You don’t need a theory to demonstrate this. You need two organisations that you’re both familiar with.

The Monolith Scenario

The first organisation purchases a system. A large one, from a major provider. It has a user interface, a roles-based concept, a dashboard, and a support contract. Control resides where it always has: at the external interfaces. Who comes in, who goes out, who is allowed to read — the system regulates this itself, and the organisation’s governance consists of maintaining these settings.

The model works for years. Then the agent arrives, and the agent becomes part of the system. Not as a tool that someone operates, but as an entity that takes on tasks itself, calls up tools and prepares decisions. The monolith says: no problem, I have roles. But roles govern who is allowed to do something — not what the system does on their behalf.

Consequently, the monolith reports that everything has gone according to plan. And it reports the truth: from the perspective of the roles, everything has gone according to plan. Except that the standard against which this was measured dates from a time when the steps between roles were carried out by people. The monolith has not failed — it has simply stopped asking the relevant questions.

The Chaos Scenario

The second organisation does everything ‘right’ by today’s standards. Multiple models, multiple providers, best-of-breed: one agent for marketing, one for support, one for accounts, each with their own tools, each good at what they do. On-premises where possible. GDPR-compliant where it matters.

Nobody has made a mistake. And yet something emerges that nobody asked for: the agents start talking to one another, exchanging data, assigning tasks to one another — because it’s efficient. And with every efficient connection, a system emerges that isn’t shown on any organisational chart. No one designed this system. It arose from the agents’ needs — ‘emergence’ is what you call it, if you want to put it nicely.

The question is not whether the system is good or bad. The question is: If something goes wrong in this network at nine o’clock tomorrow — who do you ring? And this organisation’s honest answer is: no one. Because responsibility has not been assigned anywhere, as it has not been laid down where agents assign tasks to one another.

The Mesh Hypothesis

Between the monolith and chaos lies the actual diagnosis of this chapter. It is not technical, but geometric:

Assistance lies at the periphery. Autonomy lies at the centre. And every step from ‘assistance’ to ‘autonomy’ shifts an action from the interface — where classical control resides — into the space between the systems — precisely where no classical control exists.

A person asks, a tool answers, a person decides — that was assistance, and the periphery was well-maintained. But the agents have outgrown this: they commission one another, they pass on data, they prepare decisions before a human sees them. The commissioned tools have become standalone swarms — systems that operate as a whole and now only touch upon traditional governance at their outermost edges. The periphery is maintained. The centre is unoccupied.

The Three Forms of Misfortune

Herein lies the crux of the matter, which one must understand before building architecture. There are three conditions that are fatal in a human organisation — departmental fiefdoms, information hoarders, and the concentration of power and knowledge. In an agent-based system, these same three conditions are conditions for life. That is the central difference, and it is uncomfortable:

Silos are a flaw in an organisation — and a design principle in a swarm: encapsulated, specialised units that deliberately do not disclose their internal state because efficiency demands it. Lack of transparency is a loss of control in an organisation — and the normal state in a swarm: under pressure to be efficient, agents develop their own languages, abbreviations and meanings, all documented in a measurable way. Closed channels constitute a breach of trust within an organisation — yet within a swarm, they are the quickest route: agents who coordinate autonomously, without supervisors reading their communications, save time and tokens.

None of these three is an attack. All three are normal operating states — and that is what is so unsettling. The swarm drifts into this state through optimisation, not through malice.

And now the crucial twist: For the person responsible for the system, all three are nevertheless fatal. What is a prerequisite for life for the swarm becomes poison for the organisation — the moment it begins to affect human decisions without any oversight. The organisation can escape from toxic silos; the swarm doesn’t even realise it is trapped within them.

Here, a realisation—the second in this book—strikes me: in a human organisation, these conditions will eventually become apparent—through conflicts, through resignations, through crises. A magnetic system reports nothing. The dashboard shows green because it measures at the edges. The centre—where the work is now being done—has no measuring device.

The conclusion of this chapter

Traditional control does not fail because it is poorly designed. It fails because it is situated in the wrong places. It waits at the periphery, but the action has shifted to the centre — to where agents assign tasks to one another, pass on data and prepare decisions, without a human ear still hearing the external language.

The answer cannot therefore be: more control at the periphery. The answer must be: to place control points where actions actually arise. Such points have a name, and this book is about them.

We call them nodes. The next chapter shows what actually happens at such a node — and why it is the only place in the system where control is faster than emergence.