Ask Jev well.

An option list is a snapshot. Build it once at the start of a multi-step run and it starts drifting away from reality immediately — the row got archived, the button moved, the ticket was closed by someone else. The answer will still be well-typed, and it will still name something that is no longer there.

Browser Use’s jev-ultrafast regenerates the list of page controls before every decision, so the model only ever picks among things that exist right now. Regenerating costs you one cheap step and removes a whole class of failure that is otherwise very hard to see in a log.

Questions asked in one batch cannot read each other’s answers. That is the whole rule, and most of the mistakes come from forgetting it: a second question written as though the first one already answered it simply gets no answer to work from.

So split the work in two. Anything one question needs from another is a lookup, and lookups belong in your code, before the batch. What is left is genuinely independent, and all of it goes in a single round trip instead of a chain of them.

The model reads what you wrote. It does not read the variable holding the option, the enum it came from, or the comment above the function. An option called tier_2 carries no meaning at all; “needs a specialist, not the general queue” carries the meaning you actually had in mind.

The same is true of the question itself. Whatever rule a trained person would apply — the deadline, the exception, the thing that makes this a borderline case — belongs in the sentence. If you find yourself explaining the answer afterwards, that explanation was the question.

When you compress the state into one tidy paragraph before asking, you have already made the judgment — in code that nobody reviews and no test covers. Whatever your summariser dropped is now invisible to the decision that depends on it.

Pass the pieces instead, as separate fields: what you found, where each piece came from, and what you looked for and did not find. The gaps matter as much as the findings, and they are the first thing a summary throws away. It also makes a wrong answer readable afterwards, because you can see exactly what the question was holding.

A confidence of 0.9 is the model’s own report about its answer. It is not a measured hit rate, and it does not mean nine out of ten answers at that level were right on your data. Picking 0.9 as a review threshold because it looks high is guessing with a decimal point in it.

Label a few hundred of your own examples, bucket the answers by reported confidence, and look at how often each bucket was actually right. That table tells you where to draw the line for the cost you are willing to carry. Redraw it when the traffic changes, because the curve moves with your inputs, not with the model.

A Choice holds up to 255 options. That is generous, and still far smaller than most real catalogues, inventories, or user lists. The answer is not a bigger question — it is three smaller stages.

Cut the list with the constraints you can state exactly: availability, region, permissions, anything a WHERE clause already knows. Rank what survives with a Score. Then put the handful at the top into a Choice for the judgment that genuinely needs one. Each stage is cheaper than one enormous question and, more usefully, each can be tested on its own.

Deciding to click the button and the button having been clicked are two different facts, and only one of them is in the answer. Confidence describes the judgment, never the side effect that followed it.

jev-ultrafast checks its outcome separately, after the run reports that it is done. Do the same with anything that can spend money, send something, or delete something: verify the result against the world, not against the decision. And keep the guardrails where they can be read and tested — how many attempts are allowed, how much may be spent, and where the run got to — in your code, not in the question.