Answers: building with many AI agents, as one team
By Soumen Sarkar · October 2026
The questions teams ask when every developer runs several agents on one codebase, each answered in the first two sentences. Grouped by the VibeFlock principle it shows.
Keep moving
- How do teams build one product with many AI agents at once?: Teams build one product with many AI agents by making context travel with the work: each agent learns what is changing around it before it touches code, states its assumptions instead of stopping, and leaves its reasons and a handoff when it stops. That way every person and agent builds on everyone else's work without waiting.
- What does a team need when every developer runs several agents?: A team where every developer runs several agents needs four things: a record of decisions every agent can search, a brief for each agent before it changes code, a way to state assumptions without stopping, and a handoff whenever a session stops. Each one lets an agent keep going without pulling a person away from their other sessions.
- How do AI agents keep working while teammates are offline?: AI agents keep working while teammates are offline when the answers those teammates would give are already written down, and when the agent can state an assumption and carry on wherever they aren't. The teammate settles the assumption when they're back, and the correction reaches the agent at its next turn.
- How do I run several Claude Code agents in parallel without supervising each one?: Give each parallel Claude Code session one clear goal, the context it needs when it starts, and a standing instruction to state assumptions and keep going instead of stopping to ask. Then check on the sessions through what they leave behind, their assumptions and handoffs, rather than by watching each terminal.
- What should an agent know before it starts work in a shared codebase?: Before it changes shared code, an agent should know what is being changed in that part of the code right now, the decisions that stand there, what changed recently, what was tried and dropped, and which assumptions are still open. Together that is an area brief, and it belongs in the agent's context before its first edit.
- How do I give every agent session context automatically?: Give every agent session context automatically by loading it at fixed moments instead of relying on the agent to fetch it: a brief of the team's state when the session starts, a brief for each part of the code the first time the session touches it, and news at each turn. In Claude Code, hooks run at exactly those moments.
- What are Claude Code hooks useful for in a team?: In a team, Claude Code hooks are most useful for moving context without anyone having to remember: loading the team's state when a session starts, briefing it on each part of the code it touches, attaching reasons to commits, and writing a handoff when the session stops. Hooks are shell commands that Claude Code runs at fixed points in a session.
- What tools help teams coordinate many AI coding agents?: Teams coordinate many AI coding agents with a few kinds of tools working together: git branches or worktrees to keep changes apart, instruction files like CLAUDE.md and AGENTS.md, CI to check every change, and a shared context layer, usually over MCP, that carries decisions, work in progress, assumptions and handoffs between sessions. The last one is what lets agents build on each other's work instead of around it.
- How do I measure a team that works with AI agents?: Measure a team that works with AI agents by how freely work flows, not by how much code it produces: watch waiting time, rework, pick-up time and late surprises, because those are what slow a team down when everyone runs several agents.
- How many agents can one developer run well?: There's no fixed number: one developer can run as many agents as they can keep unblocked and whose results they can absorb, which depends on how independent the tasks are and how much the agents can settle without them. Add agents until waiting or rework starts to rise, then stop.
- What is VibeFlock?: VibeFlock is a way of building one product with a team of people and AI agents at agent pace, where context travels with the work so nobody waits. It rests on seven principles, and the name was given to it by Campfyrr.
- What's the best way to run a software team where everyone uses AI agents?: Run it so nothing waits on a person: every agent starts knowing what's changing around it, states its assumptions instead of stopping to ask, and leaves its work explained when it stops. Your job as a lead becomes keeping context moving, not handing out permission.
- How do async, high-trust teams work with AI agents?: The same way they work with each other: work is written down where everyone can see it, decisions travel with their reasons, people act on the team's updates without waiting to be told, and anything reversible is decided on the spot. Agents fit that way of working better than any tool before them.
- How do customer requests reach AI coding agents quickly?: Put the customer's own words where the agents and the product owner can both read them, let the product owner confirm the intent in a line, and let an agent build from that. The request stops queueing behind meetings and starts moving at agent pace.
- Do Claude Code's projects, auto memory and agent teams work across a whole team?: Not yet: they work across one person's sessions. Projects belong to one user, auto memory stays on one machine, cross-session messaging reaches only your own sessions, and an agent team lives inside one session. A team needs a shared layer on top that every teammate's sessions read and write.
- How do I set up Claude Code for a team of 5 to 15 developers?: Give everyone the same short CLAUDE.md, one shared memory for what changes by the hour, and the same three instructions: state assumptions instead of stopping, record decisions as you make them, and leave a handoff when you stop. Then run parallel sessions in worktrees, and review by reasons.
Build on what's coming
- How can two agents work on dependent changes at the same time?: 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.
- How do I know when work I built on has landed, and what changed?: You know when work you built on has landed by subscribing to it while it's in progress, so you're told when it finishes and shown what it turned out to be compared with its plan. Then you adjust only the difference.
- How do I avoid two agents changing the same thing in different directions?: You avoid two agents changing the same thing in different directions by making work in progress visible where it lands: every agent that touches a part of the code first sees who else is changing it now, with what goal and plan, and builds on that instead of around it.
- Do git worktrees stop parallel AI coding agents from conflicting?: Git worktrees stop parallel agents from editing the same files at the same time, but not from building in different directions. Each agent also needs to know what the others are changing, what was decided and what they assumed.
Fix forward
- How should I review a pull request an agent wrote?: Review an agent's pull request by its reasons first: check what it's for, the calls it made and what it assumed, spend your attention on the high-stakes ones, and fix what you find forward instead of holding the change at the gate.
- What happens when an agent's assumption turns out wrong?: When an agent's assumption turns out wrong, someone who knows corrects it, the correction reaches the agent (or whoever continues its work), and the agent changes course and says what it changed. Because the assumption was stated, the fix is small and nobody had to stop.
- How do teams keep quality high at hundreds of changes a week?: Teams keep quality high at hundreds of changes a week by putting their attention where mistakes are expensive, making every change carry its reasons, catching wrong calls early while they're small, and fixing forward in the flow of the work instead of slowing every change at the gate.
- What should an engineering lead look at each day?: An engineering lead should look at what needs them first: assumptions in their areas, decisions that replaced earlier ones and handoffs nobody has picked up. Then what landed, so mistakes are caught while they're small and fixed in the flow of the work.
Turn unknowns into calls
- How do I stop Claude Code from stopping to ask questions?: Tell Claude Code, in its CLAUDE.md, to state a working assumption and keep going whenever something is unclear, and to stop only before actions that can't be undone. Then give those assumptions somewhere visible to go, so a person can correct them later without the session ever waiting.
- Should an AI coding agent assume or ask?: An AI coding agent should assume and keep going in almost every case, as long as it states the assumption plainly where someone can correct it. It should look first, because the answer is often already written down, and when the assumption is high stakes it should still keep going but choose the option that is easiest to reverse.
- How do I see what my agents assumed?: You see what your agents assumed by having them write each assumption down as they make it, in one place outside the session, with its reason and stakes. Then you review that list, highest stakes first, and correct only the ones that are wrong.
- Which calls should an AI agent never make alone?: An agent should state its assumption and keep going on anything reversible, but irreversible or high-stakes actions, such as deleting data, moving money, changing access or breaking a public interface, deserve a person's look before they take effect. The aim is to make the cost of being wrong visible, not to stop the work.
- How do I stop being the human router for my team's AI agents?: Stop carrying context between people by hand. Let agents state their assumptions and keep going, route each assumption to whoever should answer it, record decisions where every session reads them, and brief each session on its area before it starts. You answer the calls that are yours, in a line, when it suits you.
Answer it yourself
- Where should a team's decisions live so every agent finds them?: A team's decisions should live in one searchable record that every agent can read, each written as a one-line call with its reason at the moment it is made and tied to the part of the code it governs. Then any agent can search for them, and each agent can be handed the decisions for the area it is about to change.
- What goes in CLAUDE.md, AGENTS.md and team memory?: CLAUDE.md and AGENTS.md hold the stable instructions for working in a repository: how to build and test, conventions, and how agents should behave. Team memory holds what changes every day: decisions with their reasons, work in progress, open assumptions and handoffs, searchable by every agent.
- How do agents search what the team already decided?: Agents search what the team already decided by calling a search tool over the team's written record, usually connected through MCP, before they make a call of their own. Search works best when each decision is short, carries its reason, and names the part of the code it applies to.
- What is MCP and how does it connect agents to a team?: MCP, the Model Context Protocol, is an open standard that lets AI apps and coding agents call tools and read data from outside services through one kind of connection. For a team, an MCP server can give every person's agents, in Claude, Claude Code, Codex or Cursor, the same shared context and the same tools.
- How do I onboard someone onto a codebase built by agents?: Onboard someone onto an agent-built codebase by giving them the record of why the code is the way it is (decisions per area, what's changing now, what was tried and dropped) and letting them, and their agents, look things up instead of asking. Start them on real work in one area.
- How do I share context between Claude Code, Codex and Cursor?: Keep the team's context in one place that every tool can reach over MCP, and let each tool's own file (CLAUDE.md, AGENTS.md, Cursor rules) hold only the stable instructions. Decisions, assumptions and work in progress change too fast to live in files that each tool reads separately.
- How do I share memory across my team's Claude Code sessions?: Connect every teammate's Claude Code to one shared memory the sessions read and write as they work: what's being changed in each part of the code, what was decided, and what was assumed. CLAUDE.md holds the stable rules; the shared memory holds what changes by the hour.
Let the work speak
- How does an AI agent hand off unfinished work?: An AI agent hands off unfinished work by leaving a short note with the work when it stops: what's done, what's left, the next step, the open questions and the traps. Whoever continues, person or agent, starts from that note instead of from the agent's transcript.
- How do I continue another developer's agent session?: You continue another developer's agent session from its handoff, not its transcript: start a fresh session, give it the handoff and the area's recent decisions, and do the next step it names. The original developer doesn't need to be online.
- How do reviewers see why an agent made a change?: Reviewers see why an agent made a change when the change carries its reasons: what it's for, the calls made in it, what was assumed and what was tried and dropped. Those reasons go in the pull request description, written for the reviewer.
- How does a team stay in step across time zones with agents?: A team stays in step across time zones by making the work explain itself: every session leaves a handoff, every change carries its reasons, and every assumption is written down where the next person sees it. Then nobody waits for someone else to wake up.
- What makes a good handoff from an AI agent?: A good handoff lets the next person or agent start within a minute without asking anything: it is specific about what's done and what isn't, names one concrete next step, and records the assumptions and traps that aren't visible in the code.
- What is multiplayer AI coding?: Multiplayer AI coding is a team of people and AI agents building one product together, where everyone, including product managers, designers and support, can see, steer and build on the agents' work as it happens, instead of one developer driving one agent alone.
- Why has code review become the bottleneck with AI agents?: Agents now write changes faster than people can read them, so the slowest step is a person working out what a change is for and whether it's right. Review speeds up when every change arrives with its reasons, assumptions and the decisions it relied on.
- How can product managers and the rest of the business keep up with what AI agents are building?: Give them the agents' work in plain words, as it happens: what changed and why, what was assumed and needs a business answer, and what landed today. Then let them answer in a line where the agents will read it, instead of waiting for the next meeting.
- Should our team share Claude Code sessions, or share what the sessions know?: Share what the sessions know. A shared session is a record someone opens after the work is done; shared memory reaches the next session while it works, without anyone sharing anything. Session-sharing tools such as Lore and Claude Code's own share links do the first; Campfyrr does the second.
- How do I show non-technical teammates what our Claude Code agents are building?: Publish it to them in plain words, with a link: plans before the work, test results and sample outputs as it lands, and a short daily update. Let them answer the questions that are theirs from the same page, so their answer reaches the agents too.
- How do I share a plan, test results or a sample output from Claude Code with one link?: Ask the session to publish it: it writes the point first in plain words, puts the detail underneath, and turns it into a page with a link your team can open. With Campfyrr installed, that's the publish command or simply asking Claude to publish it.
- Should we write docs and agent instructions in ASD-STE100 (Simplified Technical English) or Markdown?: Both, because they do different jobs. Markdown decides how a page looks; ASD-STE100 decides how its sentences are written: short, one instruction at a time, active voice, one meaning per word. Write the file in Markdown, and the procedures, rules and warnings in it in STE.
- ASD-STE100 or Markdown? The same answer, written in Simplified Technical English: Markdown controls the layout of a page. STE controls the words and the sentences. Use the two together. Write the file in Markdown. Write the procedures, rules and warnings in STE.
Decide by doing
- How do I capture decisions my agents make?: Capture your agents' decisions by having them record each call in one sentence, with its reason, at the moment they make it, in a place every other agent searches. A decision written after the fact is usually missing the reason.
- What happens when two agents decide opposite things?: When two agents decide opposite things, the clash should surface the moment the second decision is made, with both calls and what relies on each, so one call stands and the agent on the other side changes course while the fix is still small.
- How do decisions reach every agent that touches the same code?: Decisions reach every agent that touches the same code when they're tied to that part of the code and delivered the first time an agent reads or edits it, before it writes anything, rather than waiting for the agent to think of searching.
- Why does our team's CLAUDE.md keep growing while agents still miss what we decided?: Because CLAUDE.md is being used for two jobs: stable instructions, and the team's running decisions. Every session reads the whole file whatever it's working on, and new decisions reach it only when someone edits it. Keep CLAUDE.md short and stable, and give decisions a live, per-area home that sessions are briefed from.
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).