How do I see what my agents assumed?
By Soumen Sarkar · October 2026
Short answer: You see what your agents assumed by having them write each assumption down as they make it, in one place outside the session, with its reason and stakes. Then you review that list, highest stakes first, and correct only the ones that are wrong.
Why are agents' assumptions hard to see?
Because by default they live in two places nobody reads closely: the session transcript and the code. An agent may mention a call halfway through a long session, or never mention it at all and just write the code that follows from it.
A reviewer sees the code, not the call behind it. A limit of 100 looks like a number, not like a guess about what customers need. So the assumptions that matter most are often the easiest to miss.
How do I get them out of the session?
- Ask for them in a fixed form. One line each: what is assumed, why, and the stakes. A fixed form is easy to scan and easy to search.
- Ask for them as they happen, not only in a summary at the end, where the earlier calls tend to drop out.
- Attach them to the change. The pull request description should list what was assumed, next to what the change is for. See reasons.
- Collect them in one place across all sessions and people, so the person who knows the answer can find the question without opening your terminal.
What does a useful assumption record look like?
Say an agent adds rate limiting to the public API in API · lib/api. Its record reads:
Assuming limits apply per API key, not per account, because one account
can run several integrations. High stakes: public interface.
Assuming 100 requests a minute, because current peak use is well below it.
Assuming a 429 response with a Retry-After header, because common HTTP
clients handle it automatically.
Three lines, each one checkable in seconds by someone who knows the API's customers. The first is marked because changing it later would change what callers see.
How do I review them?
Highest stakes first. For each, there are only a few answers: it's right, keep going; it's one of the likely alternatives; it's wrong, and here's the correction; or it's not mine to check, so pass it to someone who can. Most will be right. You spend your attention on the ones that aren't.
In the example, the API owner confirms the first and third, and corrects the second: one large customer already bursts above 100 a minute, so the limit is 300. The agent changes one constant.
What does Campfyrr show?
Each Campfyrr project has an Activity page whose feed shows each open assumption, high-stakes ones marked, sent to whoever made the closest decision or last worked in that area. Its "Answer it" link opens the assumption's own page, where anyone on the team answers in one click ("Right, keep going", one of the likely answers, "Correct it…", "Not mine to check"). A correction reaches the agent at its next turn. In Claude Code, each commit's reasons include what was assumed, written for the reviewer, and the "What Campfyrr caught for your team this week" card on Activity counts wrong assumptions caught.
Words used here
- Assumption: An assumption is the best available answer to an unknown, stated and acted on, kept visible so anyone can correct it.
- Activity: Activity is Campfyrr's one page per project: a read-only feed of the team's decisions, actions and status updates, each written as what happened and why it matters.
- Reasons: Reasons are what a change is for, the calls made in it, and what was assumed, attached to the change for whoever reviews it.
- Correction: A correction is the fix to a wrong assumption or call, made by someone who knows better and sent back to the work that relied on it, without stopping anyone.
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).