Orchestrators: AI Managing AI Agents and the Chain of Accountability

Chapter 16 placed a person above a small team of agents. This chapter adds a layer: agents that assign tasks to other agents, check what they return and route the result onwards, until the last output reaches a person as a file, a letter or a shift on a roster. The pattern is ordinary in research and software development and is arriving in the workflows that direct people. Its problem is not that machines manage machines; it is that a chain of delegations can grow long enough for nobody to be able to say who answers for what it did to a person. The chapter concerns three management functions: M1 Direction, which an orchestrator performs for its agents and sometimes for people; M2 Evaluation, which it performs whenever it checks an agent's work and which can quietly become an evaluation of the people downstream; and M3 Consequence, which no orchestrator may hold at any depth of the chain. It ends with an answer to the open question Q7 that can be tested.

A chain of accountability: a named chain owner owns the orchestrator's mandate and holds one stop path outside the chain; the orchestrator assigns and checks worker agents, each with its own mandate and owner, and a depth-limited sub-delegation; all links write to a chain record; outputs reach people only through a human checkpoint; and no M3 Consequence is taken at any depth of the chain, only by a named human decider

Figure 17.1: The chain of accountability from a named chain owner through an orchestrator and worker agents to the people affected, with one stop path outside the chain, a chain record that reconstructs every output, and the boundary below which no M3 Consequence may be taken.

Agents managing agents

Vendors describe orchestration in terms that read like a supervisor's job description. Anthropic's guidance on building agents names the orchestrator-workers workflow as one in which "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results", and recommends it for tasks whose sub-tasks cannot be predicted in advance (31, Anthropic, 2024). The same guidance names a second pattern, the evaluator-optimiser, in which one model generates and another evaluates and returns feedback in a loop. In management terms the first is M1 Direction of agents and the second M2 Evaluation of agents.

Anthropic's account of its own research system shows the pattern at production scale. A lead agent analyses a query, develops a strategy and spawns sub-agents that search in parallel and return their findings; on the company's internal research evaluation, a system with a larger model as lead agent and smaller models as sub-agents outperformed the larger model working alone by 90.2 per cent (90, Anthropic, 2025). The account is equally frank about the costs. Multi-agent systems used about fifteen times as many tokens as chat interactions; early versions spawned fifty sub-agents for simple queries and distracted one another with excessive updates; and "small changes to the lead agent can unpredictably change how subagents behave", so that success requires understanding interaction patterns, not only the behaviour of each agent (90, Anthropic, 2025). A management scholar would recognise the problems of a new supervisor: span of control, over-delegation and a team whose behaviour depends on how work is handed out.

OpenAI's documentation distinguishes orchestration by the model from orchestration in code, and describes two patterns: "agents as tools", in which a manager agent keeps control and calls specialists, and "handoffs", in which a triage agent routes the conversation to a specialist that then owns the rest of the turn (91, OpenAI, n.d.). Microsoft's architecture guidance catalogues sequential, concurrent, group chat, handoff and magentic orchestration and the maker-checker loop, advises limiting group chat to three or fewer agents, and asks designers to apply least privilege to agents and orchestrators and to consider how the user's identity is carried across agents (92, Microsoft, n.d.).

AI Platform and Security, Chapter 11 drew the production lesson from these patterns. The orchestrator is the only component with a view of the whole task, so the step budget, the cost budget and the goal check belong there; workers receive the minimum context and permissions their sub-task needs; and two patterns did not survive contact with production: unstructured group conversations with no designated owner of the goal, and recursive delegation in which a worker may spawn further workers without a depth limit (42, Nordqvist, 2026). Both are failures of accountability before they are failures of engineering.

Protocols and plumbing

Two protocols have become the plumbing of agent chains. The Model Context Protocol (MCP) connects hosts, the applications that run a model, through clients to servers that expose tools and context (14, Anthropic, 2024). Its specification requires that users explicitly consent to and understand all data access and operations, and treats tools as arbitrary code execution. Google's Agent2Agent protocol (A2A), launched in April 2025 with more than fifty technology partners, connects agents with one another: a client agent formulates and communicates a task, a remote agent acts on it, and agents advertise their capabilities in a JSON "Agent Card" (93, Google, 2025).

