TL;DR
Agentic browsers let you describe a test in plain language and have an agent drive the UI to verify it. Here is how to use them without trading away the reliability and accountability that real test suites give you.
The problem with end-to-end tests nobody wants to write
Most teams agree that end-to-end tests are valuable and still under-invest in them. The reason is rarely disagreement about value. It is cost. A Playwright or Cypress suite is real software: selectors break when the DOM shifts, flows change more often than the tests that cover them, and a flaky run erodes trust until people start ignoring red builds. The maintenance tax is highest exactly where coverage matters most, on the long, stateful journeys through your product.
Agentic browsers change the economics of that first draft. Instead of encoding every click and selector by hand, you describe the behaviour you want to verify in plain language and an agent drives a real browser to check it. Done carefully, this makes it practical to check flows nobody would have scripted by hand. Done carelessly, it hands you a suite that is confident, expensive, and quietly wrong. This piece is about getting the first outcome without the second.
What an agentic browser actually does
An agentic browser couples a language model with browser automation. The model reads the page, decides what to do next, and issues actions through the same primitives a human-written test would use under the hood: navigate, click, type, read. The difference is the level you operate at. You hand it an intent such as "sign up with a new email, confirm the welcome screen names the user, and verify the trial banner shows fourteen days," and it figures out the steps.
That is genuinely useful for two things. The first is exploration, where you do not yet know the exact path and want the agent to find it. The second is intent-level assertions, where what you care about is the meaning on screen rather than a specific selector. Both are places where traditional tests are brittle and slow to write.
The core method: explore with the agent, commit to code
The pattern that works treats the agent as the author of a draft, not as the test itself. We run it in four stages.
- Describe the journey in plain language. Write the flow as a short spec: preconditions, the steps a user takes, and the observable outcomes that prove it worked. Keep assertions about meaning ("the order total reflects the applied discount") rather than markup.
- Let the agent execute and record. The agent drives a real browser through the flow and produces a trace: the actions it took, the selectors it resolved, and the assertions it evaluated. Watch this run. The trace is the draft.
- Promote the trace to a deterministic test. Convert the stable parts of the trace into a conventional Playwright or Cypress test with explicit selectors and assertions. This is the artifact that runs on every commit, in seconds, with no model in the loop.
- Reserve the agent for the parts that are genuinely fuzzy. Keep a small number of agent-driven checks for assertions that are hard to pin to a selector, such as "the error message clearly explains what went wrong." Run these less often and treat their output as a signal, not a gate.
The discipline is in step three. The agent is excellent at discovering the path; deterministic code is what you want guarding the merge button. A senior engineer reviews the promoted test the same way they would review any other code, because that is exactly what it now is.
Pitfalls and tradeoffs
The honest failure mode is non-determinism in the gate. A model deciding at run time whether a screen "looks right" will occasionally disagree with itself, and a test that passes on Tuesday and fails on Wednesday with no code change is worse than no test, because it trains the team to ignore failures. Never put a model's judgement on the critical path of a merge unless you have accepted, in advance, the flakiness budget that comes with it.
Cost and latency are the second tradeoff. Every agent run consumes tokens and wall-clock time. A suite of two hundred agent-driven checks is slow and expensive in a way a compiled selector-based suite is not. This is the practical reason the method pushes everything stable down into deterministic code and keeps the agent for the narrow band of checks that justify it.
Finally, agents can produce false confidence. An agent told to "verify checkout works" may report success because a page loaded, while missing that the charge was wrong. Assertions still have to be specific. The agent does not relieve you of saying precisely what "correct" means; it just lets you say it in a higher-level language.
What good looks like
A healthy setup has a large, fast, deterministic suite covering the flows you understand, drafted with agent assistance, reviewed, and then frozen into code. Alongside it sits a small set of agent-driven exploratory checks that probe new areas and surface regressions a human would notice but a brittle selector would not. The agent shortens the path from "we should test this" to "we have a test," and a human still owns the decision about what ships.
The takeaway
Agentic browsers are a better way to write the first draft of a test, not a replacement for the test suite. Use them to explore flows and express intent-level assertions, then promote anything you rely on into deterministic code that a person has reviewed. That balance, AI for leverage and senior judgement on the gate, is how we approach testing day to day: broader coverage without giving up the reliability our clients depend on.
