Practical steps for verifying AI agent action results

Confirm an agent action changed the world as intended by comparing a pre-written expected outcome with fresh evidence gathered after it ran.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Checking post-action results is the part of an agent loop where you stop trusting that a step happened and confirm that it did what it was meant to do. For background on how the full cycle fits together, see the State-Questions-Action-Verify Loop method page. This page covers only the verification step.

The generic agent loop in this agent architecture guide runs observe, reason, choose action, act, observe result, update state, verify, then continue or terminate. Two of those stages matter here: observing the result after acting, and verifying it against what the action was supposed to change. Skipping the second observation and reusing what the agent saw before acting is the most common way verification quietly turns into a formality.

The skill has four parts. First, every consequential action gets an expected outcome written before it runs, stated as a change you could observe: a file that exists, a record whose field now holds a value, a test that now passes. Second, after the action, you collect fresh evidence from the environment rather than from the agent's memory of what it did. Third, you choose a verification signal that fits the outcome; a loop-engineering reference lists tests, typecheck, lint, evals and trace graders as the usual artifacts that say yes or no. Fourth, where the output is structured, you verify it field by field rather than judging the whole thing at once.

Underneath all four is a rule about what does not count. An agent's prose report that it finished is a claim, not evidence. A practitioner article on loop engineering recommends observable evidence such as tests, builds, diffs, working links, screenshots or written acceptance criteria instead of the agent's unsupported judgment that the task is complete.

The input to this skill is an action the agent just took, the expected outcome attached to it, and access to the environment it touched. The output is a verdict (passed, failed, or could not verify) plus the evidence behind it, written into state so the next decision in the loop works from facts. When verification is done well, a failed check tells you exactly which expectation broke. When it is done badly, the loop reports success on work that never landed, and you find out downstream from a customer or a broken build.

How It Works

Verification compares two things: the expected outcome written before the action, and a fresh observation taken after it. The comparison only works if both are concrete. The agent architecture guide frames this as giving every consequential action an expected outcome that can be checked after execution, then observing the result and verifying against that expectation. An expectation like "the ticket is handled" gives the verifier nothing to compare; "ticket status is resolved and a reply exists in the thread" gives it two fields to read.

Fresh observation means re-reading the environment after the action, from the source of truth. If the agent updated a database row, query the row. If it edited code, read the diff and run the build. The observation the agent made before acting describes the world it acted on, not the world it produced, so treating it as evidence confirms nothing.

Choosing a signal means matching the outcome to the cheapest check that can actually distinguish success from failure. The loop-engineering reference groups verification artifacts as tests, typecheck, lint, evals and trace graders. Where static matching is not feasible, StateFlow sends the context history to a model to assess whether the problem is solved, which works but makes the verifier itself something you have to trust.

Per-field verification comes from TypeSafe's SDE cascade: extract with a cheap model, ask a per-field yes/no Noul question such as whether a value is absent from the source or was lifted from unrelated text, with each returning the probability that something is wrong, and escalate to a more expensive model when a verifier fires. TypeSafe's introduction describes a Noul question as answering whether a statement is true on a 0-1 scale. The shape generalises beyond that tool: checking fields separately localises the failure, so the retry or escalation targets one value instead of redoing the whole output.

Finally, the verdict and its evidence go back into state. The loop-engineering reference describes the branch: on failure, feed the failure evidence back into state and retry; on a pass, persist the updated state and decide what happens next. Either way the evidence, not the agent's summary, is what the next iteration reads.

Step-by-Step Guide

Step 1: Write the expected outcome before acting

Before the agent executes a consequential action, attach a statement of what should be true afterwards. Phrase it as observable facts about the environment, not as a description of the action. "Send the refund" is an action; "a refund transaction for this order exists with the requested amount" is an outcome. The agent architecture guide treats this expected outcome as the thing verification later checks against.

If you cannot write it, the action is not ready to run.

Pro tip: Store the expected outcome next to the action in state so a later reviewer sees what was promised, not just what happened.

Step 2: Name the source of truth for each expectation

For every fact in the expected outcome, decide where you will read it after the action: a database query, an API call, a file on disk, a rendered page. The source must be the system the action changed, not a log the agent wrote. This is also where you discover expectations you cannot observe, which should be rewritten or flagged for human review. The output of this step is a short list of reads, one per expected fact.

