What happens when an agent's assumption turns out wrong?
By Soumen Sarkar · October 2026
Short answer: When an agent's assumption turns out wrong, someone who knows corrects it, the correction reaches the agent (or whoever continues its work), and the agent changes course and says what it changed. Because the assumption was stated, the fix is small and nobody had to stop.
Why is a stated wrong assumption cheap?
Because everyone can see it. An agent that writes "assuming prices are shown without tax" has put the one risky line where someone can catch it. An agent that silently guesses the same thing has buried it in the code, where it surfaces weeks later as a bug report.
So a wrong assumption isn't the failure. A hidden one is. Stated assumptions let a team move without waiting and still catch mistakes while they're small.
What should happen, step by step?
- The agent states its assumption and keeps going.
- Someone who knows sees it, ideally whoever made the closest decision or last worked in that part of the code.
- They correct it in a sentence: "No, EU prices include VAT."
- The correction reaches the agent, or the session that continued its work.
- The agent changes course and says what it changed, so anything that relied on the old answer can adjust too.
None of these steps needs a meeting, and none of them blocks the work in between.
What does that look like for a checkout?
Say an agent is adding a price summary to the checkout, in Checkout · lib/checkout. It doesn't know how prices are stored, checks the code and the team's notes, finds nothing, and states: "Assuming catalogue prices exclude tax; adding VAT on top at checkout." It builds the summary and moves on to the shipping line.
Forty minutes later, the developer who built the catalogue sees the assumption and corrects it: EU prices already include VAT. At its next step, the agent receives the correction. It changes the summary to show "includes VAT" and back-calculates the tax line instead of adding it, updates two tests, and notes the change. Total cost: a few minutes. Discovered after release, it would have meant overcharged customers and refunds.
Who should correct it?
The person closest to the answer, not a fixed reviewer. That's usually whoever made the last decision in that area, or whoever last changed that code. If they don't know either, they pass it on instead of guessing. The aim is that each assumption meets the one person who can settle it in a sentence.
How does Campfyrr carry corrections?
An agent calls state_assumption with its question, its assumption, the likely answers and the stakes, and keeps going. 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, who sees it on Activity with buttons: "Right, keep going", the likely answers, "Correct it…" or "Not mine to check". A correction reaches the agent at its next turn, and assumptions about data, money, access, public interfaces or deleting things are marked high stakes and shown first.
That's fixing forward: the work kept moving, and the course was corrected while the mistake was still small. For how to state assumptions well in the first place, see should an AI coding agent assume or ask?.
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.
- 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.
- Rework: Rework is work done again because it was built on something wrong: a mistaken assumption, a clashing decision, or a plan that changed without anyone hearing.
The principle behind this: Fix forward: We don't guard the gate. We correct the course.
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).