Skip to content
>devspeak
← glossary
patternCommunication Patterns

Verify assumptions

Ask the agent to check the facts its plan relies on, like what a file contains, how a feature works, or what the data looks like, instead of guessing.

a bit more technical

Require the agent to confirm its premises with evidence, by reading the actual code, checking real data, running commands, or consulting docs for the installed version, before acting on them. Unverified assumptions are a common source of confident but wrong changes.

picture it

Checking that the oven is actually on before you blame the recipe for raw cookies. The recipe might be fine.

✗ instead of
i think the dates are stored in UTC so just convert them
✓ try
Before converting any dates, verify how they're actually stored by checking the code and a few real records. Tell me what you assumed and what you confirmed, then propose the change.
why it matters

Agents fill gaps with plausible guesses: that a function exists, that a field is never empty, that a setting is on. Asking them to verify turns guesses into facts and catches made-up details early.

what your agent might say
agent
I assumed every user has a time zone set. I checked the database: 12% don't. I'll handle the missing case instead of relying on that assumption.
how you might use it
you → your agent
Before you change anything, list the assumptions your plan depends on and verify each one against the actual code or data. Tell me which ones turned out false.
common mistake

Thinking a confident explanation must be a checked one. Agents sound equally sure whether they verified or guessed. Ask what they actually looked at.

builds on