keeping context and decisions consistent across parallel AI agents

You start the morning with four Claude Code agents running, each in its own git worktree, each on a separate task. By mid-afternoon something is off. One agent has re-implemented a helper another already wrote. A second built against an interface that a third changed an hour ago. A fourth made a naming choice that contradicts a decision you made — out loud, to yourself — at 9am. Every diff is reasonable on its own. The system they add up to is not.

This is the failure mode that shows up the moment you go from one agent to several. The code each agent produces is fine. What drifts is everything between the agents: the decisions, the conventions, the current shape of the interfaces they all depend on. Running the agents in parallel is the easy part. Keeping them coherent is the hard part, and it's a different problem.

Why parallel agents drift

An agent's context is per-session. Each Claude Code instance has its own context window, populated by what it has read and done in that session. Nothing about that window is shared with the agent running in the next worktree. There is no common memory they all write to and read from. So when agent A decides "we use the repository pattern for data access," that decision exists in exactly two places: agent A's context, and your head. Agent B never hears about it.

Three kinds of state cause the drift, and they're worth separating because they need different handling:

• Decisions already made. Architecture, naming, conventions, the approach you settled on for a cross-cutting concern. These are durable — once made, they should bind every agent, including ones you spawn tomorrow.
• The current contract. The shape of the interfaces, types, and APIs that agents share. This changes during the work: agent A edits a signature, and agents B and C are now building against a version that no longer exists.
• What's in flight. Who is touching which files right now. Two agents editing the same module in separate worktrees won't see each other until the merge, where the conflict surfaces as a surprise.

Single-agent work hides all three, because one session holds the whole picture. Parallelism is what exposes them.

The bottleneck isn't the model's context window. It's yours.

The instinctive fix is to be the shared memory yourself — hold the decisions in your head and hand-feed them to each agent. That works at two agents. It breaks at four or five, because you become the integration layer: the only place the parallel streams reconcile is your working memory, and your working memory does not scale with agent count. You spend the day re-briefing, catching contradictions, and re-litigating decisions an agent has quietly forgotten. Throughput went up; your cognitive load went up faster. (We wrote about that tradeoff in more depth in the cognitive load of running parallel Claude Code agents.)

So the real question isn't "how do I run more agents." It's "how do the decisions get made once and then bind every agent, without routing through me each time."

The ways teams handle it today

There's a spectrum of approaches, each with a real tradeoff. Most people running parallel agents use some mix.

Context files (CLAUDE.md and friends)

Put conventions and decisions in a file every agent reads on startup. This is the right baseline and you should do it. The limit is that it's static: it captures decisions you can write down in advance, not the ones you make mid-stream, and it goes stale the moment the work moves past it. It binds the durable layer, not the in-flight one.

Copy-paste briefs

Hand each agent a tailored brief at spawn time. Flexible and precise, but it puts you back in the loop for every task, and it only carries what you remembered to include. This is the approach that makes you the bottleneck.

A shared task queue

Tools like Beads, or a kanban of tasks each in its own worktree, give agents a common backlog and a record of what's done. This handles "what's in flight" well — agents can see the work surface. It does less for "decisions already made," which still live outside the queue unless you write them into each task.

Plan first, then fan out

Spend an hour up front — non-agentic — resolving the design and the interfaces before any agent starts. One practitioner described it as conducting an ensemble: the score is set before the musicians play. This is the highest-leverage habit on the list, because most drift comes from decomposing into parallel tasks before the shared decisions are settled. The catch is that it only covers what you can foresee; anything decided after the fan-out still needs somewhere to live.

A structural take

This is the problem defract was built around, so treat this as one approach rather than the answer. Instead of every agent starting from a blank context you fill by hand, defract keeps a shared memory of the codebase, the decisions made, and the conventions in play — so a decision made once is inherited by every agent, including later ones. And it settles the design and architecture as gated stages before implementation fans out, so agents decompose into parallel work against an interface that's already fixed, not one that's still moving. The agents still run in parallel, in their own worktrees; what changes is that the shared state has somewhere to live other than your head.

That's also where it differs from a pure parallel runner — see defract vs Claude Code Agent Teams for that comparison. The runner gives you the parallelism; the open question it leaves is exactly the one above.

Whatever tooling you reach for, the test is the same: when you make a decision at 9am, does every agent still honor it at 4pm — without you being the thing that carried it there?