One feature, four people, twelve agents
By Soumen Sarkar · October 2026
Scenario. A made-up team of four ships one feature across three time zones by building on each other's work before it's finished, told hour by hour.
How do four people and twelve agents ship one feature without waiting on each other?
They build on each other's work before it's finished. Each piece says what it will become, the pieces that depend on it build to that plan, and when it lands they hear what changed and adjust in minutes. Here is one day of that, hour by hour.
A made-up team, a real way of working.
The team builds a meal-planning app. Today's feature is shared shopping lists: a household adds to one list from different phones and sees each other's changes. Each person runs about three agents.
- Ines leads the feature from Berlin.
- Kwame owns the server, in Accra: how lists are stored and synced.
- Hana builds the mobile app, in Osaka.
- Luca builds the web app and the invite emails, in Montréal.
All times are Berlin time.
Yesterday, 18:40
Kwame's agent starts the server work before he signs off. It records what the work will become, so others can build on it overnight:
start_work
goal: Shared lists: a list has members, and each item records who added it
plan: Lists get a members table. Items gain addedBy and checkedBy.
Changes stream over the existing sync channel as list.updated events.
expectedBy: tomorrow, 16:00 Berlin02:10
Hana starts her morning in Osaka. Her first agent is building the list screen, and the first time it reads the server code it gets the area brief for Lists · server/lists:
Being changed right now
Kwame: Shared lists: a list has members, and each item records who added it
Plan: members table; items gain addedBy and checkedBy; list.updated events
Expected: today, 16:00
Decisions here
Sync events carry the whole item, never a diff (Kwame)
The agent doesn't wait for Kwame to wake up. It calls wait_on with his work, gets the plan, and builds the screen to it: a small avatar on each item for whoever added it, and a tick showing who checked it off. When Kwame's work lands, this session will hear.
02:45
Hana's second agent hits something nobody has written down: what happens when two people tick the same item at the same moment? It states an assumption and keeps going.
state_assumption
question: Two people check the same item at once. Who wins?
assumption: The last tap wins, and the item shows who checked it.
likely answers: last tap wins · first tap wins
The record is silent, so the assumption goes to Kwame, who made the closest decision.
03:30
Her third agent assumes that removing someone from a list removes the items they added. That deletes things, so it's marked High stakes and will be shown first. The agent still keeps going, keeping the deletion in one small function that's easy to change.
08:30
Ines opens the Activity page and filters to Status updates. She sees Kwame's server work in progress and Hana's three pieces built on it. She leaves a reaction on Kwame's update and gets on with the invite flow's wording.
11:05
Kwame signs in from Accra to a short feed, not a queue of stalled sessions. The high-stakes assumption is marked. He follows its "Answer it" link, clicks "Correct it…" and writes one line: "Items stay when someone leaves. Show them as added by a former member." Then he opens the last-tap-wins assumption and clicks "Right, keep going".
Hana is asleep. Her agents aren't: the correction reaches the third one at its next turn, and it swaps the deletion for a relabel.
13:20
Kwame's agent, working through his plan, finds that every other event on the sync channel is named for a change, not an update. It keeps the codebase consistent and records why in a sentence:
log_decision
title: Sync events are named thing.changed
why: Every other event on the channel already is; one exception confuses clients
It doesn't stop to ask whether the plan may change. A plan is a promise, not a contract, and the landed notice will say exactly how it moved.
15:00
Luca starts in Montréal. His agent is building invite emails, and the first time it opens Invites · server/invites its area brief shows Kwame's work and the members table it will add. It calls wait_on too, and builds "accept invite" to add a row to that table, by the plan.
16:40
Kwame's work lands, and what landed differs slightly from the plan. His agent's outcome says so plainly, and everything built on it is told:
Landed: Shared lists (Kwame)
You built on this. What changed from the plan:
- Sync events are called list.changed, not list.updated,
to match the rest of the sync channel
- Members have a role: owner or member
16:55
Luca's agent hears at its next turn. It renames one event handler and makes sure only an owner can send an invite. On commit, the change's reasons are written for the reviewer, and Luca puts the link in his pull request description.
17:30
Ines filters Activity to Actions. Kwame's finished work and Luca's sit there, each written as what happened and why it matters. She doesn't have to ask anyone how the day went. At each person's end of day, a daily update is written in plain words from their work logs.
Next day, 02:05
Hana's session brief opens with "Pick up where it was left": the handoffs her three sessions wrote when they stopped, and the news that Kwame's work landed with a renamed event. Her agent changes list.updated to list.changed in two places, and the feature is whole before Ines wakes up.
What made it work
- [Build on what's coming](/vibeflock/build-on-whats-coming). Kwame said what his work would become before it existed, so three people built on it across three time zones. When it landed with two differences, everyone built on it heard exactly which two.
- [Turn unknowns into calls](/vibeflock/turn-unknowns-into-calls). Hana's agents named what they didn't know and kept going, instead of waiting nine hours for Kwame.
- [Fix forward](/vibeflock/fix-forward). The high-stakes call was shown first and corrected in a sentence, while it was still one small function.
- [Let the work speak](/vibeflock/let-the-work-speak). Handoffs and reasons meant nobody had to explain their day to anyone.
For the practice behind this day, see working in parallel on dependent changes.
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).