Orchestrator and Subagent Responsibility Boundaries

Multi-agent systems don't fail because the models are weak or the prompts are sloppy. They fail because nobody drew a hard line around where one agent's job ends and another's begins, and what happens when that line gets crossed. The industry's default move is to add more specialized agents and assume the system gets smarter by division of labor. That assumption is backwards. Production tells a different story: capability was never the bottleneck. Control flow, accountability, and who owns a failure, that's where things actually break, and no amount of prompt tuning fixes it.

Responsibility at these boundaries has to be built into the architecture. A system prompt that politely asks a subagent to behave is not a control mechanism, it's a hope.

What orchestrators and subagents actually are, and how the boundary between them is defined

An orchestrator takes a high-level goal, breaks it into pieces, hands each piece to the right agent, and stitches the results back into one answer. Simple enough on paper.

Subagents are a different animal than the name suggests. Call one a "sub-task executor" and you'll misunderstand it immediately. A subagent is a first-class agent in its own right, with its own persona, its own system prompt, its own tools, and its own workflow logic running underneath. The orchestrator doesn't need to know how a subagent does its job internally. It only needs to know who the subagent is and what domain it owns.

That's the whole appeal of the pattern, and also its biggest risk. A subagent should hand back only the essential result, not a transcript of every intermediate step or a dump of raw retrieved content. Anything more and the orchestrator drowns in noise it never asked for.

The other design primitive is least-privilege tool assignment, and it's non-negotiable. A code reviewer subagent gets only the tools its review task requires, not write access. A documentation writer gets tools scoped to documentation work, not broader execution capabilities. Least privilege gets enforced per agent, not as a system-wide policy statement someone writes once and forgets. Each agent's blast radius gets bounded at configuration time, agent by agent, before anything ever runs.

The control-return problem: what breaks first when delegation is not architecturally enforced

Here's the failure pattern, stripped to its mechanics. An orchestrator delegates a task to a subagent. The subagent starts talking directly to the user. Every message after that gets handled by the subagent. The orchestrator has effectively been cut out of its own conversation.

The consequences stack up fast. The orchestrator can no longer govern the flow of the interaction, so reasoning across agents becomes impossible. The user experience turns inconsistent, since each subagent carries its own persona and its own quirks. Auditability collapses entirely, because there's no single point tracking what got decided and why.

Prompt engineering does not fix this. From the runtime's point of view, a subagent is still an agent with full conversational authority, and telling it "don't talk to the user" or "return control to the orchestrator" is a request, not an enforcement mechanism. As Pradeep Jain put it in a February 2026 piece, instructions like these can only ask for behavior, they cannot compel it.

This is an architecture problem wearing a prompt-engineering costume. The design itself has to prevent subagents from ever acquiring conversational authority in the first place. Once they have it, no instruction is walking it back.

The SemaClaw paper (arXiv, April 2026) has a name for the degenerate case: pseudo-orchestration. A nominal orchestrator sits at the top of the system, but it does most of its reasoning internally instead of producing a decomposition that's actually verifiable and executable. The orchestrator exists in name only, a title without a job.

Agent-as-Tool: the architectural pattern that enforces the boundary structurally

The fix is almost embarrassingly simple to state: the orchestrator is the only agent allowed to speak to the user. Subagents get invoked as tools. They return structured results. Control comes back to the orchestrator automatically, every time, no exceptions.

Why does this work, mechanically? Tools don't have conversational memory or conversational intent. A tool executes when it's called and it terminates when it's done, full stop. Control returns to the orchestrator not because a prompt told it to, but because the runtime never granted the tool any conversational authority to begin with. There's nothing to take back because it was never given in the first place.

This wipes out the whole class of control-return failures described above, not by phrasing the subagent's instructions more carefully, but by changing what kind of entity the subagent is at the runtime level.

There's a real tradeoff worth naming honestly. Agent-as-Tool subagents are reactive. They cannot initiate. If a workflow needs a subagent to escalate a problem, ask a clarifying question, or flag intermediate uncertainty, the orchestrator has to be explicitly designed to catch and handle those signals. That responsibility doesn't disappear, it just moves up a level.

Once subagents are tools, routing gets more explicit as a bonus. Simple subtasks route to cheaper, faster models. Complex analysis goes to higher-capability models. The orchestrator controls this at dispatch time, and each subagent's configuration just declares which model it prefers.

Decomposition quality as a single point of failure the orchestrator owns entirely

If the orchestrator's initial breakdown of the task is wrong, everything downstream runs in the wrong direction. No amount of subagent brilliance rescues a system built on a bad decomposition. This failure belongs to the orchestrator alone, and it can't be delegated away.

Decomposition goes wrong in three recognizable ways. Subtask boundaries don't line up with subagent domains, so a subagent gets handed work that spills into someone else's specialty. Dependencies go missing, so the orchestrator fires off tasks in the wrong order and a subagent ends up working with a result that isn't ready yet. Task descriptions turn ambiguous, so the prompt handed to the subagent is underspecified and the subagent fills the gaps with assumptions the orchestrator never sanctioned.

SemaClaw's answer to this is a DAG-based, two-phase hybrid orchestration approach. The idea is to represent subtask dependencies explicitly, as structure, rather than trusting the model's reasoning to infer partial ordering on the fly. If dependency management lives in the graph instead of in the model's head, it's auditable, and it's testable.

Self-correcting orchestrators, the kind that check intermediate subagent outputs and dispatch follow-up tasks when something looks off, are harder to build. They're also dramatically more robust, and that's the real answer to decomposition risk, not better prompting.

Anthropic's own guidance on building effective agents lists orchestrator-workers as one of five core workflow patterns, with a caveat worth repeating: it fits best when subtasks can't be predicted in advance, and teams should find the simplest solution that actually works before reaching for it.

