AI · Architecture · Organization — Part 2 of 3

The Director and the Conductor

Every serious piece of AI infrastructure shipping in 2026 is solving the data plane — faster, cheaper ways to move tokens, tasks, and context between models. Almost nobody is building the layer above it: who decides what happens, under what authority, and what's supposed to come next. That layer needs a name, and it isn't the same job as the one already getting all the attention.

ONE DIRECTOR. MULTIPLE CONDUCTORS. EACH CONDUCTOR, ITS OWN SCORE. DIRECTOR priority · policy · trust CONDUCTOR fabric dashboard CONDUCTOR Gladys (coding) CONDUCTOR personal platform Claude worker Codex worker A CONDUCTOR KNOWS ITS OWN ORCHESTRA. THE DIRECTOR KNOWS WHICH ORCHESTRA MATTERS RIGHT NOW.

A conductor and a director are not the same job, and the industry currently building AI agent infrastructure has been talking about only one of them.

A conductor governs one score. They know every instrument in their orchestra, keep it in time with itself, and are personally accountable if that one performance falls apart. A director doesn't stand on the podium. They decide which productions are running at all, which one gets the budget and attention this week, what standing rules apply across every production in the building, and — if anyone asks — where things actually stand across the whole slate, not just the one currently in rehearsal. A film director doesn't conduct the score personally. There's a composer and a conductor for that. The director set the vision that score is serving, sequenced it against everything else the studio has in motion, and answers for the whole picture even though someone else was on the podium for any single scene.

That distinction — not a synonym, a different layer — is the piece missing from how the industry talks about AI orchestration. Everyone building agent infrastructure right now is building conductors, faster and cheaper ones, and calling the result solved. Almost nobody is building the layer above it.

Everyone Is Building the Data Plane

Borrow the distinction networking has used for thirty years: the data plane moves things — packets, tokens, tasks, context — as fast and cheaply as possible. The control plane decides what should move, under what authority, and what happens next. In networking, nobody confuses a switch's forwarding table with the routing protocol that decided what belongs in it. In AI orchestration, right now, almost everyone is.

Model routers are data plane — an entire product category built to move a request to the cheapest model that can handle it. AGENTS.md is data plane — a repo-scoped instruction file, not a cross-project authority. MCP and A2A are data plane — protocols for a capability to reach a tool or another agent, not for deciding whether it should. Every one of these solves a real problem. None of them answers a control-plane question: which of my projects matters most this week, what's my standing policy on trust and spend, and where does everything actually stand right now, across all of it — not just inside the one conversation currently open.

Everyone is optimizing the data plane. Almost nobody has a control plane.

That's not a rhetorical flourish — it shows up as a specific, repeated pattern across every hard problem in this space. Security research keeps finding that delegation chains move tasks correctly but can't answer who authorized the delegation itself — the data plane worked, the control plane wasn't asked. Model routing is a mature, crowded category optimizing dollars per token for metered API traffic, and has nothing to say about the far more common individual case of "I already pay for this subscription — route inside what I'm already covered for, and tell me when something's free." Nobody's shipping that, because it's a control-plane decision — policy and preference — not a data-plane one. And the term "harness" itself keeps being used to describe both the execution loop moving tokens and the thing that's supposed to govern it, which is exactly the confusion that happens when a field hasn't separated the two layers yet.

The Test That Actually Distinguishes Them

A system with one conductor and no director just has an orchestra. That's fine — most projects only need one. The moment a second conductor exists — a second project, a second bounded system, running its own workers toward its own objective — and something has to know both of them well enough to say which one matters more this week, that's not a bigger conductor. It's a different layer, answering a different question.

// The test

Can this thing govern multiple conductors at once, without personally running any of their orchestras? If yes, it's a Director. If it has to be inside the work to function, it's a Conductor — however good it is at its job.

A Conductor is deep and narrow: it knows this project's workers, this project's state, this project's score, in detail. A Director is broad and shallow by design: it doesn't need to know how a specific worker was invoked, only whether that conductor's project should be running right now, under what policy, and what it's blocked on. Collapse the two into one layer and you get exactly what Part 1 described — a human quietly becoming the integration layer, except now it's happening one level up, across projects instead of within one.

What This Actually Looks Like Running

This isn't a proposal. Parts of it have been running for months, before either layer had a name.

S8 → S25
Fabric Intelligence Dashboard
A network fabric conductor for ~120–130 multi-vendor devices, governed by a written RULES.md and a session handoff convention — SESSION-START-SXX.md / BACKLOG-SXX.md — carrying state across 17+ sessions. The shared-state principle from Part 1, running before Part 1 was written.
2026
Personal Intelligence Platform
A typed control-plane vocabulary — ACTION, INSIGHT, ROUTE, SUPPRESS, PATCH — against a patchable multi-model registry. An early, working Director vocabulary, built before this piece had a name for it.
Now
Gladys
A real Conductor: invokes Claude Code and Codex as actual child processes, enforces bounded work packets, and keeps inherited context strictly separate from independent, cold-context review — the exact boundary this series keeps insisting is real, not aspirational.

None of these three were built to prove a thesis. They were built to get work done, on deadline, across three different problem domains — networking, personal knowledge work, and software delivery. The Director/Conductor split is what's left when you notice the same shape holding up all three.

Revisiting the Architecture

Part 1's durable-architecture figure had a layer called "Orchestration + Trust" doing two jobs at once without saying so. Split honestly, it reads like this:

Layer 01
Director
Cross-Domain Authority
Priority across every conductor running, standing policy on trust and spend, and the answer to "what's happening, what's next" — for the whole portfolio, not one project.
Layer 02
Conductor
Per-Domain Orchestration
Who does what inside this project, in what order, with what context — deep expertise in one score, accountable for one performance.
Layer 03
Signaling
Communication / Signaling
How capabilities declare what they can do and negotiate a handoff — the data-plane layer MCP and A2A are formalizing industry-wide.
Layer 04
Substrate
Models | Harnesses | Tools | Services
Replaceable by design, at both the Director and Conductor level.

The Signaling and Substrate layers are exactly where the industry's current attention is concentrated, and where it's genuinely making progress — MCP and A2A are real, useful, and worth using. The gap is entirely above them. Nothing in wide circulation governs the Director layer, because almost nobody building agent infrastructure right now has more than one conductor's worth of a problem to solve. That won't stay true for long.

Why This Compounds Instead of Staying Simple

One conductor is manageable by hand — that's the whole premise of Part 1. Two conductors is where the Director question becomes unavoidable, and it doesn't arrive gently. It shows up as things this series has already named as real research problems: cognitive divergence between how much a model can hold and how much a person can track across parallel threads; the delegation-authorization gap security researchers keep finding at every handoff; the absence of anything that routes against a subscription instead of a metered bill; a term — harness — that even the people building these systems can't agree on the meaning of. None of these are separate problems. They're what happens, predictably, once there's more than one conductor and nothing governing between them.

A director doesn't need to be a better conductor. A director needs to know which productions are running, which one matters most right now, and what the standing rules are — and needs that to hold true whether there's one conductor in the building or ten.

// Continuing this series
// What's Actually Documented
The control-plane gap, in the industry's own words
Four independent sources, four different angles — security, cognitive science, and terminology itself — converging on the same missing layer.
// Continue the conversation

How many conductors do you already have?

If the honest answer is more than one — and for most people doing real work with AI, it already is — the Director layer isn't optional infrastructure. It's the thing standing between you and becoming the integration layer yourself. This is the architecture Synthlogik builds.

Start a Conversation Read More Articles