A browser agent investigates a disappearing discount

“Why does checkout show $108 but save $120?”

The application owner has a concrete problem. Applying WELCOME10 gives the expected discount. Changing delivery to collection leaves that discount on screen. Saving the order loses it.

The browser agent reproduces the problem, accepts a change to the investigation, runs two controls and compares what the browser actually sent. Its response is an inspectable account: the same code appears in the successful courier request and is absent after switching to collection. The responsible JavaScript remains to be traced.

This is the activity we want to make available inside a development workflow: direct an investigation while the application is running, with incoming evidence changing what the agent does next. Fast decisions become useful through the relationships between them—response meaning, transaction identity, experimental conditions and permission to act.

The experience

Northline is our fictional shop. The film uses its rendered interface, actual DOM interactions and captured HTTP traffic. It saves test records only. The owner instructions and review pauses are authored; the model interprets the sources, selects the available page actions and chooses among the permitted experiments during the run.

The first trial selects the Column dress in M, applies WELCOME10, changes delivery to collection and saves. Two pieces of evidence appear together: the original pre-submit page shows $108; the independently loaded saved order contains $120. Both belong to the same submission.

Then the owner changes the order of the controls:

Keep the same dress and size. Test without the code before the unchanged-delivery control.

That instruction matters to the work in progress. The agent must determine whether the owner has changed the question or only the procedure. Here it preserves the same product, size and investigation, then tests the no-code condition first.

Before each control runs, the interface explains what it can tell us:

• Switch to collection without the code. Checkout and the saved order both show $120. Collection alone did not produce the discrepancy in this trial.
• Apply the code and keep courier delivery. Checkout and the saved order both show $108. The discount can reach the saved order when delivery is left unchanged.

The agent now has a useful comparison. In the successful courier request, promotion_code contains WELCOME10. In the failing switched-delivery request, that field is absent. The recorded comparison retains both original bodies and the trial evidence supporting the finding. It also keeps equal fields, changed cart identities and differences that do not support the finding.

The ending is Request boundary identified. That is a useful handoff: a developer can investigate the path that constructs this request, starting from a reproduced behavior and a specific divergence. It does not yet establish which event handler dropped the field, what unobserved server state contributed, or how to repair the application.

The film preserves the actual sequence at its recorded playback rate, including the time left to read each control and inspect each request. It has no internal cuts or speed changes.

The model and the tool

A browser exposes several kinds of information at once: rendered controls, visible prices, scripts, cart responses, quotes and saved records. Their meanings and their authority differ. A response containing $108 is not automatically evidence that the current checkout displayed $108.

The prototype divides the investigation into dependent operations:

• Interpret a source. A finite decision identifies the role of a captured response. A following decision binds relevant meanings—cart identity, revision, amount, promotion, delivery mode—to exact fields in its request or response.
• Establish an observation. Tool code resolves those pointers, checks types and joins records by their actual identities. A saved order must link to the submission being examined; arithmetic uses integer cents.
• Choose an action. The next decision sees the observed page controls and established evidence. The tool executes a selected, permitted DOM action and captures the resulting traffic. A fluent description of a button cannot create a control that the page does not expose.
• Choose a comparison. Completed trial results and the current owner instruction inform the next experiment. A fixed experimental contract keeps product, size, quantity and price comparable.
• Qualify the finding. A complete request comparison retains every field observation. A disclosed checkout-specific rule checks whether the observed absence, earlier field meanings, control results and source relationships support this particular finding.

These layers have different failure modes. A model can choose the wrong response role. A tool can join two unrelated carts. A controller can act on an obsolete observation. A final statement can claim more than the experiments establish. Testing only the final sentence would hide where the investigation went wrong.

Why the old quote is insufficient

The failing trial contains an instructive detail. After the code is applied, a quote reports $108 for cart revision 2. After switching delivery, the submission and saved order refer to revision 3. That earlier quote is now stale for a current-price check.

Its evidence still matters: it establishes the discounted setup before the switch. It cannot substitute for the current page. The tool instead links the actual pre-submit page observation to the selected Save action, the outgoing request and the independently loaded order. The $108/$120 discrepancy is established across those records.

This is where domain tooling earns its place. It represents relationships that a screenshot alone cannot supply and that a collection of plausible model answers cannot guarantee. It also lets the person inspect the reasoning at the level of the work: what was displayed, what was sent, what persisted.

Why a complete comparison beats a final “useful field” choice

Two legitimate observations might be “these requests both select collection” and “the code field is absent from this request.” The first can be true without explaining the reported discrepancy. Asking another model to select one useful fact introduces an unnecessary bottleneck between recorded evidence and the person inspecting it.

Here the tool enumerates all captured field comparisons. Its rule qualifies a narrow request observation only when the three trial outcomes, fixed conditions, same-submission links, original semantic bindings and compatible owner instruction hold. It distinguishes an absent field from an explicit null and from incompatible structure. It keeps nonqualifying observations with their reasons.

