StableBrowse
The web is not just a collection of pages. It is a collection of task paths.
Every meaningful browser task moves through those paths: landing pages, navigation layers, search surfaces, collection views, detail templates, forms, drawers, confirmation screens, and dead ends. A page is only one snapshot. What matters for automation is what the system can do from that page and where those actions lead.
StableBrowse builds site familiarity. Discovery turns bounded website exploration into reusable site graphs for browser automation.
That is why StableBrowse treats discovery as an infrastructure problem. The goal is not to scrape a site or enumerate every URL. The goal is to construct a reusable site model: enough route grammar, interaction context, and state recognition to make future runs less uncertain.
Discovery is not crawling
Traditional crawlers are document retrievers. They follow links, deduplicate URLs, and build an index. That works when the goal is content coverage.
Browser automation has a different object of interest: capability. The system needs to know what the browser can do, where actions lead, which states are equivalent, which regions are reusable, and which transitions are worth relying on. Static URLs are only one signal. Many important surfaces are created by client-side execution, form progression, navigation overlays, conditional controls, user intent, and application flow.
So StableBrowse discovery asks a different question: What is the executable structure of this website?
That structure is not identical to the markup, the sitemap, the accessibility tree, or the rendered frame. It comes from combining those signals with observed transitions.
The cold-start state
When a new site enters the system, it has no useful prior. The agent does not know the site's route grammar, template families, interaction affordances, or task-relevant entry points.
A purely reactive browser agent handles this by exploring inside every task. It observes the current page, asks a model what to do, executes an action, observes again, and repeats. This is flexible, but it couples task execution to site discovery. The result is high variance: repeated token spend, inconsistent route selection, fragile recovery, and unnecessary exploration of already-seen surfaces.
StableBrowse separates those concerns. Discovery builds an initial site model before repeated execution depends on it. Runtime agents can then operate against prior structure instead of treating each page as an isolated prompt.
The first model does not have to be complete. It has to be useful: enough coverage to recognize common states, route through high-value flows, and identify where additional expansion is needed.
Bounded exploration
Exhaustive exploration is the wrong objective.
Modern websites contain enormous low-signal regions: product catalogs, localized URLs, marketing pages, help centers, account surfaces, checkout paths, modal variants, personalization states, and duplicate templates. Exploring all of it increases cost without necessarily improving task performance.
StableBrowse discovery is bounded around reusable structure. It focuses on the coverage frontier most likely to generalize across future tasks.
| Discovery focus | Why it matters |
|---|---|
| Entry points and primary navigation | Establishes entry points and primary navigation surfaces. |
| Repeated route families and templates | Groups repeated route families and page templates. |
| Search, filter, and refinement flows | Captures search, filter, and refinement flows. |
| Task-bearing controls and interaction regions | Identifies task-bearing controls and interaction regions. |
| Non-destructive transitions | Prioritizes transitions that can be explored safely. |
| Recognizable and resumable states | Finds states that can be recognized, revisited, or resumed from. |
| Terminal or sensitive areas | Marks boundaries that should be handled with caution. |
This is controlled frontier management, not an open crawl. The pipeline has to collect enough evidence to support execution while keeping the explored surface compact and safe.
From runs to site models
During discovery, StableBrowse records what the browser actually observes as it moves through a site. Each run contributes evidence about states, actions, transitions, and reusable page structure.
Those observations are compiled into a site model. At a high level:
- browser states become recognizable waypoints,
- transitions become executable routes,
- repeated layouts become template families,
- controls become interaction affordances,
- run artifacts preserve enough context for future recognition and reuse.
The output is not a mirror of the website. It is a reusable site model for browser automation.
That distinction is important. A runtime system does not need every rendered element or every possible URL. It needs the durable abstractions that help it answer practical questions.
A site model answers operational questions. Where am I? What kind of state is this? What actions are available? Which actions are safe to try? If execution drifts, where can the system reattach?
Site familiarity compounds
The first pass through a site is only the bootstrap.
Real production usage reveals which parts of a site matter. Some routes are central. Some templates appear constantly. Some surfaces are technically reachable but irrelevant. Some areas only become important after a user asks for a specific class of task.
StableBrowse can use that feedback loop to grow familiarity over time. The site model starts broad enough to be useful, then expands around real demand:
- bootstrap the initial route grammar,
- execute representative tasks against the model,
- identify thin or ambiguous coverage,
- expand around high-value states,
- keep reusable evidence attached to future runs,
- refresh structure when the website changes.
This is the difference between static indexing and site memory. Static indexing says, "We have seen this URL." Site memory says, "We know how this part of the site behaves well enough to use it again."
Why this matters at runtime
Site familiarity changes the runtime profile of a browser agent.
Without prior structure, every task begins with a large action space and a weak runtime prior. The model has to infer page purpose, possible actions, task relevance, and route direction from scratch. That pushes too much reasoning into the most expensive and least repeatable part of the system.
With a reusable site model, the runtime can start from a stronger prior. It can recognize known states, prefer previously established routes, narrow the action space, and reserve model reasoning for task interpretation rather than basic site orientation.
The practical effects are straightforward. Less repeated observation, lower latency on recurring tasks, smaller context windows, more stable navigation, clearer failure boundaries, and cleaner separation between exploration and execution.
The agent is no longer browsing as if the site is brand new. It is operating with accumulated site familiarity.
Discovery as an infrastructure layer
The important architectural move is to make discovery a first-class layer.
In prototype systems, exploration often happens implicitly during a task. If the model needs to find something, it explores. If it gets stuck, it explores more. That approach makes every task carry the cost and risk of live discovery.
StableBrowse moves that work into a dedicated pipeline. Discovery becomes repeatable, bounded, inspectable, and reusable. Execution can then depend on a site model that was built for automation rather than improvised inside a single prompt loop.
This is what makes browser automation feel less like a one-off browsing session and more like infrastructure. The system is not simply asking a model to look at a page. It is maintaining a reusable model of a website and using that model to make future actions cheaper, safer, and more predictable.
The web changes constantly, but it is not random. Sites expose structure. Task paths repeat. Interfaces form patterns. StableBrowse discovery turns those patterns into site familiarity.
That is the foundation reliable browser agents need.