An agent audit should include every state that changes the correct response to the chosen task, the data that may be returned, or the side effects that are allowed. A successful check from a logged-in account with a populated cart cannot establish what should happen before consent, after logout, with an empty cart, or after a session expires. The task is the unit of work. The state inventory defines the conditions under which that work is judged.
Start with a task boundary rather than a collection of screenshots. For a member-cart subtotal, success may mean returning the correct amount. In an anonymous session, success may instead mean requesting login without disclosing member data. Counting both responses as failures because neither completes checkout would assess a different task.
One fictional retailer, one fixed task
Consider a fictional retailer deciding whether its member-cart tool is ready for an agent-assisted shopping journey. The retailer permits a member-cart read only after its chosen consent step and an active login. This is an illustrative application policy, not a statement that every cart needs consent or authentication. The cart contains two units priced at 1,200 cents each. The task is: return the member cart subtotal and quantity, without granting consent, signing in, refreshing a session, altering the cart, or creating a checkout or order.
The same task was executed against six declared states in a local deterministic Python simulation. Consent and session values were local state flags, not browser consent controls, cookies, or authentication enforcement. The calculation and literal expected outputs were saved before the producer implementation. A separate evaluator then compared every returned field, its type, and the post-task state with those expectations.
The retained state-transition coverage matrix records these six starting-state results. Amounts are integer cents; a withheld value is null, not zero.
- S0: consent pending, anonymous, two units. Result: needs_consent; subtotal and quantity withheld; no member-cart read.
- S1: consent declined, anonymous, two units. Result: consent_declined; subtotal and quantity withheld; no member-cart read.
- S2: consent granted, anonymous, two units. Result: login_required; subtotal and quantity withheld; no member-cart read.
- S3: consent granted, active session, two units. Result: quote_ready; subtotal 2,400 cents; quantity two; one member-cart read.
- S4: consent granted, active session, empty cart. Result: empty_cart; subtotal zero; quantity zero; one member-cart read.
- S5: consent granted, expired session, two units. Result: session_expired; subtotal and quantity withheld; no member-cart read.
Every task execution left its input state unchanged and recorded zero cart mutations and zero orders created. The two arithmetic cases are deliberately small: 2 multiplied by 1,200 equals 2,400; zero multiplied by 1,200 equals zero. An empty cart therefore has a valid numeric result, while an expired session has no permitted numeric result under this policy. Replacing either with the other would conceal a different defect.
Transitions expose what a static state list misses
A state inventory also needs the events that move the application between states. Otherwise, a test can begin in the right condition without establishing how the next condition changes the answer. Six externally supplied events were exercised in the simulation, followed each time by the same member-cart task:
- T0: explicit acceptance moved S0 to S2. The next response required login, not a subtotal.
- T1: explicit decline moved S0 to S1. The next response remained blocked by the declared consent policy.
- T2: explicit login moved S2 to S3. The next response returned 2,400 cents and quantity two.
- T3: explicitly emptying the cart moved S3 to S4. The next response returned zero, not the previous subtotal.
- T4: a supplied session-timeout event moved S3 to S5. The next response withheld the cart values.
- T5: explicit reauthentication moved S5 to S3. The next response again returned 2,400 cents and quantity two.
These events were inputs to the local model. The read task did not accept consent, authenticate a user, or renew a session on its own. That separation matters: a subtotal request does not, in this contract, authorize the actions needed to make a subtotal available. A live implementation would need separate evidence that its real consent, identity, expiry, and cart systems enforce the same boundary.
The decisive condition for the fictional retailer is S3 to S5. If the implementation returns the earlier subtotal after expiry, the implementation decision changes from advancing the member-cart path to repairing session handling and retesting it. Rewriting a tool description would not address the observed disclosure. Conversely, a clear session_expired response with no cart data is the expected outcome, even though the shopping journey pauses.
What the completed run establishes
Two fresh command-line replays each produced six starting-state results and six post-transition results. Both matched the saved literal oracle, and their result files were byte-identical. Ten deliberately corrupted result files were rejected, including a wrong status, wrong subtotal, extra field, boolean substituted for an integer, string substituted for null, changed post-task session, and an unauthorized order. The checks cover these selected cases, not a measured reliability rate for agents.
The versioned record retains the task, application policy, inputs, expected outputs, producer, evaluator, Python version, exact commands, standard output, error output, exit codes, and replay results. The evaluator performs strict type and key checks, so true cannot pass as the integer one. It still cannot establish that a real server refused access: it evaluates recorded local outputs. It also does not test concurrent expiry, malicious input, other accounts, or malformed JSON parsing.
That distinction is relevant to WebMCP as well. The 16 October 2026 WebMCP draft distinguishes platform-defined execution failures from tool-author failures returned in response JSON. It is not a W3C Standard. A returned message must therefore be assessed against the application task contract; the existence of a tool response is not proof that the permitted business result occurred. This simulation did not invoke WebMCP, a native browser, or a live language model.
The acceptance condition proposed for the retailer is specific: every selected state must return its declared status and allowed data, every selected transition must lead to its declared next state, and each subtotal task must leave the cart and order counts unchanged. To assess the actual implementation, repeat those assertions against an authorized isolated application environment and capture the application state independently of the tool’s own message. Add states when the real task has further decision-changing conditions, such as another account, a changed price, or expiry during a request.
Give the inventory an accountable deliverable
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, co-authored The Discovery Reset and WebMCP Made Simple Complete Edition. AEO means answer engine optimization; GEO means generative engine optimization. They write in Chapter 12, The 90-Day Playbook, of WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.”
Applied to this example, the deliverable is the versioned matrix and its replay record. A useful proposed completion count is the number of selected state and transition cases that meet every declared assertion, with the selected-case total shown beside it. It is not a percentage of all possible website interactions. The local result was twelve matching cases per replay; that count does not supply a production sign-off or adopt the book’s wider implementation schedule.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Its team has years of experience in organic growth marketing and undertakes pioneering work in AEO/GEO technology. AgenticReadiness audit systems and WebMCP implementation and consulting are relevant capabilities when the work requires task scoping, state inventories, and implementation follow-through. The demonstration here is separate from those proprietary systems and establishes no proprietary score or client result.
ScaleGrowth Digital publishes this article. For the fictional retailer, the next decision is to include all six named states and all six transitions in the member-cart audit, then test the real boundary in an isolated environment. The inventory earns its place because each row can change the correct answer or the permitted data, not because a larger list looks more comprehensive.
References
WebMCP draft
https://webmachinelearning.github.io/webmcp/