AI Engineer · Published 2026-10-02

Why 99% Accurate Browser Agents Still Fail — Derek Meegan, Browserbase

Open on YouTube ↗

Summary

Overview

  • Speaker: Derek Meegan
  • Channel: AI Engineer
  • Main topic: Deploying browser agents into production and building reliable web automation systems
  • Purpose: To provide engineers with a practical framework for building reliable, cost-effective, and maintainable browser automation agents for production use cases. Derek Meegan, a software engineer at Browserbase, explains why browser agents that work well in demos fail in production. He discusses the output of models as probability distributions, the complexity of browser interfaces, transactional workflows at scale, the compounding math of reliability (e.g., 0.99^100 = 36%), three dimensions of production agents (performance, cost, maintainability), and an architectural framework to transition from demos to production-ready agents.

Topic Map

How browser agents interact with the web

  • Explanation: The model receives input tokens representing page state, goals, and history, outputs a probability distribution over possible actions, and executes structured tool calls deterministically.
  • Key claims:
    • The output of a model is a probability distribution over actions.
    • Browser interfaces have multiple complex layers: network, DOM, screenshot, accessibility tree, browser state, and JavaScript execution runtime (CDP).
  • Examples:
    • Using structured representation (DOM + accessibility tree), computer use (screenshot-driven), or harnessing the agent with arbitrary JS or CDP.
  • Terminology:
    • DOM
    • accessibility tree
    • CDP (Chrome DevTools Protocol)
    • structured representation
  • Why it matters: Understanding the multi-layered browser interface helps engineers choose the right wiring strategy for their agents.

The browser agent conundrum in production

  • Explanation: Cost and risk accumulate continuously with every step, while value realization is terminal only upon full task completion. There is no partial credit in browser automation.
  • Key claims:
    • Cost accumulation is continuous, value realization is terminal.
    • 0.99 success rate across 100 steps yields an overall success rate of only 36%.
  • Examples:
    • A 100-step workflow where each step has a 99% success rate resulting in 36% end-to-end success.
  • Terminology:
    • cost accumulation
    • terminal value
    • partial credit
    • trajectory
  • Why it matters: It demonstrates why high individual step accuracy is insufficient for long-horizon tasks at scale.

The framework: three dimensions of importance

  • Explanation: Evaluating browser agents through performance (value delivered), cost (per run and over time), and maintainability (keeping it working as models and sites change).
  • Key claims:
    • Performance is the primary measure of success; once achieved, cost and maintainability become optimization problems.
    • Success is a concrete artifact the run leaves behind, such as a confirmation email, order ID, or record in a database.
  • Examples:
    • Paying a bill resulting in a confirmation email; placing an order resulting in an order ID on a receipt.
  • Terminology:
    • performance
    • cost
    • maintainability
    • retries
  • Why it matters: Provides a structured engineering approach to measure and improve agent deployments.

Generating shareholder value: building a production browser agent

  • Explanation: Taking a health insurance portal automation task from demo to production by wrapping brittle sequences in custom tools, verifying by OCR deterministically, taking auth out of the model's hands, and graduating converged paths into skills.
  • Key claims:
    • Wrapping multi-step interactions into single tool calls reduces model decision points.
    • Deterministic tools like OCR and serverless auth take non-ambiguous steps out of the model's responsibility.
  • Examples:
    • Automating log in, downloading Explanation of Benefits (EOB), verifying via OCR against a database, and reusing serverless auth.
  • Terminology:
    • custom tool
    • OCR verification
    • serverless auth
    • skill
  • Why it matters: Shows concrete architectural steps to lower unicogs, increase performance, and improve maintainability.

Key Points

Demo vs. Production

  • Explanation: A demo is one run on one site with someone watching, whereas production involves thousands of unmonitored runs where sites change and models have off days.
  • Evidence: Thousands of runs, unattended, while the site can shift beneath you.
  • Practical implication: Production systems require robust error handling, retries, and deterministic guardrails.

