An agent that clicks through the deployed app catches what unit tests structurally cannot, because it is the only layer testing what a real visitor actually experiences.
Unit tests and integration tests tell you a great deal about whether your code does what it claims to do in isolation. They tell you almost nothing about whether a person who opens your site in an actual browser, on an actual deployed URL, with an actual network path in between, can get through the thing you built. I've shipped changes with a fully green test suite that were, in the literal sense a visitor experiences, broken — a button that didn't fire because a CSS change put an invisible element on top of it, a redirect loop that only exists in production because a test double stood in for the auth check locally. The suite was telling the truth about everything it was asked to check. It just was never asked to check the thing a visitor actually does, which is load the page and try to use it.
The category of bug that survives a passing suite is specifically the category that lives in the space the suite doesn't model: real rendering, real layout, real cross-origin behaviour, the actual sequence of network calls a browser makes rather than the sequence your test harness simulates. No amount of unit-level coverage closes that gap, because the gap isn't a coverage problem, it's a fidelity problem — the tests are checking a faithful model of the app, and the bug lives in the difference between the model and the thing that's actually deployed.
A browser-driving agent closes that gap because it is, functionally, the last mile a human takes. It loads the real URL. It clicks the real button. It reads whatever actually rendered rather than whatever the component was supposed to render. When something is subtly wrong — an element unclickable because of a stray overlay, a form that submits to the wrong endpoint after a refactor, a flow that works until step three and then silently stalls — that's exactly the shape of failure a click-through agent surfaces and a unit test cannot, because the unit test was never testing the deployed page, it was testing a stand-in for it.
The part that needs real care is isolation, because the same capability that lets an agent click through your app also lets it click through everything else the browser session has access to. A browser-driving agent run against a session logged into your actual accounts is not testing your app, it's an agent with the keys to your email, your banking, whatever else that browser profile carries. The isolation has to be structural — a separate profile, a separate session, credentials scoped to the thing being tested and nothing else — not an instruction to "only test the app" that the agent is trusted to honour on its own.
Used this way, I treat browser-driving agents as the actual end-to-end layer, not a replacement for unit and integration tests but the thing that sits above them and tests the one claim none of the layers below can make: that a real visitor, on the real deployed thing, can actually do what the product says it does. Everything below that layer is testing whether the code is correct. Only this layer is testing whether the product works.
What I've stopped doing is treating a green test suite as evidence a release is safe to announce. It's evidence the code does what the tests describe. Whether the deployed thing actually works is a separate question, and the only way I've found to answer it honestly is to have something click through it the way a visitor would, on the real URL, in an isolated session, and report back what it actually saw rather than what it was supposed to see.