None of this is new territory. The hard parts here, boundaries, invariants, failure handling, are the exact problems domain-driven design has spent years working out in conventional software. The discipline transfers pretty directly.

What accountability means at agent boundaries, and why it cannot be left implicit

Most thinking about agent boundaries skips a question that matters more than almost anything else: who is responsible for a subagent's output? Who can be asked to explain it? Who signs off on it before it goes anywhere consequential?

A 2026 paper by Hydari and Muzaffar draws a sharp distinction here. Some tasks can safely route through an agent interface because correctness is cheap to verify and responsibility transfers cleanly. Others can't, because defensibility, reviewability, signoff, and responsibility are wrapped up in what the paper calls accountability assets, and those assets can't just get recreated at the interface on demand.

Accountability assets are the complementary structures that make an AI-supported output legitimate, auditable, reviewable, and assignable to someone. When these assets cannot be straightforwardly recreated at a given boundary, that boundary cannot simply be made modular, no matter how clean the technical interface looks on a diagram.

There's a companion idea worth sitting with: rule debt. When an organization's decision rules end up baked into a subagent's system prompt rather than formal systems, they become difficult to track, version, and audit. The Hydari and Muzaffar paper identifies this as a form of accumulating governance debt that eventually has to be reconciled against what the business actually intends.

The practical takeaway: a subagent that sends a communication, modifies a record, or triggers a financial action needs a documented, traceable line back to a human-sanctioned authorization. Not just a tool permission flipped to "on." A rationale for who authorized that capability, and under what conditions.

Most identity and access management systems still treat agents the way they'd treat an anonymous script or a service account, and that's a mismatch. Agents interpret instructions, chain decisions together, and often operate across organizational boundaries. Without real identity governance around them, these actors are effectively invisible in the audit trail, right up until something goes wrong and someone goes looking.

The three properties that make an agentic system governable, and where excessive agency enters

The Cloud Security Alliance frames a governed agentic system around three properties. The agent acts on behalf of a principal, which creates a delegation relationship carrying accountability implications. It maintains state, which brings persistence and memory security requirements along with it. And it takes consequential actions, which opens a risk surface that goes well beyond simple information exposure. That third property is also what makes the agent useful in the first place: tool access, or actuation, is what lets it read a database, write a record, run a script, send a message.

OWASP's framework names a specific vulnerability tied directly to this: Excessive Agency. It traces to three root causes: excessive functionality, excessive permissions, and excessive autonomy.

Put operationally, excessive agency is an agent that can act beyond what it was actually authorized to do, either because its tool permissions were broader than the task required, or because no runtime check ever verified that the action lined up with the goal.

Least privilege comes back into the frame here. Giving subagents only the tools their specific task needs isn't tidy architecture for its own sake, it's the primary technical defense against excessive agency at the boundary. Tool-use safety follows the same logic as an evaluation dimension: does the agent respect its permission boundaries, does it check tool outputs before acting on them, does it stay inside its authorized scope. That matters most for tool-augmented, MCP-enabled, and autonomous agents, precisely because those are the systems with the biggest blast radius when something slips.

Five dimensions of boundary governance that production multi-agent systems must address

The Cloud Security Alliance has laid out security dimensions specifically for multi-agent systems.

• Runtime behavioral governance: catching drift and goal misalignment as they happen, not just checking for them at design time.
• Inter-agent communication security: message integrity, replay prevention, and trust established between agents, since the orchestrator-to-subagent message is itself an attack surface, not a harmless internal detail.
• Tool and capability governance: who approved each tool, under what conditions, and whether that approval can be audited later.
• Orchestration layer security: stopping a single subagent failure from propagating silently through the orchestrator into every downstream subagent.
• Human-agent interaction controls: escalation triggers, override mechanisms, and informed consent, governing when a decision gets surfaced to a person instead of proceeding on autopilot.

Escalation triggers deserve their own callout. The orchestrator needs to recognize when a subagent's output has drifted outside the sanctioned decision space, and it needs a defined path to hand that off to a human reviewer rather than plowing ahead on its own.

Gartner named Agent Management Platform (AMP) a distinct governance category in late 2025, projecting it will grow into a multibillion-dollar market by 2029. Their framing is direct: deploying AI agents without an AMP leaves organizations without adequate operational controls. By 2027, Gartner projects most enterprises will name agent monitoring as their single most important AI operational tool. Governance isn't a compliance checkbox tacked onto the end of a project anymore. It's becoming the primary operational concern, full stop.

How protocol standards (MCP and A2A) shift where boundaries can be enforced

Before shared protocols existed, every agent-to-tool and agent-to-agent connection was its own bespoke engineering project: custom wrappers, one-off message translations, no shared surface for anyone to audit later.

A2A (agent-to-agent) governs communication between agents. Keeping this layer distinct from tool-access governance matters more than it might seem. A system that blurs the two can't separately police tool permissions and inter-agent trust, and once that entanglement sets in, enforcement gets murky fast.

Protocol-driven systems are just easier to extend, audit, and evolve than a stack held together with one-off wrappers. The audit surface lives at the protocol layer instead of scattered across a dozen custom integrations nobody fully remembers building.

Spring AI's Task tool, in spring-ai-agent-utils 0.5.0 and later, explicitly supports both Claude's markdown-based subagent format and A2A for orchestrating a mix of heterogeneous agents. That's a good sign the two protocols are meant to complement each other rather than compete for the same job.

None of this solves the harder problem on its own, though. Protocols define the interface. They don't decide who's accountable when a subagent crosses a line, and they don't replace the harness engineering, the decomposition discipline, and the accountability chains this piece has been walking through. That work still belongs to whoever's building the system, and no protocol update is going to hand it off.