AgentEnv and REA: Turn a Recorded Web Capture Into an MCP Server

Version warning, verified before you read further: AgentEnv — the rea feature that projects a recorded web network capture into a connectable MCP server — is documented on the developer-published main branch, but as of 2026-10-24 the commands rea environment-serve and rea environment-export do not exist in rea-agents 6.7.0, the current npm latest. We proved it in our lab (below). Until the next npm release, every AgentEnv command example on this page requires a source checkout — if you run 6.7.0 from npm, you will hit COMMAND_NOT_FOUND, exactly as we did. Everything upstream of that command — the HAR inspection chain — does work on 6.7.0, and we ran the full chain end to end on 2026-10-24.

what AgentEnv is in the agentenv rea environment model

AgentEnv is the agentenv rea environment layer: it takes one recorded web network capture — a HAR file, a mitmproxy or Fiddler SAZ log, a QUIC qlog, or a browser scenario REA recorded itself — and projects it into a running MCP server. An agent connects to that rea environment server and gets exactly one tool per captured HTTP method and path template, an environment card for discovery, and a data plane for resets. Per the developer-published agentenv rea documentation, "Nothing is fetched from the recorded application; every answer comes from retained Evidence." That single sentence is the whole philosophy of the agentenv rea model: the capture is the ground truth, the live network is never touched.

Three routes make up every served rea environment: POST /mcp exposes the tool surface, GET /.well-known/agent-env.json publishes the environment card that the agentenv framework uses for discovery, and POST /agentenv is the data plane with data/reset, data/add and data/get. Two answering modes exist inside a rea environment: the default derives state from the capture, and --replay-only is pure replay — write requests are accepted and ignored, with zero side effects. [Source type: developer-published documentation, docs/agent-environments.md @ main, commits 2026-10-22/23]

the agentenv rea pipeline: capture to served environment

The developer-published agentenv rea pipeline, from raw capture to served environment, has three stages:

1. rea inspect-web-network-capture <capture> har --format json > capture.json — turn the raw capture into an Evidence record.
2. rea inspect-analysis-view — project the capture view (the environment-manifest view feeds AgentEnv).
3. rea environment-serve manifest.json --evidence capture.json --port 8765 — serve it.

Stage 3 — the rea environment serving command — is the one npm 6.7.0 cannot run yet (version warning above; the section on the version gap has the proof). Stages 1 and 2 run today, and we ran them for real — here is our actual lab output from 2026-10-24, rea-agents 6.7.0, Node 22.22.0, Linux x86_64.

We built a tiny local API and recorded six real HTTP exchanges into a HAR 1.2 file: list users, read one, a 404, a POST that creates user id=3, a re-read confirming the write, and a read of the new item. Then the inspection chain:

verified: ran 2026-10-24

Both agentenv rea stages passed on the first run after one HAR construction fix (below). The key structural takeaway: the capture view's output is the same standard Evidence JSON every other REA workflow produces. AgentEnv is an extension of the existing evidence pipeline, not a separate universe — which matters because everything on our REA evidence contract page applies to these records unchanged.

