# What a browser-agent replay must preserve

A browser-agent audit needs linked observations, intended actions and confirmed outcomes; reconstructing history is different from reapplying clicks.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-29
Original announcement: https://openai.com/index/devday-2026-recap/
Canonical URL: https://retrivium.ai/retrospectives/agents-computer-use-replay-evidence/

A browser-agent replay can mean reconstructing what happened or executing the same actions again. Those are different operations. The Agents API computer-use expansion made a useful audit question unavoidable: what evidence must survive so a reviewer can explain a result without blindly repeating its effects?

## The earlier product sequence

[Codex's May 16, 2025 introduction](https://openai.com/index/introducing-codex/) established cloud task execution. The [September 10, 2026 Agents API beta](https://openai.com/index/introducing-the-agents-api/) introduced managed sessions. The [September 29, 2026 DevDay recap](https://openai.com/index/devday-2026-recap/) added computer use. These sources establish why interaction evidence became part of a managed-agent integration; they do not guarantee that every desired audit field is automatically retained.

## A screenshot is one observation

Imagine an agent opening a record and changing a display preference. A screenshot can show what was visible, but it does not by itself identify the user's request, intended target, proposed action or resulting persistent state.

An explanatory record should connect those objects. Preserve the observation used for the decision and the outcome observed afterward. If a reviewer sees only the final image, they may know what the page looked like while remaining unable to explain how or why it reached that state.

## Reconstructing is different from reapplying

An audit should first reconstruct the historical sequence. Reapplying the same click can act on today's page, another record or an already changed setting. The historical action is not a timeless instruction.

Keep the original state and event identity distinguishable from a later reproduction attempt. If reproduction is useful, give it an explicit test environment and expected result. This makes the relationship between the historical observation and the new experiment inspectable rather than assuming equivalence.

## A diagnostic replay fixture

Use an illustrative task with a page transition, a changed preference and a final confirmation. Retain the request, source record identity, observations and action outcomes. Ask another reviewer to locate the point at which the intended state became visible.

Then remove one observation from a copy of the record. Inspect which conclusion becomes uncertain. This exercise identifies the evidence needed for explanation without requiring every screen to be stored forever. It also distinguishes a missing record from a model mistake.

## The operational implication

A useful replay explains what was observed, what was intended and what outcome was confirmed. It need not expose internal reasoning or turn a historical log into an executable action script.

The retrospective lesson is that browser reach and auditability are separate capabilities. The September expansion broadened the agent's interaction surface; an application still had to define the evidence chain that made those interactions understandable afterward.

## Related reading

- [Connecting evidence across execution events](/journal/provider-request-id-trace-context/)
- [Preserving event intervals](/journal/provider-monotonic-latency-measurement/)