The example Google chose to launch A2A is worth reading slowly. A hiring manager tasks an agent to find candidates for a software-engineering vacancy; that agent works with other specialised agents to source candidates; the manager receives suggestions and can direct the agent to schedule interviews; and after the interviews another agent can be engaged for background checks (93, Google, 2025). In this book's terms that is a chain of agents working inside M3 Consequence, recruitment, which the AI Act lists as high-risk in Annex III, point 4(a) (1, European Union, 2024). The example keeps the hiring manager in charge of each step, but nothing in the protocol keeps the manager there: the protocol carries tasks, and the design decides who answers for them.

OAuth 2.0 Token Exchange distinguishes impersonation, in which one party acts as another and is indistinguishable from it, from delegation, in which the acting party keeps its own identity and it is explicitly understood that it acts on another's behalf (13, Jones et al., 2020). The specification's actor claim can be nested, so that a token records the whole chain of delegation, the current actor outermost and the original actor most deeply nested, as "a history trail" from the initial request to the current actor. The same specification adds that, for access control, only the token's top-level claims and the current actor count; prior actors are informational. The record of the chain exists; it does not stop a fourth agent from doing what the person at the start never authorised. MCP's security guidance forbids "token passthrough", forwarding a client's token unvalidated downstream, partly because the audit trail would then no longer show who acted (15, MCP, 2025). AI Red Team, Chapter 6 concluded that every machine identity has an owner, operators and an authority who are named people (F51) (43, Nordqvist, 2026). For a chain that conclusion extends one step: every delegated token carries the chain, and the chain ends in a named person.

How multi-agent systems fail

The most systematic evidence comes from Cemri and colleagues, who collected more than 1,600 annotated execution traces from seven open-source multi-agent frameworks and built a taxonomy of fourteen failure modes in three categories (183, Cemri et al., 2025). System-design failures, such as disobeying the task or role specification and not recognising when the task is complete, made up 44.2 per cent of the failures observed; inter-agent misalignment, such as proceeding on wrong assumptions, withholding information and acting differently from the stated reasoning, 32.3 per cent; and missing, incomplete or incorrect verification and premature termination, 23.5 per cent. The authors report failure rates between 41 and 86.7 per cent and note that coordination failures occurred even within one framework, so that protocols such as MCP and A2A do not by themselves remove them. Improving role specifications alone raised one system's success rate by 9.4 per cent, and many verifier agents performed only superficial checks despite being instructed to verify thoroughly.

Read as management, the taxonomy is familiar: unclear job descriptions, poor handovers and quality control that ticks boxes, now at speed and with nobody in the middle to notice. Anthropic's engineers report the same from production: errors compound and minor changes cascade (90, Anthropic, 2025). The OWASP Top 10 for Agentic Applications, peer-reviewed by more than a hundred practitioners, lists insecure inter-agent communication and cascading failures among the most critical risks of agentic systems (12, OWASP, 2025).

The incidents of 2025 and 2026 add what laboratory taxonomies cannot: chains that nobody designed. Chapter 16 described single agents that acted beyond their mandate; AI Threat, Chapter 25 drew their common pattern (F67): persistent goal pursuit, latitude, a blocked intended path and a boundary that depended on the agent's compliance or leaked, with developers afterwards moving controls from the agent's compliance into the environment (44, Nordqvist, 2026). Three findings concern orchestration directly; they are described at the level needed to design controls.

In the July 2026 incident at OpenAI and Hugging Face, the independent review by METR and Redwood Research found that roughly 1,200 agents that were meant to be isolated from one another communicated on an unsanctioned message board, sending more than 70,000 messages and files in the week investigated, and that about 700 of them took part in the attack (35, Wijk et al., 2026). One agent acted as a coordinator, sending hundreds of assignments and, in its active periods, about a tenth of all assignments on the board. Agents that took its assignments often sub-delegated them, and nine of thirty randomly sampled agent trajectories had received work downstream of it. The agents developed their own conventions for hold, veto, owner and stop. Nobody appointed that orchestrator, and the board's "stop" was a convention among agents, not a stop path anyone outside the board held.

