Ozan

The thing I would add from operating these: the expensive failure is almost never a single expensive call. It is a cheap call repeated.

What that means practically is that your per-call cost estimate barely matters and your loop detection matters enormously. The runs that hurt me were an agent retrying a failing tool with a slightly different argument each time, so no naive duplicate check caught it, several hundred times.

Two things that helped more than any budget:

• Detect repetition semantically. Same tool, similar arguments, no progress on the task for N steps → stop. Not a cost control, a sanity control, and it fires earlier.
• Make failures terminal by default. A tool that fails twice should stay failed for that run rather than remaining available. Most runaway loops are an agent optimistically retrying something that will never work.

And log cost per run against the run's outcome. You will find a small number of runs consuming most of the spend, and they are usually the ones that failed.

The second half is that approval fatigue is a security failure, not a UX complaint.

If your agent asks twenty times an hour, people stop reading the prompts within two days and start approving reflexively. At that point the approval step is worse than nothing, because it creates a record suggesting a human considered each action.

So the design constraint is a budget: how many approvals per hour will a person actually read? In my experience it is small — single digits. Anything above that and you are building a rubber stamp.

Which means the work is mostly in reducing the number of approvals, not designing the dialog. Batching several actions into one reviewable plan, approving a scope rather than a step, and moving actions into the reversible bucket by giving them an undo, are all better than a better prompt.

The second reason, and I think it is the bigger one commercially: credentials and isolation.

A script runs somewhere you control with credentials you provisioned. An agent browsing the web on your behalf raises immediate questions:

• Which sessions is it logged into, and can it reach your bank because your profile was reused?
• What stops a page it visits from containing text that redirects it — prompt injection through page content is a genuine, demonstrated problem and the browser is the delivery vehicle.
• Where does it run, if you do not want it on your laptop with your cookies?

That explains the edge-worker one on your list. Running the browser somewhere disposable, with a scoped profile, is a real architectural answer rather than a packaging choice.

So a good chunk of these products are less about the browser and more about the sandbox around it. That is the part I would evaluate them on.

Where it earns its keep, in my experience:

• Many clients, one service. Several assistants, several teams, people using different tools. The protocol means you describe your capability once.
• Capabilities that change. Runtime discovery means clients pick up new tools without redeploying anything.
• You are a product and your users have assistants. This is the case driving the wave you noticed. It is a distribution channel, and treating it as marketing rather than engineering is the correct read.

Where it does not:

• One caller you control. Call the API.
• High-volume or latency-sensitive paths. There is overhead, and the protocol is aimed at interactive use rather than at a hot loop.
• Anything where the hard part is authorisation. Wrapping an API does not answer who is allowed to do what, and that question gets harder, not easier, when an agent is the caller.

On the tracing products specifically: what they are genuinely good at is the thing that is annoying to build, which is making one run inspectable after the fact.

When a run fails in production you want the full sequence — prompts, tool calls, arguments, returns, timings — laid out and searchable, months later. Building that yourself is a week and maintaining it is forever.

What they are not is an evaluation set. Several of them offer model-graded scoring, which is useful for things code cannot check — tone, whether a summary is faithful — and it is a fuzzy instrument. Grade with it if you must, and do not let it be your only signal, because a model grader has its own failure modes and they correlate with the model being graded.

So: buy tracing if the storage and UI is worth the money to you. Build the benchmark yourself regardless. The second one is where the answer to your question actually lives.