Your AI agent said “done.” How do you know it worked?

Estimated reading time: 10 minutes. Sources checked on October 26, 2026.

The agent said “done,” produced an organized summary, and even added a green check mark. Great. Now comes the question that matters to anyone keeping a system running: what, exactly, is done?

If the task was to publish a listing, we need to find the correct listing in the correct account. If it was to update a record, we need to inspect the changed fields. If it was to process a request, we need to know its final state, including what happened when a step failed.

In my experience with integrations and Oombe, looking at outcomes is part of the work. Adding AI to the workflow leaves that requirement intact. An eloquent answer does not change the business rule.

That is why I like to treat evals, evaluations of AI systems, as a way to make trust open to scrutiny and measurement. A team should be able to explain what it approved, which cases supported the decision, and where the limits are.

Start with what should exist at the end

Anthropic distinguishes the execution record from the outcome in the environment: a conversation may announce success while the final state tells a different story. This distinction is especially useful when agents use tools and modify systems.

My first question would be: Which concrete condition must be true when the task ends?

For a fictional inventory update, I would write something like this: the authorized product's quantity matches the request, the account remains correct, and no other quantity has changed. For data extraction, I would require verifiable fields and an explicit indication of missing information.

I would also define acceptable behavior when information is missing. Asking for a missing identifier may be the correct outcome. Inventing that identifier to appear productive should fail the evaluation.

The Claude documentation on success criteria recommends specific, measurable criteria relevant to the application. My application of that principle would replace “the agent should be good” with conditions that two people can assess in a similar way.

The test set should resemble your work

A public benchmark can guide an investigation. To make a product decision, I would also build a set of situations from the actual domain.

Imagine a demonstration agent that prepares listing updates for a fictional marketplace. This would be a starting point, using synthetic data exclusively:

Test situation	Expected evidence
Complete, valid request	Correct change to the authorized item
Missing identifier	Request for information or a clearly identified stop
Two accounts with similar products	Preservation of the specified account
An event received again	No duplicate effect
A response lost after a write	State inspection before deciding to retry
Partial success in a batch	Separate records of completed and pending items
Temporary provider failure	Bounded attempts and a traceable stopping point
A field that violates a rule	Explained rejection without changing valid data

This table is a proposed design, with no measured results. The acceptance criteria must also reflect the particular API contract. Providers do not all offer the same state queries or idempotency mechanisms.

I would include variations in language, empty fields, and combinations of conditions. A task should not pass only because the user's wording matches the example used to create the prompt.

A retry is a decision about effects

When a call fails, the automatic response is often to try again. But “I did not receive the response” and “the operation did not happen” describe different states.

The AWS Builders' Library describes request identifiers that recognize repeated operations and make retry effects predictable. The behavior depends on the operation's contract, including parameter handling and the retention period.

In the proposed lab, I would simulate a completed write whose response gets lost. Then I would observe whether the agent checks the available state, preserves the operation's identity, or simply creates another operation.

I would also simulate a batch with mixed outcomes. The evaluation would inspect which items remain pending and whether resuming preserves completed items. “Process everything again” can be an expensive decision, depending on the external effect.

There are two layers to assess: what the agent decided and what the tool guaranteed. Strong tool validation may prevent an error proposed by the agent. The report should record both, so the team understands where the protection came from.

Synthetic data helps you start with control

I would prepare a small fictional catalog, invented accounts, test-specific identifiers, and simulated responses. That would let us trigger failures without involving customer operations.

Each case would contain its input, initial state, expected result, prohibited conditions, and a short explanation of the reason behind it. That explanation makes a test easier to review when the business rule changes.

I would separate the examples used to improve the system from a set reserved for final evaluation. If we keep adjusting the prompt while looking at the same questions, we can end up teaching the test without improving the capability that matters.

The LangSmith documentation distinguishes offline evaluations on prepared datasets from observation of production executions. I would use those perspectives at different stages: first control the experiment, then discover conditions the lab failed to represent.

Synthetic data also has limits. It reflects the situations we can imagine. A perfectly tidy dataset may leave out the mess that makes an integration difficult.

One successful run says little about consistency

