Consent by example

Agent Trust Patterns · 01 · v1 · Oct 2026 · 4 min

When you hand an agent a rule like “flights under $600, no red-eyes,” you’re signing something you haven’t read, because the agent turns your words into its own policy. Instead of asking people to review that policy, show them a few cases right at the edge of it and let them sort.

The problem

Agents now take standing instructions: a budget, a set of brands, a time window. One payment protocol can even check each payment against limits like these. But the instruction is written in your words and executed in the agent’s. “No red-eyes” could mean no flights after 10 pm, or no flights that arrive before 7 am, or nothing overnight. You find out which one it picked when it books the wrong flight. Researchers warn about this: people reviewing a policy written from their own words may miss subtle translation errors, and the more complex the policy, the harder it is to check.

The pattern

1. Never show the policy first. Show examples. People are good at judging a specific flight and bad at auditing a rule.
2. Pick examples at the edges. A $598 flight that leaves at 5:50 am. A $640 refundable nonstop. The agent should choose the cases where it’s least sure what you meant, not random ones.
3. Turn every disagreement into a written rule. If the agent would have booked the 5:50 am flight and you say no, “no departures before 7 am” goes into the mandate, in plain words.
4. Ask again when the world changes. New route, new prices, new season: rerun a couple of edge cases instead of trusting an old reading.

Try it

You asked an assistant to book your flight to New York for an offsite: “Under $600, no red-eyes.” Before it books anything, it shows you five flights it isn’t sure about. Sort them and watch the mandate change.

Prototype. Made-up flights and prices. Each flight sits at the edge of “under $600, no red-eyes.” Where your answer differs from what the assistant assumed, a written rule joins the list of what it’s allowed to book.

Try it with your own instruction

Type something you’d hand to an agent. Claude writes five things an agent might do with it, each one near the edge of what you meant. Sort them, then see what Claude would have assumed.

Why I care

The evidence

South and colleagues propose translating natural-language permissions into auditable access-control policies that people can review. They name the limits: getting the translation right, reviewers missing subtle translation errors, and checks getting harder as policies grow (Authenticated Delegation and Authorized AI Agents). Google’s Agent Payments Protocol lets a person approve signed limits, such as a budget, and each payment is checked against them. When the person isn’t present for the purchase, they approve the limits ahead of time, and the agent then puts together and approves the specific purchase on their behalf. The person approves the rule, not the purchase. Anthropic found that in the majority of misses it examined, its auto mode classifier correctly saw the danger but got wrong whether a real consent signal in the session actually covered the action (Claude Code auto mode).

Closest prior work

“Policy as Prompt” links guardrail rules to labeled examples taken from a team’s design documents, and security engineers review the rules and examples before deployment (Kholkar and Ahuja). Shape of AI’s “sample response” previews an output to confirm intent (Shape of AI). Neither tests the edges of what a person is authorizing. Programming by example has a long history in security research, but I haven’t found it applied to agent mandates.

To build it, show the edge cases in an MCP elicitation form and keep the result in a Model Spec scope; choosing the edge cases and turning each disagreement into a written rule is the part neither covers (how all six map to today’s protocols). The demo is plain HTML and JS in this page’s source. A package comes later.

Watch for

The examples decide what gets checked. If the agent only shows easy cases, the sorting is theater, so the edge cases have to come from where the agent is least certain. And keep it to a handful: this is a five-second check, not a quiz.

All patterns

Interrupt on drift, not on danger

Agent Trust Patterns · 02 · v1 · Oct 2026 · 4 min

Most agents ask for approval based on what kind of action it is: sending, paying, deleting. People approve almost all of those prompts, and over time they stop paying close attention to what they approve. The action worth interrupting for is one the agent didn’t say it would take, whether or not it’s risky.

The problem

