A recorded browser test starts with a path: find this element, click it, enter a value, and expect a particular screen. That can be precise, but the path becomes another artifact to maintain whenever the interface changes.
The Journeys agent starts somewhere else. It receives the customer outcome that must remain possible, opens the site in a real browser, and decides what to do from the page in front of it.
That freedom is useful only when it comes with review, evidence, and clear boundaries. Here is how those pieces fit together.
The outcome stays fixed while the route can change
A journey begins with a plain-English goal such as completing checkout or signing in to an account. During a run, the agent repeats a small loop:
- Observe the current rendered page and browser state.
- Evaluate whether the previous action moved the journey forward.
- Choose and perform the next action.
- Check the result against the original outcome.
It does not assume that the element used last week still has the same index or selector. Each step is chosen after reading the current page. If a form rejects a value, the useful response is to understand the message and try a genuinely different value—not repeat the same action because step seven said so.
The same approach lets a journey respond to confirmation email, an existing signed-in session, or an unexpected intermediate screen. The goal remains the constraint. The route is allowed to adapt.
The first useful path is attended
Adaptation is not the same as automatic trust. Every new journey starts with a run a person watches.
You can pause before the next browser action, resume, or send guidance when the agent needs context it cannot infer from the page. After a successful run, Journeys asks whether the agent followed the path your product intends. A lucky pass by an unreliable or inappropriate route should be retried, not approved.
Only an approved path can move into scheduled monitoring. Scheduled runs cannot be guided mid-flight: their result needs to stand on what the agent and site did without a person rescuing the attempt.
Memory is advice, not replay
A passing run can leave a short notebook for the next one. Its lessons describe useful pages, controls, approaches that worked, and dead ends to avoid. New model-written lessons must be grounded in numbered steps from the completed trace.
The notebook deliberately refuses executable instructions such as CSS selectors, XPath expressions, element indexes, or one-off values to type. Those would turn memory back into a brittle script. If current browser evidence contradicts an older lesson, the page wins.
Later passing runs can add or refine model-written lessons. A failing run does not rewrite them. Guidance typed by a person follows different rules: it can be kept even when the run fails or is stopped because it records what the person said, not what the trace proved. The agent may mark that guidance as no longer working, but only a person removes a person’s words.
The result comes with evidence
The live browser is only one view of a run. The video frames used for live watching are temporary, but the useful investigation record is durable:
- each completed step keeps its evaluation, next goal, page address, and a screenshot when the browser supplies one;
- the recording can be replayed after the run;
- failed requests, console errors, and uncaught exceptions are attached to the step where they occurred;
- the final report brings the trace and browser findings together.
The agent produces a self-report when its loop finishes, but the server owns the final run verdict. That distinction matters when a person cancels a run: an agent stopped halfway through must not turn its partial self-report into a green monitoring result.
Every action stays inside the run’s boundaries
The agent’s ability to choose a route does not give it an unrestricted browser.
Secret values are handed through a sensitive-value channel, so the model refers to placeholders instead of seeing the real credential or email code. Emitted activity is scrubbed against those same live values. A saved browser session is loaded as browser state and does not enter the model’s context.
Navigation is fenced before and during the run, including redirects and new tabs. File access is limited to the fixtures explicitly assigned to the journey; with no fixtures, there is no file access. Each run also has bounded time and resource budgets so a lost browser cannot hold a monitoring slot forever.
Adaptive does not mean infallible
An agent can still misunderstand a page, take an undesirable route, or meet a site state it cannot resolve. Journeys does not hide that uncertainty behind the word “AI.” It uses an attended first run, grounded memory, durable evidence, and enforced boundaries to make adaptation something a person can inspect.
The promise is not that every journey always passes. It is that the journey is tested from the customer’s side of the browser—and when it changes, the result comes with enough context to understand why.
Browser journeys are one layer rather than a complete monitoring strategy. See what each type of website monitoring can and cannot prove before deciding which checks belong beside one.