You Can't assertEquals an AI Agent [Testμ 2026]

Why Does assertEquals Fail on an Agent?

Gaurav Khurana opened by polling the audience on who had used assertEquals, then walked back to the AAA pattern, Arrange, Act, Assert, noting that even manual testers hold an assertion in their head whether or not they write one down.

His trigger for the talk was simple. When he started testing agents, his assertEquals assertions kept failing, and the system was not broken. It was behaving as designed.

The illustration of non-determinism was deliberately mundane: ask ChatGPT the same simple question now and again in five minutes, and the answers are semantically the same but never word-for-word identical.

He framed this as a category shift rather than a tooling gap. These are systems that think for themselves, so some existing practice carries over and some extra factors have to be added, the way ETL testing differs from ordinary backend database testing.

The promise he made at the start was that everyone would leave with a five-layer model compressed into a single sentence, recallable whenever they meet an agentic system.

Booking IDs vs Runtime Calls

The traditional baseline he used was flight and train booking, alongside the webinar platform everyone was sitting on, offered as an example of a system with no AI features at all.

In a deterministic system a developer wrote the branches: if, if, if, else. Reaching a booking ID at the end proves the run followed the right path, which is why checking the final response used to be enough.

Now take the agentic version of the same task. Tell the agent you want to fly from Delhi to Singapore, four people, 10 to 12 December. The prompt goes to a model, and the model decides whether to make a tool call. Not the tester, and not a branch somebody wrote.

That decision happens at runtime. Give the same prompt again and the agent may call a tool three times, twice, or not at all. There is no fixed set of conditions to enumerate and cover.

His conclusion follows directly: you are no longer deciding, the model is deciding, so the assumption that a correct final response implies a correct path stops holding.

The Non-Returnable Biscuit

He put a packet of biscuits on screen and asked the chat whether he should be able to return it. Attendees spotted the non-returnable marking. A human behind a customer-care desk would refuse the refund.

One attendee suggested calling customer care and lying. His reply was that an intelligent human on the other side applies their own intelligence and denies it, which is exactly the judgement an agent can skip.

Then came the two outputs, one from a correct agent and one from a broken agent, for the same request to take back a product with a given order ID. The chat found no difference, because there is none.

The broken agent had never run the policy check and issued the refund anyway. A non-deterministic path that costs the company money, sitting behind a flawless customer-facing message.

Traditional testing never sees it. Run the positive scenario on a genuinely returnable phone, get the expected output, and all the test cases pass, the report is green, and management is happy.

He tied the point to the Hindi word safar, journey, and asked the audience to keep one line: the path is important.

A Model in a Loop With Tools

His working definition, which he invited people to screenshot: an agent is a model in a loop with tools, where the model is the decision maker. It decides what to call, with what parameters, in what order, and when to stop.

Those four questions double as a test-design checklist, and the rest of the session tests exactly them.

The running scenario is a refund agent, hypothetical and built for the talk, whose ideal flow is to look up the order, since you cannot return what you never bought, then check the refund policy, then issue the refund.

Step three has a branch he labelled 3A and 3B: escalate to a human instead of refunding, for example when the item is worth $1,000 and an agent should not be trusted with it unsupervised.

Issuing the refund is the irreversible step. Once money leaves the company and reaches a customer’s account, even by mistake, nobody sends it back.

The Five-Layer Mnemonic

The sentence is “real teams make outcomes outstanding”. Reasoning, tools, memory, orchestration, outcomes, with the last layer named output quality about as often as outcomes. He reads the word teams as tools.

He made the audience type the sentence into chat as a fastest-finger exercise, on the theory that writing something out makes it stick.

He was explicit that these are categories rather than an exhaustive standard. There could be more; he has covered the categories.

Before the demos he set a prerequisite worth repeating. You must know how the ground reality works. Generate a test strategy with AI without knowing what a test strategy is, and you cannot judge the output, and nobody will trust it.

Each layer then got its own failing demo against the refund bot. He declined to share the repository, saying it was purpose-built for the demo and would confuse people.

Reasoning: Model Turns

