Multi-Agent Orchestration in Claude Code

Most people who try AI coding tools use one agent at a time. You give it a task, it writes the code, you review it, and then you give it the next one. That makes each task quicker, but the project still moves in single file, because every piece of work waits for the one before it.

Multi-agent orchestration changes the shape of the work. Several AI coding agents run in parallel on different parts of the same codebase, each in its own isolated workspace, while a lead agent plans, reviews and integrates what they produce and a human makes the judgement calls. It's how we took Semoria, our LinkedIn content platform, from a product requirements document to a live product with paying users in six weeks.

This post is about the method rather than the product. It covers how the lead agent and the sub-agents fit together in Claude Code, the three patterns we reused throughout, what has to be true before parallel agents help rather than hurt, and where we deliberately went back to a single agent. If you're after the stack itself, Inside Semoria covers the architecture.

What is multi-agent orchestration in Claude Code?

Multi-agent orchestration means running several AI coding agents in parallel against different parts of the same codebase, with one lead agent coordinating their work. It is the part of the Semoria build that made the timeline possible.

The setup looks like this. A lead agent owns the plan, the scope, and the integration. Sub-agents get scoped tasks ("build the API route for voice profile creation", "refactor the trial-tracking helpers", "draft the weekly digest email template") and an isolated workspace, which in practice is a git worktree pointing at the same repository. The sub-agents work in parallel. The lead reviews each completed slice, integrates it back into the main worktree, and arbitrates any conflict when two slices have touched the same shared file. Tests run after every integration.

Single-agent development compresses individual tasks. Multi-agent orchestration compresses the whole project, because the slices do not queue behind each other. A new API route, a refactor of the billing flow, a new email template, and a new marketing page can all be in flight at the same time, on the same evening. The discipline is in scoping the tasks so the surface areas do not collide, and in being honest about what is independent versus what is genuinely sequential.

Claude Code supports this directly. Subagents give each task its own context and brief, and git worktrees give each agent its own working copy of the repository, so parallel edits can't collide on disk. Other AI development tools offer similar building blocks, so the method isn't tied to Claude in principle. It's simply easiest to run in Claude Code today, because both pieces come built in.

There are three concrete patterns we used repeatedly across the Semoria build.

Pattern one: parallel feature drafts. When three independent features were specified (for example, the achievements system, the notification bell, the email digest scheduler), three sub-agents drafted them in parallel in separate worktrees. The lead reviewed and integrated them sequentially over a single afternoon, instead of waiting on each one to finish before the next began.

Pattern two: draft-and-review pairs. One sub-agent writes the feature, a second sub-agent reviews it with a senior-engineer brief ("look for missed edge cases, security gaps, brittle assumptions, dead code"). The reviewer's output goes back to the lead, who decides what to action. This catches more than a single pass through the same agent does, because the review brief is different from the drafting brief and the reviewer is looking for what the drafter missed.

Pattern three: a batch refactor across the codebase. A single sub-agent gets a brief like "rename PlanTier to PlanStatus across all 73 API routes and 47 components, then run the typecheck and fix what breaks". The agent handles the mechanical work; the human checks the diff for anything subtle that the type system did not catch.

What has to be true before you parallelise?

Parallel agents amplify whatever you hand them, so most of the speed was decided before any agent wrote a line. The planning phase ran for under a week and produced a small product requirements document, an architecture decision record and a pricing shape. Three things from that week mattered for orchestration in particular.

The first was a deliberately small scope. The requirements document described the smallest version of the product someone would pay for, and everything else went on a written list of later work, including the second voice profile, scheduling and the calendar view, the free tools, annual pricing, the notification bell and mini series. None of it was cut, and every item went live within eight weeks of launch. Writing that list down at the start is what kept the agents, and the people directing them, out of scope creep.

The second was a boring, well-documented stack. AI agents write noticeably better code against tools they have seen many thousands of times, and the most widely used technologies in the Stack Overflow Developer Survey are also the best documented. Inside Semoria goes through each choice and what it costs to run.

The third was a feature set that split cleanly. Voice fingerprinting, the content pipeline, billing and the email templates each had their own tables, routes and workflows. That separation was designed in from the start, and it's what made parallel work safe later on.

How did the build cadence change across the six weeks?

The build cadence was not uniform. The shape of the work changed across the six weeks, and the methodology adjusted with it.

Week one was deep-work mode with a single agent. Architecture scaffolding, the initial database schema, the auth flow, the first set of API routes, the basic dashboard chrome. This kind of work has too much shared surface to parallelise safely: every later feature depends on these foundations, and a small mistake propagates. One agent, one worktree, one careful pass per night.

Weeks two and three were the heaviest parallel-work phase. The foundations were in place, and the feature set decomposed cleanly into independent slices: voice fingerprinting (its own API surface, its own tables), content generation pipeline (its own n8n workflows, its own state machine), Stripe billing (its own webhook handlers, its own RLS policies), email templates (each one independent of the others). Three to five sub-agents in flight at most points, the lead reviewing in fast cycles.

Week four was a polish-and-harden mode. Single agent, careful work, but with a different brief: security review of every endpoint, row-level-security audit on every table, prompt-injection blocking on every AI call, rate limiting, observability wiring. The kind of work that benefits from one mind holding the whole picture rather than four minds in parallel.

Week five was parallel again, this time on the marketing engine. The programmatic blog, free tools, persona pages, social automation, and email funnels all decomposed cleanly because they share no runtime state with each other. Four sub-agents on marketing surfaces while the lead handled the final billing integration.