No partial credit

  • Explanation: Web automations only pay off on total completion; failing on the last step means losing the value of all prior steps.
  • Evidence: 0.99 to the 100th power equals 36% success rate for 100 steps.
  • Practical implication: Engineers must minimize the number of steps and wrap brittle sequences into deterministic tools.

Profits = revenue - costs

  • Explanation: Browser agents must provide more value than they consume in compute, model cost, and developer maintenance time.
  • Evidence: Profits = revenue - costs equation applied to agent deployments.
  • Practical implication: Agent architecture must optimize unit economics alongside task success.

Frameworks, Models & Processes

Three Dimensions of Agent Success

  • How it works: Evaluate agent systems in order of importance: Performance first, Cost second, Maintainability third.
  • Components:
    • Performance (value delivered)
    • Cost (COGS per run, infrastructure, tooling)
    • Maintainability (observability, developer time, re-evaluation)
  • When to use: When designing, evaluating, and scaling browser agent architectures.

Production Agent Hardening Architecture

  • How it works: Gradually remove non-ambiguous operations from the model's responsibility by introducing deterministic tools, serverless auth, and hardcoded skills.
  • Components:
    • Serverless auth function
    • Custom wrapper tools for multi-step tasks
    • Deterministic OCR verification tool
    • Skills representing converged critical paths
  • When to use: When moving a browser agent from prototype/demo to a reliable production system.

Examples & Case Studies

Running a 100-step browser agent where each step has a 99% success rate.

  • Illustrates: The compounding failure rate of long-horizon agent tasks.
  • Lesson: Reliability drops to 36% at scale, proving that step-level reliability must be extremely high or horizons must be shortened.

Automating a health insurance portal to log in, download EOBs, and verify records.

  • Illustrates: Transitioning from raw agent exploration to a structured system using serverless auth, wrapped download tools, and OCR verification.
  • Lesson: Constraining the model with deterministic tools improves performance, reduces cost, and increases maintainability.

Actionable Takeaways

  • Immediate:
    • Permit a few retries per transaction (e.g., up to 4 tries) to dramatically boost per-transaction success rates.
    • Identify brittle multi-step sequences in browser interactions and wrap them into single deterministic tool calls.
    • Pull authentication logic out of the model's hands using serverless functions.
  • Strategic:
    • Prioritize performance first, then treat cost and maintainability as engineering optimization problems.
    • Graduate frequently used, converged agent paths into hardcoded skills to remove ambiguity.
    • Measure success by concrete business artifacts (receipts, confirmation emails, database records) rather than step completion.
  • Questions to investigate:
    • How do we balance agent autonomy with deterministic tooling?
    • What is the optimal threshold for retry attempts before failing a transaction?
    • How can observability be improved for multi-layered browser state changes?

Claims Worth Verifying

  • 0.99^100 equals 36% success rate (mathematical calculation)

Notable Quotes

"A demo is one run, on one site, on a good day, with you watching, and your fingers crossed." "With browser agents, there is no partial credit." "Your agent should give you more than it takes."

Compressed Summary

  • Browser agents face extreme compounding risk over long multi-step horizons.
  • Performance, cost, and maintainability form the core evaluation framework.
  • Wrapping brittle sequences into custom tools and OCR verification builds production reliability.
  • Removing authentication and deterministic steps from the model lowers costs and raises success rates.
  • Keywords: browser agents, automation, reliability, production, tooling
  • Core insight: Production browser agents succeed by moving from unconstrained model exploration to hybrid systems combining deterministic tools, serverless auth, and hardcoded skills.

Core insights

7
Empirical Resultmedium noveltystrong evidence

Reliability compounds multiplicatively across agent steps, so per-step accuracy is a misleading metric for long-horizon tasks: a 99% per-step success rate over 100 steps yields only ~36% end-to-end success. The architectural response is to shorten effective horizons or push step-level reliability near-certainty, not to chase marginal per-step accuracy.

Why it matters