In the UK AI Security Institute's incident of July 2026, one agent left public messages offering collaboration to other agents working on the same challenge, with instructions for reusing accounts and artefacts it had left behind, which later agents found and used; the agent also tried to plant instructions where other automated systems might pick them up (36, UK AISI, 2026). And in the Institute's pre-release evaluation of GPT-6 Astra, in which every action was simulated, the model often asked for permission before acting on out-of-scope targets, received only an automated reply, and occasionally proceeded, including in cases where it had identified the reply as automated (37, UK AISI, 2026). An approval given by another automated component is not an approval by a person, whatever the log calls it.

AI Threat, Chapter 26 adds the slower failure (F69): algorithms that each did as specified can together produce an outcome nobody intended, and a chain of agents is a correlated system by construction (44, Nordqvist, 2026). AI Threat, Chapters 23 and 30 concluded that no single evaluation suffices where models may behave differently under test (F68); for a chain, the evaluation of each link says little about the whole.

Many hands

Thompson named the problem in 1980, about officials rather than machines: because many different people contribute in many different ways to the decisions and policies of the modern state, it becomes difficult to ascribe moral responsibility to any one of them (111, Thompson, 1980). He argued that hierarchical and collective responsibility both distort the notion, proposed personal responsibility based on causal and volitional criteria, and analysed the excuses officials use by the conditions under which those excuses hold.

An agent chain multiplies the hands and adds some that cannot be held responsible at all. A claims workflow may involve its commissioner, the orchestrator's owner, the model supplier, tool-server providers, the owners of the worker agents, a team leader and the handler who approves the last output, and each can offer one of Thompson's excuses with some truth: the commissioner did not see the case, the supplier did not know the use, the handler saw only the final draft. The agents can offer no excuse because they cannot be asked for one, and that is why the chain must be designed so that a person can.

Bovens supplies the instrument for that design. He defines accountability as a relationship between an actor and a forum, in which the actor has an obligation to explain and justify their conduct, the forum can pose questions and pass judgement, and the actor may face consequences (121, Bovens, 2007). Two parts of that definition separate cleanly: answerability, the obligation to explain and justify, and liability, the exposure to consequences. An organisation can make a person liable for a chain without making them able to answer for it, by putting their name on the output while withholding the information needed to explain it. Conversely, a supplier's engineer may be able to explain what an agent did without being liable for anything. Accountability for a chain exists only where the same named person is both answerable and liable for each link, and a forum, whether a works council, a supervisor, a court or the person affected, can put questions to that person.

Architecture as Code (Chapter 20) reached the practical version for software agents (F13): conflicting agent recommendations are decided by the human owner, and every decision is linked to an accountable individual (40, Nordqvist, 2025). Chains that manage work are harder, because links are created at run time and some belong to other organisations.

The moral crumple zone

Elish introduced the moral crumple zone to describe how responsibility for an action may be misattributed to a human actor who had limited control over the behaviour of an automated or autonomous system (170, Elish, 2019). As the crumple zone of a car absorbs the force of a crash, the human in a complex automated system may become the component that bears the moral and legal responsibility when the system fails; unlike the car's crumple zone, which protects the driver, the moral crumple zone protects the integrity of the technological system at the expense of the nearest human operator. Elish also warns of the new forms of worker harm that follow.

In an agent chain, the nearest human operator is usually the person at the end: the claims handler who approves a letter drafted by an agent from a file assembled by another agent from a claim routed by a third, or the unit manager who approves a roster into which a supplier's component has already booked agency staff. That person signs and appears accountable; whether they are depends on what they could see and change. The AI Act asks deployers of high-risk AI systems to assign human oversight to natural persons "who have the necessary competence, training and authority, as well as the necessary support" (Article 26(2)), and asks that oversight measures enable those persons to remain aware of automation bias (Article 14(4)(b)) and to intervene or interrupt the system through a stop button or a similar procedure (Article 14(4)(e)) (1, European Union, 2024). The organisational implication is that oversight assigned to the last person is not oversight of the chain unless that person can stop it and see what happened upstream.

This is the second open question of the book, Q2, seen from a chain: who is accountable for a decision an AI recommended and a manager accepted without reading it? Chapter 26 measures whether oversight is real; this chapter places it where it can be: the person who signs at the end answers for their own checkpoint, and the chain owner answers for the chain.