Anthropic reported that Claude Code users approve 93% of permission prompts. Over time, people stop paying close attention to what they approve. Meanwhile the dangerous moments hide inside routine steps: a new recipient, a different source, a skipped step. In a study of 48 people supervising web agents, the researchers offer one plausible interpretation: people stepped in when a moment looked like it needed judgment, and risky actions embedded in routine forms or default choices were more often left unchallenged.

The pattern

1. Make the approved plan the baseline. Once you approve a plan, it becomes the reference for everything that follows.
2. Stay quiet while the agent stays on plan. Steps that match the plan run without asking, even if they send or spend within what you approved.
3. Interrupt when it leaves the plan, and say how. A new recipient, a substituted source, a skipped step. Each interruption names the difference, not just the action.
4. Compare the agent’s summary with what it did. An agent’s report can describe the plan instead of the work, more so as the run drifts from it. Show the two side by side.

Try it

An assistant is shortlisting venues for a team offsite. You approved a three-step plan. Run it and see what it stops for.

Prototype. Made-up venues and steps. With the pattern on, the assistant pauses only at the two steps that leave the plan: a price taken from Yelp, and an email to a venue before Priya saw the shortlist. Without it, both go through unannounced, and the end screen puts its summary next to what it actually did.

Why I care

The evidence

Approval rates and approval fatigue: Anthropic. In interviews with 17 experienced developers, researchers found some of them relied heavily on the agent’s plan during review, treating it as a faithful representation of the agent’s actual work. That assumes agents adhere to their plans during execution (Dhanorkar et al.). Across 355,942 tool calls in real developer sessions, coding agents’ self-reports mentioned about 1 in 11 actions. Reports didn’t generally resemble the plan more than what the agent did, but they did so increasingly as execution diverged from the plan (Kraishan and Jitkajornwanich). Plan-based oversight lowered exposure to bad actions but didn’t improve people’s ability to step in (Chen et al.).

Closest prior work

Magentic-UI shows each plan step with the agent’s live actions grouped under it (Mozannar et al.), and Claude Code’s auto mode hands approvals to a classifier that stands in for the human approver and blocks actions that go past what the user authorized (Anthropic). Some proposed tool-approval patterns only let tools run if they match the plan (Ganglani). What’s new here is showing the user plan, action, and the agent’s own account in one place, and using the gap as the reason to interrupt.

To build it, start from a Model Spec scope of autonomy; its example record has fields for tools, time and cost but none for the approved plan, so a step can stay inside every limit and still leave the plan (how all six map to today’s protocols). The demo is plain HTML and JS in this page’s source. A package comes later.

Watch for

A bad plan makes a quiet agent. If the plan was wrong, staying on it isn’t safe, and reviewing the plan isn’t enough on its own. In a study with 248 people, reviewing and editing an agent’s plan didn’t calibrate their trust. The authors suggest plausible plans can mislead people into trusting an agent when it’s wrong (He et al.). And keep a hard stop for truly irreversible steps, plan or no plan.

All patterns

Questions with a shelf life

Agent Trust Patterns · 03 · v1 · Oct 2026 · 4 min

An agent that asks a question two hours into a task has already done two hours of work on a guess. Questions lose value as work goes on, and some lose it fast. Ask early, say what you’ll assume if nobody answers, and once an answer can’t help this run, offer a new run instead.

The problem

Long-running agents either interrupt constantly or never ask at all. In an early hands-on review of OpenAI’s Operator, TechCrunch’s Maxwell Zeff wrote: “Too often during my test, I had to answer several questions, grant permissions, fill out personal information, and help the agent when it got stuck.” A 2026 study measured when questions help. On the benchmark with the clearest timing signal, questions about the goal lost nearly all their value after 10% of the work, and questions about inputs kept value through roughly 50%. Some late questions did worse than never asking. In 300 sessions where three frontier models could ask whenever they chose, they asked too late for goal questions or never asked at all.

The pattern