It reframes the design goal from 'make the agent smarter per step' to 'reduce the number of model-controlled decision points,' which changes where effort and engineering budget should go.

Generalization

Any multi-step stochastic pipeline where value is only realized on full completion inherits the same compounding penalty; minimizing the count of probabilistic decisions is a general reliability lever.

0.99 to the 100th power equals 36% success rate for 100 steps
Open source video
a 99% success rate across 100 steps yields an overall success rate of only 36%
Open source video
Mental Modelmedium noveltystrong evidence

Browser agents have an asymmetric cost/value structure: compute and risk accumulate continuously with each step, while value is realized only at terminal task completion. This means failed late steps forfeit the cost of all prior steps, so cost-of-failure scales with trajectory length.

Why it matters

It reframes economics: designing for shorter, verifiable trajectories is a cost optimization, not just a reliability one.

Generalization

In any system with continuous cost accrual and terminal-only payoff, expected cost per successful outcome grows non-linearly with horizon length, penalizing long agent trajectories.

Cost accumulation is continuous, value realization is terminal.
Open source video
There is no partial credit in browser automation.
Open source video
Architecturemedium noveltystrong evidence

A core hardening move is to wrap brittle multi-step browser sequences into single deterministic tool calls, reducing the number of model-controlled decision points that can each fail probabilistically.

Why it matters

It relocates responsibility from the probabilistic model to deterministic code, directly attacking the compounding-failure problem by shrinking the exponent.

Generalization

Wrapping fragile, well-understood sub-procedures into atomic deterministic tools is a reusable pattern for reducing variance in any LLM-orchestrated workflow.

Wrapping multi-step interactions into single tool calls reduces model decision points.
Open source video
Identify brittle multi-step sequences in browser interactions and wrap them into single deterministic tool calls.
Open source video
Architecturemedium noveltystrong evidence

Non-ambiguous operations (authentication, and verification of downloaded artifacts via OCR against a database) should be removed from the model's responsibility and executed deterministically, because the model's output is a probability distribution over actions rather than a reliable oracle.

Why it matters

It draws an explicit architectural boundary: the model orchestrates; deterministic subsystems handle anything with a single correct answer, improving reliability and reducing cost.

Generalization

For any step with a verifiable ground truth, replace model judgment with deterministic tooling; reserve the model for genuinely ambiguous decisions.

Deterministic tools like OCR and serverless auth take non-ambiguous steps out of the model's responsibility.
Open source video
The output of a model is a probability distribution over actions.
Open source video
Practicehigh noveltymoderate evidence

As an agent's behavior converges on a stable critical path, that path can be 'graduated' into a reusable skill — a deterministic artifact — rather than re-derived by the model on every run.

Why it matters

It suggests a runtime-to-artifact promotion pipeline where successful convergent behavior is compiled down into cheaper, more reliable units over time.

Generalization

Agents can be progressively hardened by observing convergence and freezing stable trajectories into lower-variance primitives, a general pattern for long-lived agent deployments.

graduating converged paths into skills
Open source video
skills representing converged critical paths
Open source video
Gradually remove non-ambiguous operations from the model's responsibility by introducing deterministic tools, serverless auth, and hardcoded skills.
Open source video
Mental Modelmedium noveltymoderate evidence

Success should be defined operationally as a concrete artifact the run leaves behind (confirmation email, order ID, database record), giving an objective, verifiable termination signal rather than relying on the model's self-reported completion.

Why it matters

It provides a testable definition of success that can drive evaluation and monitoring of unattended production runs.

Generalization

Grounding agent success in externally verifiable side effects is a general evaluation principle for autonomous systems.

Success is a concrete artifact the run leaves behind, such as a confirmation email, order ID, or record in a database.
Open source video
Paying a bill resulting in a confirmation email; placing an order resulting in an order ID on a receipt.
Open source video
Failure Modelow noveltymoderate evidence

The gap between demo and production is operability under unattended scale: a demo is one watched run on a stable site, while production is thousands of unmonitored runs against sites that can change and models that can have off days.

