Browser agent with live network decisions
A browser agent tests incoming responses in parallel, then uses the results to choose its next action.
Find a black dress in size M under $150. Check that it is available and prepare the cart.
A browser agent given this task has more to work with than the visible page. The application exchanges catalog data, inventory, cart state, scripts and event traffic. Those responses can tell the agent where it is, what the application knows and whether its last action worked.
The opportunity is to make that information useful while the agent is still navigating.
The experience
Our prototype follows a bounded journey through a fictional storefront. It opens the store, visits the dresses section, checks a variant, prepares a cart and opens checkout. Model decisions over the incoming resources gate progress. The second example follows the checkout path while checking for a deliberately planted fake development credential.
The navigation plan is fixed for this controlled demonstration. The resource interpretation is recorded model work. Exact field checks and arithmetic determine whether the requested size, color, stock and price satisfy the goal. The interface shows the current step, its evidence and the next action it permits.
A script mentioning an inventory endpoint is an instructive distraction. It can tell the agent that an endpoint exists. It does not establish that the required size is in stock. The actual inventory response supplies a different kind of evidence.
The public showcase replays the controlled resource stream and tested decisions. It makes no new model requests, visits no external store and performs no payment. Displayed timings belong to the recorded checks. Open a source to inspect why a gate passed or why a resource was excluded.
The model and the tool
The agent has a goal. Each resource can be examined against several current questions. Independent checks run in parallel; dependent actions wait for their required evidence.
storefront resources
↓ parallel checks
product data / availability / exposed credential
↓ relevant evidence
exact variant + stock + price checks
↓ conditions satisfied
cart action → reservation evidence → checkout
A semantic decision identifies a response worth using. The tool retains its path, content type and body. The browser controller then applies an operation with a specific precondition. This separates discovering the relevant material from interpreting its known fields and acting on it.
The distinction affects what a failure means. A missed inventory response is a resource-understanding problem. A wrong price comparison is an implementation problem. Proceeding before a required result is available is an orchestration problem. A useful test follows the entire journey and checks which gate admitted each action.
The same observation can serve more than one purpose. While the shopping path examines catalog and inventory, an assessment branch examines the resources for accidental credential exposure. These branches can share the captured traffic while retaining different questions and completion conditions.
A useful research connection
SayCan connects a language model’s assessment of useful actions with estimates of what a robot can execute in its current environment. After a skill executes, the system chooses again. Our browser prototype uses a fixed navigation plan and deterministic conditions around resource decisions. The shared design question is concrete: what evidence makes this next action appropriate now?
The Dataflow paper supplies another useful connection. Incoming information can arrive late or out of order, and results may need updating. A browser agent needs corresponding rules: which page or action produced this response, which question examined it, and whether its result still applies after navigation.
Semantic operators in LOTUS show how model-based filters and joins can become parts of a larger data-processing plan. For a browser agent, that suggests an architecture in which many resource checks discover useful evidence, then a smaller dependent computation resolves the next action. The interface can make that progression visible instead of presenting one opaque browsing session.
Building it with System1
A browser capability needs its questions, permitted decisions and executable actions developed together. Examples should include relevant responses, plausible distractions and absent evidence. Evaluation should test the gate that follows the decision, including cases in which the agent must remain where it is.
The controlled example already makes one distinction consequential: actual availability versus a reference to the availability service. Further development could test split inventory responses, stale reservations, failed requests and contradictory updates. Each case would connect a particular interpretation to what the browser may do next.
A deployed tool also needs bounded concurrency and explicit state identity. Each decision belongs to a source, a question and a tool revision. The controller needs to know which results it is still waiting for and which have become irrelevant. Those are part of the usable capability System1 develops alongside the model.
Where this could lead
Consider an agent testing a company’s own checkout after a release. It changes a delivery option, recognizes the responses carrying shipping choices, then checks that the selected option reaches the order state. The agent could produce a reproducible sequence with the relevant requests attached. An engineer would receive the interaction and backend evidence together.
A performance assessment could use a related sequence. Resource interpretation could identify which responses supply the visible product information; deterministic timing and dependency analysis could then examine what delayed their arrival. The model would help locate the relevant work. Measured timing would establish the delay. This proposed combination could connect a slow user action to a smaller, inspectable part of the application.
Another agent could investigate how a feature is implemented before testing it. It would observe a controlled journey, classify resources by their role, compare the ones that change after an interaction, and construct a tentative map from visible controls to backend services. The next test would follow the discovered relationship. Each stage would preserve the evidence that supports it.
These possibilities concern authorized work on applications their operators control. Their architectural move extends beyond browsers: parallel observations discover where attention is useful, conditional checks establish what can happen next, and an agent acts within a tool that preserves the consequences. Faster decisions matter because they can become part of the action loop while the work is unfolding.