Why would an orchestrator be forbidden from reading a sub-team's internal files?

So a team can be replaced, upgraded, or added without ever touching the orchestrator's own logic. The only thing that has to stay stable is the contract; the internals are free to change.

The Conductor Pattern: How a Real Multi-Agent System Actually Coordinates

Q: How does a multi-agent pipeline know when to stop retrying and escalate to a human?

By tracking whether the same category of finding keeps recurring across review rounds instead of resolving. Past a point, the system stops trusting its own retry loop and escalates to a human instead, since a failure that persists that long usually means the underlying instructions are wrong, not the implementation.

The conductor never reads anyone's sheet music.

This isn't a hypothetical pattern. It's the architecture behind a real production system, a Claude Code plugin that sequences a growing roster of independent agent teams through one conductor that knows almost nothing about how any of them actually work. That's not a limitation someone hasn't gotten around to fixing. It's the one rule everything else depends on, and it took real mistakes in production to earn.

You trust a team completely by never reading its internals.

The outer layer

Sequencing, not supervising

The conductor's entire sense of what to run next comes down to one fact per team: roughly what it needs before it can start, and roughly what it leaves behind when it's done. Nothing about the running order is memorized or hardcoded; it falls out of those two facts alone. A team with nothing to wait on can always start cold, and a team waiting on something simply waits.

Not every relationship in the roster is a sequence, either. Some teams do the identical job for different underlying technology, and picking between them is a decision the system has to make deliberately, on purpose, every time, never a default it falls into because one option happened to run last time.

Every arrow in the chain is a human decision, not a conductor decision.

The discipline

Even when a team's output could obviously feed the next one directly, the system stops and asks anyway. It never auto-chains, not even once. Every transition is a decision point, not a default that fires because the pieces happen to line up. That's a deliberate constraint the whole design depends on, not an oversight waiting to be optimized away.

The trust boundary

Knowing a team by two things, and two things only

The conductor knows a team by two things, and two things only: a short description of what it does, written once by someone who actually read that team's real internals carefully, and one stable public entry point, the same one a person would use to run it directly. It does not open that team's own working files to understand how the work actually happens underneath.

There's one narrow, deliberate exception: at the exact moment it runs a team, the conductor follows that team's public entry point the same way a human would. Doing that is running the team, not investigating it. Going one file further would be.

Why it matters

A team can be rebuilt completely on the inside, new internal approach, new structure, nothing about how it used to work preserved, and the thing that calls it never has to change, because it was never coupled to any of that in the first place. Only the contract has to hold still.

Inside one team

A straight line, until it isn't

Open up any single team on the conductor's roster and the shape changes completely. Early stages run one after another, each reading the one before it and handing off a single artifact. Then the build finishes, and several independent reviewers, each looking at something different, run at the same time rather than one after another.

Their verdicts combine before anything is called finished. If every reviewer is satisfied, the work is done. If even one isn't, the builder runs again with every report in hand, including from the reviewers who had nothing to flag.

The builder needs the full picture, even from the reviewers who said yes.

The circuit breaker

A finding that keeps coming back gets named explicitly rather than silently sent around for another attempt. Past a point, the system stops trusting its own retry loop and brings a human in instead. Repetition past that point is a signal the instructions were wrong, not a signal to try the same fix again.

Underneath every layer

The steady pulse: what the system remembers

Topology answers who talks to whom. A separate, orthogonal layer answers a different question: does the system get smarter than it was yesterday? Every agent, in every team, writes to one shared record, not a debug trace, but a structured account of what it decided, what it assumed, and eventually, whether that assumption held up.

That last part is the piece most systems skip. Agents don't just log what they did; later, they come back and check their own predictions against what actually happened, closing the loop between a guess and its outcome. A separate process mines the accumulated record for patterns no single run would ever reveal, then turns a confirmed pattern into something the next run of that same team actually benefits from.

What it remembers

Not "what happened in this one run," but which upstream step keeps quietly failing to give a later step what it needed, a pattern invisible from inside any single run, visible only once enough of them accumulate in one place.

Name the shape all you want. The part that actually holds is what you refuse to look at.

Hub-spoke, mesh, hierarchy: the taxonomy explains what a diagram of arrows can show you. This system runs two shapes at once, nested: an outer sequencer that deliberately knows almost nothing, and an inner hierarchy-with-fan-out that knows everything about its own one job. Neither shape is the load-bearing decision. The load-bearing decision is the boundary between them, written down as a rule an agent actually follows, not a suggestion in a README nobody enforces.

None of this was designed once and left alone. The clearest proof: when it came time to verify a second, very different kind of application built by this same system, one already-working review process turned out not to actually cover it, confirmed by checking directly, not assumed. The fix wasn't to stretch what already existed to cover both cases. It was to build a second, purpose-made process for the case that genuinely needed different tools, and, just as deliberately, to not build a third anywhere the underlying job didn't call for one. Recognizing when a solution silently stops generalizing, and being willing to build two things instead of pretending one covers both, is a harder discipline than picking a topology ever is.

Before you let one agent read another team's internals "just this once" to save a step, ask what you're actually trading away: the freedom to change that team's insides without ever touching the thing that calls it.

Questions worth answering directly

What does a meta-orchestrator do in a multi-agent system?

It sequences independent teams based on what each one needs before it can start and what it leaves behind when it's done, never their internal logic, and asks the user before every handoff instead of auto-chaining teams together.

Why forbid an orchestrator from reading a sub-team's internal files?

So a team can be replaced, upgraded, or added without ever touching the orchestrator's own logic. Only the contract has to stay stable; the internals are free to change completely.

How does a pipeline know when to stop retrying and escalate?

By watching whether the same category of finding keeps recurring instead of resolving. Past a point, the system stops trusting its own retry loop and escalates to a human instead; that kind of persistence usually means the underlying instructions are wrong, not the implementation.

What does activity logging add beyond orchestration?

A shared record of every decision, assumption, and outcome across every agent, so later analysis can find which upstream document keeps failing to answer a question, not just what happened in one run.