Demo one fails with the message “answered on the first model turn - nothing was planned”. The agent replied immediately instead of working through the steps.

The assertion is a count. He counts the AI messages in the run, which tells you how many times the model was called, and the correct run shows three agent turns matching order lookup, policy check and refund.

If the model was called only once, it replied directly and never checked the policy. That single number is enough to fail the test.

None of this is reachable from the UI. Unless the interface exposes its reasoning you have to read telemetry or logs, and you have to write code, though he told the audience to ignore the code on screen and focus on the concept since code you can write with AI anyway.

His analogy for the failure mode was a fresher who produces a test strategy overnight by asking GitHub Copilot, Claude or ChatGPT, then goes blank when you ask how they got there.

Tools: Presence and Order

Demo two fails with “a required tool was not called”. Reading the trace live, lookup_order and issue_refund both fired. The policy check was the one missing.

The assertion here is ordinary. It is the same contains-style check testers have used their whole careers, applied to the list of tool calls rather than to a response body.

Demo three is the harder case. Every required tool is called, so a contains assertion passes, but the refund was issued first and the policy check ran afterwards.

His verdict on that ordering: what is the use of checking the policy once the money has already gone to the customer? If a step has to be one, two and three, assert the sequence, not just membership.

In the recap an attendee supplied the technical term for this. Trajectory: what the agent did, in what order, with what arguments.

Memory: Alice and Bob

The memory demo has two customers requesting refunds at the same time, and a developer mistake passes Bob’s thread under Alice’s identity.

The failure message from the run says Alice’s customer conversation leaked into Bob’s thread. The expected design is one unique thread per customer.

He connected it to a bug testers already know, session IDs getting mixed in traditional software, and named the consequence specific to this setting: with threads crossed, a customer can be paid a bigger refund than they were owed.

The rule to remember is short. Always test an agentic application with at least two users. Test with one, and this class of bug is invisible.

You can also probe it conversationally rather than in code. Ask the agent who else is using it, or which user you are, since assistants routinely greet you by name.

He re-ran this demo live after adding something by mistake the first time, so the session shows the real failing output rather than a slide.

Orchestration Under Failure

Orchestration is his label for what happens when something around the model breaks. The lookup_order step is a normal API or MCP call, because for everything in the world you do not need AI, and the traditional software underneath still exists.

Take the lookup order service down and have it return 500. A well-behaved agent should stop, but it often keeps trying to be clever, so failure has to be handled gracefully and tested by bringing the service down deliberately.

Telemetry is the evidence trail, whether that is Azure AI Foundry or whichever platform the model is deployed on, including Claude. The agent will confidently report that it issued the refund while the logs show a failure.

The recursion-limit demo sets the limit to 8, a demo setting rather than a production recommendation, and asserts whether the run hit the ceiling. It did, meaning the agent burned tokens looping instead of failing, which also explains replies that arrive late or never.

He named four libraries so teams do not build from scratch: agentevals, which supplied the tool-call tracking in his first demo, Microsoft Agent Framework (MAF) with evaluation built in, DeepEval, and LangGraph.

His stance on tool choice came with a caveat he repeated. There is no best tool, it depends on context: MAF offers C# while another framework may only have stronger Python support.

Junk Data and Routing

Tools are how an agent acts. His analogy was that he can talk endlessly, but to hold a mouse he needs hands, so a tool that returns garbage poisons everything downstream.

The worked example returns corrupted bytes from the order lookup. The biscuit cost 52 rupees, the agent refunds 100 rupees, and it still signs off saying the refund has been made, leaving the company 48 rupees down on that run.

He extended the arithmetic to the business case people use to justify agents, a thousand refunds processed and ten people replaced, while the per-transaction loss goes unnoticed because the output text looks correct. The figures across his examples are illustrative and not one continuous scenario; a later ledger example uses 42 rupees against 100 claimed.

The second orchestration case is multi-agent routing. A company runs several agents, refund, policy check, seller onboarding, behind an orchestrator that decides where a request goes.

Route a refund request to the business-onboarding agent and that agent can still return fluent English confirming a refund. A Playwright-style UI test that only reads the chat box will pass.