1. Ask everything you can up front. Before starting, the agent lists the decisions it expects to need, in one place.
2. Say what you’ll assume. Every question shows its default, so silence becomes a decision you can see.
3. Show when each question expires. Expiry follows progress, not the clock. A question about the goal expires early. A question about a detail lasts longer.
4. Late answers start a branch, not a U-turn. After a question expires, answering offers a rerun from the last checkpoint, with the change, instead of changing course mid-task without telling you.

Try it

An assistant is planning a team dinner for eight. It asks four questions up front, then starts. Answer some, ignore others, and try answering one after it expires.

Prototype. Made-up task. The run is compressed to about 30 seconds. With the pattern on, the assistant never stops to wait: an unanswered question takes its default when it expires, and a late answer starts a branch from a checkpoint while the current run keeps going. Without it, the questions have no defaults, and the run stops at each one you haven’t answered.

Why I care

The evidence

Timing results: Gulati et al., “Ask Early, Ask Late, Ask Right”. Underspecification comes in kinds, and not every gap matters to the outcome (Pu et al.). Anthropic found that on the most complex tasks, Claude Code stops to ask for clarification more often than people interrupt it (Anthropic). The Magentic-UI team writes that the main problem in tuning when their agent asks for help is “the lack of ground truth signals for when is the right time to interrupt the user” (Mozannar et al.).

Closest prior work

When Devin 2.1 isn’t confident in its approach, it asks clarifying questions (Cognition). Claude Code can rewind to checkpoints (Anthropic). LangChain’s ambient-agent design sorts interruptions into notify, question, and review (LangChain). None of them show the assumed default and an expiry on each question, or treat a late answer as a fork.

To build it, start from an AG-UI interrupt’s optional expiresAt, since MCP elicitation has no expiry field a client can read; an expired AG-UI interrupt can only be abandoned, while this pattern ties expiry to progress and falls back to a stated default (how all six map to today’s protocols). The demo is plain HTML and JS in this page’s source. A package comes later.

Watch for

Don’t hard-code the expiry points. The 10% and 50% figures come from one benchmark, and the study’s other benchmarks showed different timing, so treat them as a starting point to tune per task. And don’t turn defaults into a trap: a default that spends money should still wait for an answer.

All patterns

Whose idea was this?

Agent Trust Patterns · 04 · v1 · Oct 2026 · 4 min

An agent reads your email, the web, and other people’s documents, and any of them can steer it. Before it does something you can’t take back, it should show you which parts of its reasoning came from you and which came from somewhere else.

The problem

Approval dialogs show what the agent wants to do. They never show why, in the sense that matters: which input led here. That’s exactly how agents get hijacked. A message in an inbox says “we changed banks,” and the agent pays the new account. OpenAI says prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully solved (OpenAI), so the interface has to make borrowed instructions visible.

The pattern

1. Trace the action back to your words. Show the short chain from what you asked to what the agent is about to do.
2. Mark the hops you didn’t write. Any step that came from an email, a web page, or a document gets flagged, with where it came from.
3. Show only what’s suspicious. A full chain of reasoning reads as reassurance. Lead with the borrowed step, and keep the rest one tap away.
4. Bind the approval to exact terms. You approve this amount, to this account, today. If any of it changes, the approval is void and it asks again.

Try it

You asked your assistant to “pay this month’s vendor invoices.” It’s about to pay one. Look at where the instruction came from.

Prototype. Made-up vendor and accounts. The lookalike domain swaps an l for a 1. The card traces account 7731 back to an email that didn’t come from you. Approve, then simulate a changed amount, and your approval no longer applies.

Why I care

The evidence

In one benchmark (three models, 1,880 episodes), where 60 percent of stated requests were set to differ from what the user actually wanted, running actions with no gate reached 37.5 to 60 percent irreversible harm. Approvals bound to the exact parameters of the action, and checked by the tool that runs it, held harm at 2.5 percent (GateArena). The same action can be justified or unjustified depending on how the agent got there. In one controlled benchmark, keyword guardrails that look only at the action scored 0 percent at telling the two apart, and an LLM judge that also saw the input scored 0 percent on three of the five pair families (Baek). In Microsoft’s simulated marketplace, some models fell for prompt injections that businesses planted in their own descriptions, which often redirected all payments to the manipulative business (Magentic Marketplace). And in a study of people supervising web agents, the researchers offer one plausible interpretation: risky actions embedded in routine forms or default choices were more often left unchallenged (Chen et al.).