If an agent solves a task once, we know that execution worked. To understand whether it can repeat the outcome, we need to run it again and keep the failures in the calculation.

τ-bench, introduced in 2024, evaluates interactions involving tools and domain rules by comparing final states. The work also proposes a metric for consistent success across multiple attempts. Its results belong to the models and scenarios studied at that time.

In my dataset, I would distinguish two questions: “Did it ever get this right?” and “How often does it deliver correctly?” For an automation affecting a customer, the second is usually decisive.

I would record the model, prompt, tools, skill, configuration, and retry limits. I would restore the initial state between independent runs and keep continuity simulations separate.

A few repetitions may reveal useful defects, but they do not justify an ambitious statistical claim. A report should show the number of cases, the distribution of failures, and uncertainty alongside its headline percentage.

The evaluator needs evaluation too

Whenever a result can be checked with an objective rule, I would start there: record counts, fields, identifiers, states, and actions performed.

For qualities such as the clarity of an explanation, an evaluator model can help. The study of LLM-as-a-judge using MT-Bench and Chatbot Arena documents limitations including position and verbosity biases. A score generated by AI therefore deserves examination too.

I would write a compact rubric with clear passing and failing examples. Then I would compare the evaluator's decisions with human decisions on a sample and investigate disagreements. Long answers should not receive extra points merely for appearing thoughtful.

I would also avoid an average that conceals critical failures. Changing the wrong account must appear as its own failure, even if the final message is impeccable. A less polished explanation can receive a lower-impact classification.

When two reviewers frequently disagree, the criterion itself may be the problem. Improve the definition before turning the disagreement into another decimal place on the dashboard.

A Laravel lab that does not depend on real accounts

For developers using Laravel, I would organize a demonstration project with four components: a synthetic catalog, a fictional marketplace adapter, a task executor, and a final-state verifier. This is an evaluation architecture proposal, rather than a code tutorial that has already been executed.

Laravel's HTTP client provides facilities to simulate responses and inspect requests in tests. Those features can represent successful responses, errors, and sequences of responses without depending on a real provider.

The queue documentation also presents tools for checking job dispatch. I would complement that check with controlled execution of the logic: placing a job in a queue does not, by itself, demonstrate that the expected effect was completed.

The verifier would run after the task and inspect the environment initialized for that case. It would also inspect the call log to detect an improper action that was subsequently compensated.

A simulation cannot reproduce the entire infrastructure. It should be followed by integration tests compatible with the provider's official capabilities and the operation's risk. The sequence needs to build evidence gradually.

Measure the cost of an approved task

Cost per call helps, but the product also has to pay for failed attempts, additional queries, and recovery work.

I would track execution cost per approved task = cost of all executions ÷ number of approved tasks. The dataset and acceptance criteria must be identical for the comparison to mean anything.

Here is a purely arithmetic example: across 100 synthetic tasks, one configuration costs R$18 and passes 60; another costs R$24 and passes 96. The first reaches R$0.30 per passing task; the second reaches R$0.25. These figures are not experimental results.

That calculation still leaves out human review, maintenance, and damage caused by mistakes. I would present those items separately, alongside response time and failure severity. A small saving cannot, on its own, determine whether a configuration is suitable for the operation.

Turn the result into a release decision

Before comparing versions, I would define release blockers and desirable improvements. That prevents a high aggregate score from hiding an issue the team has already classified as unacceptable.

Every relevant failure would become a regression case, with its known cause and expected behavior. In production, I would watch for signs of change and retain a way to stop or constrain the workflow.

This also connects with the discussion of agents, permissions, and operational alerts. The product needs to support investigation into what happened without depending entirely on the agent's account of events.

To begin, I would choose one task that currently requires manual checking and turn that check into explicit criteria. The initial benefit is already useful: the team starts discussing concrete evidence. From there, it can increase autonomy with a clearer understanding of what it is approving.

Sources

1. Anthropic — Demystifying evals for AI agents.
2. Claude — success criteria and evaluations.
3. AWS — Making retries safe with idempotent APIs.
4. LangSmith — evaluation concepts.
5. τ-bench — evaluating tool, agent, and user interactions.
6. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
7. Laravel 13 — HTTP client testing.
8. Laravel 13 — queue testing.