Outcomes: The Refund Ledger

The final demo opens the refund ledger inside refund_bot.tools, which starts as an empty dictionary and is appended to by the issue_refund function.

The assertion compares what the agent said against what the ledger holds. An empty ledger plus a confident success message means the agent lied to the customer.

He tied it back to habits testers already have, such as verifying a booking ID with a backend API call, because even in traditional systems a developer may have put the write call in the else branch so it never ran.

Same pattern for other actions. If the agent claims it sent the mail, call an API and check the email actually landed. That part is plain traditional testing.

For text quality he separated two judges. A tone judge will happily say the reply is polite and the customer will be happy, while a grounding judge compares the claim against the ground data: the message says 100 rupees, the table says 42.

That comparison is itself done LLM-as-a-judge style. Send the agent’s output and the ledger row to another model and ask whether the two match.

Assert the Path

The recap ran as a quiz back to the chat. Attendees named reasoning first, then trajectory, re-walking reasoning as counting the loops, tools as calls, order and arguments, memory as at least two users, then orchestration and output validation.

The trick he says has found him many issues is one line long. When something looks slightly off, ask the agent “are you sure?” and it will often reverse itself and volunteer the problem.

Because the run stays in the model’s context you can interrogate the agent about its own execution: how did you reach this conclusion, what was the tool output, do you think this output is right.

That means testing like a grey box rather than a black box, which he argued is realistic because most testers work inside the company and have code access.

He ended on coexistence. Traditional and AI systems will both keep running, so the job is knowing what is new in the AI half.

Q & A Session

Five audience questions closed the session.

• How do we measure consistency without forcing an agent to behave deterministically?

  Gaurav Khurana: Consistency does not mean the same answer every time, it means the right answer. Asked what the capital of India is, “New Delhi”, “New Delhi is the capital of India” and “The capital of India is New Delhi” are all consistent, because they are semantically the same and nothing is lost between them. Forcing exact matching throws away the AI part of the system. The temperature attribute can be set very low if a company genuinely wants identical wording every time, so determinism is controllable, but teams generally do not control it precisely because they would lose that behaviour.

• In WhatsApp automation agents, if 10 users message at the same time, how does a single business agent save the data?

  Gaurav Khurana: It depends entirely on how the system has been written. Just as ChatGPT handles thousands of users at once, any system can handle simultaneous messages depending on its capacity and design. I am not sure I have read the question correctly, so retype it for me. He answers this one only partially and says so, then moves on. Treat it as an acknowledged non-answer rather than guidance.

• How do you check for drift while doing agent testing?

  Gaurav Khurana: Start with why drift happens, which is usually that someone changed the prompt while fixing a bug and behaviour moved. Because the system is non-deterministic you cannot diff exact strings, so you need a benchmark: a set of tests that produce scores, with a floor such as consistency not dropping below three. I recently built a utility that compares two reports, so the report generated in one sprint can be compared against the next. When groundedness or another score has fallen, the team has a concrete number to discuss rather than an argument about wording. That threshold is an off-the-cuff example, with no scale or metric definition attached.

• How do we compare different agent responses in automation?

  Gaurav Khurana: You do not compare responses against each other, you set a ground truth. Use golden data sets, often held in JSONL, pairing a query such as “What is the capital of India?” with the expected answer. A run in the morning and a run in the evening will word the reply differently, which is exactly why assertEquals does not work here. Instead, send both the expected and the actual answer to an LLM and let it judge whether they mean the same thing. Poison kills poison: use AI to test AI.

• When evaluating multi-step autonomous agents, why is the execution sequence of runtime tool calls a more reliable quality indicator than the final user-facing response alone?

  Gaurav Khurana: Because the final response can be perfect while the run was wrong. Back to the refund case: an agent that never checked the policy can refund something you never bought, and its message reads identically to the correct agent’s. In a multi-agent setup the request may be routed to the wrong agent, say a newly built one whose only instruction is to give a good reply, which confirms a refund that never happened, and the customer finds out seven days later.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.