Field guides
VibeFlock in practice
How teams of people and AI agents build one product at agent speed, without anyone waiting. Essays and playbooks by Soumen Sarkar.
The problems it solves
- Agents keep breaking team decisionsAgents break team decisions when the decision never reaches them: it sits in a chat thread, or in a CLAUDE.md so long and contradictory that the newest call can't win. Record each decision when it's made, tie it to the part of the code it governs, mark the one it replaces, and brief every session on it before it edits that code.
- Development is fast; deciding what to build, clearly, is the slow partWhen an agent builds a feature in an afternoon, a vague spec turns into the wrong feature by lunch. Product teams keep up by writing each decision down with its reason, putting what the business knows on the part of the product it affects, and reading the plan before anything is built.
- Getting what the business knows to the agents, fastBusiness context reaches agents late because it travels from person to person before it reaches the work. Attach it to the part of the product it affects, in the business's own words, so every agent working there is told before it changes anything.
- Half-finished work loses its contextWhen a session stops partway, what it knew stays in a transcript on one machine: what's done, what's left, the traps it found. A short handoff written at the moment it stops (done, unfinished, next step, open questions, traps) lets you or a teammate continue in minutes instead of reconstructing it.
- Making Claude handle every system yourself: when the glue becomes the projectWhen a team wires Claude into Slack, the tracker, GitHub, docs and CI itself, the glue grows with every tool and breaks with every change. A shared layer of hooks and one MCP server can carry the team's context to every session, so you keep only the connections that do real work. It doesn't replace your tracker, your CI or the tools' own connectors.
- Review is the bottleneck when agents write the codeAgents write good changes faster than people can work out what each one is for. Review moves again when every pull request arrives with its reasons: what it's for, the calls made, what was assumed. Read those first, then the code they point to.
- Showing non-technical teammates what the agents builtPublish the work as pages people can read: the plan before it starts, test results and a sample output as it lands, each with the point first in plain words and a link to share. Campfyrr does this from Claude Code; it doesn't run your tests or replace your demo.
- Silos at agent speed: when engineering moves fast and everyone else doesn'tWhen agents make building fast, the gaps between engineering and everyone else become the slow part. Teams close them with one shared record and one plain "where are we" page anyone can open, instead of status meetings.
- Stop being the human routerYou become the human router when every unclear point in every session waits for you. Have agents state an assumption and keep going, send each assumption to the person who knows, and keep for yourself only the calls that are yours: about ten minutes a day.
- Telling your CEO and PM what shipped, without a meetingLet the work report itself. Each session records what it finished in plain words as it goes; at the end of each person's day that becomes a short update, the big calls post to Slack the moment they're made, and a "where are we" page answers anyone who asks.
- Testing is critical, and testers are left out of planningTesters see the work last because the plan lives in a developer's session, where they can't read it. Publish the plan before the work starts, let testers answer the agents' assumptions, and publish test results as pages anyone can open. Campfyrr does those three things; it doesn't run your tests.
- We ship in a day, but feedback takes a weekFeedback is slow because it travels from person to person before it reaches the work. Close the loop: let whoever knows answer the agent's assumption from a link, so the answer reaches it at its next turn, and record corrections where the next session is briefed on them.
- When building is easy, review falls on the businessWhen agents build faster than anyone can check, review falls on whoever meets the output first: support, sales, the founder or the customer. Move review earlier: show the plan and a sample output before it ships, and send each assumption to the person who knows the answer.
- Your teammates' Claude Code sessions don't know about each otherEach Claude Code session starts from the code and your CLAUDE.md, not from what your teammates' sessions are changing right now. Worktrees keep their files apart; to keep their work aligned, every session needs to see the work in progress, decisions and assumptions in the area before it edits it.
Comparisons: Campfyrr and the alternatives
- Building your own Claude glue vs a shared layer: what to build, what to hand overIf you need Claude to act on a tool, build the glue yourself: an MCP server, a hook, a Slack webhook. If you need every session to know what the team decided, use a shared layer like Campfyrr, because that glue breaks quietly. Most teams need both.
- Campfyrr vs Conductor: parallel agents that don't collide, and don't contradictIf you want to run many coding agents at once without them trampling each other's files, use Conductor. If those agents keep making calls that contradict each other, use Campfyrr. Most developers running agents in parallel on a team end up with both problems.
- Campfyrr vs ContextStream: agents that find code fast, or a team that stays on one set of decisionsIf your agents waste time finding the right code, and you're fine sending source to a hosted index, use ContextStream. If your problem is sessions building on calls nobody checked, and people outside engineering need to follow and answer, use Campfyrr: it never takes your code and costs a fraction per seat.
- Campfyrr vs Entire: finding out why an agent did it, or telling the next one firstIf your problem is finding out why an agent did something after it's done, use Entire: it keeps the full session behind every commit in git, so a reviewer can trace a line back to its prompt. If your problem is the next session undoing a call it never heard about, use Campfyrr: it gives that session the team's decisions and reasons before it edits. Many teams have both problems.
- Campfyrr vs GitHub Copilot Memory: agents that know the code vs sessions that know the team's callsIf your problem is handing issues to agents and reviewing what comes back on GitHub, use Copilot with Agent HQ: its memory keeps the agents right about the code. If your problem is developers' own sessions breaking calls the team already made, use Campfyrr. Many teams on GitHub have both problems.
- Campfyrr vs Kawa Code: agents editing the same lines, or following different decisionsIf your agents keep editing the same lines as a teammate's, use Kawa Code: it flags overlapping uncommitted edits at the end of each turn. If your agents write different lines from different decisions, use Campfyrr: it briefs each session on what the team decided before it works. Many teams have both problems.
- Campfyrr vs Lore: show one agent run, or keep every session in stepIf you want to show a teammate exactly how one agent run went, use Lore. If your team's sessions keep building on decisions that changed this morning, use Campfyrr. Many teams have both problems.
- Campfyrr vs Slack Code and Linear: hearing what the agents assumed before it shipsIf you want to watch and steer one agent task where you already work, use Slack Code or Linear. If you keep finding out what the agents assumed only after it shipped, use Campfyrr. Many teams have both problems.
- Campfyrr vs Superconductor: share one agent run, or keep every run in stepIf you want product, design and engineering in the same agent run, watching and steering it together, use Superconductor. If your runs on the same product keep making calls that contradict each other, use Campfyrr. Many teams have both problems.
- Claude Code memory vs team memory: when CLAUDE.md and auto memory stop being enoughIf you work alone, or each person owns their own repository, Claude Code's CLAUDE.md, auto memory and Projects are enough: keep using them. If a second person's sessions change the same product, a call made in your session has to reach theirs the same hour, and that's what shared team memory like Campfyrr adds. Most teams start with the first and grow into the second.
- Memory MCP servers vs team memory: your agent's notebook, or your team's recordIf your problem is that your own agent forgets your preferences and project facts, use a memory MCP server: the good ones do it well, and some are free. If it's that your session can't see what your teammates' sessions decided, and why, you need a team's record such as Campfyrr. Many engineers have both problems.
- Sharing a session link vs sharing what sessions know: what does the next person need?If you want to show someone exactly how a run went, share the session: a Claude Code link, Lore or an exported transcript. If each new session starts without what the last one decided, tried and dropped, share what sessions know. Many teams need both.
For your role
- For engineering leads running a team on Claude CodeIf you lead a team on Claude Code, you are probably the router: sessions don't know about each other, questions wait for you, and pull requests arrive without their reasons. Campfyrr briefs every session, routes assumptions to the person who knows, and puts reasons on every change. A team can set it up in about an hour.
- For engineers running three or four sessions at onceIf you run three or four Claude Code sessions at once, Campfyrr works in the background: each session gets a brief on what the team knows the first time it reads or edits a part of the code, and a handoff is written when a session stops, so your next session opens on it. There's nothing to fill in.
- For founders: seeing the work without being the last reviewerA founder doesn't need to review every change an agent makes. With Campfyrr you read one plain-words page on what's in progress and what landed, answer the assumptions that are yours from a link, and put what customers told you where the agents will read it, on a free seat.
- For product managers: deciding clearly when agents build in hoursWhen agents build a feature in hours, a product manager's job is to decide clearly and early. Campfyrr lets you answer an agent's product assumptions from a link, put what you know on the part of the product it affects, and see what's being built in plain words, on a free seat.
- For QA and testers: getting into the loop at the plan, not the endWhen agents build, a tester's best moment is the plan, not the pull request. With Campfyrr you read each plan from a link before the work starts, answer the calls agents make while they build, and share test results as pages anyone can open. It doesn't run your tests and it isn't a test management tool.
Stories
- The feature nobody reviewed until the customer didWhen a feature is built and shipped in a day, the first person with the customer's context to see it is often the customer. Show the plan and a sample output to the person who knows the customers before it ships, and send them the agent's assumptions to answer in a line.
- The spec that got built exactly as writtenAn agent builds a one-line spec exactly as written, fast and well, and it still isn't what the product manager meant, because what she meant never left her head. Write the decision down with its reason, put the customer's words where the agent reads them, and read the plan before anything is built.
- The tester who saw it lastWhen testers first see agent-built work as a finished build, they can only find bugs, not prevent them. Publish the plan before the work starts, send the agent's assumptions to the tester, and let them answer from a link while the plan is still cheap to change.
Real examples from our own record
- Real example: a handoff, and how the next session picked it upOn 19 October 2026 a session building Campfyrr ran out of context mid-task. The handoff Campfyrr wrote named the right next step, and the session that continued did it and shipped in about two minutes. It also listed work as unfinished that was already done, so the useful habit is to check the branch first.
- Real example: the decision that replaced anotherOn 19 October 2026 our team replaced a four-day-old decision about how pages are found. The new decision was recorded, the old one was marked replaced, and the next session's brief opened with one line saying so, so no agent kept building on the call that no longer stood.
Field notes
Essay
What is VibeFlock? Building at agent speed
VibeFlock is how teams of people and AI agents build one product at agent speed, with context that travels with the work so nobody waits.
Principle
Turn unknowns into calls: how AI agents keep moving
When an AI coding agent hits something unclear, it shouldn't stop to ask. It should state an assumption, keep going, and let the team correct it.
Playbook
Build on what's coming: many AI agents, one codebase
How several AI agents can change one codebase at once without colliding: build against the plan of work in progress, and adjust when it lands.
How it works
How Campfyrr works: briefs, assumptions and handoffs
How Campfyrr carries context between people and AI agents: area briefs, stated assumptions, handoffs, reasons for every change, and one Activity page.
The seven principles, at length
- 1. Keep moving: work that never waitsAt agent pace, waiting is the most expensive thing a team can do. Why work should never stop for a person, and how context can move with it.
- 2. Build on what's coming: unfinished work is a promiseAt agent pace, waiting for work to finish is too late. How teams build on work in progress by its plan, and adjust in minutes when it lands.
- 3. Fix forward: correct the course, don't guard the gateAt hundreds of changes a week, quality comes from catching mistakes early and fixing them in the flow of work. What fix forward means, and its limits.
- 4. Turn unknowns into calls: nothing we don't know gets to stop usWhen an agent hits an unknown, it shouldn't stall or guess in silence. It should state its assumption and keep going. How that works, and its limits.
- 5. Answer it yourself: look first, then decideBefore asking a teammate, look where the team already wrote it down. If it isn't there, state an assumption or make the call that's yours.
- 6. Let the work speak: work that explains itselfWork isn't done when the code runs. It's done when the next person or agent can pick it up without asking: what it's for, what was decided, what's left.
- 7. Decide by doing: our decisions live in what we doMake the call in the work, say why in a sentence, and let that sentence travel to every person and agent who touches the same code.
Playbooks: how to work this way
- VibeFlock in two minutes: connecting Claude, Claude Code and CodexConnect Claude, Claude Code and Codex to one team record in two minutes, so every session starts knowing what the team is doing.
- Instructing agents to state assumptions and keep goingThe instruction that stops agents stalling: state the assumption in one line, mark the stakes, keep going, and let people correct it fast.
- Making a team's knowledge findable by every agentPut decisions, rules and handoffs in one record every agent searches first, written as lines with reasons, so nobody answers twice.
- Handoffs that write themselvesMake stopping the trigger and the agent the writer: a handoff of what's done, what's left and what to watch for, every time work stops.
- Working in parallel on dependent changesPublish the plan of the change underneath, build the change on top against it today, and adjust in minutes when the first one lands.
- Reviewing agent-made changes by their reasonsReview agent-written changes by reading their reasons first: check the calls, settle the assumptions, and fix forward instead of gating.
- Recording decisions as agents workRecord each call the moment it's made, in one line with its reason, where every agent reads it. Steps, agent instructions and the signals that it's working.
- Leading a team where everyone runs several agentsHow to lead when every person runs several agents: keep context moving, answer assumptions fast, pick up handoffs, and watch the flow, not the output.
- Measuring a team at agent pace: waiting, rework, pick-up timeMeasure what slows a team of people and agents down: waiting time, rework, pick-up time and late surprises. Each one points at a fix.
- Claude Code hooks for VibeFlockHow Claude Code hooks bring team context to every session: the moments that matter, how to write safe hooks, and what Campfyrr's work hook does.
- Codex, Cursor and other MCP clientsCodex, Cursor and other MCP clients get the same team tools but no hooks. How to connect them and which calls to make at each moment.
- Agent instructions for a never-blocked teamInstructions that keep agents moving: look first, state assumptions and continue, name high stakes, cover the moments agents stall, and test it.
Scenarios: a day of it, by the clock
- One feature, four people, twelve agentsA 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.
- A day of VibeFlock, minute by minuteOne developer, four agents, one working day: briefs, assumptions, corrections, landed work and handoffs, minute by minute, with nobody waiting.
- Joining a codebase that changes 200 times a dayA new developer joins a fast-moving codebase and ships on day one by looking first: briefs, the team's record, and assumptions answered from it.
- A weekend of agents, a Monday with nothing to catch up onAgents work through a weekend, handoffs write themselves when sessions stop, and Monday starts with nothing to catch up on. A made-up team, told by day.
- From idea to landed in one afternoonA made-up team takes one idea from first request to landed in an afternoon, recording each call as it's made and catching a clash the moment it happens.