The lead who took a day off
By Soumen Sarkar · October 2026
Story. If your team's agents stop whenever you're away, you're the human router. Have every session state its assumption and keep going, send each one to the person who knows, and keep only your own calls for when you're back.
What happens to the work when the lead is away?
This story is a scene, built from how teams work with agents today. What comes after it is real.
It's 8:30 on a Friday, and I'm sitting on the windowsill by Dev's desk. Maya, who leads this team of five, isn't here. She booked the day off a month ago: her daughter's school trip. Before she left last night she said, half joking, "Try not to need me."
Dev starts his morning the way he always does. He opens three Claude Code sessions. One adds late fees to invoices. One moves the reminder emails to a new sending service. One cleans up the customer import. I watch them read the code and write their plans, and they're quick and careful. Across the room, Sara and Priya start theirs.
At 9:10, the late fee session reaches something the code can't tell it. Should a late fee be added on top of a discount, or worked out from the full price? It asks Dev. Dev doesn't know. Maya made the billing calls. He types the question into the team's chat and tags her, out of habit.
At 9:40, Sara's session asks whether the new sending service may use the old reply-to address. Sara thinks Maya set that up. She tags Maya too.
By eleven there are six questions in the chat with Maya's name on them. Two are about billing. One is about the import, which Priya rebuilt in the summer, though nobody thinks to ask her. Three sessions sit still, each with a question on the screen and a cursor blinking under it.
At 12:15, Maya's phone lights up on a coach somewhere on the motorway. She answers two questions between a sandwich and a head count. The other four wait for Monday. When I leave at five, Dev's late fee change is where it was at 9:10.
Nobody did anything wrong. The agents asked good questions. Dev and Sara sent them where questions had always gone. It just happened that every road ran through one person, and that person was on a school trip.
I come back three weeks later. It's a Friday again, and Maya is off again. This time it's a long weekend.
The team has changed one thing. Every session has one more line in its instructions: when something is unclear, say what you're assuming, keep going, and record it where the team can see it. Each assumption goes to the person most likely to know, not to whoever started the session.
At 8:40, Dev opens his sessions. One of them is adding a refund button to invoices. At 9:05 it reaches a fork: may a refund be larger than what was paid, if a late fee was charged? I watch it write: "Assuming a refund can't exceed the amount paid, including late fees." Then it carries on. Before it goes to anyone, the team's record answers it. Maya recorded that exact rule in the spring, when late fees went in. The session reads the answer at its next turn, finds it already did the right thing, and moves on. Nobody's phone buzzes.
At 9:30, Sara's session, still on the sending service, writes: "Assuming bounced emails are retried once, then marked on the customer." The nearest decision about bounces is Priya's, so it goes to Priya. Her laptop pings. She reads it, frowns and corrects it in one line: "Twice, then marked. Some customers' mail servers are slow." The session reads her answer at its next turn and changes two lines.
At 10:15, an assumption about how to round tax on part-refunds goes to Maya. She made the tax call, so it really is hers. It sits there, quietly, and nothing waits on it. The session has finished the refund flow on its own assumption, marked as unconfirmed.
At 11, one goes to the whole team, because nobody has worked on the export screen yet. Dev picks it up between two coffees, answers it and turns it into a decision so the next session won't need to ask.
At five, Dev's refund change is ready for review. Sara's is merged. Priya is building on Sara's. I count the times anyone tagged Maya today. It's none.
On Tuesday morning, Maya opens the team's Activity page with her first coffee. I watch her read down it. One assumption is waiting for her: the rounding on part-refunds. The agent assumed rounding down; she wants it rounded to the nearest penny. She corrects it in a line, and the session that made it picks it up at its next turn. She reads Priya's correction about bounces and nods. She reads the decision Dev recorded about the export screen and leaves it alone.
It takes her nine minutes. Then she closes the page, opens a session of her own and starts building something she's been putting off for a month.
At 10, Dev wanders over with a question. It's not a question for an agent. It's about whether he should lead the next project. They talk for half an hour. It's the first long conversation I've seen them have.
Here's what I want you to notice
The agents were excellent both Fridays. In the first one, they did exactly what we ask of a careful colleague: they stopped and asked. What failed was the road the question took. Every road ran through Maya, so when Maya was away, the work stopped.
Look at who actually knew the answers. One was already in the team's record, written months ago. One belonged to Priya. One really did belong to Maya, and could wait four days without holding anything up. Very little of what was sent to Maya was Maya's.
If your team stalls when you take a day off, you aren't leading the work. You're routing it. Stop being the road every question travels on. Let your agents make the call out loud, and let the call find the person who knows.
And look at what Maya got back: a nine-minute Tuesday, and time for the conversation with Dev that no agent could have had.
What's the proof?
- A question stops the work until a person answers. In the Claude Agent SDK, a clarifying question goes through a callback that, in Anthropic's words, "pauses execution until you return a response", and "can stay pending indefinitely." That's the right design for one person with one agent. On a team, the work waits for whoever the question was sent to.
- Agents can carry far more on their own. Anthropic studied 200,000 of its own engineers' Claude Code sessions between February and August 2025. The longest runs of steps an agent took without a person went from 9.8 to 21.2, and the number of times a person stepped in fell from 6.2 to 4.1 per session (Anthropic, "How AI is transforming work at Anthropic"). The agents are ready to keep moving. The question is whether we let them.
- We work this way ourselves. The instructions in Campfyrr's own repository tell every session: "Turn unknowns into calls: when something is unclear, `stateassumption` with what you're assuming and keep going. Corrections arrive at a later turn."_
That's what Campfyrr does today. When a session states an assumption, Campfyrr first checks whether the team's record already answers it. If not, it sends the assumption to the author of the closest matching decision or rule. Failing that, it goes to the last other person who worked in that area, and otherwise to the team. Anyone can pass one on if it isn't theirs. The answer reaches the session at its next turn.
What it doesn't do: it doesn't make the call for you, and it doesn't replace your tracker or your planning. When nobody has worked in an area yet, the assumption goes to the whole team, and someone still has to pick it up.
What do I do on Monday?
- Add one line to your agents' instructions: "When something is unclear, state your assumption, keep going, and record it where the team can see it."
- Ask each teammate to record the calls they own as decisions, with their name on them.
- Stop forwarding questions to yourself by default. Send each one to the person who made the nearest call.
- Read the team's assumptions once a day, at a time that suits you.
- Confirm or correct each one in a line.
- Take a day off, and count how many sessions waited for you.
For the problem in full, read stop being the human router, and the short version in how do I stop being the human router? The playbook for agents that state assumptions has the exact wording, and what should an engineering lead look at each day? covers the morning read. The idea behind it is turn unknowns into calls.
The problem this answers: The human router: "I'm the human router. Sessions stop to ask, and the questions wait for me."
The principle behind this: Turn unknowns into calls: Nothing we don't know gets to stop us. We name our assumption, and we move.
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).