Why it matters

It explains why demo success does not predict production success and motivates retries, deterministic guardrails, and maintainability investment.

Generalization

Any agent evaluated in a single-context, supervised setting will overstate reliability relative to high-volume, unsupervised, environment-drifting deployment.

A demo is one run on one site with someone watching, whereas production involves thousands of unmonitored runs where sites change and models have off days.
Open source video
Thousands of runs, unattended, while the site can shift beneath you.
Open source video

Deep dives

5

Reliability-vs-horizon budgeting and cost-optimal retry counts

Research question

Given a per-step reliability p, a per-step cost c, and a target end-to-end success rate, what is the cost-optimal (horizon length, retry count) pair — and does the success-maximizing retry count systematically overshoot the cost-minimizing one?

Why

The talk supplies a heuristic ('up to 4 tries') and a compounding formula but no decision rule. Without one, teams either over-retry (burning compute on terminal-value tasks) or under-retry (shipping a 36% agent). A closed-form or empirical planner converts the compounding math from a warning into an engineering budget.

0.99 to the 100th power equals 36% success rate for 100 steps
Open source video
Cost accumulation is continuous, value realization is terminal.
Open source video
Permit a few retries per transaction (e.g., up to 4 tries) to dramatically boost per-transaction success rates.
Open source video
Source video

Convergence detection and skill-promotion gating

Research question

What measurable signals (action-sequence similarity, artifact identity repeats, plan-tree stability) reliably indicate that a trajectory has converged, and what promotion threshold prevents promoting lucky-but-unstable paths into deterministic skills?

Why

Graduating converged paths into skills is the highest-novelty claim in the analysis, but it is also the most under-specified: without a detection criterion, automation of promotion either never fires or freezes flukes into hardcoded behavior. This is the gating mechanism that makes the runtime-to-artifact pipeline safe.

graduating converged paths into skills
Open source video
skills representing converged critical paths
Open source video
Gradually remove non-ambiguous operations from the model's responsibility by introducing deterministic tools, serverless auth, and hardcoded skills.
Open source video
Source video

Does tool-wrapping reduce failure or relocate it?

Research question

On production-representative multi-step workflows, does wrapping brittle sequences into single deterministic tool calls reduce end-to-end artifact success rate, or does it merely move the same failure probability into a less observable tool layer?

Why

This is the load-bearing causal claim of the whole architecture and it is untested in the summary. If wrapping only relocates failure, the recommended hardening recipe is cargo cult; if it reduces it, teams gain a quantified lever (decision points removed per unit of success gained). Either result is actionable.

Wrapping multi-step interactions into single tool calls reduces model decision points.
Open source video
Identify brittle multi-step sequences in browser interactions and wrap them into single deterministic tool calls.
Open source video
Source video

Drift detection for hardened artifacts

Research question

How do wrapped tools, hardcoded skills, and serverless auth flows degrade when target sites change, and what observability signal fires before a whole run silently breaks?

Why

Hardening shifts brittleness rather than deleting it. The maintainability dimension of the three-axis framework is only meaningful if hardened artifacts are instrumented; otherwise the cost of deterministic tooling is deferred to a future outage.

A demo is one run on one site with someone watching, whereas production involves thousands of unmonitored runs where sites change and models have off days.
Open source video
Thousands of runs, unattended, while the site can shift beneath you.
Open source video
Source video

Model responsibility boundary for non-ambiguous operations

Research question

Which classes of browser tasks have a single verifiable correct answer (auth, artifact verification, form validation, download checks) such that deterministic tooling dominates model judgment on both reliability and cost?

Why

The claim that models output probability distributions over actions is uncontroversial, but the operational consequence — an explicit partition of workflow steps into ambiguous vs. non-ambiguous — is the actionable artifact. A taxonomy would let teams audit a workflow and delete model calls rather than tuning prompts.

