An app investigation can become an environment an agent can practice in.

Understanding a browser workflow answers one question. Turning it into an environment asks another: can an agent interact with a controlled version of that workflow, complete a task, and receive a meaningful result?

The idea behind the workflow

REA’s published environment guide describes recording an application session, turning the observed API into tools, and exporting an environment bundle for AgentEnv. Tasks and reward checks can then support training or evaluation.

That is a workflow described by the project, not a claim that this publication has exported or evaluated an environment. Read the current quickstart before attempting a capture; environment contracts and supported surfaces can evolve.

A recording is a starting point

A recorded request tells you what happened in one observed context. It does not automatically define every valid state, input or failure mode. A useful environment needs a clear boundary around what it represents.

For a small example, imagine a local notes application with create, list and export operations. An agent task could ask for a note with a known title and a checked exported result. That is a proposed learning exercise, not a recovered third-party service.

The environment designer must decide which operations exist, which state they change, and how the state is reset. Without those decisions, repeated tasks can depend on leftovers from earlier runs.

Define success before adding a reward

A visible “Saved” message may be an interface observation. A task such as “export exactly these three notes” needs a stronger check of the exported data. The success condition should describe the outcome you care about, not an easy proxy the agent can satisfy while missing the task.

Keep a record of the task’s starting state, allowed actions, expected final state and cleanup. If a task uses an external service, its availability and changing data become part of the evaluation conditions.

For an initial environment, a deterministic local fixture is often easier to reason about. You can inspect failures without wondering whether a remote service changed during the run.

Keep the investigation and environment claims separate

There are at least three claims to check: the observation accurately records the original interaction; the exported tools represent the intended contract; and the task checks evaluate the behavior you care about.

Success at one layer does not prove the next. A complete capture may still omit an edge case. A runnable bundle may still contain a task whose reward can be satisfied for the wrong reason.

A planning template

Target: a local learning application
Question: which observed operations are needed for one small task?
State: a clean, reproducible starting dataset
Actions: only the operations required for that task
Success: an independently checked final state or output
Reset: restore the same starting state before each attempt
Unknowns: behavior not represented by the recorded session

Use this to evaluate the scope before collecting a large recording. The smallest coherent environment is a better first project than trying to model every part of an application.

If the browser observation itself is still unclear, begin with one action and one request. The environment work becomes easier when the observation already answers a precise question.