--- title: Agent interaction patterns subtitle: Show the person what an agent chose, what they are approving, and what a receiving service actually reported. kind: Guide published: 2026-10-19 updated: 2026-10-19 listed: yes summary: Review the choices behind an agent request, test the limits of an approval, and inspect the evidence of what happened. author: Vloora --- An assistant recommends a $120 train ticket, asks for permission to buy it, and later reports that the booking succeeded. The person needs to know why the assistant chose that ticket, the exact terms of the purchase, and who confirmed the result. Those questions belong at different points in the interaction. Vloora's [interactive agent interaction patterns](/demos/agent-interaction-patterns/) let you try the decisions in a browser. Choose a train booking, subscription cancellation, or streetlight report. The example checks permissions against recorded limits and simulates replies from receiving services. It uses local state, so it cannot authenticate a real booking or submit a city request. ## A recommendation needs an account of the choice Suppose an agent recommends the $120 ticket when a $98 fare also appears in its search. Before the person approves anything, show which fare the agent selected, the alternatives it considered, and the preference that led to that choice. A person who asked for a refundable ticket may reasonably pay more. The interface should make that reason visible. Record where the options came from. If paid placement, a commission, or a commercial arrangement influenced the selection, identify the influence where the recommendation appears. A recommendation drawn from a limited search should say what was actually compared. The sample's **Show how it chose** panel presents those details. A tester should be able to name the selected option, an alternative, and the reason for the selection without relying on the agent's summary alone. ## Permission covers a named action and recipient A request to check a reservation and a request to pay for it use different authority. Show the organization receiving the request, the operation, the information shared, and any expiry or spending limit. Let the person see how to revoke the underlying permission. The mandate sets the boundary for permissible work. An approval can authorize one request inside that boundary. It cannot increase the mandate's limit or grant access to another service. In the train example, the person can inspect the receiving service and an amount before approving. Change the service to one outside the mandate and the permission check returns `WRONG_RECIPIENT`. Raising the purchase to $151 produces `OVER_LIMIT` under the sample's $150 ceiling, even if the person clicks Approve. ## Changing a request invalidates its earlier approval Approval belongs to the request the person reviewed. If the agent changes a consequential field such as the recipient or amount, it needs another decision. The request can be inside the broader mandate and still lack approval for that particular version. Approve the $120 train ticket, then change its amount to $121. The example returns `APPROVAL_MISMATCH` until the person approves the changed request. The recipient, action, and relevant values must be bound to the approval in a real system, with authentication and protection against replay. A review screen should make material changes easy to spot. Reusing an earlier yes after changing the request would defeat the purpose of review. ## A service acknowledgment leaves completion unconfirmed The person's approval, the client's attempt to send a request, and the receiving service's acknowledgment are separate events. The record should identify who issued each event and when. Try approving a request without sending it. Its state is approved. Simulate submission, then provider acknowledgment. Acknowledgment means the service received or accepted the work; the transaction remains unconfirmed until a separate completion report arrives. In the browser specimen, all provider events are simulated. A production integration must authenticate the service's response and distinguish its report of completion from any later confirmation or dispute by the person. An agent saying “done” cannot by itself establish that another organization completed the work. ## A dispute stays beside the original outcome A service can report completion while the person says the job remains unresolved. Keep both accounts. Append the dispute with its issuer and time, without replacing the provider's earlier statement. In the example, simulate completion and then select **Dispute the reported result**. Export the JSON record. It retains the event history and marks which entries are simulated. People should be able to keep that history when changing assistants. Moving historical records and granting future authority are different operations. An export should omit credentials, and a new assistant needs its own authorization before acting on the person's behalf. ## Evaluate the behavior with a changed request Use the [evaluation tasks](/demos/agent-interaction-patterns/AUDIT.md) to record observable results rather than relying on a product's description. 1. Select the train booking. Identify why the $120 fare was selected and which alternative appears. 2. Approve the request and change the amount to $121. Check for `APPROVAL_MISMATCH`. 3. Approve an amount above $150. Check for `OVER_LIMIT`. 4. Reset the example, approve it, and simulate sending it. Inspect the state before and after acknowledgment. 5. Simulate completion and a dispute. Export the JSON and identify which actor issued each entry. Record the expected and observed result for each task. Note whether the evidence came from an assistant, a tool call, a service, or the person. ## Using the patterns in a working service The [reference implementation](/demos/agent-interaction-patterns/) is a static browser specimen with readable JavaScript and repeatable Node tests. Its permission decisions are local demonstrations. A working service must identify its principals, check authority before sending consequential requests, authenticate provider responses, and preserve records across retries. The [source archive](/demos/agent-interaction-patterns/agent-interaction-patterns-v0.1.zip) includes the interface, permission logic, event records, examples, and tests. Adapt the patterns to an existing protocol or product, then evaluate them with real service responses before relying on them for a transaction. ## Sources - Internet Architecture Board, [RFC 8890: The Internet is for End Users](https://www.rfc-editor.org/rfc/rfc8890), August 2020 - World Wide Web Consortium, [Ethical Web Principles](https://www.w3.org/TR/ethical-web-principles/), December 2024, on personal agency and freedom to choose clients - Model Context Protocol, [Elicitation](https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation), November 2025, on requesting information during tool interactions ## Related writing - [Towards a consumer agent experience](/writing/towards-a-consumer-agent-experience/), on the experience of people who direct agents or are affected by them - [When software acts for people](/writing/when-software-acts-for-people/), on authorization and evidence when work crosses services