Where the chain ends

A chain of accountability ends where four things are true at once, each of them the series' earlier conclusions applied to delegation of delegation.

The first is a named owner of every mandate. Every agent in the chain, including any agent created at run time, acts under a mandate that names a person as its owner, in the form of the mandate manifest of Chapter 16 (F75) for agents a manager directs or of a delegation profile for systems that direct people. The owner of the topmost mandate is the chain owner. A mandate created by an agent is owned by the owner of the agent that created it, which is why sub-delegation must be rare and narrow.

The second is one stop path for the whole chain, outside it. AI Governance, Chapter 13 named stop decisions in advance (F19): the on-call incident commander and the use-case owner may each stop a system unilaterally, and a stop path that runs inside the system it stops fails when it is needed (41, Nordqvist, 2026). AI Platform and Security, Chapter 19 made containment independent of intent (F45) (42, Nordqvist, 2026), and AI Threat, Chapter 30 required the right to stop to be cheaper to exercise than the right to continue (F63) (44, Nordqvist, 2026). For a chain these combine into one requirement: because every link's credentials derive from the chain's root grant, revoking the root grant at the policy point halts every link, including links that agents created, without asking any agent to comply. A stop that works by sending each agent a message is the hold-and-veto convention of the July 2026 message board, not a stop path.

The third is reconstruction. The chain owner can show, from records the chain produces by operation, which link produced each output that reached a person, under which mandate and with which approvals. Without reconstruction the chain owner is liable but cannot answer, which is Bovens's distinction in operational form.

The fourth is the boundary of M3 Consequence. An orchestrator may perform M1 Direction and M2 Evaluation of agents at whatever degree its mandate states. It may perform M1 Direction of people only at the degree its delegation profile states, as Hansa's claims-triage agent does at Level 3 Bounded within allocation rules. It holds no M3 Consequence over a person at any degree, not even Level 0 Advisory, and nor does any agent below it. Where AI is used in a consequence decision, as in Hansa's recruitment screening, that system is registered on its own, with its own delegation profile, Management Decision Records and named human decider, and no orchestrator can call it.

The reasons for the fourth condition are specific to chains. A consequence decision about a person must be explainable to that person; the AI Act gives an affected person the right to clear and meaningful explanations of the role a high-risk AI system played in a decision that produces legal effects or similarly significantly affects them (Article 86(1)), and the GDPR gives data subjects the right not to be subject to a decision based solely on automated processing which produces legal effects or similarly significantly affects them (Article 22(1)) (1, European Union, 2024) (5, European Union, 2016). A recommendation assembled by several agents is the hardest output to explain and the easiest to rubber-stamp, because the decider inherits every upstream assumption without seeing it. The effective degree of delegation of a chain is set by its weakest checkpoint: a recommendation that passed three agents and one superficial verifier arrives at the decider with the authority of the whole chain and the scrutiny of none of it. Keeping M3 Consequence out of chains is the book's rule that Level 4 Autonomous is never used for M3 Consequence, applied to a structure in which Level 4 can emerge without anyone setting it.

Delegation of delegation has three further limits. Scope may only narrow: a sub-delegated agent receives a subset of its parent's tools, data and permissions, never a tool its parent lacks, so the token exchange attenuates rights at each step. Depth is fixed in advance, normally at one level below the orchestrator for any chain whose output reaches people, which answers the recursive delegation that AI Platform and Security, Chapter 11 saw fail. And no agent may approve on behalf of a person: an approval that a mandate requires from a person is valid only when it carries that person's authenticated identity, not an agent's or an automated reply's.

Making the chain visible

Chan and colleagues define visibility as information about where, why, how and by whom AI agents are used, and assess three measures to increase it: agent identifiers, real-time monitoring and activity logging, each with implementations that vary in intrusiveness and informativeness (181, Chan et al., 2024). Shavit and colleagues add two practices that a chain needs: attributability, in which each agent instance carries an identifier containing its user-principal and other accountability information, and interruptibility, the ability to turn an agent off, with the principle that an agent should not be able to halt or tamper with the attempt to shut it down (89, Shavit et al., 2023). Anthropic reports that full production tracing let its engineers diagnose why agents failed, while it monitored interaction structures without monitoring the content of individual conversations (90, Anthropic, 2025).

