You click Export and a file arrives. Before asking how the entire service works, ask a smaller question: what did that one click make the browser request?
Start with a question you can observe
A useful browser investigation might compare an empty search with a search containing one word. Another might trace the request produced by changing a sort control. The goal is to connect an action to an observed result, then identify the client code responsible where the evidence permits it.
A browser has access to the page and the requests it makes. That boundary matters. A JSON response can show an output contract without revealing the private database query that created it.
Define a capture before collecting it
Write a short capture brief: the page you control or are allowed to examine, the starting state, the action, and the expected visible result. Include whether the action writes data. A search in a local demo is a different operation from submitting a real order.
Investigate the search interaction on this local demo page.
Start with an empty query. Enter "bridge" and submit once.
Record the request and the visible result associated with that action.
Do not submit other forms or change account settings.
Report missing or redacted response fields as unknown.This is a planning template. Consult the actual REA browser tool schema in your agent for capture parameters. Tool names and supported controls change more quickly than the underlying method.
Read the observation as a chain
A helpful chain has an action, a request, a response observation and an interface update. If a link is missing, say so. The timing of a request alone does not prove that it caused the state change you care about.
For example, a page may issue analytics traffic and a search request after the same click. The search response shape and the consuming code are stronger evidence than “this URL appeared near the action.”
Capture only the data the question needs. Use a demo account or local fixture for tutorials so screenshots do not expose private queries, tokens or personal records. The learning point should survive without those details.
What a client-side finding can establish
You may be able to locate a request constructor, see the submitted fields, identify a response consumer, and observe how a loading or error state changes. These are useful implementation facts.
You cannot infer the full server architecture from one endpoint. A field named score does not establish the ranking algorithm. One successful response does not establish rate limits, permissions or behavior for other accounts.
Turn the finding into a focused experiment
Change one input at a time. Keep the page version, query and initial state in your notes. Compare an empty input, a normal input and a boundary case such as a very long query. If the request is cached or no new request occurs, that is an observation worth preserving.
The output of this exercise should be a compact behavior contract: given this state and action, the client sent these fields and rendered this result. It is enough to guide a small prototype without pretending the backend has been recovered.
Where to go next
For a local static exercise with retained evidence, use Pocket Notes. If your goal is to turn a recorded interaction into an agent environment, read the AgentEnv explainer before collecting a larger session.