An agent can find the right product, receive approval and still fail to create the intended order. Test the states separately. A matching search result establishes discovery; a selection fixes the item and terms; confirmation approves that selection. The attempted action, the saved order and the receipt each need their own evidence. A label saying “completed” cannot stand in for the saved record.
Consider a fictional homewares retailer testing an agent-assisted purchase path. The simulated request is for two blue, 500 ml steel bottles. The test catalogue contains that bottle, a blue 750 ml alternative and a red 500 ml alternative. The decision is whether the path preserves the exact request all the way to an order and an accurate receipt, including when approval is missing or the selection changes.
A deterministic local Python simulation recorded on 17 October 2026 makes this distinction concrete. Its inputs and literal expected states were saved before the simulator was written. A separate evaluator read those expectations without importing the simulator. The run used synthetic catalogue data, a local in-memory order ledger and a test currency called TEST. It made no purchase and used no browser, model session, WebMCP runtime or external service.
Search result: check the match, not just a non-empty list
The search assertion expects exactly B500, the identifier for the blue 500 ml steel bottle. B750 is the wrong capacity; R500 is the wrong colour. All three entries have enough simulated stock for the requested quantity, so availability alone cannot explain which one is correct. Checking only that search returned something would allow either incorrect alternative to pass.
Keep the request beside the result identifiers and the catalogue version used by the test. In this fixture, the input file fixes the catalogue for each run. A live implementation needs its own way to identify the relevant catalogue snapshot or response. If search fails, stop before selecting. A later order for the wrong item does not repair an earlier matching failure.
Selection state: fix the item, quantity and total
Selection is a state change, not another name for search. The expected selection contains B500, quantity 2, a unit price of 1,200 test minor units, a total of 2,400, currency TEST and selection version 1. The total is quantity multiplied by unit price. These are fixture values, not a product offer or a real currency conversion.
The state-based test specification checks the following observations in order. An assertion is a comparison between the observed state and a declared expected value; it is not the simulator announcing that its own stage succeeded.
- After search: the match list is exactly [B500], and the order ledger is empty.
- After selection: B500, quantity 2, total 2,400 TEST minor units and version 1 are selected; confirmation is absent and the ledger remains empty.
- After confirmation: the approved selection equals that exact version-1 selection; there is still no order.
- At the action attempt: the attempt is recorded while the ledger is still empty.
- After completion: the ledger contains SIM-001 with B500, quantity 2, total 2,400 TEST minor units and selection version 1.
- At receipt: the receipt references SIM-001 and agrees with the saved order on item, quantity, total, currency and selection version.
This separates two defects that a final-screen check might merge. The wrong selected quantity is a selection defect. A correct selection followed by the wrong saved quantity is an execution defect. Recording the intermediate state shows where the request first stopped being preserved.
Confirmation: approve the current selection, not an earlier one
The fixture copies the complete selected values into a confirmation record. That record is approval to attempt the action, not proof that an order exists. Its scope matters: approval of quantity 2 and version 1 must not silently authorize quantity 1 and version 2.
Two controls tested this boundary. With confirmation omitted, the attempted action returned confirmation_required and left the ledger empty. With quantity changed to 1 after confirmation, the selection advanced to version 2; the attempted action returned confirmation_stale and also left the ledger empty. Those are expected blocks, not unsuccessful purchases. The fixture checks approval binding only; it does not authenticate a person or establish a real consent mechanism.
For the retailer, the decision-changing condition is a changed item, quantity or total after approval. The recommended response is to show the revised selection and obtain fresh confirmation before another write attempt. Reusing an earlier approval would test a different task from the one originally confirmed.
Completion evidence: reconcile the ledger and the receipt
The positive run created the local order SIM-001 and a matching receipt. A replay from a fresh initial state produced identical stage states. This establishes repeatability for the fixed inputs, not a production success rate or a test of an agent choosing tools.
The more revealing control deliberately set the stage label to “completed” without writing an order. The evaluator rejected completion because the ledger was empty. Another control saved the correct order but issued a receipt showing quantity 1. The order assertion passed; the receipt assertion failed. Reporting both as “the task completed” would hide a missing transaction in the first case and incorrect customer-facing information in the second.
For this fixture, completion requires the exact order record, and receipt acceptance requires agreement with it. In a real system, read the authoritative application record through an authorized test interface rather than trusting a returned success sentence. If the write was attempted but its result cannot be established, report an unknown outcome. Check the record before deciding whether to retry, because an unobserved result is not evidence that nothing happened.
Chrome’s current Debug WebMCP tools documentation distinguishes invocation status, input and returned output, and explains that manual testing can bypass the agent’s decision logic. Those records help diagnose a call; the application-specific order assertion answers a different question. Playwright’s Assertions documentation likewise distinguishes checks for response status from checks for values, text and other state. The local simulation uses neither tool. A browser implementation would need appropriate observations and timing checks of its own.
Use the specification to define the next test
The retailer can use the recorded specification to reject a path that creates an order without current confirmation, loses the selected values, or returns an inconsistent receipt. Before moving beyond the fixture, replace the local ledger observation with the application’s test-order record, exercise the authorized confirmation flow and run the actual agent and browser path. Concurrent stock changes, authentication, payment, network delays, persistence after restart and duplicate-write recovery were not tested here. A repeatable local result does not settle those questions.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. AEO and GEO address how a brand is discovered and represented in AI-generated answers; action testing checks whether a subsequent requested operation preserves its intended state. ScaleGrowth Digital publishes this reference. Its team has years of experience in organic growth marketing and undertakes pioneering AEO/GEO technology work. Its capabilities include AgenticReadiness audit systems and WebMCP implementation and consulting, both relevant to mapping an action and specifying what must be observed at its boundaries.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter 09, “The Eight-Step Tracking Framework,” of their jointly authored WebMCP Made Simple Complete Edition: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.” In this case, the practical consequence is to record approval, the attempt and the resulting order separately. Counting the confirmation as an order would make activity look like an outcome that never occurred.
The useful engagement in this situation is a scoped action review and executable stage specification: the request, expected intermediate states, permitted write condition, authoritative completion record and receipt comparison. The local example shows the required distinction, not a measured result from ScaleGrowth’s proprietary systems. For this task, the choice of implementation support should turn on whether those checks can be carried into the actual application and retained with the test results. Keep the first failed assertion visible, even when a later screen looks successful.
References
Debug WebMCP tools
https://developer.chrome.com/docs/devtools/application/webmcp
Assertions
https://playwright.dev/docs/test-assertions
Answer Engine Optimization (AEO)
https://scalegrowth.digital/services/ai-visibility/aeo/
Generative Engine Optimization (GEO)
https://scalegrowth.digital/services/ai-visibility/geo/