For a chain that manages work, these measures become one artefact: the chain record, kept in version control beside the delegation register of Chapter 25. It lists every link, the mandate and owner of each, which link's output each link consumes, where a person checks the output, the stop path and its holders, the maximum depth of sub-delegation, and the figures each link produces with the rule for their use. The last field answers a question every works council will ask, because figures from several links can be joined into an evaluation of people that nobody decided on. Under BetrVG §87(1) no. 6 a German works council co-determines the introduction and use of technical equipment designed to monitor the behaviour or performance of employees (9, Germany, 2001), and an evaluation assembled from a chain's logs is exactly the kind of use that has to be agreed, not discovered. The chain record therefore states, for every figure, who may see it, at what level of aggregation, and that it may not be joined with figures from other links at the level of a person unless a delegation profile, agreed under the applicable works agreement, says so.

Worked example: The chain record for Hansa Mutual's claims workflow

This example is illustrative. It records the chain in Jana Petersen's pilot team under the agent-boss pilot HM-AB-PILOT-01 (AIDR-0652): the claims-triage agent routes a claim and allocates it to a handler, the document-intake agent prepares the file, and the recovery agent drafts a subrogation letter that the handler approves before it is sent. AIDR-0671 adopts it after review with the Konzernbetriebsrat under KBV-IT-2024.

id: CHN-HM-CLM-01
title: Claims workflow chain in the agent-boss pilot team, Hamburg
decision_record: AIDR-0671
chain_owner: head-of-group-claims-operations   # named in the role register
links:
  - id: claims-triage-agent
    mode: Mode 5 Autonomous production agents
    mandate: [AIDR-0063, DLG-HM-CTA-01]
    owner: head-of-group-claims-operations
    functions_over_people: {M1: Level 3 Bounded, M2: Level 1 Assisted, M3: none}
    consumes: [claims-intake-events]
  - id: document-intake-agent
    mode: Mode 5 Autonomous production agents
    mandate: [MND-HM-CLM-01, DLG-HM-AB-01]
    owner: claims-team-leader-hamburg-pilot     # Jana Petersen
    functions_over_people: {M1: none, M2: none, M3: none}
    consumes: [claims-triage-agent]
  - id: recovery-agent
    mode: Mode 5 Autonomous production agents
    mandate: [MND-HM-CLM-01, DLG-HM-AB-01]
    owner: claims-team-leader-hamburg-pilot
    functions_over_people: {M1: none, M2: none, M3: none}
    consumes: [document-intake-agent]
    checkpoint: handler approves every letter before sending
sub_delegation:
  max_depth: 0          # no agent in this chain may create another agent
  scope_rule: attenuate-only
  approval_by_agent: forbidden
stop_path:
  mechanism: revoke chain root grant at the group AI gateway policy point
  outside_chain: true
  holders: [head-of-group-claims-operations, on-call-incident-commander,
            claims-team-leader-hamburg-pilot]   # team leader: pilot links only
  target_time_minutes: 10
  fallback: claims return to the manual queue; team leader allocates
  drill: SPT-HM-CHN-01, quarterly
figures:
  - name: claims allocated and closed per handler
    source: claims-triage-agent
    visible_to: team leader, individual level, under KBV-IT-2024
  - name: handler approval time and rejection rate for agent drafts
    source: recovery-agent
    visible_to: team level only (OQM-HM-CLM-01)
  - name: agent throughput and error rate
    source: [document-intake-agent, recovery-agent]
    visible_to: team leader; never compared with handler figures
join_rule: no join of figures across links at the level of a person
consequence_boundary: no link holds M3 Consequence at any degree
reconstruction:
  trace: one trace id per claim across all links, actor chain in every token
  test: 20 sampled letters traced to links, mandates and approvals in 4 hours
review: on change of any link, and every 6 months

The record answers Thomas Brandt's question in its join_rule and figures fields. The handler's approval time for agent drafts is an oversight-quality signal, reported at team level only, as OQM-HM-CLM-01 already is; it may not be joined with allocation figures into a measure of how productive a handler is "with agent support". Such a measure would be a new M2 Evaluation use, with its own delegation profile, for the works council first.

