Instructing agents to state assumptions and keep going
By Soumen Sarkar · October 2026
Playbook. The instruction that stops agents stalling: state the assumption in one line, mark the stakes, keep going, and let people correct it fast.
How do you get agents to state assumptions and keep going?
You tell every agent, in its standing instructions, that when it hits an unknown the team's record doesn't answer, it writes one line (what it's assuming, the likely answers, and the stakes), acts on it, and keeps going. Then you give the people who know the answers a fast way to confirm or correct those lines, so a wrong guess is caught while the change is still small.
That's the fourth VibeFlock principle in practice: nothing we don't know gets to stop us. An agent that stops to ask is holding a half-finished change while the code around it moves. An agent that guesses in silence leaves a trap. A stated assumption is neither: the work moves, and the guess stays visible.
Who is this for, and what do you get?
It's for anyone running several agents at once who keeps finding sessions parked on a question, or finding out in review that an agent quietly decided something it shouldn't have. It works with Claude Code, Codex, Cursor or any other agent, because most of it is instructions and habits.
What you get:
- Sessions that finish their work instead of waiting for you to come back to the terminal.
- Every guess written down where a person can see it, with the likely answers already listed.
- Corrections that take a sentence, because the agent said exactly what it assumed.
- High-stakes guesses (money, data, access) seen first, every time.
What does a good assumption look like?
A good assumption is one line a busy person can settle in seconds. It says what the agent is doing, not just what it's wondering. Here's one from a hypothetical team working on Notifications · lib/notifications:
Assumption: the daily digest goes out at 9am in each recipient's own timezone.
Likely answers: recipient's timezone | the team's timezone | UTC
Stakes: normal
Built on it: scheduleDigest() and the "next digest" label in settings
Whoever owns notifications can answer that with a word. If the answer is "the team's timezone", the agent changes one function and one label, not a week of work built on a silent guess.
Compare a high-stakes one, in Workspaces · lib/workspaces:
Assumption: deleting a workspace also deletes its exported files.
Likely answers: delete them | keep them 30 days | keep them until the owner deletes them
Stakes: high: deleting things
Built on it: deleteWorkspace(), behind one helper so it is easy to change
The agent still keeps going. It builds the deletion behind a single helper, so whichever answer comes back, the change is small. The full block, with every field explained, is the assumption line template.
The steps
- Say where the record is. Agents can only "look first" if they know where to look. Name the place in the instructions: the team's decision log, the area summaries, the open pull requests. If the answer is there, there's no assumption to make.
- Add the instruction. Put it in CLAUDE.md, AGENTS.md or your agents' rules file, so every session gets it from the first turn. The wording is below.
- Define high stakes, once, for the whole team. Data, money, access, public interfaces and deleting things. Agents mark those lines "high", build them so they're easy to change, and people read them first. Everything else is normal.
- Decide where the lines go. Without a tool, the simplest place is the pull request description, under a heading like "Assumed (not confirmed)", plus a line in the area's notes. The point is one place a person can scan.
- Route each line to someone who can answer it. That's whoever made the closest decision in that area, or whoever last worked there. If nobody obvious owns it, the team lead takes it.
- Settle them in the flow of the day. Read new assumptions when you come back to your desk, high stakes first. Confirm with a word, or correct with a sentence. Don't save them for a meeting.
- Close the loop. A correction is only useful if it reaches the agent that made the guess. The agent then fixes forward and says what it changed. If the answer will matter again, record it as a decision so the next agent finds it instead of assuming.
What does the person's side look like?
The people answering assumptions matter as much as the agents stating them. If answers are slow, agents keep building on guesses longer than they should, and corrections get bigger.
Make it light. Someone who owns an area checks new assumptions there a few times a day, in the gaps between their own work, the way they'd glance at messages. Each one takes seconds: the assumption is stated, the likely answers are listed, and confirming is a word. A correction is one sentence with the reason: "Team's timezone, because digests summarise the team's day, not the reader's."
If an assumption isn't theirs to answer, they pass it to someone who knows rather than guessing. And if the same kind of assumption keeps coming up, they write the answer down once, as a decision, so agents stop needing to assume it.
What should you tell your agents?
Paste this into your standing instructions and adjust the places in angle brackets:
## Unknowns: state them and keep going
When something is unclear, first search <where the team's record lives>.
If the answer is there, follow it.
If it isn't, do not stop to ask. Write one assumption line:
what you're assuming, the likely answers, the stakes,
and what you built on it.
Mark the stakes "high" if it touches data, money, access,
public interfaces or deleting things. Keep going, but build
high-stakes choices so they are easy to change.
Only state an assumption when the answer would change the code.
If the call is yours to make (naming, structure inside your change),
make it and record the reason instead.
When a correction arrives, change course, then say what you changed.
Two lines in there carry most of the weight. "Do not stop to ask" turns a stall into a call. "Only when the answer would change the code" keeps the list short enough that people actually read it.
What should you watch for?
- Agents asking anyway. Some agents fall back to asking out of habit, especially after a long session. If it happens, check the instruction is in the file the agent actually reads, and that it says "do not stop to ask" in so many words. A permission prompt for a command isn't a question in this sense; that's the tool's own safety setting.
- Guesses hidden in code. An agent that picks a default without writing it down hasn't stated an assumption. Review for constants and defaults that encode a choice, and ask for the line.
- Too many trivial lines. If every variable name becomes an assumption, people stop reading. Push those back to "make the call and say why".
- Assumptions that are really decisions. If the call sits inside the agent's own change and nobody else is affected, it should decide, not assume. Assumptions are for things someone else knows.
- High stakes built deep. A high-stakes guess spread across ten files is expensive to correct. The instruction asks for one place; check that it happened.
- Lines nobody answers. If assumptions pile up unanswered, the routing is wrong. Name an owner per area, even a rough one.
How do you know it's working?
You'll see it in the shape of the day, not in a dashboard you have to build:
- Fewer parked sessions. You come back to finished work with a short list of lines, not a terminal waiting on a question.
- Answers take seconds. People settle assumptions with a word or a sentence, because the likely answers are already there.
- Corrections stay small. When a guess is wrong, the fix is one function or one label, because the agent named what it built on it.
- The same question doesn't come up twice. Answers that matter become decisions, and the next agent finds them before it would have assumed.
- Review gets quieter. Fewer "why did it do this?" comments, because the why was written down at the time.
What does Campfyrr automate?
Campfyrr turns the line into a call agents make and a card people answer. The agent calls state_assumption with the question, its assumption, the likely answers and the stakes, then keeps working.
- Answered from the record first. If the team's record already answers it, the answer comes straight back to the agent, and nobody is bothered.
- Sent to the right person. Otherwise it goes to whoever made the closest decision or last worked in that area, or to the team. It shows in the project's Activity feed with an "Answer it" link to its own page, where they answer in one click: "Right, keep going", each of the likely answers, "Correct it…", or "Not mine to check", which passes it on.
- High stakes first. Assumptions about data, money, access, public interfaces or deleting things are marked "High stakes" and shown first. The agent still keeps going.
- Corrections reach the agent. A correction reaches the agent at its next turn; in Claude Code the hooks deliver it along with other news for that session.
- Visible where it matters. Open assumptions in an area appear in the area brief that any session touching that code receives, and in the change's reasons for its reviewer.
- Counted. The "What Campfyrr caught for your team this week" card on Activity shows how many questions were answered from the record, how many assumptions were stated and confirmed, and how many wrong assumptions were caught.
For the short version of the reasoning, see should an agent assume or ask? and how to see what your agents assumed. For the instruction file as a whole, see agent instructions for a never-blocked team.
The habit is one line. Write what you're assuming, say what's at stake, and keep going, so the only thing that waits is the guess, and it waits in plain sight.
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).