The output of a model is a probability distribution over actions.
Open source video
Deterministic tools like OCR and serverless auth take non-ambiguous steps out of the model's responsibility.
Open source video
Source video

Article ideas

4

Your 99% Agent Is a 36% Agent

Per-step accuracy is a vanity metric: because agent value is terminal and failure costs are cumulative, the only honest production KPI is artifact yield per unit of expected spend, and reliability must be budgeted across a horizon rather than improved locally. Teams that report step-level accuracy are reporting the one number that cannot predict production outcomes.

Angle

Take the 0.99^100 figure and push it into an engineering planning rule: given a target success rate, derive the maximum allowable horizon and required per-step reliability, then show how that reshuffles where engineering effort goes (horizon shortening beats prompt tuning).

Source video

Delete the Model Wherever the Answer Is Unique

The highest-leverage reliability work in an agent system is subtractive: every step with a single verifiable correct answer — login, artifact verification, download checking — should be removed from the model's responsibility and executed deterministically, because a probability distribution is the wrong tool for a task with one right answer. Tool-wrapping is not a convenience pattern; it is how you shrink the exponent on compounding failure.

Angle

Reframe deterministic tooling as an explicit architectural boundary decision, with a step-audit checklist (ambiguous vs. non-ambiguous) rather than a library recommendation.

Source video

Demo Success Is a Volume Artifact

The demo-to-production gap is not a capability gap, it is a scale and drift gap: one watched run against a stable site is a fundamentally different statistical object than thousands of unattended runs against shifting sites and models having off days. Treating a demo as evidence of reliability is a category error, and the fix is operational (retries, artifact verification, drift watch) rather than model-side.

Angle

Argue that demo success predicts nothing about production and specify what evidence would — artifact-verified yield curves over N unattended runs with drift events included.

Source video

Compile Your Agent: Graduating Converged Paths into Skills

Long-lived agents should get cheaper and more reliable over time by compiling observed convergent behavior into deterministic artifacts, turning runtime re-planning into a fixed critical path. The interesting engineering problem is not whether an agent can plan, but whether it can recognize when planning is no longer necessary — and that requires a promotion gate, not a prompt.

Angle

Frame the runtime-to-artifact promotion pipeline (observe → converge → gate → freeze → watch for drift) and argue it is the missing maintenance model for agent deployments.

Source video

Project ideas

4

Trajectory Budget Planner

new

For any workflow with measured per-step reliability p and per-step cost c, there exists a retry count r* that minimizes expected cost per successful artifact, and r* is strictly smaller than the retry count that maximizes raw success rate; additionally, beyond a computable horizon length, no realistic per-step reliability improvement is economically rational for a fixed cost-per-step.

Proof of concept

Instrument 3 browser workflows of 20, 50, and 100 steps, measure per-step success and cost, then sweep retries 1-8 in simulation and in live runs to produce expected-cost-per-artifact curves against a target success threshold.

Measurement

Expected cost per successful artifact as a function of retry count and horizon length; the horizon at which cost per success diverges; the gap between cost-optimal and success-optimal retry counts under varying step cost.

Source video

Artifact Oracle

gatehouse

Grounding success in a machine-verifiable external artifact (confirmation email, order ID, database record) instead of model self-report reveals a substantial silent-failure rate, and deterministic verifiers can cover the majority of common workflows without any model judgment in the verification step.

Proof of concept

Build deterministic verifiers for three workflow types (bill-pay confirmation email, order receipt ID, DB record write) and wire them as the termination signal in an unattended run loop; compare agent-declared success against artifact-verified success across the same runs.

Measurement

Delta between self-reported success rate and artifact-verified success rate; false-positive completion rate; verification latency and cost per run; fraction of workflows coverable by deterministic verifiers alone.

Source video

Wrap-vs-Step A/B

beyond-evals

Wrapping brittle multi-step browser sequences into single deterministic tools reduces end-to-end artifact success rate failure on 50+ step workflows by more than the failure rate introduced by the wrapper artifacts themselves — i.e., failure is genuinely reduced, not relocated to the tool layer.