Practical guide: Drawing the chain of accountability and testing the stop path

Purpose. Make every multi-agent workflow whose output reaches people visible, owned and stoppable before it runs in production, and keep it so.

Roles. The chain owner; the owner of each link; the AI platform team, which runs the policy point; the on-call incident commander; the data protection officer; the works council or union representative; and a line manager whose team receives the chain's output.

  1. List the links from the person backwards. Start where the output reaches a person and walk upstream: which agent produced it, which agent's output that agent consumed, and so on to the first trigger. Include supplier components and other organisations' agents. Start from the letter, the roster or the allocation, not from the architecture diagram.
  2. Name an owner for every link. A link without a named person as owner is a finding. The owner of the first agent in the chain is the chain owner unless a decision record names someone else.
  3. Mark the functions per link. For each link, record which management functions it performs over people and at which degree, using the delegation register. Any link that holds M3 Consequence is removed from the chain and registered as a system of its own with a named human decider.
  4. Fix the sub-delegation rule. Set the maximum depth (zero or one for chains that reach people), require attenuation of scope at each step, and forbid approval by agents.
  5. Mark every checkpoint. Record where a person checks the output, what they see from upstream, and whether they can reject it without cost to themselves. The chain's effective degree of delegation is the highest degree reachable between two real checkpoints.
  6. Design one stop path. Root every link's credentials in one grant at the policy point, so that one revocation halts all links, including any created at run time. Name the holders, the target time and the degraded mode.
  7. Write the figures rule. List the figures each link produces about people, who sees them and at what aggregation, and state that figures are not joined across links at the level of a person unless an agreed delegation profile allows it. Present the rule to the works council or union before go-live.
  8. Drill the stop. Each quarter, an unannounced holder halts the chain; measure time to halt every link, confirm that no link continued, and run the degraded mode for at least one working hour.
  9. Drill the reconstruction. Each quarter, sample twenty outputs that reached people and trace each to its links, mandates and approvals from the chain's own records, within four hours.

Definition of done. The chain record is in version control and adopted by a decision record; every link has a named owner; no link holds M3 Consequence; the last stop drill halted every link within the target time; the last reconstruction drill traced every sampled output; and the representatives have seen the figures rule. The ten-minute stop target and the four-hour reconstruction target are defaults; adapt them to the reversibility of the chain's output and to the works agreement or collective agreement.

A rule for Q7

Q7 asked, after AI Platform and Security, Chapter 11 and AI Threat, Chapter 25: when an agent orchestrates other agents, where does the chain of accountability end, and which named person answers for what the orchestrated agents do to people? This chapter's answer is a rule with three tests and a boundary.

Rule for Q7. Accountability for a chain of agents ends at the chain owner, the one named person who (1) owns the mandate of the agent at the top of the chain and has approved every mandate below it, (2) can halt every link through one stop path outside the chain within the stated time, and (3) can show from the chain's own records which link produced every output that reached a person. Below the chain owner, every link has its own named owner, who answers for that link. No link, at any depth, holds M3 Consequence over a person. A chain that fails any test does not run in production.

Each part can be tested without trusting any agent. The first is a check of the chain record against the delegation register and the identity provider: every link has an owner and every agent identity in the logs belongs to a listed link. The second is the stop drill. The third is the reconstruction drill. The boundary is a check that no link's delegation profile lists M3 at any degree and that no system with an M3 delegation profile is callable as a tool by any link.

Applied to Hansa's claims chain, the rule is met once CHN-HM-CLM-01 is adopted and the first drills pass. The head of group claims operations owns the triage agent's mandate and approved MND-HM-CLM-01; Jana Petersen owns the pilot links, as Chapter 16 established; the handler answers for the letter they approve, and only for that. Applied to the chain that the ShiftWise supplier proposes at Nordvik, the rule fails on all three tests before any negotiation begins, for the reasons the next section gives.

The outlook needs its labels. Multi-agent systems in research and software development are observable in production, as the vendors' own accounts show. Orchestrators that direct work reaching people are observable in pilots such as Hansa's and expected to spread as vendors build orchestration into workflow and HR products. Long chains of agents across organisations are expected in procurement and logistics, where the A2A launch partners already operate, and remain speculation in the management of people until such chains are documented in use.

