By Soumen Sarkar · October 2026
Short answer: 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.
What does coordinating agents need to cover?
Four things. Changes have to stay apart while they are made, every change has to be checked, agents have to follow the same conventions, and each agent has to know what the others are doing and have decided. The first three are well covered by tools most teams already run. The fourth is where agents collide.
- Git branches and worktrees keep each session's files apart. A worktree per session lets several agents edit the same repository at once without stepping on each other's working copy.
- CI runs tests and checks on every change, so a broken build is caught whichever agent wrote it.
- Instruction files, CLAUDE.md for Claude Code and AGENTS.md for Codex and others, give every session the same stable conventions and behaviour.
- An issue tracker holds what the team intends to build.
- A shared context layer carries what changes during the day: decisions with reasons, work in progress with its plan, open assumptions, and handoffs. It is usually reached through MCP, so every client can read and write it.
Where do the gaps show up?
Take a hypothetical team of three developers running nine agents on a product analytics dashboard. One agent is renaming events in Analytics · lib/analytics from page-view style names to object-action names, such as report_opened. Another, started by a different developer, is building a new funnel chart that reads those events.
Git keeps their files apart, so there is no conflict to resolve. CI passes on both changes, because each is correct on its own. The instruction files say nothing about this rename, because it is a decision of the week, not a standing rule. So the funnel agent builds on the old event names, and the chart shows zero once the rename lands.
With a shared context layer, the funnel agent is told about the rename in progress and its plan before it writes a query. It builds on the new names, states one assumption about a name the plan doesn't list, and the chart works the day both land.
How do I choose a context layer?
Ask three questions of anything you consider:
- Does it reach every agent you use, not just one client?
- Does context arrive without being asked for, at session start and before an agent touches an area?
- Does it keep work moving, or does it add a step where someone has to approve or reply?
Where does Campfyrr fit?
Campfyrr is a shared context layer for this. It works through MCP with Claude, Claude Code, Codex, Cursor and other clients, and in Claude Code its hooks bring the context in automatically. It sits alongside the rest: it doesn't read your code, run CI, assign work, integrate with Jira or Linear, or replace git.
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.
- Team record: The team record is everything a team has written down that a person or agent can search before asking: decisions, rules, handoffs, assumptions and the reasons behind changes.
- Assumption: An assumption is the best available answer to an unknown, stated and acted on, kept visible so anyone can correct it.
- Handoff: A handoff is what unfinished work carries for whoever continues it: what's done, what's left, the next step, and what to watch out for.
The principle behind this: Keep moving: The work never waits, and neither do we.
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).