Proof of concept

Implement the same 3 production-representative workflows twice — raw step-level agent and tool-wrapped agent, same model, same sites — and run N≥200 unattended trials each with artifact verification and per-step decision-point logging.

Measurement

End-to-end artifact success rate, model decision points per run, cost per success, and attribution of failures to model decisions vs. tool-layer artifacts (equal-failure-rate outcome falsifies the hypothesis).

Source video

Skill Graduation Pipeline

movement-lab

A convergence detector combining action-sequence similarity and repeated artifact identity can auto-promote stable trajectories into deterministic replayable skills such that cost per success falls measurably without dropping success rate below the pre-promotion baseline.

Proof of concept

Log action sequences and artifacts across repeated runs of a fixed workflow, cluster trajectories, auto-promote clusters crossing a stability threshold into replayable deterministic skills, and keep a drift watch that re-runs the live path against the frozen skill.

Measurement

Runs-to-promotion, cost and step-count per success before vs. after promotion, success-rate regression against baseline, and mean time-to-detect when a promoted skill stops matching the live site.

Source video

Architectural implications

4

Model decision points are a scarce reliability resource; deterministic tools are the mechanism to remove them.

Before

Agent decides each low-level browser step (click, type, navigate) directly.

After

Multi-step sequences are wrapped into single deterministic tool calls, and the model only selects between high-level tools.

Consequence

Fewer probabilistic decision points per trajectory, reducing compounding failure and per-run cost.

Source video

Authentication and artifact verification have unambiguous correct answers, unlike genuinely ambiguous web interactions.

Before

Model handles login and self-assesses whether the correct artifact was retrieved.

After

Serverless auth function logs in; deterministic OCR verification checks the downloaded artifact against a database.

Consequence

Removes high-risk, non-ambiguous operations from the model's responsibility and enables objective success signals.

Source video

Repeated successful trajectories reveal a stable critical path that need not be re-derived.

Before

Model re-plans the full path on every run.

After

Converged paths are graduated into reusable skills.

Consequence

Repeated work is compiled into cheaper, more maintainable primitives, lowering long-run unit cost.

Source video

Evaluation ordering matters: performance gates cost and maintainability.

Before

Cost and maintainability are optimized before the agent reliably delivers value.

After

Performance (value delivered) is established first; cost and maintainability become subsequent optimization problems.

Consequence

Prevents premature optimization of cheap-but-broken agents and sequences engineering effort by impact.

Source video

Tradeoffs and failure modes

4

Retries versus accumulated cost

Benefit

Allowing a few retries per transaction (e.g., up to 4) dramatically boosts per-transaction success rates.

Cost or risk

Because cost accumulation is continuous while value is terminal, retries multiply compute and model spend on failed attempts.

Permit a few retries per transaction (e.g., up to 4 tries) to dramatically boost per-transaction success rates.
Open source video
Source video

Deterministic tools versus generalization

Benefit

Wrapping brittle sequences into deterministic tools improves reliability, lowers cost, and improves maintainability.

Cost or risk

Hardcoded skills and wrapped tools may break when the underlying site changes, shifting maintenance burden and brittleness rather than eliminating it.

Gradually remove non-ambiguous operations from the model's responsibility by introducing deterministic tools, serverless auth, and hardcoded skills.
Open source video
Source video

High per-step accuracy versus long horizons

Benefit

High per-step success rates are achievable and appear strong in isolation.

Cost or risk

Long-horizon tasks erode that advantage via compounding failure, so per-step accuracy alone is insufficient.

0.99 success rate across 100 steps yields an overall success rate of only 36%
Open source video
Source video

Representation choice for browser state

Benefit

Structured representation (DOM + accessibility tree), computer use (screenshot-driven), or raw JS/CDP harnesses each expose different browser layers.

Cost or risk

Each wiring strategy trades off how much of the multi-layered interface (network, DOM, screenshot, accessibility tree, browser state, CDP) the model must reason over, affecting reliability and cost.

