how to wire an AI orchestrator into a structured development pipeline

The spawning problem

Most orchestrators start the same way: a manager agent picks a task from a backlog, spawns a Claude Code session, and waits for it to finish. This works for one-shot scripts. It breaks for anything that involves real product work.

The problem is not the spawning. Claude Code handles that fine. The problem is what the manager agent is blind to once the session starts.

It does not know whether the implementation agent surfaced scope questions and guessed at the answers. It does not know whether the agent jumped straight to writing code before design was agreed. It does not know what the diff contains before the PR merges. And if the session fails or stalls, it has an exit code and a wall of terminal output - neither of which explains what went wrong or what to do next.

Building a reliable orchestrator on top of plain subprocess control is like automating a production deployment using only the process exit code. The signal is there, but everything meaningful is hidden.

What a manager agent actually needs from a pipeline

Before wiring anything, it helps to be precise about what kind of interface a manager agent needs. There are four distinct requirements, each different in character.

Scope handling

When an implementation agent hits something ambiguous - the acceptance criteria are unclear, two approaches have meaningfully different scope, a dependency is missing - it should surface a question rather than pick arbitrarily. A manager agent needs a way to receive those questions and answer them: apply a rule, escalate to a human, or make the call itself. Without this, the implementation agent either stalls waiting for input that never arrives, or it guesses and compounds the ambiguity downstream.

Gate approval

A structured pipeline has checkpoints where work is reviewed before advancing: design before architecture, architecture before implementation, implementation before merge. These are the moments where mistakes are cheap to fix. A manager agent running a pipeline needs to hold work at each gate, inspect what was produced, and decide whether to approve, request changes, or restart the stage. A manager that cannot hold gates is just a faster version of uncontrolled execution.

State inspection

At each gate, the manager needs access to the actual output: the design spec, the architecture decision, the diff against the base branch. Knowing "stage X completed" is not enough. The manager needs to inspect the content to make a real approval decision, and to feed context into the next stage. Without state inspection, gate approval becomes rubber-stamping.

Stage agent control

Agents get stuck. A stage agent might stall on a dependency, hit a full context window, or interpret a task differently than intended. The manager needs the ability to send additional context into a running session, stop it cleanly, restart it with updated instructions, or promote a blocked task to human review. This is the recovery path that separates a reliable orchestration system from a fragile one.

What a plain runner gives you

The default tools for orchestrating Claude Code sessions are subprocess control: spawn a process, watch stdout, check the exit code. Scripts and meta-agents built on this pattern get process start and stop, raw terminal output, and pass or fail. That is the complete surface area.

None of the four requirements above are on that list. You cannot receive scope questions. You cannot hold a gate. You cannot inspect a diff before merge. You cannot restart a stage agent with new context.

The result is predictable: orchestrators that work on well-scoped, self-contained tasks and fail quietly on anything else. Scope assumptions compound. Review gates disappear. Diffs merge before anyone inspects them. The orchestration layer adds throughput but removes the process discipline that makes throughput trustworthy.

The gated lifecycle pattern exists precisely because of this gap: raw parallelism scales until the coordination problem catches up, and the coordination problem is always about gates, scope, and state.

What the interface needs to look like

The shift is from treating a development pipeline as a process to run to treating it as a service to drive. The interface has to be first-class: structured, addressable operations, not stdout parsing.

Concretely, that means an interface that lets a manager agent push a task into the pipeline, receive scope questions and answer them, get notified when a stage completes and a gate opens, inspect the output at each gate, approve or request changes, and monitor in-progress stage agents. All of this through a protocol the manager agent already speaks, without custom subprocess wiring for each orchestrator.

MCP is the natural fit. A manager agent built on Claude Code already uses MCP for tool calls; exposing a development pipeline as an MCP server means the manager drives the pipeline the same way it calls any other tool. The interface becomes composable rather than custom-wired.

One detail matters here: the manager agent needs the pipeline to use the same logic the human UI uses. If a human can approve a gate and the stage agent picks up and continues, the manager should get identical behavior. A separate API layer that diverges from the UI path creates a split codebase and eventually divergent behavior - the orchestrator ends up testing something different from what ships.

This is also where stage boundary enforcement matters most at the orchestration layer. A manager that can hold gates is only useful if the pipeline enforces those gates even when the manager is slow to respond - the stage agent should not be able to advance itself.

defract as the pipeline substrate

defract 1.5.0 ships an MCP server that exposes the full lifecycle as a programmable interface. A manager agent gets the same operations a human uses in the UI: push tasks into the backlog, receive and answer scope questions when they surface, approve or reject phases at each gate, inspect diffs before merge, send context updates to a running stage agent, manage parallel workstreams. The MCP server runs on the same code path as the UI - there is no separate API that can drift.

If you are building a tool on top of Claude Code and want to add structured development to what your orchestrator manages, this is the integration point. The defract MCP server handles the sequencing, gate enforcement, stage agent lifecycle, and state that makes approval decisions meaningful - your orchestrator focuses on decisions, not pipeline plumbing. See also: running parallel Claude Code agents for the foundations of parallel work, and which agentic coding patterns actually scale for where the gated lifecycle fits in the broader landscape.