Claude Code as Orchestrator: One Brain, Many Hands Claude Code làm nhạc trưởng: một bộ não, nhiều đôi tay

Once tools like Codex and AGY can run headless — driven by a script, not a human typing into a chat box — a new question quietly becomes the important one. Not which agent is smartest, but who holds the overall vision. The moment you give one AI a second AI to help, you stop having a tooling problem and start having a management problem.

My answer, after living with it for a while: Claude Code is the orchestrator. Everything else is a worker that takes a narrow ticket and goes away.

The general contractor problem

A construction site with many skilled tradespeople only runs well when one person holds the master blueprint. If every crew does its own part and also quietly adjusts the architecture, reshuffles the schedule, and sets its own standards, the project drifts — not dramatically, but in small, compounding ways that are painful to unwind later.

Multiple AI agents on one repo are exactly this site. More agents do not automatically produce a better system. Without a single coordination point, they don't add up — they diverge. The thing that keeps the build coherent isn't raw skill; it's a single point of integration that owns the plan and reconciles the pieces before they harden into conflicts.

One channel, not a switchboard

The operating rule I follow is almost embarrassingly simple: I only talk to Claude Code. I write prompts for Claude Code, I hand it objectives, and I let it decide when to call Codex or AGY. I don't open Codex to type a prompt by hand. I don't open AGY to write a different one.

The failure mode this avoids is becoming a manual router — copying a result out of one window, pasting it into another, holding the state of three branches in your own head. The instant you do that, you are the orchestrator, and you're slower and more forgetful at it than the model is.

Mental model: tech lead and contractor

It helps to name the two roles precisely, because they are genuinely different jobs.

Claude Code is the tech lead. It reads the repo, understands the objective, holds the plan, sees where the risk is, knows what has to be tested, and — crucially — can reject a worker's result that doesn't hold up.

Codex and AGY are contractors. They accept a narrow scope, work inside a sandbox, return a result, and exit. The single most important principle here: a worker should not own the repo. Ownership — the plan, the standards, the final yes/no — stays with the orchestrator.

Why spreading context around fails

The tempting alternative is to give several agents full context windows and let them all edit the same working tree. It breaks in a specific, predictable way:

Agent A changes an abstraction. Agent B is still building on the old one. Agent C writes the docs from some intermediate state that no longer exists.

The conflicts that result aren't merely Git conflicts you can resolve line by line. They're conceptual — three different mental models of the same codebase, all live at once. No merge tool fixes a disagreement about what the code means.

Codex as the code worker

Codex fits code work well for a mechanical reason: codex exec runs headless and script-friendly, with clean output. Run it with --json and it emits a stream of JSONL events — thread.started, turn.started, item.completed, turn.completed — so the orchestrator can track state as structured data instead of parsing prose. The --output-schema flag pushes this further, forcing the result into a shape you define, which kills most of the regex-and-hope parsing. That makes it strong for patches, reviews, extraction, and any structured generation where you want a predictable envelope around the answer.

AGY as the cautious second opinion

AGY here is the Google Antigravity CLI (v1.0.0 — the standalone CLI, not the v2.x desktop app). It runs on its own with a print mode (-p), a directory flag (--add-dir), a continue flag (-c), and OAuth. I treat it as a second opinion — a different perspective on wording, structure, or an alternative read — precisely because it didn't write the thing it's reviewing.

There's a real caveat: its free tier is small (roughly 20 requests a day) and shared with the desktop app, which makes it a bad fit for careless fan-out. Codex sees more frequent use simply because codex exec is cleaner to drive; AGY behaves more like a reviewer whose quota cost forces you to call it on purpose.

A realistic fan-out

Say a task bundles three things: a refactor, some docs, and tests. Here's how it actually plays out:

1. Claude Code reads the repo first and identifies the boundaries — what's coupled, what isn't.
2. It decides the refactor-plus-tests slice is something Codex can take, and writes a specific worker prompt: which files to read, which to modify, the test criteria, and the expected output (the patch, plus the risks and assumptions it hit).
3. The docs slice goes to AGY for wording and structure suggestions.
4. Both results come back, and Claude Code does not blindly merge them. This step is the synchronization gate: it reads the diffs, fixes the mismatches, runs the tests, and only then updates the plan. Nothing lands until the tests pass.

The human watched one conversation the whole time.

It's not "three times faster" — it's a cleaner head

It's tempting to sell this as a speed multiplier. That's the wrong pitch. For small tasks, coordination overhead can make it slower. The real benefit is different: Claude Code doesn't have to carry all the side analysis in its main context.

Workers return compressed results — a patch, a few notes, the risks, the assumptions. The orchestrator stays the final decision-maker, but its working memory doesn't get clogged with every worker's intermediate reasoning. On a long task, that's what keeps the session coherent instead of slowly drowning in its own scrollback.

Infrastructure: worktree plus terminal

Parallel agents need parallel workspaces or they overwrite each other. Git worktree is nearly the backbone here: each worker gets its own branch and directory, so patches never clobber one another, and the orchestrator integrates across branches at the end. Pair it with tmux to hold several terminal sessions, keep long-running commands alive, and step back into any worker when you need to. It's an old, boring pattern, and that's the point — separate file space via Git, separate execution space via terminal, let the orchestrator do the joining.

