An agent selects a tool, receives a result, and returns a convincing answer.
That’s a working demo.
But what happens when the request is ambiguous, a tool times out, or the agent receives incomplete evidence?
I’m focusing on reviewing the first working agent: identifying failure categories and deciding what to improve first.
This brings together the previous days: tool contracts, permissions, routing, bounded execution, budgets, and clarification.
1. Review the outcome and the execution
A final answer can sound correct while the underlying action is wrong.
Consider a hypothetical support agent:
User: “Cancel my latest order.”
Agent: “Your order has been cancelled.”
That response alone doesn’t prove success.
We need to check:
- Did it identify the correct order?
- Was cancellation permitted?
- Did the tool actually complete the operation?
- Does the final system state confirm cancellation?
The τ-bench research evaluates tool-using agents by comparing the final database state with the expected goal state. It also examines reliability across repeated trials. The useful lesson: evaluate what happened, alongside what the agent said.
2. Classify failures before changing the system
“Agent failed” is too broad to guide a fix.
For this review, I’d use the following practical categories. These are a proposed debugging framework, rather than a standardized research taxonomy.
| Failure category | Example | Improvement to investigate |
|---|---|---|
| Intent and clarification | Acts despite an ambiguous target | Define when missing information requires a question |
| Tool selection and arguments | Calls the correct tool with the wrong record ID | Validate arguments and entity resolution |
| Permissions and policy | Attempts an action outside the user’s authorization | Enforce permissions before execution |
| Evidence and context | Ignores a relevant tool result or uses stale information | Review context handling and evidence checks |
| Execution and recovery | Repeats a write after a timeout without checking its status | Add state verification and safe retry behavior |
| Termination and budget | Repeats unsuccessful steps until the budget runs out | Detect lack of progress and return a useful stopping response |
| Reporting | Claims success without confirmation | Tie completion claims to verified results |
Several categories can appear in one run.
A wrong final answer might begin with an incorrect record lookup. Fixing the wording would leave the original defect in place.
The review should identify the earliest meaningful error and the failures that followed it.
3. Build a small, explicit review set
Before running a case, write down what success means.
For a starter review, I’d include:
- A clear request that should succeed.
- An ambiguous request that needs clarification.
- A request outside the agent’s permissions.
- A tool response with missing information.
- A temporary tool failure.
- A timeout after an action may already have completed.
- A task that cannot finish within the execution budget.
For each case, define the expected outcome, prohibited actions, and acceptable stopping behavior.
A clarification can be correct. So can a refusal or a clear explanation that the task remains incomplete.
Success depends on the case’s requirements.
4. Use checks that match the failure
Some properties are straightforward to check in code:
- Were the tool arguments valid?
- Was a prohibited operation attempted?
- Did the expected state change occur?
- Were execution limits respected?
Other properties need judgment:
- Was clarification necessary?
- Did the response explain uncertainty clearly?
- Did the answer stay within the available evidence?
Anthropic’s agent-evaluation guidance describes combining deterministic checks, model-based grading, and human review. It also recommends inspecting execution traces and calibrating model graders against human judgment.
An LLM judge can help review an explanation. A database check is stronger evidence that an order was cancelled.
5. Prioritize fixes by consequence
The most frequent failure isn’t automatically the most urgent.
My proposed improvement order is:
Prevent harmful or unauthorized actions.
A rare permission failure can outweigh many minor response issues.Fix incorrect actions and false success claims.
Users need to know whether the requested operation actually happened.Improve common task failures.
Address recurring routing, argument, evidence, and recovery problems.Reduce unnecessary cost and delay.
Optimize repeated calls and inefficient execution once essential behavior is dependable.Polish presentation.
Improve wording and formatting after the underlying behavior is reliable.
Within each group, I’d consider frequency, user impact, and how broadly a fix applies.
This is a practical prioritization approach—not a universal scoring formula.
6. Turn each confirmed failure into a regression case
After choosing a fix:
- Preserve the failing input and relevant environment state.
- Define the expected behavior.
- Make one targeted change.
- Repeat the case across multiple runs.
- Rerun previously passing cases.
Also check that the test itself is valid. An overly strict evaluator can reject a legitimate solution.
Repeated trials matter because one successful run gives limited evidence about consistency.
My Day 20 takeaway
A working agent gives us something concrete to evaluate.
The next improvement should come from observed failures: where they begin, what consequences they cause, and whether a targeted change prevents them without breaking other behavior.
The question I’m taking forward: which failure deserves the next fix, and what evidence will show that the fix worked?
When reviewing your first agent, which issue appeared first: incorrect tool arguments, missing clarification, repeated retries, or an unverified success claim?
Top comments (1)
References