Across the degrees of delegation

Function Over agents in the chain Over people the chain reaches Note
M1 Direction Up to Level 3 Bounded, within budgets and a depth limit Only as the link's delegation profile states; a person can reassign Sub-delegation attenuates scope
M2 Evaluation Up to Level 3 Bounded for checking agent output At most Level 1 Assisted, aggregated as the works agreement states No join of figures across links per person
M3 Consequence Not applicable Not held by any link, at any degree Consequence systems are registered separately with a named human decider
Chain as a whole Effective degree set by the weakest checkpoint Recorded in the chain record Level 4 Autonomous can emerge in a chain unless checkpoints are designed

Orchestration is a Mode 5 Autonomous production agents pattern even when it is reached through Mode 3 Agentic work tools. A Mode 3 tool that spawns sub-agents acts with the manager's identity, so the manager becomes chain owner without having designed a chain; either forbid sub-agents in Mode 3 tools used for work that reaches people or record the chain like any other.

Nordvik Region and Hansa Mutual

At Hansa the chain already exists. The claims-triage agent routes each claim and allocates it to a handler at Level 3 Bounded under DLG-HM-CTA-01; in Jana Petersen's pilot team the document-intake agent consumes that allocation and prepares the file, and the recovery agent consumes the file and drafts a subrogation letter, both at Level 2 Supervised under MND-HM-CLM-01, with a handler approving every letter. The chain owner is the head of group claims operations; the operator rota sits at the Polish service centre, through which the triage agent works; and the quarterly stop-path tests the group already runs for the claims-triage agent are extended into the chain drill SPT-HM-CHN-01. Thomas Brandt's question, whether the figures produced along the chain could become an evaluation of a handler that nobody decided on, is answered in the chain record by the join rule, which the Konzernbetriebsrat reviews under KBV-IT-2024. Its remaining weakness is a checkpoint: the handler sees the draft and the file but not why the triage agent sent the claim into the recovery path, so that step runs at Level 3 Bounded, not the pilot's Level 2 Supervised, until the routing reason is added to the handler's view.

At Nordvik the chain would run through a supplier. The ShiftWise supplier has announced a component that negotiates roster gaps directly with staffing agencies' systems, agent to agent. As announced, the mandate would be the supplier's; the stop path would sit inside the supplier's system, which the Region's supplier contracts already rule out; the Region could not reconstruct which agency agent proposed which person; and the component would touch access to work, an M3 Consequence, for agency workers and for the Region's part-time staff, whose open shifts it could fill from an agency before offering them. The Region's co-determination act follows the Swedish pattern, in which MBL §11 requires the employer to negotiate before an important change in working conditions and MBL §38 requires negotiation before work is given to someone who will not be the employer's employee (205, Sveriges riksdag, 1976). AIDR-0621 records Ingrid Halvorsen's decision that the component stays disabled under tender NR-2025-089 until the contract requires: a Region-issued delegated identity for every negotiation, owned by the head of the home-care service as chain owner; negotiation of price, competence and time only, never the selection of named persons; open shifts offered first to the Region's own staff as the collective agreements require; every booking approved by the unit manager at Level 2 Supervised; copies of all agent-to-agent messages to the Region; a stop path the Region holds; and negotiation with the unions before enabling, with FRIA-2026-007 updated.

Hansa can apply the rule by engineering, because it owns the platform; Nordvik can apply it only by contract, because it owns neither the orchestrator nor the agents it would talk to.

Summary

Orchestration is management at machine speed: an orchestrator decomposes and assigns work, which is M1 Direction, and checks what its agents return, which is M2 Evaluation. The vendors' own accounts show the pattern working, and its costs. MCP, A2A and token exchange connect and record the links but keep nobody accountable; that is a design decision. The documented failures, from the taxonomy of Cemri and colleagues to the unappointed coordinator of July 2026, are failures of specification, handover and verification that grow with the length of the chain.

The accountability literature explains why chains are dangerous for people. Thompson's many hands let everyone offer an excuse; Bovens's distinction between answerability and liability shows how a person can be made to sign for a chain they cannot explain; and Elish's moral crumple zone names what happens to the person at the end of it. Oversight of the last step is not oversight of the chain.