the agentenv rea version gap: 6.7.0 has no environment-serve (we hit it so you don't)

This is the section most agentenv rea writeups skip, and it is why this page exists: an agentenv rea guide without the version gap sends readers straight into COMMAND_NOT_FOUND. We attempted rea environment-serve and rea environment-export on 6.7.0, installed clean from npm:

verified: ran 2026-10-24

We then verified it was not an install quirk: rea --help's full 336-line command list contains no environment or agentenv entry; the inspect-analysis-view view enum in 6.7.0 has exactly 20 kinds and none of them is environment-manifest or environment-state; and a full-text grep of the installed dist/ for agentenv and environment-serve returns zero hits. verified: ran 2026-10-24

The timeline explains it. npm release dates (registry, fetched 2026-10-24): 6.4.0 → Oct 11, 6.5.0 → Oct 14, 6.7.0 → Oct 18, and 6.7.0 is still dist-tags.latest. The agent-environments commits landed on main Oct 21–23 (edccb430, 5375ff0f, 7ec9b6e5, 957bcfa1). The feature is merged but has not shipped in any npm release. The practical agentenv rea consequence: any tutorial that shows you rea environment-serve without a source checkout is describing something you cannot run today. Follow our REA setup guide for the pinned-install baseline, and treat the environment commands as source-checkout-only until the next release (6.8 or later) — when it ships, we will re-test this whole page and update it, alongside our REA 6.7.0 changelog breakdown.

fail-closed by design: what the agentenv rea pipeline refuses to do with your capture

Our lab run surfaced two refusals worth reading closely, because they show how the rea environment chain treats your data.

Strict agentenv rea input validation, with a pointer to the exact field. Our first HAR draft gave a GET request a "postData": null field. The whole file was rejected — not parsed partially, not repaired silently:

verified: ran 2026-10-24

The validator is a pinned upstream har-schema (draft-06): if a field exists it must be a valid object. Removing the stray field made the identical file pass. That is schema-level fail-closed behavior — the same principle our fail-closed glossary entry describes across REA.

A manifest cannot be served from records it did not cite. Per the developer-published documentation, serving refuses any manifest whose parent evidence IDs do not match, reporting both IDs back in a structured invalid_request. The capture check itself is purely offline — the limitation text in our own evidence output reads "Recorded URLs are never fetched," and the unknowns field explicitly lists what the record cannot prove: "Historical records do not establish live runtime attribution or deployment authenticity." verified: ran 2026-10-24 An evidence format that documents its own limits is exactly what you want when a rea environment will serve it to an agent later when an agent will reason over it later.

Two more agentenv rea fail-closed properties come from the developer-published documentation rather than our lab: every tool result — including MCP-layer parameter errors — carries _meta.provenance.untrusted_content: true, and even tool names, parameter names and observed values are treated as captured data, never as instructions. Write tools are not served at all unless the capture's subsequent reads confirm the write took effect ("no call claims a change it does not make"). And replay is not emulation: a served rea environment makes no authorization model, no response semantics, no state transitions. [Source type: developer-published documentation]

agentenv rea vs a normal rea mcp session

The most common agentenv rea question is how a rea environment differs from the MCP server REA already ships. We measured the normal one directly:

verified: ran 2026-10-24

• Tool surface: an agentenv rea server differs from a normal rea mcp session (207 analysis tools): an AgentEnv server exposes one tool per captured HTTP method and path template — the capture defines the surface.
• Side effects: analysis tools may execute the target or a debugger; a served rea environment is zero-outbound by default — recorded URLs are never fetched, and replay mode ignores writes.
• Trust model: both treat content as untrusted, but the environment additionally marks every result with provenance metadata.
• Determinism: an agentenv rea environment is deterministic: per the developer-published documentation, ids, clocks and UUIDs generated by writes derive deterministically from state Evidence ids — "the same calls after a reset give the same state" — and data/reset returns the rea environment to the captured moment in one call.
• Isolation and distribution: each rea environment is its own server; rea environment-export produces a Docker bundle (pinned node:24.18.0-bookworm-slim, pinned rea-agents version, verifier script) that the agentenv framework runs with agent-env run — "an environment an engineer deploys on a laptop runs unchanged on a shared platform." [Source type: developer-published documentation]
• Budgets: a served agentenv rea catalog reserves 1 MiB for discovery, replies cap at 256 KiB, state intake at 32 MiB, and data/add accepts up to 4 MiB inline; over-limit requests get a structured resource_constraint refusal — "Fields and tools are never silently omitted." [Source type: developer-published documentation]

should you use an agentenv rea environment today? the practical answer

Run the agentenv rea inspection chain now if you record web traffic and want it in Evidence form — stages 1 and 2 work on 6.7.0 and produce the same evidence records the rest of REA uses, fully offline. Wait on serving: until an npm release carries the rea environment commands, any agentenv rea walkthrough, a source checkout is mandatory (version warning at the top of this page, proof in our lab section). When the next release ships, expect our agentenv rea re-test here first — this agentenv rea page carries a re-verification flag so stale claims cannot hide — the page carries a re-verification flag precisely so stale claims cannot hide. If your actual goal today is agent access to analysis rather than to an agentenv rea capture, the 207-tool rea mcp server is the supported path; see the wiring notes on our REA vs Ghidra MCP page.

FAQ

What is the agentenv rea environment, in one sentence?

AgentEnv — sometimes searched as agentenv rea — is the rea environment feature that projects one recorded web network capture (HAR, mitmproxy, Fiddler SAZ, qlog, or a REA-recorded browser scenario) into a connectable MCP server whose tools answer only from the retained evidence — never from the live network.

Why does the agentenv rea command rea environment-serve say COMMAND_NOT_FOUND for me?

In every agentenv rea setup on npm 6.7.0 (current latest as of 2026-10-24) (current latest as of 2026-10-24) and the rea environment commands have not shipped in any npm release yet — we reproduced the exact refusal in our lab. The feature is merged on the main branch (commits Oct 21–23, 2026); until the next npm version, running it requires a source checkout. Every command example on this page carries that warning.

Is connecting to a rea environment safe? Does it call the recorded site? Does it call the recorded site?

The capture check and the served rea environment are offline by design: the evidence output itself states "Recorded URLs are never fetched," replay mode ignores writes, and per the developer-published documentation write tools are only served when the capture's later reads confirm their effect. Results are still marked untrusted content — treat everything as data, not instructions.

How is an agentenv rea environment different from rea mcp?

rea mcp is one server with 207 fixed analysis tools; an agentenv rea server (we verified the count with rea mcp doctor on 2026-10-24). A rea environment is one server per capture, with one tool per captured HTTP route, deterministic reset-and-replay state, and answers drawn exclusively from evidence. Analysis of binaries uses the former; reproducible replay of recorded web traffic uses the latter.

Can I export an agentenv rea environment and run it elsewhere?

That is rea environment-export: the rea environment export produces a Docker bundle with pinned node and rea-agents versions plus a verifier, runnable via the agentenv framework's agent-env run — the same bundle behaves identically on a laptop and a shared platform. Note the same source-checkout warning applies to the export command as of 2026-10-24.

Do I need new skills to read AgentEnv evidence?

No. The agentenv rea capture and view stages emit standard REA evidence records — the same format documented on our evidence contract page — so verification tooling and reading habits carry over unchanged.

Related: REA setup guide · the REA evidence contract · the 6.5–6.7 changelog: what changed · REA vs Ghidra MCP wiring · fail-closed, explained