Platform Agentic: When Agents Orchestrate Agents — The Compliance Gap Nobody's Talking About
1. Foreword
TLDR. Every compliance framework in this space was designed with a single system in mind. Multi-agent architectures — orchestrators delegating to sub-agents — break every one of those assumptions simultaneously. The risks are specific, the mitigations are concrete, and almost nobody is talking about them yet.
I'm the LangChain ambassador for the Netherlands and the author of Platform Agentic — a book on compliance, governance, and accountability for teams building agentic AI systems.
Most of the compliance conversation around AI agents focuses on a single agent doing a single thing. That's where the regulations are clearest and where the engineering patterns are most established. But production agentic systems in 2025 and 2026 are increasingly multi-agent: an orchestrator that routes tasks to specialized sub-agents, each with its own tools, model, and capability profile.
That architecture introduces compliance problems that single-agent frameworks weren't designed for. This post names them precisely, shows where in the regulatory text the obligations arise, and describes the engineering patterns that address them.
This is the most original material in Platform Agentic — and the most underaddressed in the industry.
2. The Single-System Assumption
Every compliance framework covered in Platform Agentic was designed with one implicit assumption: the system you are evaluating is a single, identifiable unit with a defined capability set, a defined data access profile, and a defined set of actions it can take.
That assumption makes risk classification tractable. A credit scoring model is clearly high-risk. An image captioning tool for a public website is limited risk. You assess the system. You assign a tier. You apply the obligations.
Multi-agent systems break this assumption in three ways.
The system's capabilities are distributed. The orchestrator's capability profile is not just its own tools — it includes the full capability set of every sub-agent it can invoke. An orchestrator that appears read-only can initiate irreversible actions through a sub-agent. Assessing only the orchestrator's direct capabilities misses this.
The system's boundaries are dynamic. An orchestrator can spawn sub-agents, route tasks to different agents based on runtime reasoning, and delegate to agents with different data access profiles than its own. The effective boundary of the system at runtime is determined by the orchestrator's reasoning, not by its static configuration.
The audit trail can fragment. When an orchestrator acts, its log captures what it decided. When a sub-agent acts on that decision, a separate log captures what the sub-agent did. Without explicit correlation, those two records describe different events. The compliance chain only holds if both records are connected.
graph TD
A["Single-system assumption:\nOne agent, one capability set,\none audit trail"]
B["Multi-agent reality:\nOrchestrator + N sub-agents\nDistributed capabilities\nFragmented audit risk"]
A -->|"breaks"| B
3. The Multi-Agent Classification Rule
The most important principle in multi-agent compliance is this: the chain inherits the classification of its highest-risk component.
An orchestrator routing a request to a summarization sub-agent. The sub-agent reads a patient record to generate a clinical note. That single step touches Protected Health Information. It classifies the entire system — orchestrator included — as high-risk under the EU AI Act and HIPAA.
flowchart LR
O[Orchestrator] --> A[Subagent A\nLimited risk]
O --> B[Subagent B\nHigh risk — PHI]
A & B --> C[System classification:\nHigh risk]
The orchestrator does not avoid the classification because it never directly accesses PHI. It can reach a sub-agent that does. That reachability is what matters. The classification applies to the system as a whole — including every sub-agent the orchestrator can invoke.
This has three practical consequences.
Apply the five classification questions to the full reachable graph, not just the orchestrator. The questions — does the system make consequential decisions, affect vulnerable populations, lack meaningful human oversight, process sensitive data, or take irreversible actions — must be answered for the system as a whole. If any reachable sub-agent answers "yes" to a high-risk question, the whole system does.
Document the full reachable graph. A classification document that describes only the orchestrator's direct capabilities is not a compliance artifact. It is a document that will drift out of sync with the system it describes — specifically at the moment a new sub-agent is added.
Re-classify when a new sub-agent is added. Adding a sub-agent that touches PHI, financial records, or biometric data to an existing multi-agent system is a classification event, not a deployment event. The risk tier may change. The obligations that follow may change with it.
If any step in the agent's chain would be high-risk in isolation, classify the whole system as high-risk.
4. The Audit Chain Must Span the Entire Execution
An orchestrator logs its decisions. A sub-agent logs its actions. Without explicit correlation, those are two separate records describing two separate systems. The compliance chain — the single, coherent record of what happened and why — doesn't exist.
Every major framework's audit requirements apply to the system, not to individual components of it. HIPAA's audit controls require mechanisms to record and examine activity in systems containing PHI. "The orchestrator didn't access PHI — only the sub-agent did" is not a valid answer. The orchestrator directed the sub-agent to access it. That direction is part of the record.
SOC 2's processing integrity criterion requires that the full processing chain is traceable. PCI-DSS Requirement 10 requires that agent tool calls in payment environments appear in the same audit infrastructure that covers every other system — not in a separate agent-specific log.
flowchart TD
O["Orchestrator run\nrun_id: root-abc123"]
A["Sub-agent A\nparent: root-abc123"]
B["Sub-agent B\nparent: root-abc123"]
T1["Tool call: fetch_record\nparent: sub-agent-A"]
T2["Tool call: write_summary\nparent: sub-agent-A"]
O --> A
O --> B
A --> T1
A --> T2
The engineering requirement is explicit trace correlation across agent boundaries. Every sub-agent invocation must be a child span of the orchestrator's root trace. Every tool call made by any sub-agent must trace back to the root run ID. That root run ID is the compliance record for the entire execution — one record, one chain of accountability.
In LangSmith, the @traceable decorator achieves this automatically. When a sub-agent is invoked from within a traced orchestrator run, the sub-agent's trace becomes a child span of the orchestrator's trace, correlated under the same root run ID.
from langsmith import traceable
@traceable(name="orchestrator-run")
def orchestrator(task: str) -> str:
return subagent(task)
@traceable(name="subagent-run")
def subagent(task: str) -> str:
return process(task)
Every tool call, LLM call, and retrieval step inside subagent appears as a child span of orchestrator-run. The root trace ID is the compliance record for the entire execution.
An orchestrator that cannot account for everything its sub-agents did has not logged a session. It has logged a gap.
5. Human Approvals Are Non-Transitive
When a human approves an orchestrator action, they approve that specific decision. They do not approve every downstream action the orchestrator subsequently triggers.
This distinction matters for two frameworks that explicitly address it.
GDPR Article 22 gives data subjects the right to obtain human intervention and contest automated decisions that significantly affect them. The right attaches to each consequential decision — not to an approval granted at the orchestrator level that propagates through the chain. A sub-agent deciding which customer records to access is making a decision. If that decision is consequential, it needs its own human review path.
The EU AI Act's human oversight requirements apply to the deployment context as a whole. An orchestrator that has been approved for production does not transfer that approval to sub-agents it spawns at runtime. Each high-risk component in the chain requires its own oversight mechanism.
The practical consequence: cascaded instructions are not approved instructions. An orchestrator telling a sub-agent to take an action is not the same as a human authorizing that action. If the sub-agent's action is consequential, the chain must route through a human approval step before the action is taken — not at the orchestrator level, but at the point of the consequential decision.
flowchart TD
H["Human approves\norchestrator action"]
O["Orchestrator"]
SA["Sub-agent: consequential action"]
H -->|"approves"| O
O -->|"delegates"| SA
SA -->|"needs its own"| HA["Human authorization\n(non-transitive)"]
Delegated authority is not the same as granted authority. Human approvals given to an orchestrator do not cascade to sub-agents — each consequential downstream action requires its own authorization pathway.
6. Permission Scope Must Narrow at Every Handoff
An orchestrator has read access to ten document categories. It delegates a summarization task to a sub-agent. The question is not what the orchestrator can access. It is what the sub-agent needs to do this specific task.
The answer is always: less. Permission scope must narrow or stay equal at every agent handoff. It must never expand.
The data minimization principle — required by GDPR, HIPAA's minimum necessary standard, and PCI-DSS — applies at each agent boundary as much as at the system entry point. A sub-agent receiving the orchestrator's full tool list and data access profile has not had its scope defined. It has inherited a capability set that is almost certainly larger than what its assigned task requires.
Security follows the same logic. An orchestrator that passes its own tool list to a sub-agent unchanged has not scoped the handoff. A prompt injection attack against that sub-agent has access to everything the orchestrator could do. The blast radius is the orchestrator's full capability set, not the sub-agent's assigned task scope.
flowchart LR
O["Orchestrator\n10 tools"] -->|"narrow scope"| A["Subagent A\nread_doc only"]
O -->|"narrow scope"| B["Subagent B\nwrite_summary only"]
In code, this means each sub-agent is constructed with its own explicit, closed tool list — never with the orchestrator's tool list passed wholesale:
summarizer = Agent(
tools=[read_doc_tool], # subset only
system_prompt=(
"Summarize the provided document."
),
)
# Never: tools=orchestrator.tools
An orchestrator that passes its own tool list to a sub-agent unchanged has not scoped the handoff. It has cloned itself.
7. What This Means in Practice
Multi-agent compliance is not a separate discipline from single-agent compliance. It is the same five principles — transparency, data minimization, human oversight, audit trails, accountability — applied to a system with distributed capabilities, dynamic boundaries, and a fragmented default audit trail.
Four specific engineering requirements close the gap.
Declare the full reachable graph at design time. Every sub-agent the orchestrator can invoke must be documented as part of the system's capability profile. Changes to that graph are classification events.
Trace across agent boundaries. Use a framework that creates parent-child spans automatically (LangSmith's @traceable does this). The root run ID is the compliance record for the entire execution.
Narrow permissions at every handoff. Each sub-agent gets its own explicit tool list — a strict subset of what it needs for its assigned task. No inheritance. No defaults.
Route consequential sub-agent actions through their own human approval paths. Don't assume an approval at the orchestrator level covers downstream decisions. Each consequential decision requires its own authorization.
8. Closing
The compliance frameworks were designed for a world where the system you are assessing is a single, bounded thing. Multi-agent systems require applying those frameworks to something that is distributed, dynamic, and potentially fragmented across multiple audit records.
The work is not to wait for the frameworks to catch up. It is to apply existing principles — classification, audit, oversight, minimization, accountability — to the architecture as it actually is.
The orchestrator inherits the classification of the highest-risk thing it can reach. The audit chain must span everything the orchestrator can direct. The approval given to the orchestrator does not authorize the actions of the things it invokes.
These are not new obligations. They are existing obligations applied precisely.
References