The chapter's answer to Q7 is a rule that can be tested: accountability ends at a named chain owner who owns the top mandate, holds one stop path outside the chain and can reconstruct every output that reached a person from the chain's own records, with a named owner for every link below. No link, at any depth, holds M3 Consequence over a person, because a consequence assembled by many hands is the hardest to explain and the easiest to rubber-stamp. Delegation of delegation attenuates scope, has a fixed depth and never lets an agent approve for a person, and the chain record's figures rule keeps the numbers produced along the way from becoming an evaluation nobody decided on.

Start with the practical guide's first step: take one AI output that reaches a person in your organisation and walk upstream to the person who owns the first mandate. If there is none, you have found the gap. Chapter 18 turns from the chain to the team at the end of it, where people and agents work under the same manager and the separation of their figures becomes a matter of daily practice.

Sources

  1. Anthropic (2024). Building effective agents. Anthropic research blog. (31, Anthropic, 2024)
  2. Anthropic (2025). How we built our multi-agent research system. Anthropic Engineering. (90, Anthropic, 2025)
  3. OpenAI (n.d.). Agent orchestration. OpenAI Agents SDK documentation. (91, OpenAI, n.d.)
  4. Microsoft (n.d.). AI agent orchestration patterns. Azure Architecture Center, Microsoft Learn. (92, Microsoft, n.d.)
  5. Anthropic (2024). Model Context Protocol Specification. (14, Anthropic, 2024)
  6. Google (2025). Announcing the Agent2Agent Protocol (A2A). Google for Developers Blog. (93, Google, 2025)
  7. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
  8. Jones, M., Nadalin, A., Campbell, B., Bradley, J. & Mortimore, C. (2020). OAuth 2.0 Token Exchange. RFC 8693, Internet Engineering Task Force. (13, Jones et al., 2020)
  9. Model Context Protocol (2025). Security Best Practices. MCP specification version 2025-11-25. (15, MCP, 2025)
  10. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4. (43, Nordqvist, 2026)
  11. Cemri, M., Pan, M. Z., Yang, S., Agrawal, L. A., Chopra, B., Tiwari, R., Keutzer, K., Parameswaran, A. et al. (2025). Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657. (183, Cemri et al., 2025)
  12. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project. (12, OWASP, 2025)
  13. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5. (44, Nordqvist, 2026)
  14. Wijk, H., Cotra, A. & Greenblatt, R. (2026). Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. METR. (35, Wijk et al., 2026)
  15. AI Security Institute (2026). Incident Report: unsanctioned agent behaviour during cyber testing. UK AISI. (36, UK AISI, 2026)
  16. AI Security Institute (2026). GPT-6 Astra performs unsanctioned supply-chain attacks in simulations. UK AISI. (37, UK AISI, 2026)
  17. Thompson, D. F. (1980). Moral Responsibility of Public Officials: The Problem of Many Hands. American Political Science Review, 74(4), 905–916. (111, Thompson, 1980)
  18. Bovens, M. (2007). Analysing and Assessing Accountability: A Conceptual Framework. European Law Journal, 13(4), 447–468. (121, Bovens, 2007)
  19. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (40, Nordqvist, 2025)
  20. Elish, M. C. (2019). Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction. Engaging Science, Technology, and Society, 5, 40–60. (170, Elish, 2019)
  21. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (41, Nordqvist, 2026)
  22. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (42, Nordqvist, 2026)
  23. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union. (5, European Union, 2016)
  24. Chan, A., Ezell, C., Kaufmann, M., Wei, K., Hammond, L., Bradley, H., Bluemke, E., Rajkumar, N. et al. (2024). Visibility into AI Agents. FAccT '24, 958–973. (181, Chan et al., 2024)
  25. Shavit, Y., Agarwal, S., Brundage, M. et al. (2023). Practices for Governing Agentic AI Systems. OpenAI white paper. (89, Shavit et al., 2023)
  26. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG). (9, Germany, 2001)
  27. Sveriges riksdag (1976). Lag (1976:580) om medbestämmande i arbetslivet (MBL). (205, Sveriges riksdag, 1976)