The EU AI Act's Article 14 requires that high-risk AI systems "shall be designed and developed in such a way... that they can be effectively overseen by natural persons during the period in which they are in use." For a single-model classifier producing a categorical output, the architectural implications are reasonably well understood: a human-in-the-loop reviews outputs above a threshold, the system surfaces explanations alongside its decision, and there is a clear handoff to a human owner. For a multi-agent system, the same one-sentence requirement creates a problem with no widely accepted answer.
Multi-agent systems extend an LLM's planning capability with tool-using behavior across multiple specialized agents that interact, share state, and produce composite outcomes through chains of intermediate decisions. The output a regulator reviews is not the prediction of a single model. It is the result of a planning-execution loop that took dozens or hundreds of LLM-driven decisions, any of which could have been the determinative one. Where exactly does effective human oversight attach?
What Article 14 Actually Requires
Article 14(2) defines the objective: oversight measures shall be appropriate to the risks, level of autonomy, and context of use, and must aim at preventing or minimising risks to health, safety, and fundamental rights. Article 14(4) lists what the oversight measures must enable a natural person to do: understand the system's capabilities and limitations; remain aware of the possible tendency to automatically rely on the output; correctly interpret the output; decide not to use the output or otherwise disregard, override, or reverse it; and intervene or interrupt the system through a stop button or equivalent procedure.
For a multi-agent system, the last of these is the architecturally demanding one. The stop button must work. That means in any state the system can reach, including states where multiple agents are mid-execution against external tools, there must be a mechanism that halts the system in a recoverable way. Most multi-agent frameworks shipped to production in 2026 do not have this. The frameworks expose a stop at the orchestrator level that signals to agents to terminate, but agents that have already initiated irreversible tool calls cannot un-take those actions. The stop button stops planning but does not stop the consequences of decisions already executed.
The Multi-Agent Oversight Problem
Consider a typical agentic workflow in regulated finance: a loan adjudication agent receives an application, plans a sequence of investigations (credit check, KYC verification, income verification, AML screening), delegates each to a specialist agent, aggregates results, and produces a recommendation. Each specialist agent itself calls multiple tools. The orchestrator agent is aware of the plan; the specialists are aware of their slice; the human overseer is aware of the recommendation.
An Article 14 inspection asks: how does the human reviewer evaluate this recommendation? Reading the recommendation alone does not satisfy the requirement to understand the system's capabilities and limitations from a single output. Reading the orchestrator's plan does not satisfy the requirement to correctly interpret the output, because the plan is a representation of intent, not of what actually happened. The reviewer must be able to reconstruct what each specialist did, why, what data they accessed, and how their outputs combined into the recommendation.
Pattern 1: Hierarchical Supervisor Oversight
The first architectural pattern is to designate a supervisor agent whose sole role is to observe and constrain the work of application agents. The supervisor does not participate in the work. It evaluates plans before they execute, intercepts tool calls before they cross trust boundaries, and produces the synthesis that the human overseer reads. The supervisor's interface to the human is structured: not a chat log of agent reasoning, but a regulator-style decision packet showing the plan, the policy in force when the plan was made, the tool calls that were approved versus blocked, and the supervisor's intervention log.
This pattern maps cleanly to the requirements for understanding capability and interpreting output. The capability and limitation surface of the system is the supervisor's contract: defined once, versioned, and shown to the overseer. The output the overseer interprets is filtered through the supervisor, which is responsible for surfacing dissent, novelty, and out-of-distribution conditions explicitly.
Pattern 2: Reversibility Tiering
For the stop button to work in multi-agent contexts, the system must distinguish between reversible and irreversible actions. Reversible actions can be executed during planning loops; irreversible actions require human approval before execution. The architectural commitment is that the agent cannot decide which category an action belongs to. That decision is made by the tool registry, version-controlled by the platform team, and changeable only through documented change control.
A loan recommendation written to a draft queue is reversible. The same recommendation transmitted to the customer is irreversible. The architecture must make this distinction enforceable at the tool boundary, not negotiable by the agent. The stop button therefore stops irreversible actions; it does not need to stop the entire planning process. This is a much weaker and much more tractable engineering requirement than halt all in-flight operations atomically.
Pattern 3: Designed Intervention Points
Article 14 does not require continuous human oversight; it requires oversight that is effective. For long workflows, effective oversight is achieved through designed intervention points: specific decision moments where the workflow pauses, presents its state, and requires either an affirmative continuation or a human override. The intervention points are not optional. The planner cannot skip them; the supervisor enforces them.
Choosing intervention points is a domain decision. In a loan workflow, the natural intervention points are after KYC completes (have we identified the right person?), after income verification completes (do the numbers reconcile?), and before transmission to the customer (does the recommendation reflect what we intend to say?). Three intervention points across a workflow that internally takes thousands of LLM-driven decisions. The human overseer's cognitive load is bounded; the system's reasoning surface is not.
Pattern 4: Trace-Replay Tooling
Correctly interpreting the output requires that the overseer can investigate what happened in detail. The architectural response is trace-replay tooling that allows a reviewer, after the fact, to walk through the decisions an agent made, see what the agent saw at each step, and evaluate whether the decisions hold up. The trace must be deterministic-replayable to the extent possible: given the same inputs and the same tool responses, the system would have made the same plan.
This is not show me the chat log. A chat log of agent reasoning is incomplete and often misleading: the model's verbalized chain of thought is not always the actual basis of its decision. The trace must include the actual prompts, tool calls, and intermediate outputs that determined behavior, with cryptographic timestamps that establish the order of operations. Trace-replay tooling is the mechanism through which deciding not to use the output becomes operational; a reviewer who cannot reconstruct how the output was produced cannot reasonably decide to override it.
Pattern 5: Policy-as-Code Versioning
The technical documentation under Article 11 must describe the system's design. For a system that adapts (different prompts, different tools, different agent compositions over time), the documentation must be versioned alongside the system. Policy-as-code makes this tractable: the policy that governs agent behavior is expressed as code, stored in version control, deployed alongside the system, and surfaceable in the trace.
When a reviewer asks what policy was the system operating under when this recommendation was made, the system can answer with the specific commit of the policy code at the moment of the decision. When a regulator audits the system years later, the policy version is recoverable. This is what technical documentation under Article 11 actually means in production: not a static PDF written once, but a versioned codebase that includes the behavior specification.
The Documentation a Regulator Will Ask For
A regulator inspecting a high-risk agentic system under Article 14 will expect a set of documents. The first is the human oversight specification: who oversees, at what intervention points, with what authority, against what acceptance criteria. The second is the tool registry with reversibility classifications. The third is the supervisor contract and the audit packet specification. The fourth is the trace-replay tooling demonstration: select a real workflow run from the past, and walk the inspector through what happened.
Most organisations attempting Article 14 compliance for agentic systems are producing the first document and assuming the others will be produced by their AI vendor. The vendor, in turn, is assuming the customer's compliance team will produce them. The result is a documentation gap that surfaces during the conformity assessment under Article 43. Closing the gap requires accepting that Article 14 oversight is a system architecture decision, not a procedural one.
The Pragmatic Take
Article 14 is not impossible to satisfy for multi-agent systems. It is impossible to satisfy through hope. Organisations deploying agentic AI in high-risk contexts must either accept the architectural commitments above (supervisor pattern, reversibility tiering, intervention points, trace-replay tooling, policy-as-code) or accept that their systems will not pass an honest Article 14 assessment.
The right time to make those commitments is at architecture time. Retrofitting them to a deployed agentic system requires substantially more engineering effort than building them in from the start, and produces a system whose audit trail has a clear before-and-after seam that an auditor will probe. The seam is itself a finding.
EU AI Act: What CTOs Actually Need to Do Before August 2026
The Vendor Rescue Pattern: How to Recover a Failed Implementation in 12 Weeks
The LLM Hallucination Problem in Regulated Environments: What 'Acceptable Error Rate' Actually Means
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.