How to verify an agent’s work
An agent reaching its final step is only part of the story. Define success, inspect the destination, and test what happens when something goes wrong.
To verify an agent’s work, define the expected result, inspect the destination, and compare what actually happened with that expectation. Include cases with missing information, rejected changes, and partial completion in your review.
The question I care about after a run is straightforward: did the intended work happen? An agent can click Save and still leave the wrong value, encounter a validation error, or update a different record. The destination is where I would look for evidence.
When designing a runbook, I would write the completion check alongside the instructions. Here is a practical way to make that check useful.
Describe the intended end state
“Click Save” describes an action. “The selected record contains the new status, and the status is still present after reopening it” describes an outcome. The second instruction connects the work to a check that can reveal a silent failure.
For a research task, the end state might be a document with five named sections and source links for every factual claim. For a data-entry task, it might be a specific record with a known identifier and the expected field values. Use the real destination and the smallest set of checks that can establish whether the work is correct.
Look at the destination
An activity trace helps explain what the agent attempted. The destination helps establish what happened. Review both when the result matters. A successful click does not prove that the application accepted a change, and a confident summary does not prove that the cited source supports it.
If the task creates a document, open the document. If it updates a record, inspect that record. If it prepares a list, sample the entries against their sources. Match the depth of review to the consequences of an incorrect result.
Test the cases that should not succeed normally
A clean example is a useful first test, but it leaves important behavior unexplored. Try cases where the expected information is absent, ambiguous, or unavailable. The correct outcome may be to stop and report the issue rather than continue.
For example, if two records share the same company name, the runbook should use another identifier or ask for clarification. Guessing may produce a polished result attached to the wrong company. Make the exception rule part of the instructions.
- A required field is missing.
- Two possible records match the input.
- The destination rejects a submitted value.
- The source page cannot be opened.
- The requested result already exists.
Inspect partial work before retrying
A stopped run may still have changed something. Before repeating a task that creates or updates records, check what already exists. Repeating every step can turn a partial success into duplicate work.
Give the runbook an explicit rule for existing results. It might update a document with a known identifier, skip an already processed request, or stop for review. Which rule is right depends on the task; the important part is deciding before a retry.
Keep a small record of what passed
For the first few runs, record the input, the expected result, the actual result, and any correction you made. Separate a run that completed without help from one that needed intervention. Both teach you something, but they support different conclusions about readiness.
Infragrid’s runbooks give you a place to make the task’s instructions explicit. Use that structure to describe the intended result and the exceptions, then verify the output in the application where the work lands. Better checks give you a clearer basis for deciding when to use the runbook again.
From reading to doing
Turn your next task into a runbook.
Capture how you work, refine the instructions, and give your agent a repeatable starting point.