What REA Can See When an AI Agent

REA lets an AI coding agent investigate software without its source code, then use the findings to build an implementation. That is an appealing proposition if you have ever wanted to reproduce a feature you can use but cannot inspect from the inside. It also raises a question that a polished demonstration can leave unanswered: how much of the original behavior did the agent actually see?

The project, short for Reverse Engineer Anything, connects agents to tools for inspecting native binaries, JavaScript and Electron applications, .NET assemblies, and websites. Its documentation describes a sequence: the agent calls REA through the Model Context Protocol (MCP), REA returns findings with evidence, and the agent asks follow-up questions or writes and tests code. The target and the tools installed determine what that investigation can cover. Deep native analysis, for example, uses Hopper, Ghidra or IDA; static JavaScript and .NET inspection can work without a native analysis engine.

That makes REA useful for a narrower, more interesting reason than its name suggests. It can put observations about a program in the same workflow as an agent that writes code. A developer trying to reproduce one interaction can move from a guess based on a screenshot to a question about the code or behavior behind it. The resulting implementation still has to survive tests of that interaction. If the developer expands the claim from “this feature works” to “this app has been recreated,” the test has expanded too.

The Tool Connection is Not the Understanding

MCP explains how an agent can reach REA, but it does not certify the agent's conclusions. The protocol's architecture documentation defines a way for applications and servers to exchange context and invoke tools. It explicitly leaves how an AI application uses a language model and manages that context to the application. Think of it as a connection between a workbench and its instruments. A functioning connection gets a reading to the worker; it does not interpret the reading or check the finished product.

REA's own result contracts are unusually revealing about that second job. A function analysis can mark individual facets, including pseudocode, callers and references, as observed or unavailable. When a comparison lacks a required facet, its result remains unknown rather than treating an empty field as an empty program. The documentation also says that even a complete set of calls observed by a provider does not claim to include every runtime target.

Here is the practical consequence. Suppose an agent examines a function and gets no list of callers. If that list was never collected, the agent cannot conclude that nothing calls the function. If a provider did collect an empty list, that is a stronger finding, within the provider's declared coverage. REA's contracts preserve this distinction so the agent can reason with it. Whether the agent actually does so in a given investigation depends on the questions it asks and the claims it makes afterward.

The same caution applies at the scale of an application. Matching the visible response to one click supports a claim about that click under the conditions tested. It does not settle what happens with another account, an unusual input or a feature whose work takes place on a server. It gives readers a useful question for any reconstruction demo: which behavior was observed, and which behavior was filled in by the agent?

The Older Instruments Beneath the Agent

Reverse engineering had a substantial toolkit before agents entered this workflow. Ghidra, the NSA's reverse-engineering suite, became publicly available in 2019. REA can use an existing Ghidra, Hopper or IDA installation for deep native analysis; its documentation also describes returning pseudocode and assembly from native analysis. The chronology helps locate the change. The agent-facing workflow brings established inspection tools into a process where software can ask questions about their results and attempt an implementation. It has not made the underlying task of interpreting a binary disappear.

Nor does every target call for the same instrument. REA says static JavaScript and .NET inspection read supplied files without running the application, while runtime capture runs or interacts with a selected target using the user's permissions. A file can reveal code paths that a brief interaction never exercises; a runtime interaction can reveal behavior that reading a file alone does not demonstrate. Selecting one route sets the boundary of what the agent can claim to have examined. It also changes the practical stakes: the project's documentation says analysis runs locally, while the agent receives tool results and its model provider has its own data policy.

A useful comparison comes from an earlier, smaller agent task. In a 2025 account of inspecting a meme website's undocumented API, a developer connected Claude Code to Chrome DevTools MCP to examine network requests and write an API client. The first attempt ran into the model's token limits because the request list was too large. After adding filtering and pagination to the tool, the developer said the agent identified endpoints, payloads and image locations and generated a client. This is one practitioner's account of one website, not a performance comparison with REA.

Both workflows put observations in front of an agent. The browser exercise focused on requests the browser made, which suited the task of mapping an API. REA describes a broader menu, including native analysis and inspection of supplied JavaScript or .NET files. That breadth can answer questions a network trace cannot, provided the relevant target and analysis tool are accessible. The browser exercise also exposes a less glamorous constraint: collecting information and getting useful information into an agent's working context are separate jobs. Filtering rescued that developer's task, while also making the choice of what to inspect consequential.

The strongest case for REA is consequently quite concrete. A person investigating a feature can ask for evidence behind an explanation, follow a promising code path and test a proposed implementation instead of stopping at visual resemblance. The qualifications belong in the same workflow. REA's contracts say a call graph with partial or unknown coverage can return an empty call list without proving there are no calls. Its documentation also warns that strings, page text and other material from a target can contain instructions aimed at the agent. Such text is part of what the target contains; treating it as a command would let the object of an investigation interfere with the investigation.

When someone shows an agent rebuilding an app, the most informative next screen may be the one after the successful click: the evidence attached to the finding, the coverage marked unknown, and the tests of what the rebuilt app does when the easy path ends.