Build on what's coming: unfinished work is a promise
By Soumen Sarkar · October 2026
Unfinished work is a promise, and a promise can be built on.
Why build on work that isn't finished yet?
Because at agent pace, finished is too late. If every change waits for the one beneath it to land, a team's work runs in single file, and a dozen agents move at the speed of the slowest. When a teammate says what their work will become, the rest of the team can build toward it today, and adjust in minutes when it lands.
That's the second VibeFlock principle: unfinished work is a promise, and a promise can be built on. Nobody's progress is held hostage by anybody else's.
Why does this matter so much now?
Because almost everything a team builds depends on something else that's also moving. The checkout depends on how prices are stored. The invoice email depends on the checkout. The pricing page depends on all three. With several people each running several agents, these pieces are being changed at the same time, by different sessions, often in different time zones.
There are only three ways to handle that. You can wait, and lose the day. You can guess at what the other work will look like, and redo your part when the guess is wrong. Or you can ask the other work what it intends to become, and build against that. The third is the only one that keeps both sides moving.
It also changes what a dependency feels like. A dependency on finished work is a wait. A dependency on a stated plan is a conversation that has already happened: the shape is known, the timing is known, and the only open question is how closely the result will match. That question is answered the moment the work lands.
What does it look like in a working day?
Take a scenario: a four-person team running about a dozen agents, shipping a pricing change with a new annual plan.
On Tuesday morning Tomás starts an agent in the billing code, the area the team knows as "Billing · lib/billing". Its goal is to add annual plans to how prices are stored. Before it writes much, it says what the work will become:
- Each price gets an interval, monthly or yearly.
- Amounts stay in the smallest currency unit, as they are today.
- A new function returns the price for a plan and an interval, with the discount already applied.
- Expected by early afternoon.
An hour later, Priya's agent starts on the checkout summary. The first time it opens the billing code, it sees Tomás's work in progress and its plan. It doesn't wait, and it doesn't invent its own shape for prices. It writes the summary against the planned function, keeping the call in one place so it's cheap to adjust.
Maya's agent, building the invoice email, does the same. Sam glances at the work in progress and asks to be told when it's finished, because the pricing page is his next job.
At two o'clock Tomás's work lands. It turned out close to the plan, with one difference: the discount comes back as a separate figure rather than folded into the price, because the invoice needs to show it. Priya's agent hears exactly that on its next turn, changes two lines, and carries on. Maya's agent needs no change at all: the separate figure is what the invoice wanted. Sam starts the pricing page against code that's already there.
Nobody waited for anyone. And the one surprise cost minutes, not an afternoon, because it arrived as "here's what changed from the plan" rather than as a broken build.
What do people do?
You say what your work will become, so others can build on it before it's done. That means:
- Write the plan where the work lives, at the start, in a few lines. Name the shapes others will touch: the function, the field, the screen.
- Give a rough time. "Early afternoon" is enough. It lets others decide whether to build now or pick something else first.
- Say when the plan changes. A promise that quietly shifts is worse than no promise.
- When it lands, say how it turned out against the plan. That one sentence saves everyone downstream from finding out the hard way.
What do agents do?
An agent builds against the plan of work in progress, and adapts the moment that work lands. Before it builds on something unfinished, it reads that work's plan. It keeps its dependency narrow and in one place. And when the work lands, it reads what changed and adjusts, rather than assuming the plan held. For the mechanics of two agents doing this at once, see dependent changes at the same time.
What if the promise changes?
It sometimes will, and that's fine. A plan isn't a contract. It's the best statement of where the work is heading. The point is that when it changes, the people and agents built on it hear about it at once, while the fix is still small. A change found the moment work lands costs minutes. The same change found a week later, inside three other features, costs days.
There are honest limits:
- A vague plan is weak ground. "Improve billing" can't be built on. If the plan doesn't name the shapes others will touch, build on it lightly, or wait for a sharper one.
- Not everything should be built on early. If the unfinished work changes how data is stored or deleted, or what customers are charged, keep the dependent work easy to undo until it lands.
- Seeing work in progress is also how you avoid collisions. If two agents are about to change the same thing in different directions, the time to notice is before either lands. Building on what's coming and not building around it are the same habit.
How does Campfyrr make it hold?
Campfyrr makes work in progress visible where it lands, with its plan, and tells everything built on it what landed and what changed.
- Work in progress is announced. An agent calls
start_work with a goal, a plan and when it's expected. In Claude Code, a session's first request also becomes the one-line goal of its work in progress automatically. - It shows up where it matters. The first time another session touches that part of the code, its area brief says what's being changed there right now, by whom, the plan and when it's expected.
- Agents can depend on it. An agent calls
wait_on to build on unfinished work: it gets the plan now and hears when the work lands. In Claude Code that news arrives on the session's next turn. - People can follow it. On the Activity page, work in progress shows in the feed with its goal, and later what it became.
- It lands with its story. When work finishes, it's shown as landed, with what it turned out to be compared with its plan.
What does a team gain?
A team that builds on what's coming works side by side instead of in single file. Each person's work becomes ground for everyone else's before it's finished, and when it lands, the adjustment takes minutes.
Unfinished work is a promise. Keep it clearly, and the whole team can build on it.
Questions this answers
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).