Responsibility cannot be delegated to architecture — it can only be distributed amongst people.
This is the most uncomfortable sentence in this book, which is why I have placed it at the beginning of the most important chapter. For everything we have built up to this point — the diagnosis of the abandoned centre, the node as a checkpoint — boils down to a question that no architecture can answer: Who?
Chapter 3 ended with the observation that the junction is machinery and that responsibility requires a network. This chapter is about that network. It is called the Accountability Mesh, and its core principle can be summed up in a sentence that has remained unchanged since the first version of this idea:
Not every subagent needs a name. But every node needs an owner. Every interface needs a person. Every process needs accountability.
Not every subagent needs a name. But every node needs an owner. Every interface needs a person. Every process needs accountability.
Why traditional accountability is not enough
Every organisation has a system of accountability based on the organisational chart: department heads, divisional managers, senior management. It works for human labour because human labour fits within the organisational chart: it has a place, a line manager, a career path.
Agentic work does not fit within the organisational chart. It lies — as diagnosed in Chapter 2 — in the middle, between the systems. And where no organisational chart applies, no accountability applies either. This is not a matter of negligence on the part of those involved; it is a gap that arises when the structure of accountability grows more slowly than the structure of work.
The Accountability Mesh closes this gap. It is not an alternative to the organisational chart — it is the second network that spans precisely where the organisational chart ends: between the systems.
The idea: federated responsibility
The Mesh is based on a simple principle that I call federated responsibility. It means:
Responsibility is not centralised, but is delegated to the places where decisions are made.
The centralised approach — ‘the AI officer is responsible for everything to do with AI’ — fails for the same reason as centralised control: it sits on the periphery and does not reach the centre. And it creates a situation familiar to everyone in large organisations: responsibility that formally lies with one person but, in practice, with no one.
The federated approach distributes responsibility: every node in the system — in the technical sense described in Chapter 3 — has an owner. Every interface between systems has a designated person. The mesh is the overall picture of these assignments: not a committee, but a network of responsibilities that takes the same form as the system itself. Where the swarm grows, the mesh grows with it. Where the mesh does not grow with it, what would otherwise remain invisible immediately becomes apparent: a node without an owner.
The three levels of the mesh
The mesh spans three levels. They build upon one another, and none can replace the other:
Level 1: Within the system. Every agent-based node within a system has an owner — the person responsible for the rules governing that node, who receives its escalations and checks its exceptions. This is the lowest, indispensable level: it gives every checkpoint a face.
Level 2: Between systems. Every interface through which systems interact with one another has a designated person — someone who can answer the question ‘What happens at this interface?’ with a simple ‘yes’ or ‘no’ without having to look it up first. This is the level that is usually the first to be lost in practice, because interfaces belong to no one as long as no one owns them.
Level 3: Semantics. Every meaning shared within the system — what ‘critical’ means, what ‘approved’ means, what ‘customer’ means — has a verifying authority: someone who decides when two departments use the same word differently and the collective understands it differently. This level sounds soft, but it is the toughest: Chapter 6 shows that semantics becomes a security issue as soon as it belongs to no one.
Anyone who takes these three levels together will see the crux of the mesh: it is not a control body that monitors from above. It is an ownership structure that grows from the bottom up — and does so precisely in the form of the system that makes it accountable.
The question of scaling: node categories
So far, the Mesh sounds like a promise no organisation can keep: if every node needs an owner and the system has hundreds of nodes — does it then need hundreds of people?
No. And the answer is the most important practical aspect of the Mesh: Nodes are grouped into categories, and each category has one owner.
A node is a checkpoint — but many checkpoints monitor the same thing. The node that approves the CRM export, the node that validates the marketing data field, and the node that oversees agents’ access to customer data: three checkpoints, but one set of rules, one risk type, one responsibility. They form a category — and the category has an owner who creates, monitors and develops it further. One person, several nodes: this is not a compromise on control, but its most sensible form. Control that requires one person per checkpoint would not be governance, but a staffing plan.
The category is also the right scale for the third rule of the Mesh (“Assignments expire”): it is not every single node that is checked, but the category — its set of rules, its borderline cases, its escalation history. The owner of a category does not view their nodes as a list, but as a landscape.
The fourth level: overlap
And this closes a gap that remained open in the first draft of the Mesh: nodes overlap. The same data flow touches two categories (customer data and data protection), the same agent serves two departments, the same interface supports two sets of rules. A category owner who sees only their own category carries out only a half-check at such points — and, in the context of this book, a half-check is worse than none at all, because it creates a sense of confidence that no one can back up.
That is why the Mesh needs a level above the categories: the overlap level. Where node categories intersect, a distinct point of responsibility arises — either as an assignment to the owner whose category bears the greater risk, or as a designated dual responsibility with a clear rule on who decides in the event of a conflict. Overlap is not a special case that can be tidied up; it is the normal state of mature systems. The Mesh resolves it not through pruning, but through designation: Where two sets of rules meet, there is a person who determines which one applies.
This gives the Mesh four levels: within the system, between systems, in semantics — and above the categories. Four levels, one principle: no point in the system where responsibility falls into a void.
The difference from traditional control
One might object: ‘Don’t we already have this? Responsibility matrices, RACI models, process-oriented organisation?’ This objection deserves an honest answer, for the Mesh is not the invention of responsibility — it is its extension into a structure that traditional matrices cannot represent.
A RACI matrix assigns responsibility for processes — linear sequences with a beginning and an end. The Mesh assigns responsibility for connections — points where autonomous systems intersect and prepare decisions that nobody has modelled as a process. The difference is the same as that between an organisational chart and a swarm: one is drawn, the other has grown. For something that has grown organically, you do not need a new hierarchy — you need an allocation that grows with it.
The Mesh in practice: three rules
To ensure the Mesh does not become merely a declaration of intent, three rules suffice. They are deliberately simple, because the Mesh thrives on being implemented on a small scale:
- No new node without an owner. Whoever puts an agent, an integration or an interface into operation must, at the same time, designate the owner. No owner, no operation.
- Every escalation has an address. A node without a known recipient is a flaw in the architecture, not an operational risk. Pillar 3 from Chapter 3 becomes an organisational rule here.
- Assignments expire. Ownership is not a vested right, but a state with an expiry date: People leaving, changing roles, outdated systems — the assignment is reviewed and renewed before it becomes obsolete. (This book practises what it preaches: even its statements become obsolete.)
What the Mesh is not
Honesty at the end, as always: the Mesh is not a safety net in the sense of ‘nothing will go wrong’. It does not guarantee that nothing will go wrong — it guarantees that if something does go wrong, there is a person who will take responsibility for it, understand it and make a decision. That is a huge difference. The first is a promise that no one can keep. The second is a structure that any organisation can build — and which, once built, brings about the most remarkable thing: systems in which errors find people faster than people find errors.
This covers the machinery (Chapter 3) and its network (this chapter). What is still missing is the person themselves. Not as a role description, not as a job profile — but as a question: what does a person actually do at a node, and why can’t a machine replace them there? That is the subject of the next chapter.