Pro tip: If the only place a fact appears is the agent's own output, treat that expectation as unverifiable until you find an independent read.

Step 3: Choose the verification signal

Match each expectation to the cheapest check that can actually tell success from failure. Code changes usually get typecheck and lint first, then tests. Generated text gets evals, and constraints on how the agent worked get trace graders, following the artifact list in the loop-engineering reference. Reserve human review for outcomes no automated check encodes.

Step 4: Observe fresh after the action

Once the action returns, perform the reads you named, now. Do not reuse observations from before the action or values the agent carried in its context. An action that returns success can still leave the world unchanged if a write failed silently, hit the wrong record or was rolled back. Capture the raw observation (the query result, the diff, the screenshot) so it can be inspected later.

Pro tip: Add a short wait or poll for systems with eventual consistency, and record that you did, so a too-early read is not mistaken for a failure.

Step 5: Verify structured output field by field

When the action produced structured data, check each field on its own rather than asking whether the whole object looks right. The SDE cascade asks per-field questions such as whether a value is absent from the source or lifted from unrelated text, each returning the probability something is wrong. Per-field checks tell you which value broke, which makes the recovery step narrow. Decide in advance what score on each field counts as a failure.

Pro tip: Start with the fields that drive downstream actions, such as amounts, IDs and dates, before verifying descriptive text.

Step 6: Record the verdict and evidence in state

Write one of three verdicts per expectation: passed, failed or could not verify. Attach the raw evidence and the check that produced it. On failure, the evidence goes back into state for the retry; on a pass, the updated state is persisted before the loop decides what comes next, as the loop-engineering reference describes. A verdict without evidence should be treated as could not verify.

Pro tip: Keep could not verify separate from failed; conflating them hides broken checks behind apparent agent errors.

Best Practices

• Write expected outcomes as states of the world, not as actions. An action description can only be confirmed by the agent saying it did it, while a state can be read independently.
• Read from the system the action changed. The practitioner article on loop engineering points to builds, diffs, working links and screenshots because each can be inspected without trusting the agent.
• Layer cheap checks before expensive ones. Typecheck and lint catch structural breakage fast, so tests, evals and human review only see outputs that already pass the basics.
• Check scope, not just success. The same article has the verifier confirm the diff stays within the permitted scope, which catches actions that achieved the goal by changing things they should not have touched.
• Verify structured outputs per field. A per-field question, like those in the SDE cascade, points recovery at the one wrong value instead of forcing a full redo.
• Keep the raw evidence with the verdict. A stored query result or diff lets a reviewer audit the call later and lets you tune thresholds when checks prove too strict or too loose.

Common Mistakes

• Checking only whether the action ran, such as a tool call returning without error.: Verify whether the action achieved its expected outcome. The agent architecture guide separates acting from observing the result and verifying it, and both later stages are needed.
• Reusing a pre-action observation as evidence.: Take a fresh read after the action from the source of truth. An observation made before acting describes the old world, so it cannot confirm a change.
• Accepting the agent's prose report that the task is done.: Treat the report as a claim and check observable evidence instead. The practitioner article recommends tests, builds, diffs, links, screenshots or written acceptance criteria over the agent's unsupported judgment.
• Asking a model whether the whole output looks correct.: Break the output into fields and ask one narrow question per field. A holistic yes hides which part is wrong and tends to pass plausible but unsupported values.
• Discarding the evidence once the check passes.: Persist the verdict and evidence in a state artifact such as a progress file, checkpoint, trace or issue comment, as listed in the loop-engineering reference. Without it, nobody can review why a later decision was made.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: State–Questions–Action–Verify Loop

Related Skills

• Recovering from Verification Failures
• Defining Verifiable Success Criteria
• Applying Loop Termination and Continuation Rules
• Formulating Typed Decision Questions
• Representing Current Agent State
• Selecting and Executing Bounded Actions

Sources

• Introduction - TypeSafe AI
• SDE cascade - Introduction - TypeSafe AI
• Agent Architecture: Loops, Planning, Verification, Termination
• Turning /goal and /loop into Verifiable AI Agent Workflows | by
• StateFlow: Enhancing LLM Task-Solving through
• README.md · cy0307/awesome-loop-engineering at refs/pr/3

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.