CFD with multiple agents: how to keep context across worktrees

On October 10, Ahmed from Winskel wrote to me after reading Context-First Development. Ahmed was building an app to coordinate tasks between Claude Code and Codex. The question, in essence, was this:

How would you preserve the project's context when two agents take on different pieces?

I was glad to get it. Someone had read the methodology, connected it to their own work, and found something I still needed to explain better.

CFD proposes writing down a project's decisions so an agent can pick up the work without us having to explain everything again. Ahmed's question added a problem: while one agent learns something new, another one may be working with information that is already out of date.

That led me to extend the methodology for working with several agents in parallel.

The same transaction, two different months

Picture a finance app. One agent builds the transaction export and another one builds the monthly summary.

Each one works in its own worktree: a separate directory where it can change a branch of the same repository. That way their local edits don't get mixed up. Git lets you keep those directories open at the same time.

Then a transaction shows up close to midnight. The first agent uses the account's time zone and places it in September. The second one uses UTC and counts it in October.

The files can be merged without conflicts. The app, however, shows two answers for the same piece of data.

Separating the files lets the agents work in parallel. Both agents also need to know the rule that decides which month a transaction belongs to.

First, agree on what each one will do

In CFD, each agent gets a small task, with an expected result and a way to check it. It is also settled which parts of the project it may change.

In our example, someone has to decide which date to use before work starts. That decision is recorded in the repository and both agents read it. The export and the summary are built from the same criterion.

If both need to change a shared piece, that change is resolved first. After that, they can carry on separately.

Each agent keeps its own progress notes. "Month-end close still needs testing" belongs to the task of whoever wrote it down. The project's rules, on the other hand, are available to everyone. A task board shows who is doing what.

If a decision changes, the work in progress has to take it in

Some questions only come up during implementation. Suppose nobody had decided what to do with dates close to midnight.

The agent that finds the problem stops. The developer makes the decision and adds it to the repository. If the other agent is working on something affected, it also pauses that part until it has caught up.

Both have to read the new rule and check the work they have already done. Updating the files does not guarantee that an open conversation with the agent stops using the old interpretation.

In the example, the check is concrete: the export and the summary must place that transaction in the same month.

This was the main improvement over my first answer to Ahmed. Documenting a decision once the work is done can come too late for the agent that has spent a while working on a different assumption.

Review the results one at a time

The agents can implement at the same time. Their changes go into the project one at a time, with a human review at each step.

If the export goes in first, the summary is reviewed against the project that already includes the export. The review checks that it does its task and that it still respects the shared decisions.

That is why CFD suggests starting with two or three agents when there are independent tasks and time to review their results. If finished changes pile up waiting for review, opening another agent only makes that wait longer.

Review capacity is part of planning, just like implementation capacity.

What changed in CFD

The methodology now spells out how to split the tasks, what context each agent shares, and when to stop to take in a new decision. It also keeps a human review before each result is merged.

Ahmed's question helped me pin down a scenario I hadn't developed enough. Those rules are now in the CFD repository, in the decision on parallel work with worktrees, with the technical detail needed to apply them.