Agent instructions for a never-blocked team
By Soumen Sarkar · October 2026
Playbook. Instructions that keep agents moving: look first, state assumptions and continue, name high stakes, cover the moments agents stall, and test it.
What instructions keep agents from ever blocking?
Tell agents three things: what to do instead of stopping, which few calls deserve extra care, and what to leave behind when they stop. Instead of stopping, an agent looks for the answer, and if it isn't there, states an assumption and keeps going. The calls that deserve extra care are the high-stakes ones: data, money, access, public interfaces and deleting things. And whenever it stops, it leaves a handoff. Write those once, in the file every agent reads at the start, and agents stop stalling on unknowns.
This playbook is about writing those instructions well, covering the situations where agents usually stop, and testing that they hold.
Who is this for?
Anyone who writes CLAUDE.md, AGENTS.md or an agent rules file for a team: tech leads, and developers who run several sessions and are tired of coming back to find one waiting on a question.
What do you get?
- Agents that keep moving through unknowns, with every assumption written where someone can correct it.
- Clear handling for the situations that usually stall a session: missing requirements, unfinished dependencies, failing tests, clashing instructions.
- A way to test your instructions and tune them from what agents actually do.
Why do agents block?
Most agents stop for one reason: they hit something they don't know, and their default is to ask. With one agent and a person watching, asking is cheap. With a person directing four sessions, each stop is a session idle until someone notices, and the person spends the day answering instead of directing.
The fix isn't telling agents to guess. Guessing in silence is worse than stopping, because nobody can correct what they can't see. The fix is turn unknowns into calls: make the best call available, say it plainly, and keep going, so someone who knows better can set it right without stopping anyone.
Step 1: Start from the working agreement
Begin with the team agent instructions template. It covers the core: look first, state assumptions and keep going, build on work in progress, record decisions with reasons, leave a handoff, and let the change explain itself. Fill in where your team keeps decisions, assumptions and handoffs.
Everything below adds to it. Keep the template's lines short; agents follow short, concrete instructions better than long, careful ones.
Step 2: Name your high-stakes list
"Be careful with risky changes" means nothing to an agent. Name the areas and kinds of change that count as high stakes in your codebase:
- Data: migrations, anything in
db/migrations, anything that changes what's stored. - Money: Billing · lib/billing, prices, refunds, invoices.
- Access: Auth · lib/auth, permissions, tokens.
- Public interfaces: anything under
app/api, webhooks, exported types. - Deleting things: any delete, overwrite or cleanup of real data.
High stakes doesn't mean stop. It means the assumption is marked high stakes so the right person sees it first, and the agent builds so the hard-to-undo step is the last one and easy to hold back.
Step 3: Cover the situations where agents stop
These are the moments that most often stall a session. Give each an instruction:
When you'd normally stop, do this instead:
- The request is ambiguous. Pick the reading that fits the code and the record
best, state it as an assumption with the other likely readings, and build that.
- You need work someone else hasn't finished. Read its plan and build against it.
Say which plan you built on. If there's no plan, state what you expect it to
look like and build against that.
- A test fails in an area you aren't changing. Don't fix it around your work and
don't stop. Note it in your handoff under "watch out for", and keep going on
your part.
- The request conflicts with a decision or rule that stands. Do what the person
asked, say so plainly, and name the decision. Don't silently follow either one.
- You need a credential, access or a person's sign-off you don't have. Build
everything that doesn't need it, leave the step that does clearly marked, and
state it as a high-stakes assumption.
- The change deletes or overwrites real data. Build it so the destructive step
runs last and can be held back, mark the assumption high stakes, and keep going
on the rest.
- You're running out of context or the session is ending. Leave a handoff: done,
unfinished, next step, open questions, traps, and what you tried and dropped.
Step 4: Say what a good assumption looks like
Agents state better assumptions when they've seen one. Add a single example, from your own codebase, in the shape of the assumption line. For instance: an agent adding annual plans in Billing · lib/billing assumes "upgrades from monthly to annual are prorated to the day, because the existing plan-change code already does that", with "prorated to the day | charged in full | credited at renewal" as likely answers, stakes high because it's money.
Also say what doesn't need one. Choices the code already makes obvious, naming, and formatting don't. Without this line, some agents state an assumption for every small choice, and the real ones get lost.
Step 5: Say where things go
Every instruction that says "write it down" needs a place. Name it in the instructions:
- Assumptions: in the pull request description under "Assumed", or in the team record.
- Decisions: in the area's decisions file, or the team record.
- Handoffs: in the pull request description under "Handoff", or the team record.
An agent told to "record its assumption" with nowhere named will write it in its reply to you, and it's gone by the next session.
Step 6: Put it where every client reads it
Claude Code reads CLAUDE.md. Codex reads AGENTS.md. Other clients have their own rules or instructions file. If your team mixes clients, keep one source and copy it into each, or point each file at a shared one. Personal instruction files should add to the team's, never contradict it. What goes in CLAUDE.md, AGENTS.md and team memory goes into what belongs where.
Step 7: Test the instructions
Instructions are code; test them. Give an agent a task with a deliberate gap, such as "add a cancellation reason to subscriptions" without saying whether it's required, and watch what it does:
- Did it look first for a decision or earlier work?
- Did it state an assumption, with likely answers and stakes, where you said?
- Did it keep going, or stop and ask?
- If you then correct the assumption, does it change course and say what it changed?
- If you end the session halfway, is there a handoff?
Run the same test after you change the instructions. When an agent still stops, read what it was unsure about and add a line that covers it.
How do you keep the instructions current?
Treat the file like any other shared code. Change it in a pull request, with the reason in the description, so the team sees why a line was added or cut. When a correction to an agent's assumption reveals a gap, such as an agent that kept assuming refunds go to account credit, add the line that would have prevented it, then check the next few sessions follow it.
Read the instructions again whenever the team's areas change. A new area that handles money or access belongs on the high-stakes list the day it appears, not after the first wrong assumption about it. And when two people's sessions behave differently, compare their personal instruction files before anything else.
What should you watch for?
- Stopping anyway. Some agents still end a turn with a question. Strengthen the line: "Never end a turn on a question the record could answer or an assumption could cover."
- Silent guessing. An agent that keeps going without stating what it assumed is the worst outcome. Check that assumptions are being written.
- Assumption noise. Dozens of trivial assumptions hide the few that matter. Tighten "what doesn't need one".
- High stakes ignored. If assumptions about deleting data or changing prices aren't marked high stakes, name those areas more concretely.
- Instructions that grow. Long files get skimmed. Every few weeks, cut what agents already do well.
How do you know it's working?
- You come back to sessions and find them finished or handed off, not waiting.
- Assumptions appear where you said they would, and most are confirmed without changes.
- Corrections lead to a change of course and a line saying what changed.
- High-stakes assumptions are answered first, by the right person.
- People spend less time answering agents and more time directing them.
What does Campfyrr automate?
Campfyrr gives these instructions tools to call, and sends a version of them to every client that connects.
- The server's own instructions. Every MCP client gets them on connect: read what the team knows before changing code, state assumptions and keep going, say what you're working on, depend on unfinished work with
wait_on, hand off or finish when you stop, write the reasons at commit. Running the /connect setup with --repo also adds a short note to CLAUDE.md. - Assumptions.
state_assumption takes the question, the assumption, likely answers and the stakes. If the team's record already answers it, the answer comes straight back. Otherwise it goes to whoever made the closest decision or last worked in that area, and it shows in the Activity feed with an "Answer it" link to its own page, with one-click answers: "Right, keep going", the likely answers, "Correct it…" or "Not mine to check". High-stakes ones are marked and shown first; if the agent leaves the stakes out, they're guessed from the words. The agent keeps going either way. - Corrections. In Claude Code, a correction reaches the agent at its next turn through the hooks. Other clients get it when the agent calls
session_inbox. - Dependencies.
wait_on returns the plan of matching work in progress to build against, and tells the agent what actually landed when it finishes. - Stopping. In Claude Code, a handoff is written from the session when it stops, compacts or ends.
Campfyrr doesn't approve or block anything. An agent that keeps going on a high-stakes assumption is still building; the person who knows sees it first and can correct it.
For the shorter answers, see how to stop Claude Code from stopping to ask questions and whether an agent should assume or ask.
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).