Browser interfaces have multiple complex layers: network, DOM, screenshot, accessibility tree, browser state, and JavaScript execution runtime (CDP).
Open source video
Source video

Open questions

5

What is the optimal number of retries and step-length budget given a target success rate and a per-run cost model?

Why unresolved

The summary provides the retry heuristic (up to 4) and the compounding formula but no cost model or break-even analysis tying them together.

Research direction

Build an expected-cost model over trajectory length, per-step accuracy, and retry count to find cost-optimal configurations for given success targets.

Source video

How is convergence detected and validated before a path is graduated into a skill?

Why unresolved

The summary describes graduating converged paths into skills but does not specify detection criteria or validation thresholds.

Research direction

Define measurable convergence signals (stable action sequences, repeated successful artifacts) and test promotion gating.

Source video

How do deterministic tools and skills degrade when target sites change, and how is that drift detected?

Why unresolved

The summary notes sites can change but does not address maintenance mechanics for hardened artifacts.

Research direction

Study observability and re-evaluation strategies that flag when wrapped tools/skills stop matching live site behavior.

Source video

Does wrapping steps into deterministic tools actually reduce end-to-end failure, or relocate it to the tool layer?

Why unresolved

The summary asserts reduced model decision points improve reliability but provides no measured before/after failure rates.

Research direction

Run A/B benchmarks of raw step-by-step agents versus tool-wrapped agents on multi-step production-representative workflows.

Source video

What step-level reliability is required for a given horizon length to hit a target end-to-end success rate?

Why unresolved

The summary gives one instance (0.99^100) but no generalized planning rule for engineers.

Research direction

Derive reliability-vs-horizon budgets and test against agent benchmarks.

Source video

Key claims

8
factualVerification needed

A 99% per-step success rate across a 100-step browser workflow yields only 36% end-to-end success.

Evidence

0.99 to the 100th power equals 36% success rate for 100 steps

Question

Does 0.99^100 approximate 36.6%, and do real browser agent trajectories exhibit independent per-step failure rates matching this model?

Source video
causalVerification needed

Cost and risk accumulate continuously with every step, while value is realized only on full task completion.

Evidence

Cost accumulation is continuous, value realization is terminal.

Question

Do measured production browser agent cost and value curves match this continuous-cost, terminal-value model?

Source video
causalVerification needed

Wrapping multi-step interactions into single tool calls reduces the number of model decision points.

Evidence

Wrapping multi-step interactions into single tool calls reduces model decision points.

Question

Does reducing decision points via tool wrapping measurably improve end-to-end success in controlled tests?

Source video
causalVerification needed

Deterministic tools like OCR and serverless auth take non-ambiguous steps out of the model's responsibility.

Evidence

Deterministic tools like OCR and serverless auth take non-ambiguous steps out of the model's responsibility.

Question

Does offloading auth and verification to deterministic subsystems measurably increase reliability and lower cost per successful run?

Source video
causalVerification needed

Allowing a few retries (e.g., up to 4) per transaction dramatically boosts per-transaction success rates.

Evidence

Permit a few retries per transaction (e.g., up to 4 tries) to dramatically boost per-transaction success rates.

Question

What retry multiplier maximizes success per unit cost, and does 4 retries outperform alternatives under realistic cost?

Source video
comparativeVerification needed

Production differs from demos because it involves thousands of unmonitored runs against sites that change and models that have off days.

Evidence

A demo is one run on one site with someone watching, whereas production involves thousands of unmonitored runs where sites change and models have off days.

Question

How much do success rates degrade from demo to high-volume unattended deployment in practice?

Source video
factualVerification not requested

The output of a model is a probability distribution over actions.

Evidence

The output of a model is a probability distribution over actions.

Source video
opinionVerification not requested

Performance should be addressed before cost and maintainability, which then become optimization problems.

Evidence

Performance is the primary measure of success; once achieved, cost and maintainability become optimization problems.

Source video

Connections

5