Grok Build Runs Eight Subagents in Git Worktrees. That Detail Is the Whole Product.

Most of the coverage of Grok Build focused on the numbers: eight parallel agents, a two million token context window, a beta that opened in May for SuperGrok Heavy subscribers on Grok 4.3.

The number that actually matters is none of those. It is that each subagent runs in its own git worktree.

That sounds like an implementation footnote. It is the difference between parallel agents being useful and being a way to corrupt your working tree eight times faster, and it is worth understanding whether or not you ever run xAI's CLI.

The problem worktrees solve

Try running several coding agents at once on a single checkout and you will discover the failure mode within about ten minutes. Agent A edits a file. Agent B reads it mid-edit and gets a half-written state. Agent C runs the test suite against a tree that contains three agents' partial work and reports failures that belong to nobody. Somebody stages something. Now you cannot tell which change came from where.

The naive fixes are all bad. Serialise the agents and you have given up the parallelism you were paying for. Give each one a full clone and you are copying the repository several times and losing shared git history. Lock files between agents and you have built a distributed systems problem inside your editor.

Git worktrees are the right primitive and they have existed since 2015. One repository, several working directories, each on its own branch, sharing the object store. Each agent gets a real filesystem it can edit freely, tests run in isolation, and the merge back is an ordinary git operation rather than a reconciliation puzzle.

Grok Build wiring this in as the default for subagent fan-out is the design decision I would point to if someone asked what is good about it. It is unglamorous and it is what makes the eight-agent claim mean something.

Plan mode is the other good decision

Before it writes anything, Grok Build can produce a full diff of proposed changes and wait for approval.

For a single agent that is a nice convenience. For an agent that can spawn seven others, it is close to essential, because the failure mode of parallel agents is not that any one of them does something terrible. It is that the aggregate of eight reasonable-looking changes is incoherent, and you do not find that out until you are reading a very large diff with no memory of what was intended.

An approved plan gives you a thing to check the result against. It is also the artefact you can hand to a colleague, which matters more than it sounds, because the reviewability of agent-produced changes is the actual bottleneck on how much of this work a team can absorb.

I would use plan mode by default and treat turning it off as a decision, not a preference.

Three modes, and the third one is the interesting one

Grok Build runs as an interactive terminal UI, headless with a flag for scripts and CI, and as an ACP agent over JSON-RPC.

That third mode deserves more attention than it got. The Agent Client Protocol lets another application host the agent: an IDE, a workspace tool, your own internal system. The same standard is how Buzz connects agents into its channels, and how Claude Code, Codex, and Goose are reachable from third-party hosts.

What that means practically is that the harness is becoming a swappable component. If your team builds tooling that speaks ACP, you are not choosing a coding agent permanently. You are choosing which one to point at today.

This is the same argument as MCP on the tools side, and it points the same direction: put the standard between you and the vendor, and vendor decisions stop being your decisions. Given how fast this particular corner of the market is consolidating, with xAI now inside SpaceX and Cursor now inside xAI, keeping the harness swappable seems like ordinary prudence rather than paranoia.

When eight agents actually help

I want to be careful here, because parallel subagent fan-out is the feature everyone wants and the one most often misapplied.

It helps when the work is genuinely divisible. Migrating a pattern across forty files. Writing tests for a dozen independent modules. Auditing every route for a specific problem. Each unit is independent, each subagent can work in isolation, and wall-clock time collapses to roughly the slowest single item.

It helps for research fan-out, where several agents explore different parts of a codebase to answer one question and report back. Reads are cheap, they do not conflict, and breadth genuinely beats depth for that task.

It does not help when the task has sequential dependencies. If step two needs step one's output, eight agents means seven idle agents and a coordinator burning tokens explaining the situation to each of them. You will pay several times the cost for the same wall-clock time and a worse result, because every handoff is a chance to lose information.

The honest test before fanning out is whether you could hand the pieces to eight different contractors who never speak to each other. If yes, fan out. If the answer involves any of them needing to check with another, do not.

Where it sits against the alternatives

I am not going to declare a winner, partly because these tools change every six weeks and partly because the differences that matter are workflow differences rather than capability differences.

What Grok Build does distinctively well: parallel fan-out with proper isolation, and an approval-first default. If your work has a lot of divisible mechanical change in it, migrations, sweeps, large refactors, that combination is genuinely strong.

What would make me hesitate: it is bundled behind SuperGrok Heavy rather than sold on its own, which makes it hard to evaluate on cost against alternatives. And a two million token context window invites a working style, load everything and let it sort it out, that I think is a trap. Retrieval into a smaller window generally beats a saturated large one, and long context is most useful as headroom rather than as a strategy.

The sensible position is that most teams already run more than one of these. There is nothing wrong with using one tool for large mechanical sweeps and another for careful work in a codebase you know well.

The part worth copying

Even if you never install it, three things here are patterns worth adopting in your own agent infrastructure.

Isolate parallel agents at the filesystem level, with worktrees or equivalent. Any system where several agents write concurrently to shared state will eventually produce a mess nobody can attribute.

Require an approved plan before write operations, particularly when an agent can spawn others. The plan is what makes the result reviewable, and reviewability is the constraint on adoption.

Connect through a protocol rather than an SDK. ACP for harnesses, MCP for tools. It costs almost nothing at the start and it is what lets you change your mind later without a migration.

Those three are not xAI's ideas specifically, but Grok Build is a clean demonstration of all three in one product, which makes it a useful thing to look at even if you go on to use something else.

We build agent infrastructure with exactly these properties, worktree isolation for parallel work, approval gates before writes, and protocol connections so the harness stays swappable. If you are putting coding agents to work at any scale, we are happy to look at how it is set up.