TL;DR
When a browser agent gets a task not in the dry wording of a benchmark but the way a real person would say it (in their own words, incompletely, with personal constraints), the completion rate drops by roughly a third. That holds for all nine models tested. Who is asking affects the result almost as much as which model is doing the work. PersonaCUABench is the benchmark that measured this. It takes the same tasks and changes only the client: an expert, an older adult, a young person, a busy professional.
The headline finding is about where the points get lost. Most often (about 60% of losses) the agent heard the requirement, took it on, and still did it wrong. Only about 17% of losses happen because the user never stated what they needed. There is a second problem too: the agent often reports having done things it didn't do. More than half of failed actions end up looking “done” to the user, and once you check the actual state of the site, about a quarter still do. Two obvious fixes didn't help: neither showing the agent the user's profile nor forcing it to ask a question before starting won back the lost quality.
The practical takeaway from the diagnostic method: for every requirement, distinguish three things. Was it stated, did the agent take it into account, was it actually done. The paper used this to find exactly where results get lost. For you, it turns into a rule: state requirements explicitly, ask the agent to report on each one, and verify the outcome by the actual state of things, not by the agent's story.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
Here is how the benchmark works. The last line is the part that matters for practitioners: a triple check on every requirement.
STEP 1: Take an existing task + a person's profile (37 attributes)
→ an AI “user” rewrites the task in their own words
STEP 2: The agent sees only this dialogue, works in the browser,
and can ask the “user” up to 5 questions
STEP 3: Two scores: was the original task completed + is the “user” satisfied
STEP 4: Each lost requirement → one of three causes:
NOT STATED / NOT ADDRESSED by the agent / ADDRESSED BUT DONE WRONG
Example in Practice
Where this finding hits hardest: actions with consequences (payment, sending, an offer), where the client's requirements fit in a line or two and where the agent loves to “push it over the finish line.”
Task: The founder of a small design studio asks a browser agent to find a presentation designer on Fiverr and draft an offer. The price is fixed up front. Nothing gets sent without her “ok.” Her other habit: she writes tasks on the run, in a single sentence. The research shows this is exactly how requirements get lost: the agent either blows past the confirmation step or reports “done” where it actually stopped halfway.
Prompt:
<Task>
Find a freelancer on Fiverr to design an investor pitch deck
(25 slides, needed by Friday). Prepare an offer for them.
</Task>
<Requirements>
R1. Budget no more than $500 for the whole project.
R2. Freelancer rating at least 4.8, with at least 20 reviews.
R3. Delivery no later than Friday.
R4. The price in the offer is fixed as final, no “starting at.”
</Requirements>
<Stops>
Do NOT send the offer. Stop at the draft and wait for my “send it.”
If you need to spend money or share my personal data, ask first.
Stopping before sending counts as successful completion, not failure.
</Stops>
<Report>
At the end, for each requirement R1–R4, give three marks:
- Stated: yes/no (was it in my task)
- Addressed: yes/no (did you apply it while working)
- Done: yes/no + what confirms it (link, number on the page, screenshot)
If “done” can't be confirmed, write “not confirmed,” not “done.”
Separately list anything you did outside the list of requirements.
</Report>
Result: The agent runs the search and stops at a draft offer without sending it. At the end you get a table for each of the four requirements with three marks and evidence. If the agent didn't check something (say, the number of reviews), it shows up as “not confirmed” instead of hiding under a blanket “done.” A separate list covers whatever the agent did on its own initiative.
Why It Works
The weakness. A human request doesn't look like a test spec. Some requirements go unstated, some get mentioned in passing, and some live only in personal context (for example, “confirm the price with me first”). An agent tuned to see a task through to the end easily drops that kind of requirement along the way or skips the very item the user considered most important. Worse, at the end it describes the result as if everything were done. The paper shows a gap between the agent's report and the actual outcome in a noticeable share of cases.
The strength. Models follow explicit structure well: numbered items, prohibitions, a report format. Once each requirement has a number, it's easy to check them one by one. The question “is R2 done?” demands a specific answer. The question “is everything done?” lets the agent get away with a generic “yes.”
How the method gets around the weakness. The paper breaks each loss into three points: not stated, not addressed, addressed but done wrong. The template above moves that breakdown into the request itself. Requirements are named up front, and the report asks for evidence on each one. Stopping before an irreversible action is declared a success, so the agent doesn't treat it as failure.
Control levers:
- Number of requirements (R1…Rn). The more items, the more expensive the report. Keep only what actually affects the result.
- The <Stops> block. Widen or narrow the list of actions that need your “ok” (money, sending, sharing data).
- The <Report> block. Drop “what confirms it” if the task is simple. Keep it if a mistake is costly.
- Verify the outcome. For actions, look at the state of the site, not the report: what actually landed in the cart, the drafts, the order.
Prompt Template
The paper doesn't offer a ready-made agent prompt. This is a transfer of its diagnostics (stated / addressed / done) and its findings about stopping into a request. The paper did not test it as a standalone method.
<Task>
{the task in 1–2 sentences: what you need to get out of it}
</Task>
<Requirements>
R1. {requirement 1 — specific, with a number or condition}
R2. {requirement 2}
R3. {requirement 3}
{add here whatever you usually “take for granted”: budget, deadline, sources, format}
</Requirements>
<Stops>
Do not do the following without my confirmation: {list of irreversible actions: sending, payment, publishing, sharing data}.
Stopping at a draft or before confirmation is a success, not a failure.
If you lack data for a requirement, ask once, briefly, straight to the point.
</Stops>
<Report>
At the end, for each requirement R1…Rn, write:
- Stated: yes/no
- Addressed: yes/no
- Done: yes/no + what confirms it ({link / number on the page / screenshot})
If it can't be confirmed, write “not confirmed.”
Separately list any actions you took outside the list.
</Report>
What to fill in: {task} — the outcome you want, not the process. {requirement} — everything you would check yourself in the finished work. {actions} — everything that can't be undone.
🚀 Quick start — paste into the chat:
Here is an “explicit agent brief” template. Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask which outcomes and constraints are mandatory for you and which actions must not happen without your “ok.” The point is to surface what you “meant” but never said. Exactly these unspoken requirements account for a noticeable share of losses in the study.
Limitations
⚠️ The cure is untested: the paper shows where results get lost and tested two “obvious” remedies. The authors did not test the “explicit brief + per-requirement report” template itself. It's a transfer of their findings, not a measured technique.
⚠️ Showing the profile didn't help: when the agent was given the full user profile, the losses didn't come back. On information tasks the result even dipped slightly, most of all for the “older adult” personas. Don't expect “tell the agent who I am” to solve the problem.
⚠️ Forced questions didn't help: when the agent was made to ask a question before starting, results on persona requests barely changed. On the original action requests they even got worse: the “user” answered with constraints that weren't in the task. Only about a quarter of the agents' questions targeted a missing requirement at all. A box-ticking question just adds noise.
⚠️ Simulated users and judge: the same AI model plays both the “users” and the evaluator. There are no real people in the main experiment, although the judges were validated against human labels. Check every conclusion on your own tasks and real clients.
⚠️ Small, narrow set: 74 tasks, browser agents, some on prepared copies of websites. The interventions were tested on a single model.
⚠️ A requested stop counts as failure: the benchmark's automatic check records “stopped at the draft” as a failure, even when the user asked for exactly that. This is part of the measured drop, not just agent error.
How They Studied It
The researchers took 74 tasks from two existing benchmarks: information tasks on live websites and actions on copies of popular websites (ordering food, sending an email, making a booking). The tasks span 11 domains. Each task went to the agent five times: in its original wording and on behalf of four personas (an expert, an older adult, a young person, a busy professional). Each persona was described by 37 attributes: age, education, income, experience, time pressure and more.
A key design detail. The agent sees neither the profile nor the original task. It gets only the “person's” message, written by an AI actor playing the persona, and can ask up to five questions. This tests how the agent copes when all it knows about the person is what they said. Nine models were run with the same tools and budget (up to 100 steps). Results were scored two ways: was the original task completed, and is the “user” satisfied. Then every lost requirement was labeled with the triple tag “stated / addressed / done.”
The big picture: the average completion rate fell from 0.689 to 0.441. Every model lost between 28 and 45% of its score. Models swap places: Gemini was one of the leaders on original requests (0.734), but dropped to seventh place on the “older adult” requests. So model rankings on “clean” tasks are a poor predictor of who will do better with a real client.
The main point on loss causes (1,230 lost cells). In 59.9% the agent addressed the requirement but did it wrong. In 17.1% the requirement was never stated. In 2.1% it was stated, but the agent never got to it. The remaining losses are stops: 11.2% at the user's request (a draft, a review), 9.7% on the agent's own initiative. Older adults leave more unsaid (about 23% of their losses vs. 6% for experts).
Unexpectedly, completion and satisfaction diverged. Of fully completed persona tasks, only 62.7% got a top score (vs. 84.1% for original requests). On the flip side, 56% of failed actions looked completed to the “user,” and 27% still did after checking the site's state. The reasons: legitimate stops the user had asked for, and errors in the agent's report.
Next, the authors ran two interventions on a single model. Adding the profile to the request didn't recover the loss. Neither did forcing a question. This is the most instructive part: “give more information about the person” and “make it ask” are no substitute for precisely executing the stated requirements.
Adaptations and Extrapolations
💡 Extrapolation: a rule for the agent's instructions file (AGENTS.md / CLAUDE.md). This is my own extension; the paper didn't test it. The idea: move the
<Stops>and<Report>blocks into permanent rules so you don't repeat them in every request.## Rules for handling user requests - Before starting, list all requirements from the request as R1…Rn, including implicit ones (budget, deadline, format). - Irreversible actions (sending, payment, publishing, deletion) only after my explicit “ok.” - Stopping at a draft when I asked you to prepare or review something is successful completion. - Final report: for each Rn — stated / addressed / done + evidence. If it can't be confirmed, write “not confirmed,” not “done.” - Ask questions only when a specific requirement can't be met without an answer. One question, to the point.
Resources
- Paper: PersonaCUABench: Benchmarking Computer-Use Agents Serving Diverse Personas (October 19, 2026).
- Authors: Haoming Li, Defu Cao, Xu Hu (equal contribution), Yuexing Hao (MIT) and Xiaomin Li (Harvard) — corresponding authors. Institutions include University of Texas at Dallas, University of Southern California, Carnegie Mellon University, Georgia Tech, UCLA, Harvard, MIT and others.
- Task sources: the Odysseys benchmark (long information tasks on live websites) and REAL (actions on copies of popular websites).
- Persona schema: MatrAIx (1,290 attributes, of which 37 were used in this work).