Conductor and orchestrator are Addy Osmani’s terms for two contrasting ways of directing AI coding agents, defined in his post The future of agentic coding: conductors to orchestrators (January 2026), which sets out to explore the distinction and define the two roles. In the conductor model, a developer guides one agent in real time, synchronously and sequentially, with that agent’s context window as a hard ceiling — the posture of tools like Claude Code’s CLI or an in-editor agent mode. In the orchestrator model, a developer coordinates an entire ensemble of agents, each with its own context window, working asynchronously while the developer plans work, assigns it, and checks in periodically rather than steering every step.
Usage
That post sets the two modes against each other on five axes: scope of control, from one task to a set of tasks that can be delegated at once; degree of autonomy, from an agent that waits for a prompt at each step to one that plans and executes many steps internally before asking for feedback; synchronous versus asynchronous interaction; the artifacts each leaves behind; and how a developer’s effort is distributed. On the last of these, Osmani’s account is that a conductor is actively engaged for nearly the whole time the agent is working, whereas an orchestrator’s effort is front-loaded into writing a good task description and back-loaded into reviewing and testing the result, with little required in between — which he presents as what lets one person keep more work in flight than single-agent work allows.
The same account ties each mode to what the tooling affords. Conductor-style work is the posture of an in-IDE assistant or a CLI session: the developer triggers each action and reviews the output immediately, and most of the interaction is ephemeral, so context or decisions not captured in code may be lost when the session ends. Orchestrator-style tools instead give agents enough agency to clone a repository, create a branch, edit across files, run tests and refine a solution before presenting anything, and they return the work as a pull request — so the exchange is recorded in version control and is reviewable by the rest of the team, rather than living in a chat window.
That post also extends the orchestrator role past implementation to a pipeline of specialized agents — planning, coding, testing, code review, documentation, and deployment or monitoring — coordinated by one human who approves plans, resolves questions the agents raise, and gives final approval to deploy. It presents this as a direction rather than current practice, pointing to early signs such as enterprise platforms offering building blocks for multi-agent workflows and agents critiquing one another’s pull requests with a human in the loop at the end.
The distinction is presented as a shift in required skill as much as a shift in tooling: Osmani describes the move from conductor to orchestrator as a skills shift before it is a tooling one, linking that characterization back to the post where he set the two roles out. The same two labels are used in a Google whitepaper on how AI is changing the software lifecycle, which he says he co-wrote — so that account shares an author with this one rather than corroborating it independently. Its practical guidance, as he relays it, is the same: conductor for real-time work on code a developer doesn’t yet know well, orchestrator for asynchronous delegation of well-specified work such as migrations or test generation.
Another post by the same author draws the same two modes without naming them conductor and orchestrator: “local, high-touch sessions where you stay human-in-the-loop” for architecture decisions, tricky refactors, product nuance, and ambiguous requirements, versus “cloud or background sessions that run asynchronously” for bounded, well-specified tasks such as straightforward features, migrations with clear patterns, test generation, and documentation updates (Your AI coding agents need a manager).
Another post returns to the conductor image directly to explain why the role is tiring even though a conductor does not play every instrument: holding the whole piece requires whole-system awareness, and that awareness is what does not scale by trying harder (Your parallel Agent limit).
When It Applies
The two modes are presented as coexisting rather than succeeding one another. The same developer may dispatch an asynchronous agent on one task while working conductor-style with another on a tricky algorithm, and the pair is described as two ends of a spectrum with hybrid workflows in between rather than as rigid categories. Experience is offered as a rough guide to where someone starts: junior developers becoming comfortable directing a single agent before taking on several, and more experienced engineers adopting orchestration earlier because they already decompose tasks and evaluate outcomes.
Orchestration is where the difficulties concentrate. The future of agentic coding: conductors to orchestrators names quality control and trust, since no one is eyeballing every change as it is made; coordination and conflict when several agents touch one codebase, addressed today by workspace isolation and one-agent-per-task rather than by agents negotiating with each other; context and state that does not travel across agents, leaving each a silo; output quality that tracks specification quality, which moves the human’s own “coding” up a level into writing specs and acceptance criteria; and debugging an agent that has gone wrong, which may mean dropping back into conductor mode to fix it. Responsibility for license compliance, security vulnerabilities and bias in the resulting code is described as staying with the human orchestrator or their organization throughout.
Related Terms
Agent Teams, Agentic Autonomy Levels, Orchestration Tax, Parallel Agent Limit