The rule is specific to this checkout investigation. Its conclusion is a captured request difference under verified conditions. It does not encode a universal requirement that every valid checkout serialize a promotion field, nor does it turn correlation into a code-level diagnosis.

Parallel work still has dependencies

After Apply code, the cart and quote responses are interpreted concurrently. Each first receives a role decision, then a field-binding decision. The following action choice waits for the required evidence.

The two response paths overlap. Within each path, the field question depends on the role. The next browser action depends on the completed source checks. That arrangement gives concurrency a purpose: useful evidence becomes available inside the action loop, without pretending that every operation can run independently.

The complete run made 78 model calls: 53 source decisions, 21 page/action decisions and four investigation decisions. Thirty original response interpretations plus 39 exact-input reuses supplied 69 interpreted JSON responses. Reuse retained the original meanings only when the complete decision input matched. The run allowed at most four concurrent source operations and one control operation.

The chart measures a particular transition. The film also includes deliberate reading intervals. Neither playback duration nor one HTTP request measures the complete task’s latency.

A useful research connection

From reproducing a failure to isolating a difference

Zeller and Hildebrandt’s Simplifying and Isolating Failure-Inducing Input distinguishes reducing a failing test from isolating a difference between passing and failing cases. Its test outcomes include unresolved. Its notion of 1-minimality means that no individual remaining change can be removed while preserving the failure; it does not guarantee the globally smallest example.

Our browser does not implement their dd or ddmin algorithms. The connection informs a possible next tool: explicitly represent permitted changes, a reproducible starting state and the criterion for the same failure. Then use repeated experiments to narrow the relevant combination.

Consider a proposed test involving membership pricing, a promotion, a delivery switch and gift wrapping. A mismatch with all four enabled cannot assign responsibility to any one. Removing an option might also make the sequence invalid. An investigation needs to preserve that unresolved result rather than call it a pass. Source interpretation could identify the relevant amounts; experimental tooling would govern admissible comparisons. This is an extension to build and evaluate, beyond the three controls demonstrated here.

A late answer can be useful and no longer current

Akidau and colleagues’ Dataflow Model separates event time from processing time and describes how later data can refine earlier results. Its distinctions between computation, grouping, emission and refinement help expose a browser-specific problem: finishing last does not make a result current.

Imagine an earlier cart response taking longer to interpret than the response produced by a delivery switch. Applying whichever answer finishes last could restore the old cart. Discarding the slow answer entirely would lose evidence about the earlier trial. The architecture needs historical identity and separate permission to affect current work.

Our controller uses source, action, trial and owner-revision relationships for that purpose. A change to the order of controls can preserve the question; a different product or investigation cannot simply inherit the earlier comparison. This is an application of the temporal distinction, not an implementation of Dataflow windows or its distributed guarantees. A general system that retracts all downstream conclusions after revised evidence would require further machinery.

Building it with SYSTEM1

The purchasable capability is an application-specific investigator: questions, response meanings, permitted actions, experimental operations and inspectable results developed together. Its callable tooling must know what counts as a transaction, a valid comparison and a completed observation in that application.

That gives custom training concrete targets. Examples can teach the decisions the tool actually consumes: distinguish a saved order from an optimistic receipt, find the relevant total among several amounts, recognize a source whose role is unknown, or decide that a correction changes the investigation. Evaluation can follow each interpretation into the operation it permits.

This prototype uses a prebuilt fast model. It has no custom-trained browser model and demonstrates one owned scenario. Its controller and checkout rule are authored. Producing and refining such domain contracts alongside trained decision models is the broader SYSTEM1 pipeline; the present recording does not claim that an unrestricted browser agent or arbitrary application integration was generated automatically.

An embeddable version would expose operations such as starting a scoped investigation, adding an owner instruction and retrieving trial evidence. The sandbox would own the browser, capture and permitted actions. Its API would return domain results with source references, rather than require each caller to reconstruct the investigation from a network dump.

Where this could lead

• Investigations that carry forward. A developer could supply a suspected event handler after this finding. A later stage could connect the request difference to an instrumented trace, test a proposed repair and retain the original failing control. Each stage would need its own evidence standard; a request boundary alone would not count as a repaired defect.
• Feature maps built through operation. An owner could ask which services support a particular interaction. Parallel resource interpretation could discover candidate relationships, while subsequent actions discriminate between a service merely mentioned in a script and one whose response changes the visible result. The map would grow through experiments, with uncertainty attached to each relationship.
• Tests that explain a performance regression. A related tool could identify the responses supplying a visible feature, then use actual timing and dependency measurements to investigate delay. Meaning would locate the relevant work; measurement would establish its duration. A slow model answer would remain distinct from a slow application response.

These possibilities change the rhythm of application work. The owner can stay at the level of the question—reproduce this, try that condition, show what persisted—while a layered system performs and connects the smaller decisions. The useful result is a growing investigation they can steer, inspect and carry into the next action.