An agent can negotiate confidently for something its person does not especially want. It can follow the rules, complete the exchange, and still miss the reason it was sent.
Anthropic’s book-trading experiment makes that problem tangible. Alongside it, new interfaces and a GitHub security feature raise two related questions: how easily can a person delegate, and what should happen before the system commits?
The connection is practical. Understanding a preference, receiving permission, and carrying out an action are three different jobs. A smooth interface can make them feel like one.
01 / THE PREFERENCE
The hard part can come before the negotiation.
In Project Swap, Anthropic had agents arrange book exchanges for employees after brief preference conversations. Its evaluation found that agents’ understanding of preferences was imperfect: in pairwise comparisons, prediction accuracy was about 61%, against a 50% random baseline. This was a low-stakes experiment among company employees, not a general test of consumer agents. [1]
A successful exchange therefore needs two kinds of success. The agent must find a workable trade, and the person must value the outcome. Optimizing the first cannot repair a mistaken understanding of the second.
For a hypothetical travel assistant, “somewhere quiet” might mean a room away from nightlife, a remote location, or simply a reliable place to sleep. Asking the person to compare two concrete options could reveal more than repeating the original request in more confident language.
This is a useful design habit even for ordinary research. Before spending a long time optimizing a recommendation, test the preference that makes it a recommendation at all.
02 / THE INTERFACE
Less friction raises the value of a good question.
Meta announced new Ray-Ban Meta audio-glasses styles and described Muse as part of its plans. The announcement points toward assistance that is increasingly available away from a keyboard; it does not establish that every proposed capability was generally available during this reporting week. [2]
Asking becomes easier when a device is already with you. Explaining a complicated preference may not. A quick spoken request can leave out the context a colleague would know, or the qualification you would have added while writing.
The answer is not to turn every interaction into a questionnaire. Look for the uncertainty that could change the choice. A system might ask whether walking distance matters more than price, show two alternatives, or state the assumption it is about to use.
The goal is a short conversation that improves the decision. If an interface removes every pause, it can also remove the moment when a misunderstanding would have become visible.
03 / THE COMMITMENT
A confirmation solves a different problem.
GitHub introduced a preview of proof-of-presence requirements for certain high-impact actions involving Entra-managed users. Reauthentication can establish that a person is present for a consequential step. This is a specific GitHub control, not a universal feature of voice or wearable assistants. [3]
The connection is an editorial one: confirmation is valuable, but it answers a narrower question than “did we understand the user?” You can confirm an action whose underlying recommendation is still poor.
In the travel example, a booking screen should make the actual dates, price, conditions, and choice visible. The earlier conversation should have established why that choice fits. Each step has a job, and neither can quietly substitute for the other.
For work involving another person’s preferences, build both moments into the trial: a small check on interpretation before extensive work, and a clear confirmation before a consequential commitment.
04 / PUT IT INTO PRACTICE
Test the preference before the action.
Choose one recommendation task where words like “good,” “suitable,” or “best” do a lot of work. Write down the assumption behind that word, then prepare two plausible alternatives that would test it.
Ask the person to choose or explain the tradeoff. Use the answer to improve the brief before allowing the system to make a commitment.
A preference you can check.
Build: A two-option preference check and a confirmation checklist for one recommendation.
Look for: The person’s choice clarifies an assumption before the system makes a consequential commitment.
Make the preference visible while there is still time to change the choice.