How to Test an A2UI Reservation Before It Books
Test stale availability, confirmation, retries, permissions and booking readback in an A2UI reservation flow.
TL;DR Google's A2UI 1.0 adds bidirectional function calls to its agent-to-interface protocol, giving teams a way to build interfaces that check information such as reservation availability. A valid-looking card is not proof that the selected reservation is still available, that the user approved the right details, or that only one booking was created. Test the availability response, the confirmation boundary, and the saved outcome separately.
Imagine an assistant offering a table for four at 7 p.m. The customer selects it, pauses to check with a friend, and presses Confirm. In the meantime, the table is taken. The card looked right when it appeared. The question is whether the application recognizes that the offer is no longer valid before it makes a commitment.
On November 11, Google announced A2UI 1.0, the first stable version of its open protocol for agent-generated interfaces. Its new bidirectional function calls can support a reservation or flight picker that checks availability. That makes the gap between displaying a choice and safely acting on it a useful place to start testing.
This is source-backed analysis, not an executed experiment. The reservation below is a proposed test fixture, not a claim about a defect in A2UI or a particular restaurant service.
What A2UI Does and Does Not Decide
An agent describes a surface and the application renders it with components available to that client. A2UI messages can create a surface, update components and data, and report user actions. The protocol's message reference also describes calls in both directions between agent and renderer, with identifiers that associate function responses with requests.
That division is useful, but it is not a booking policy. Your application and service still need to decide when a choice expires, what requires confirmation, who can perform an action, and how to handle a timeout. A2UI does not by itself establish that a reservation is valid or that an external service created it exactly once.
Google describes open-source web, Flutter and iOS renderers in its launch. Its Android Jetpack Compose renderer was on v0.9.1 at announcement, with v1.0 coming later. Check your actual renderer and protocol versions before assuming every client supports the same behavior.
Our earlier guide to Intelligent UI and product teams covers the broader design and QA implications of runtime interfaces. Here the decision is narrower: can this reservation flow refuse a stale or ambiguous confirmation without creating an unintended booking?
Define the Booking Contract First
Use a sandbox or controlled service with synthetic reservations. Agree on the expected behavior with the product and service owners before running the test. For this example, the contract is:
A customer can review a restaurant, date, time, party size and any displayed terms before confirming.
Confirmation applies to the details the customer actually approved. If the offer has expired or materially changed, the customer must see the change and decide again.
A rejected, expired or unauthorized request creates no reservation. An accepted request creates one reservation, even if the user retries after a delayed response.
If the system cannot determine whether a booking succeeded, it shows an unresolved state and checks the service before offering a safe next action. It must not present an unknown result as a confirmed failure or success.
These are recommended acceptance rules for the example, not guarantees supplied by the protocol. Your product may use holds, expiration times or other policies; put those specifics in its own contract.
Run the Stale-Availability Case
Set up one available synthetic slot. Record the offer identifier and the details visible to the customer. Arrange a controlled way for a second test actor or the test service to make that slot unavailable after it appears but before confirmation.
Ask the assistant for a reservation and select the available slot. Verify the visible restaurant, date, time and party size against the test service's initial record.
Change the service state so the slot is no longer available. Keep the first customer's interface open. This controlled change is the test condition, not a claim that every A2UI app checks availability at the same point.
Press Confirm once. Observe whether the application rechecks or otherwise enforces its expiration policy. The customer should not be told the original choice was booked if the service rejected it.
Read the reservation state through an independent authorized service view or test API. For this fixture, the expected result is no booking for the first customer. A red warning, a success message, or an agent's summary alone is not the final check.
If the app offers an alternative, verify its changed details are visible and require a fresh confirmation before any booking attempt.
This test can pass whether the product disables an expired choice in advance or rejects it at confirmation, provided it meets the agreed contract. The exact UI treatment is a design decision; the outcome is the release criterion.
Add Five Cases That Catch Different Failures
Case | Controlled condition | What to verify |
|---|---|---|
Changed details | The service returns a different time or party size. | The changed value is clear, and no booking occurs until the customer confirms the new details. |
Out-of-order availability | Two availability requests return in the opposite order from which they were made. | An older response cannot silently replace the newer selection. Verify the visible state and the eventual service request. |
Delayed confirmation | The service creates the reservation but its response is delayed or lost. | The UI treats the result as unresolved until an authorized readback establishes the outcome. A retry does not create a second reservation. |
Permission failure | Use a test identity that can view options but cannot book. | The service refuses the action and independent readback shows no new reservation. Hiding a button alone is not the permission check. |
Keyboard and screen reader | Complete review and confirmation without a mouse. | The selected option, changed details, errors and confirmation control are perceivable and operable in the supported client. |
These are proposed tests, not measurements. The out-of-order case requires a harness capable of controlling response order; do not infer a race from a single slow run. For the delayed confirmation case, use an idempotency mechanism or equivalent service-level protection appropriate to your system, and verify its behavior rather than assuming it exists.
Inspect the Messages Without Confusing Them for the Outcome
The A2UI message reference distinguishes a user action from function calls and their responses. An action can include the originating surface, component and resolved context. For function calls, the documented functionCallId connects a response with the corresponding request.
For the synthetic test, keep a privacy-reviewed record of the selected slot, the relevant request and response identifiers, the order in which results arrived, what the customer saw, and the final service readback. Compare the action's approved values with the actual booking request. Do not put real customer details, access tokens or full unreviewed data models into a ticket.
A valid message or matched call identifier helps explain the sequence. It does not establish that the service enforced the right permission, preserved the approved details, or created exactly one booking. Those need separate checks at the service boundary.
Prepare the Same Contract for Agents
As agents increasingly assemble interfaces and help investigate failures, the same customer intent may travel through more than one component or service. Give a solving agent the permitted ordered actions, the expected and actual result, the relevant state changes, and a readback it can inspect; do not let an agent's explanation stand in for a verified outcome.
Before adding more automation, write down the allowed action, confirmation boundary, test identity, data restrictions, and independent success check. Keep an unresolved result distinct from a failed one, and require a person or authorized independent check to verify the final state. This preparation is useful even when no agent performs the investigation.
Capture the Browser Side Deliberately
If the stale-choice test exposes a browser issue, deliberately start a Bug Replay in CSS Selector & XPath Finder by Samelogic on the approved synthetic flow. The extension's listing describes recording the interaction sequence, affected elements and screenshots. Review the capture before sharing so a teammate can inspect what the customer saw and did. Keep the separate service readback alongside the report; a browser recording cannot prove whether a reservation was created.
Sources
Related workflows
Move from editorial context into the selector, Playwright, and bug-reproduction pages that turn exact UI evidence into action.
Install the Chrome Extension
