Leading a team where everyone runs several agents
By Soumen Sarkar · October 2026
Playbook. How to lead when every person runs several agents: keep context moving, answer assumptions fast, pick up handoffs, and watch the flow, not the output.
How do you lead a team where everyone runs several agents?
You lead by keeping the work flowing. Your job is to make sure context reaches every session without a person carrying it, that nothing sits waiting on a human for long, and that the calls being made are visible enough to correct while they're still small. Most of your day goes on the few things only a person can settle; everything else should move without you.
This playbook is a set of habits you can start this week, with any tools.
Who is this for?
Tech leads and engineering managers whose people each run two, three or more agents at once: Claude Code sessions, Codex, Cursor. Picture a four-person team running twelve agents between them, shipping dozens of changes a day into one codebase. That's the pace this is written for.
What do you get?
- A team where nobody stops to wait for you, and you can see that nobody is waiting.
- Assumptions answered quickly, with the risky ones answered first.
- Unfinished work that someone picks up the same day, instead of going stale.
- A clear view of where the work is held up, without a meeting to find out.
What changes about the lead's job?
At agent pace, the team's output stops being the constraint. Twelve agents produce more changes than any person can read line by line. The constraint becomes context: does each session know what the others are doing, what was decided, what was tried? And it becomes response time: when an agent states an assumption only a person can check, how long until someone checks it?
So the lead's work shifts. Less assigning and approving, more keeping context moving and answering the calls that need a human. The keep moving principle puts it as a promise: nobody stops the work to wait for anybody else.
Step 1: Write the working agreement once
Agree how the team works, write it down, and put it where every agent reads it at the start of a session. The team agent instructions template is a good base: look first, state assumptions and keep going, build on work in progress, record decisions with reasons, leave a handoff, let the change explain itself.
Then make it concrete for your codebase: where decisions live, which areas count as high stakes, where handoffs go. Agent instructions for a never-blocked team goes through tuning it.
Step 2: Give every area someone who answers for it
Split the codebase into areas and give each one a person whose calls stand there. Not an owner who approves changes, but the person an assumption goes to when the record doesn't answer it. For example:
- Billing · lib/billing: Priya
- Search · lib/search: Tom
- Onboarding · app/onboarding: Ana
Write this down where agents can see it. Then, when an agent working in Billing assumes "refunds go back to the original card, not to account credit", it knows Priya is the one to check, and Priya knows the assumption is hers to answer.
Step 3: Make work in progress visible
Every session that starts something others might touch says what it's for, its plan, and when it should be done. A line at the top of the pull request draft, a note in the area summary, or a shared list all work. What matters is that a second agent arriving in the same area sees the work in progress and builds on it rather than around it.
This is the single habit that prevents the most rework. Two agents changing the invoice model in different directions on the same afternoon is a lead's problem; two agents where the second one read the first one's plan is not. Working in parallel on dependent changes covers how to build against a plan.
Step 4: Answer assumptions fast, risky ones first
Your team's agents will state assumptions all day. Most will be right. Some will be wrong, and the earlier a wrong one is corrected, the less work is built on it.
Make answering a short, frequent habit rather than a block of time:
- A few times a day, read the assumptions that need a person.
- Start with the high-stakes ones: anything touching data, money, access, public interfaces or deleting things.
- Confirm with a word, or correct with a sentence and a reason.
- Pass on anything that isn't yours to the person whose area it is.
Instructing agents to state assumptions and keep going sets up the agent side.
Step 5: Make sure handoffs get picked up
When a session or a person stops before the work is done, the handoff should be picked up within the day. A handoff nobody continues is work in progress that has quietly stopped, and the people building on it don't know.
Check once a day for handoffs nobody has continued, and either pick them up yourself, ask someone to, or close them with a reason. Handoffs that write themselves covers making them worth picking up.
Step 6: Check clashing decisions the same day
When two people or agents make opposite calls, only one can stand, and checking it's the right one is a lead's job. It's urgent: until it's clear, work built on either side is at risk. Make sure the call that stands is the one that holds, mark the other superseded with a reason, and tell whoever built on the one that was replaced.
Step 7: Review by reasons
At this volume, reviewing every line isn't possible, and pretending otherwise slows everything down. Ask every change to carry its reasons: what it's for, the calls made, what was assumed, what was tried and dropped. Review those first, and read the code where the reasons point. Reviewing agent-made changes by their reasons has the details.
What should a lead's day look like?
A rhythm that works for many teams:
- Start of day: what needs you: assumptions to check, decisions that replaced others, handoffs not picked up.
- Through the day: short checks for new assumptions, high stakes first. No standing meetings needed for status; the work shows it.
- End of day: read each person's short written update of what changed and why, in plain words.
- Once a week: look at how the work is flowing. Measuring a team at agent pace covers what to look at.
What instructions should agents get?
On top of the team's working agreement, a few lines help a lead keep the flow visible:
- When you start work others might touch, write its goal, plan and expected
finish where the team can see it.
- When something only a person can decide stops part of your work, state it as an
assumption, mark it high stakes if it is, and keep going on everything that
doesn't depend on it.
- Say who your assumption is for: the person whose area it touches.
- When you stop unfinished, leave a handoff. When you finish, say what landed and
how it differs from the plan.
What should you watch for?
- You as the bottleneck. If every assumption routes to you, the areas aren't split well. Move answering to the people closest to the code.
- Silent agents. An agent that never states an assumption is usually guessing without saying so. Ask to see what it assumed.
- Handoffs piling up. A growing list of unpicked handoffs means the team has more work in flight than it can carry.
- Decisions in chat. A call made in a message thread is lost by the next session. Ask for it in the record, with the reason.
- Measuring output. Counting merged changes tells you little when agents write them. Watch waiting, rework and pick-up time instead.
- Too many agents per person. The limit is how many sessions' assumptions and reviews one person can keep up with. How many agents one developer can run well goes into it.
How do you know it's working?
- You can say what everyone is working on without asking anyone.
- Assumptions get answered within hours, and high-stakes ones first.
- Handoffs are picked up the same day.
- Clashing decisions are found and settled before both sides ship.
- Your day has more time for the hard calls, and less for status.
What does Campfyrr automate?
Campfyrr gives each project one Activity page that holds most of this playbook.
- One feed. Decisions, actions and status updates, each written as what happened and why it matters. People react to updates; nothing waits on a button. Agents can call
needs_my_action to mention what's new since you last looked. - Filters. Type (Decisions, Actions, Status updates), Person, Area, and Since, including "your last visit".
- Work in progress. Shown in the feed with its goal. In Claude Code, a session's first request becomes the goal of its work in progress on its own.
- Assumptions. Each goes to whoever made the closest decision or last worked in that area, and shows in the feed with an "Answer it" link to its own page, where anyone answers in one click: "Right, keep going", the likely answers, "Correct it…" or "Not mine to check", which passes it on. High-stakes ones are marked. The agent keeps going either way.
- Handoffs. Written from the session when Claude Code stops, compacts or ends, and shown in the feed as work paused partway, with its next step. Your own next session opens with yours; to take over a teammate's, paste it into your first prompt.
- Clashes. The newer call stands on its own, the earlier one is marked superseded, and the feed shows the change.
- This week. A "What Campfyrr caught for your team this week" card on top: wrong assumptions caught, clashes caught, questions answered from the record, handoffs picked up and how fast. A "Where are we?" link gives a plain-words view of the project.
- Daily updates. Written in plain words from each person's work log at their end of day, with optional Slack per project.
Campfyrr doesn't assign work, approve or block changes, or read your code. The calls stay with the team; Campfyrr keeps them visible.
Leading this way is the keep moving principle applied to the person whose attention is scarcest: the work moves, the context moves with it, and the lead's time goes to the calls that truly need a person.
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).