How can two agents work on dependent changes at the same time?
By Soumen Sarkar · October 2026
Short answer: Two agents can work on dependent changes at the same time when the first one states what its work will become (its plan and the interface it will expose) and the second builds against that plan, adjusting when the first one lands.
Why not just do them one after the other?
Because the second change then waits for the first one to finish, be reviewed and merge. At agent pace that can be most of a day, and it adds nothing: the second agent could have been building the whole time.
Unfinished work is a promise. If the first agent says clearly what its work will become, the second can build on that promise today.
What does the first agent need to say?
Enough for someone to build against it without reading its code:
- The goal: what the work is for, in one line.
- The plan: the steps, in order.
- The shape: the function names, fields, endpoints or events it will expose.
- When: roughly when it expects to land.
The shape is the part that matters most. "Invoices will have a lineItems array with amountCents and taxCents" lets another agent write real code today.
What does that look like with two agents on billing?
One agent is adding itemised invoices to the billing API, in Billing · lib/billing. It starts by publishing its plan: a new GET /invoices/:id response with lineItems, each carrying description, amountCents and taxCents, expected by mid-afternoon.
A second agent, in another developer's session, is building the invoice PDF. Instead of waiting, it reads that plan and writes the PDF layout against the promised shape, with a small fixture that matches it. Its tests run against the fixture.
At 15:30 the API work lands. One thing differs from the plan: tax moved to the invoice level, so line items no longer carry taxCents. The PDF agent hears about it, drops the per-line tax column, adds a tax row under the subtotal, and swaps the fixture for the real endpoint. Twenty minutes of adjusting instead of half a day of waiting.
What makes this safe?
Two habits:
- Build against the plan, not a guess. If the plan is vague, state an assumption about the missing part and keep it visible, so it's checked when the work lands.
- Compare when it lands. The moment the first change is in, look at what it turned out to be against what it promised. Adjust in the flow of the work.
Most of the time the plan holds and there's nothing to adjust. When it doesn't, the difference is small and known, because both sides were working from the same written promise.
How does Campfyrr support it?
An agent calls start_work with its goal, plan and expected time, and that work in progress shows on the team's Activity page and in the area brief of anyone who touches the same code. The second agent calls wait_on to build on it: it gets the plan now, and at its next turn after the work lands it hears that it landed and what changed against the plan. People see the work in progress, and later what it became, in the Activity feed.
The result is less waiting time, and no surprise at the end. For the related question of finding out what changed, see how to know when work you built on has landed.
Words used here
- Work in progress: Work in progress is work under way, shown with its plan, so others build on it rather than around it.
- Landed: Landed means work that finished, shown with what it turned out to be compared with its plan.
- Waiting time: Waiting time is the time work spends stopped for a person: from the moment a question, assumption or handoff needs someone until they act on it.
The principle behind this: Build on what's coming: Unfinished work is a promise, and a promise can be built on.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).