Do you need a fancy UI for this?

Tools like OMX (oh-my-codex) and cmux try to productize the pattern — making multi-agent, multi-terminal work visible and hiding the mechanics of worktree, split, session, and notification. They're interesting, but I'd push back on adopting them reflexively. At the scale of "Claude occasionally calls Codex," a plain setup is plenty. The question of what do you even look at them with only becomes real once several workers are genuinely running in parallel. Buy the dashboard when you have something to put on it.

Cost discipline: the unglamorous part that decides survival

This is the boring section that actually determines whether the workflow lasts. I keep the Claude Code subscription as the always-on orchestrator — the primary place I work — while Codex and AGY are metered worker calls spent with intent. Let an agent call workers in loose exploratory loops and you've built a token-burning machine. Fan-out earns its keep only when the task has clear boundaries, verifiable output, and genuinely takes load off the main context. Otherwise it's spend with no return.

Where this breaks — and how to hold the line

This pattern is hierarchical orchestration, and like any hierarchy it has a few specific failure points worth naming up front rather than discovering the hard way.

The root can poison everything. The orchestrator is a single point of failure. If Claude Code misreads the goal, every worker faithfully executes the wrong thing — the mistake doesn't average out across agents, it multiplies. The mitigation is blunt: spend real effort on the orchestrator's understanding before any fan-out, and have it state the plan back to you, so you can catch a wrong turn while it's still cheap.

The output is probabilistic, so make the gate deterministic. An LLM worker won't return the same thing twice, and it can hand back confident, well-formatted, wrong code. You don't fix that with a nicer prompt — you fix it with the synchronization gate: the orchestrator merges nothing until the integration tests pass. The tests are what convert a probabilistic result into a trustworthy one. No test, no merge.

Workers need a leash, not freedom. The fear that agents will "go rogue" is reasonable, and the answer is guardrails baked into the worker prompt: which files it may touch, what it must not change, the exact shape of the output, and a hard definition of done. A worker isn't set loose on the repo — it's handed a fenced yard and one task. (This is the operational face of a worker should not own the repo.)

Be explicit about the handshake. A worker session has a clear open and close: the orchestrator hands it a bounded ticket, the worker runs in isolation (its own worktree), returns a compressed result, and exits — it doesn't linger holding state. Treat each call as a transaction, not a long-lived conversation. The orchestrator is the only thing that persists across the whole job; workers are summoned, used, and dismissed.

That last point is the real reason to split sessions at all. It's context isolation — keeping one worker's noise out of the orchestrator's working memory — not "every agent for itself." The separation is a discipline, not a free-for-all.

When NOT to orchestrate

The common trap is splitting work just because you can. A one-file bug is often faster for Claude Code to fix directly than to write a worker prompt, wait, read the patch, and merge it. An architectural decision that's still forming should not go to a worker that lacks the full picture — it'll hand back something plausible and subtly misaligned. Keep high-coupling, high-trade-off, and history-dependent work inside the orchestrator's head.

What's actually safe to delegate

Good worker tickets have concrete input, output, and a way to judge them — and don't require the soul of the whole codebase:

• "Read this module and propose the missing test cases."
• "Write a migration for this schema."
• "Scan the docs for API inconsistencies."
• "Extract the action items from these 20 notes as JSON matching this schema."

Each of these is bounded, verifiable, and self-contained. That's the signature of work worth handing off.

Why an agent and not a script?

A fair objection: if the task is "write a migration for this schema," why not a plain script or a CI job? It'd be cheaper, faster, and deterministic. The honest answer is that the line sits exactly there. If a task is fully specifiable — the same input always maps to the same correct output — a script wins, and you should write the script. Don't pay an LLM to do sed's job.

You reach for a worker only when the task needs judgment: reading an unfamiliar module and inferring which test cases are genuinely missing, refactoring across code that doesn't follow one rigid pattern, choosing the least-surprising wording for a doc. Those resist being pinned into if/else. The rule of thumb: if you could write the regex, write the regex. Hand an agent only the part that truly requires reasoning over messy, underspecified context — that's the part a script can't touch, and the only part that justifies the cost.

The real skill is decomposition

The actual skill was never how many agents to call. It's decomposition: knowing what needs full context, what's a narrow ticket, what can run in parallel, and what isn't worth orchestrating at all. Claude Code as orchestrator only works if you give it clear objectives and the authority to integrate. Codex and AGY only work if the worker prompt is specific enough that they don't have to reinvent the context from scratch.

A modest setup, on purpose

I lean toward something deliberately modest: one main orchestrator, a few headless workers, git worktree for parallel work when it's actually needed, and discipline against fan-out that can't justify itself. This doesn't turn development into a perfect autonomous orchestra. It just stops me from shuttling by hand between chat windows.

So when several agents show up on the table, the question worth asking isn't which agent is best. It's: which work actually deserves to be lifted out of the orchestrator's head?

You — by what criteria are you dividing work among your agents?