Week six was the dress rehearsal. End-to-end tests, real-user trial walkthroughs, payment edge cases, mobile compatibility on the email templates, the Stripe webhook race conditions that the unit tests had missed. Multi-agent again, but on bug fixes rather than features.

The honest takeaway: the build cadence is not "always parallelise". It is "parallelise when the work decomposes, and stop parallelising when it does not". The skill is in the judgement of which is which.

What does AI do well versus what do humans still own?

The split between AI and human work was around 70-30 by hours, but the 30 percent that stayed with the human is the part that mattered most for whether the output was a product or just code.

AI handled the bulk of drafting, refactoring, test writing, integration scaffolding, batch edits, code review against a fixed brief, documentation, and anything where the specification was clear and the definition of done was verifiable. The latest GitHub Octoverse report shows a step-change in AI-assisted code volume across the industry, and the Semoria build is consistent with that trend at the project scale: most of the lines of code that shipped were AI-drafted under human direction, then reviewed and adjusted by either another agent or the human directly.

Humans handled prioritisation, scope arbitration, taste calls on product UX, the business model and pricing, security review of anything irreversible, decisions about which work to parallelise versus serialise, and the recurring "is this actually a good idea" check. Research summarised in the Harvard Business Review's generative AI coverage consistently lands on the same conclusion: AI lifts productivity most where the human stays in the lead seat for judgement, and lifts it least (or not at all) where the human disengages.

In concrete terms, the human role on the Semoria build looked like this every day. Pick the next slice of work in priority order. Decide whether it is one task or three. If three, write the briefs and dispatch sub-agents in parallel. While they work, review the previous slice's output and either approve, integrate, or send back with notes. At the end of the day, run the test suite, look at the deploy preview, and make a call on what tomorrow's first slice will be. The AI did the writing. The human did the steering.

The mistake people make when they think AI does not work for them is dropping the human role entirely and expecting the AI to make all of the steering decisions too. That is not the methodology that compresses six months into six weeks. The methodology is to keep the human role hard and small, and to delegate the writing.

How does this compare to other ways of building a SaaS?

Here is the honest comparison we used internally when we made the build call:

The middle two rows are where most independent builders sit today. The third row, multi-agent orchestration, is where we built Semoria and where most platform-grade builds with a small team will sit over the next two years.

When should you use multi-agent orchestration?

It earns its keep when a project has several pieces of work that can genuinely run side by side, and someone experienced is free to sit in the lead seat. Platform builds, internal tools with several distinct modules, and a marketing engine built alongside a product all fit that description. A single well-scoped feature doesn't, and neither does the foundation work at the start of any build, where one agent and one careful pass will beat four agents competing for the same files.

The human role is the part people underestimate. Someone has to choose the slices, write the briefs, review what comes back and decide what tomorrow's first job is. Take that role away and you get a lot of code very quickly, but not a product.

We now run the same shape for platform-grade client work, as set out on the Agenticise services page, and our working assumption for a Semoria-sized project is six to eight weeks from requirements to first paying user. For a sense of scale, the Semoria codebase at week six held 424 TypeScript files, 73 API routes, 64 database migrations and 27 transactional email templates, every figure taken from the production repository rather than estimated.

The rest of the series covers the product side. Inside Semoria covers the architecture and its running costs, building the marketing engine alongside the product covers the launch marketing, and the origin post covers why Semoria exists at all. The Semoria case study brings the whole story together.

Frequently asked questions

What is multi-agent orchestration in AI development?

Multi-agent orchestration is the practice of running several AI coding agents in parallel against different parts of the same codebase, with a lead agent coordinating their work. Each agent gets an isolated workspace, a scoped task, and a clear definition of done. The lead reviews, integrates, and arbitrates conflicts. The result is real wall-clock compression on multi-feature work without sacrificing review quality, because independent slices run concurrently rather than queueing behind each other.

How do you stop parallel AI agents from conflicting?

Two safeguards. First, every parallel agent works in an isolated git worktree so file edits cannot collide at the filesystem layer. Second, the lead agent scopes tasks so the surface areas do not overlap, which is the same discipline a senior engineer applies when splitting work across a team. When agents do touch shared files such as types or configuration, the lead serialises those changes and runs them through review before integration. The human role shifts from writing code to arbitrating scope and judging trade-offs.

When should you not run AI agents in parallel?

When the work shares too much surface to split cleanly. On the Semoria build, the foundations (the first database schema, auth and the core API shape) and the hardening work (security review, row-level-security audits and rate limiting) both went to a single agent, because every later feature depended on them and one mind holding the whole picture made fewer mistakes than several working side by side. The rule we use is to parallelise when the work breaks into slices with no shared state, and to stop the moment it does not.

What does AI handle versus what humans still own?

AI handles drafting, integration scaffolding, refactoring at scale, batch reviews, and any task with a clear specification and a verifiable definition of done. Humans still own judgement, taste, business model decisions, security review of anything irreversible, prioritisation, and arbitration when parallel work touches the same surface. The Semoria build was about 70 to 80 percent agent execution and 20 to 30 percent human direction, but the 20 to 30 percent was the part that determined whether the output was actually a product or just code.

How maintainable is AI-built code?

Maintainable when it is reviewed under the same standards human-written code would be reviewed under, and brittle when it is not. Multi-agent orchestration helps because review is built into the workflow. A separate review agent runs against each merged slice, a senior engineer arbitrates anything irreversible, and tests are written in the same pass as the feature. Semoria went live with paying users at the end of the six-week build and still runs on that same codebase today.