When an agent redraws the interface, what did the user confirm?

On October 29, 2026, Google published an A2UI/CopilotKit tutorial for assembling agent-generated interfaces from application components. It makes a practical question more immediate: which version of a changing interface does a user's confirmation authorize? Google tutorial.

The following is Open Market Notes' design analysis, not a report of a discovered vulnerability. Its concern is the interval between reading a proposal and acting on it. Generative interfaces can help people compare options without composing another prompt. But when the agent also revises the proposal, the application must preserve the relationship between the terms someone considered and the action ultimately performed.

The same button can acquire a different meaning

Consider a hypothetical support console. A customer-service worker reviews a proposed replacement shipment to a customer's existing address. While they inspect the stock information, another conversation updates the address. The agent redraws the shipment card. The worker presses the button they were already moving toward.

Every field might be valid, and the worker might have authority to create shipments. Yet the system still needs to determine whether the worker approved the old destination or saw and accepted the new one. Treating the latest form state as the answer silently assigns an interpretation to the human's intent. Freezing the entire interface indefinitely creates a different problem: the operator can confidently approve information that has ceased to be usable.

A2UI's action documentation allows event context to contain literals or values resolved from the current data model. That supplies an event's data; deciding what the person understood remains an application responsibility. Action documentation.

This distinction matters when testing. A test that confirms the backend received the displayed address may still miss a change immediately before the click. The difficult case is a perfectly synchronized system whose user has not caught up with it.

There is also a presentation problem even when no underlying value changes. Suppose the working card shows only a shortened address while the review card shows the full destination. The application should make the relevant distinguishing details visible before confirmation, including the recipient when several people share a location. Highlighting a changed field is useful only if the label explains its business meaning. An internal identifier can bind an action reliably while giving the person no usable basis for deciding. Conversely, exposing every internal field can bury the few details that matter. The review surface needs a deliberate selection of decision-relevant information, with a way to inspect the rest. This selection should be owned by the product, rather than left entirely to the agent's choice of a visually compact layout.

Give the proposal a business identity

Our proposed design separates a working interface from a reviewable proposal. The agent can continue searching and suggesting. Once the worker enters a consequential review step, the application creates a proposal with an identity, revision and explicit business terms. The confirmation refers to that proposal rather than an interchangeable position in a list or a button label.

The authoritative service then checks that the proposal can still be carried out. For this example, destination, item and delivery commitment belong to the decision; card color and a rearranged explanation generally do not. If a consequential term changes, the application should show the difference and ask for a new decision. It should retain unrelated user work rather than clearing the entire form. A concise explanation of what changed is more useful than an unexplained “please try again.”

The A2UI specification describes two-way binding as local to the client and action-triggered transmission of input. A rendered field and the durable business record therefore need separate consideration in an application's design. Protocol documentation.

An established technical building block is HTTP's If-Match precondition, which can make a modification depend on a matching entity tag. RFC 9110. Applying conditional updates to this problem is our inference, not a feature claim about the tutorial. A tag protects only the resource it represents. If destination and inventory live in different services, checking a card revision alone does not establish that both remain valid. The business service needs a coherent validation-and-commit boundary, or an explicit reservation arrangement with defined expiry.

Decide which changes deserve interruption

Reconfirmation has a cost. Interrupt on every incoming update and workers learn to dismiss notices. Interrupt too rarely and “confirmed” ceases to describe a meaningful decision. The product team should define material changes in the language of the task, with the people accountable for its outcomes.

For a replacement shipment, an updated delivery destination may require review even if delivery is faster. An improved outcome on one dimension does not imply consent on another. By contrast, correcting a spelling mistake in an internal explanation may not require a second approval if the actual instruction remains identical. These are proposed policy choices, not universal rules built into a UI protocol.

The interface should also make concurrent activity legible. It can distinguish a newer suggestion waiting for review from the proposal currently under consideration. If another operator changes the underlying case, the first operator should see the specific conflict before commitment. A visible “updating” indicator alone offers little protection if the action remains enabled with changing semantics.

Measure the decision, not just the render

Acceptance testing should deliberately change consequential terms during reading, keyboard navigation and submission. It should cover delayed messages, reordered suggestions and a second operator editing the same case. The expected result is not always a blocked action: unchanged decision terms should be able to proceed without unnecessary repetition.

A useful record links the reviewed proposal, the user's action and the resulting business operation. Store the information needed to reconstruct that relationship under an appropriate retention policy, rather than assuming a full screenshot or an entire conversation is always necessary. Neither a click log nor a successful API response alone establishes what was accepted.

The cited documentation does not establish how often such mismatches occur in production or whether a particular implementation suffers from them. What it supports is a timely design question. As agents become responsible for composing the surface on which people decide, teams need an explicit account of when that surface may change, which changes invalidate a decision, and how the final operation remains tied to the terms the person actually reviewed.