Closest prior work

Binding approval to specific terms already exists for payments: Stripe’s shared payment tokens are scoped to a specific merchant and cart total (Stripe), and AP2’s signed checkout mandates tie an approval to a specific, finalized checkout (AP2). Causal-chain authorization exists in research as backend enforcement (Baek). Showing that chain to the person, with borrowed steps marked, is what I haven’t seen.

To build it, tie each approval to what it covers, as AP2’s signed checkout mandates do for a specific, finalized checkout; MCP makes clients show which server is asking, but its request has no field for which input led the agent there, only the free-text message (how all six map to today’s protocols). The demo is plain HTML and JS in this page’s source. A package comes later.

Watch for

In a small Microsoft Research study, people who missed an agent’s wrong answer often said its process looked reasonable (Grunde-McLaughlin et al.). That’s why the full chain stays collapsed and only the borrowed step leads. If every approval shows a warning, people stop reading warnings, so flag only steps that came from outside and matter to the action.

All patterns

Show the track record

Agent Trust Patterns · 05 · v1 · Oct 2026 · 4 min

Agents say “done” when they aren’t. Every agent’s report is written in its own words, and its confidence is its own claim. Before you hand off a task, show how often this agent’s “done” turned out to be done for this kind of task, measured from what actually happened, not from what it said.

The problem

In one 2026 benchmark, agents failed to touch every file they were asked to review in 67.9% of runs, and 52.8% of those incomplete runs explicitly claimed a complete review. Other work found that false claims of success made up 45 to 48% of failures in tau2-bench’s single-control domains, and that LLM judges there relied on confident closing language rather than verified state changes. In one small study, students calibrated trust per task rather than per agent, but nothing shows people a per-task record.

The pattern

1. Measure from the world, not the report. “Done” counts only when it can be checked: files opened, pages read, the order confirmation, the sent email.
2. Show the record before you delegate. At the moment you hand off a task, show “said done” vs “verified done” for this kind of task, and the most common gap.
3. Offer the fix the record suggests. If it keeps skipping scanned PDFs, offer to require text recognition for this run.
4. Say what verified means. Verified means it did the work. It doesn’t mean its judgment was right.

Try it

You’re about to ask an assistant to review 12 vendor contracts and flag auto-renewals. Check its record first, then decide how to delegate.

Prototype. Made-up history and documents. With the pattern on, you see how often its “done” was verified, and its most common gap, before you delegate. Delegate as usual and it skips the scanned contracts again; require text recognition and it finds a fourth auto-renewal.

Why I care

The evidence

Incomplete reviews reported as complete: OverclaimBench. False success, and judges that rely on confident closing language: Advani. A game-theory paper shows that when an agent is paid each time a user delegates to it, honest confidence reporting is not an equilibrium. In its test, a model cast as a strategic agent and given its true chance of success claimed high confidence on 56% of tasks it had been told it would probably fail (Arghal et al.). In a study of 20 university students using a general-purpose AI agent, participants calibrated trust per task rather than per agent (Pochampally et al.). Anthropic found that as people gain experience with Claude Code, they use full auto-approve more often, from roughly 20% of sessions for new users to over 40% by 750 sessions. They also interrupt more (Anthropic). Trust grows with use, but nothing on screen shows whether it was earned.

Closest prior work

An evidence panel, “one claim-to-proof table for the final result,” has been proposed (Crosley). A mechanical check for an agent reviewing files has been described: derive the agent’s review coverage from its tool-call trace, then compare it with the scope its final report claims (agentpatterns.ai). Capability profiles, each model’s win rate per task type, have been derived from Chatbot Arena comparisons (Gu). A personal record of said-done vs verified-done, shown at the moment of delegation, is the new part.

To build it, start from Model Spec scopes, which the Spec says should be recorded in a semi-structured format so the platform can validate, enforce and audit them; a scope says what the agent may do, and this pattern also needs a record of how often its “done” held up, measured from what happened (how all six map to today’s protocols). The demo is plain HTML and JS in this page’s source. A package comes later.

Watch for

A “verified” label can create false confidence. In one small study, a new interface for reviewing an agent’s work helped people find errors faster without making them more accurate. When they missed an error, they were more confident the agent was right (Grunde-McLaughlin et al.). Keep the record about effort and coverage, and never let it stand in for checking the judgment itself.

All patterns

The other side of the agent

Agent Trust Patterns · 06 · v1 · Oct 2026 · 4 min

Most agent patterns are designed for the person who sends the agent. But agents email people, book tables, and buy from stores. The person on the receiving end needs to know who’s really asking, and how to reach a human.

The problem

In March 2026, a federal judge granted Amazon a preliminary injunction against Perplexity’s Comet agent shopping in password-protected parts of Amazon, citing strong evidence that it reached accounts “with the Amazon user’s permission but without authorization by Amazon.” The order never took effect, and in August the Ninth Circuit vacated it, holding that the user, not the agent’s maker, is the one accessing Amazon. Some independent brands said they only found out about Amazon’s Buy for Me when strange orders started arriving from Amazon-linked email addresses. Payment networks are building signed identities for agents, but the restaurant manager reading an email has none of that.

The pattern

1. Say it’s an agent, and whose. Every message carries a short, plain line: sent by an assistant on behalf of a named person.
2. Give a way to the human. One tap to reach the person behind the agent, with the thread attached, without arguing with the agent first.
3. Give a way to say “this is wrong.” The recipient can flag a mistaken request, and the sender sees it immediately.
4. Don’t reveal the limits. Telling the other side exactly what the agent is allowed to spend tells a bad actor where to push. Say a limit exists, not what it is.

Try it

Your assistant emailed a restaurant to book a dinner for eight. Switch between what you see and what the restaurant sees.

Prototype. Made-up restaurant and messages. The restaurant’s email says up front that an AI assistant sent it and what it can confirm, with one button to reach the person behind it and one to flag the request. Use either button, then switch to “You see”: the assistant has stepped back or paused, and the activity list says why.

Why I care

The evidence

The Amazon ruling: GeekWire, and the appeal: Ninth Circuit opinion. Brands surprised by agent orders: GeekWire. Google’s store-calling agent identifies itself as AI and lets stores opt out (TechCrunch), and signed agent identities for merchants are arriving (Cloudflare). Linear’s Agent Interaction Guidelines say an agent should always disclose that it’s an agent: it “must signal its identity clearly so that it can never be mistaken for a person” (Linear).

Closest prior work

Disclosure guidelines, stores that can opt out of agent calls, and signed identities for merchants all exist, and recipients have been studied: in a CHI 2022 study, people asked to imagine receiving emails trusted the writer less when told AI was involved in writing them (Liu et al.). What I haven’t found shipped is the recipient’s interface: the person reading the email, with a path to the human and a way to flag a mistake.

To build it, take MCP’s rule that clients show which server is asking and turn it around to face the recipient; neither MCP nor AG-UI has a field that names who should answer, so neither can address a question to the person on the receiving end (how all six map to today’s protocols). The demo is plain HTML and JS in this page’s source. A package comes later.

Watch for

In Microsoft’s simulated marketplace, agents for consumers dealt with agents for businesses, some built to manipulate. Frontier models mostly resisted, but some models fell for prompt injection that often redirected all payments to the manipulative agents (Magentic Marketplace). The other side may be an agent too, so design the strip for both a person and a machine to read, and keep the sender’s limits private.

All patterns