REA Deep Dive: How AI Agents Reverse Engineer Software

Part	Question
Problem	Why is understanding existing software so difficult?
Solution	What is REA, and what problem does it solve?
Mechanism	How do AI agents, MCP, and analysis tools work together?
Evidence	How does the Notion case demonstrate this capability?
Action	How do you get started, and what should you watch out for?

Working out how existing software behaves is often harder than it looks. A feature that seems simple can sit on top of several layers of code, internal messaging between components, data structures and system calls. If you want to understand or reimplement that feature, writing the code is usually the easy part. The hard part is finding out how the original software did it.

REA (Reverse Engineer Anything) approaches this by connecting AI agents to software analysis tools through the Model Context Protocol (MCP). An agent can then investigate the target software, look at the relevant implementation details, and base its next reasoning and development steps on what it actually found.

This article covers why existing software is hard to understand, what REA can do and how it works, and how it was used to analyze Notion's clipboard feature. It ends with how to get started and how REA fits alongside the models and model access platforms an AI workflow also needs.

1. Problem: why is understanding existing software so difficult?

Even a feature that looks simple in a modern application usually depends on several components working together.

Take copying in a desktop app. The user clicks a button or presses a shortcut. Inside the app, the system may have to identify the selection, convert it into one or more data formats, pass the data between processes, and call operating system APIs to write it to the clipboard.

With open-source software, you can usually trace that process by reading the code. Without the source, it gets much harder.

1.1 The limits of black-box observation

The usual fallback is to watch the software from outside: use the interface, try different inputs, and compare what comes out in different situations.

That helps, but it may not show you the logic inside. Two applications can produce the same visible result with completely different implementations, and two features that look identical can behave differently with unusual inputs, edge cases or complex data.

Without the original implementation, you are left with questions like these:

• Which functions are responsible for implementing this feature?
• How is data passed between different components?
• Which internal interfaces or system APIs does the software call?
• What assumptions does the application make about its input?
• If you need to build a compatible feature, which behaviors must be reproduced?

Compiled native code, a multi-process architecture or complex dependencies make each of them harder.

1.2 Generating code is not the same as understanding it

AI coding assistants can write programs from natural-language instructions, existing code and other context. Producing code that looks right is a different job from finding out how an existing application works.

Say a developer asks an AI to reproduce the clipboard feature of an unfamiliar desktop app. It may quickly produce code that copies plain text correctly while missing how the original handles rich text, structured content, metadata or inter-process communication. That version can pass simple tests and still behave differently in real use.

The underlying problem is missing evidence. An agent that can't inspect the implementation or gather enough behavioral information can only guess from what it already knows.

So an AI that works on existing software needs two things: the ability to write code, and a reliable way to investigate the system it is working on. REA was built for the second.

2. Solution: what is REA, and what problem does it solve?

REA stands for Reverse Engineer Anything. It's an open-source project that connects AI agents to tools for investigating software and analyzing how it works.

An agent using REA examines a target application, collects findings, and uses them to answer technical questions or guide implementation work. REA's analysis workflows let the agent look at the software's underlying structure and behavior, which goes deeper than watching it from outside.

The REA GitHub repository has the source code, the list of supported analysis targets, configuration instructions and documentation.

According to the documentation, REA supports native binaries, JavaScript and Electron applications, websites, .NET assemblies, Android apps, WebAssembly and other technical artifacts. Each target type needs its own approach. Analyzing a JavaScript app follows a different technical path from analyzing a compiled native binary.

2.1 What can REA be used for?

REA applies to several kinds of software investigation:

• Working out how a feature in unfamiliar software is implemented, which functions handle it, and how the components relate.
• Tracing call paths and data flow when a feature spans several modules or processes.
• Analyzing compiled applications. For supported targets, REA connects the matching workflow so the agent can inspect binary structure, assembly code or decompiled pseudocode.
• Reimplementation and compatibility work, where developers use the analysis to understand the target's behavior, then design, build and test compatible functionality in their own projects.

That makes it useful for software maintenance, technical research, interoperability development, teaching, and authorized reverse-engineering work.

Software analysis is different from recovering source code automatically. REA doesn't guarantee recovery of an application's complete original source, and it doesn't promise an exact copy of the original software. Its analysis capabilities give an agent more concrete evidence to work from when it tries to understand a target.

2.2 How does REA differ from traditional AI coding assistants?

The table compares the two workflows.

Dimension	Traditional AI coding workflow	REA-assisted workflow
Starting point	User instructions, existing code, or a requirements description	Investigation questions about a target piece of software
Core activity	Generating, explaining, or modifying code	Investigating software with the help of analysis tools
Access to internal implementation details	Depends on the context provided	Can inspect supported targets through analysis workflows
Source of evidence	May rely heavily on existing context and model knowledge	Can incorporate analysis results specific to the target software
Follow-up implementation	Generates or modifies code	Uses analysis findings to guide implementation and testing
Main limitation	Tends to make assumptions when context is insufficient	Coverage and conclusions are still bounded by the target, the tools, and the evidence

REA is best understood as a toolkit that extends an AI agent's ability to investigate, used alongside the programming tools a developer already has. What it adds is more reliable information about the target software before the agent writes any code.

3. Mechanism: how do AI agents, MCP, and analysis tools work together?

REA involves three parts: the AI agent, the connection layer, and the analysis tools underneath.

3.1 The AI agent decides what to investigate

The agent interprets the developer's question, works out what information it still needs, reads the analysis results and chooses the next step. A developer might ask:

"How does this desktop app copy rich text to the clipboard?"

Finding a function with "clipboard" in its name won't answer that. The agent may need to locate the feature's entry point, trace the calls, follow the inter-process communication and find where the operation is finally performed. The agent does the reasoning and coordination, and REA supplies the analysis results.

3.2 MCP connects agents to external tools

The Model Context Protocol (MCP) lets compatible AI applications work with external tools and resources through a standard interface. In REA, MCP is how a compatible agent client reaches REA's capabilities. The agent requests an analysis, gets the results, and decides from them whether to keep investigating.

A language model can't inspect every kind of software artifact by reasoning alone. It needs tools that analyze the target and return information it can judge, and REA's MCP integration gives agents a structured way to use them.

3.3 Analysis tools examine the target software

The analysis layer does the technical work, and the tools depend on the target type. For JavaScript or Electron apps, analysis may focus on modules, code structure and how components relate. For native binaries it may involve binary structure, assembly code or decompiled pseudocode, and some native workflows need external tools such as Hopper, Ghidra or IDA.

No single technique handles every format equally well, so each target needs its own methods and dependencies.

3.4 From a question to evidence-based implementation

An REA-assisted investigation usually goes through five stages:

1. The developer defines the feature or behavior they want to understand.
2. The agent investigates the target using the relevant REA workflows.
3. The analysis returns concrete findings, such as code relationships, function information or other data about the target.
4. The agent builds an explanation from that evidence and notes what still needs confirming.
5. If the goal is to reproduce a feature, the agent uses the findings to guide implementation and testing.

This often takes several rounds. When the first results don't explain a behavior, the agent asks follow-up questions or looks at related components. That loop is how reverse engineering normally works: form a hypothesis, test it against evidence, and revise as new information comes in.

REA supports the loop, but the result still depends on the target software, the available analysis capabilities, and how accurately the results are interpreted.

3.5 From software analysis to AI workflows

REA is also an example of a broader pattern in AI development. What an agent can do depends on its model, and also on the tools, data and external services it can reach.

A complete AI workflow usually has two layers. The model layer understands instructions, analyzes information, generates content and reasons. The tools and execution layer connects to external services, fetches information, takes actions or analyzes specific software.

REA sits mostly in the second layer. It lets the agent investigate the target with analysis tools instead of guessing at the internals from the user's description.

The model still matters. Models differ in code understanding, complex reasoning, cost and response speed, and developers building AI applications may want to reach several models through one platform instead of tying the whole application to one. So besides giving an agent tools, developers also have to decide how to manage and access the models that do its reasoning.

4. Evidence: how REA analyzes Notion's clipboard feature

One case published by the REA team analyzes the clipboard feature in Notion Desktop 7.6.1. It's a good example because copying is a simple action for the user, while inside an Electron application it can involve several components.

The official REA Notion clipboard case study shows the call path and the related analysis.

4.1 Step 1: Start from what the user can observe

Say a developer wants to know how Notion handles copying. The first question is which part of the application actually performs the operation.

Looking at what lands in the clipboard won't answer that. The developer has to find the implementation path.

4.2 Step 2: Trace the function call path

The official case describes a path that starts with a call on the page side:

clipboard.write(data)

The preload layer wraps this call and passes it to the main process through Electron's inter-process communication. The full path is:

1. The clipboard interface on the page side
2. The preload layer using ipcRenderer.invoke
3. An IPC channel named notion:clipboard:write
4. A main-process handler registered with ipcMain.handle
5. The final call to Electron's clipboard write function

With concrete function names and call relationships, the developer has a technical path to analyze. "Notion implements copying with Electron" is true but vague. The traced path shows how the request actually moves through the application.

4.3 Step 3: Why application architecture matters

Electron applications usually keep web-facing code apart from privileged operations, which run in the main process, so the communication between those layers is a large part of how a feature works. Following the clipboard call from the page side through the preload layer to the main process shows where the operation starts, how it's forwarded and where it finally runs.

That helps in three ways. It identifies the components involved in the feature. It gives a clearer starting point for looking at how data is transformed and transferred. And it separates the interface the user sees from the code that performs the underlying operation.

A developer building something similar in their own Electron project can design the architecture from this information instead of guessing how the original application was built.

4.4 Step 4: The analysis goes beyond plain text

The case also describes how Notion uses HTML identifiers to reference locally stored structured block data, which preserves the block structure of the copied content.

Reproducing the feature therefore means knowing what the transferred data contains, as well as which APIs are called. A simple text editor can get away with copying a string. A more complex application may need the copy to carry formatting, content structure or references to richer data. The clipboard API alone won't tell you any of that, so you need to understand the application logic around it.

4.5 What does this case demonstrate?

The Notion case shows software analysis taking an agent from a broad question to a specific technical explanation: the call path, the process boundaries it crosses, and how the app handles structured content. Finding the clipboard API was only the first step.

The case covers one specific version of the application, and the simplified snippets in the official write-up are not the complete original source code. It still shows clearly how REA is meant to be used.

More generally, it shows what reverse engineering involves: joining scattered technical findings into an explanation of how the whole system behaves.

5. Action: how to get started with REA, and what to keep in mind

Once the idea makes sense, the next questions are how to try REA and whether it fits your task.

5.1 Step 1: Read the official documentation

Start with the REA GitHub repository and the official guide.

Look at which target types are supported, the installation requirements, the available analysis workflows, and the dependencies the software you plan to study will need. This matters most for compiled native applications, where different workflows may need different external tools.

5.2 Step 2: Check your local environment

REA installs and configures through npm and has specific Node.js version requirements. Its documentation lists:

• Node.js 22.x, version 22.19 or later
• Node.js 24.x, version 24.11 or later
• Node.js 26 and above

Check the installation docs again before you start, since requirements can change between versions. Also decide which AI agent client you'll use, and confirm it can be configured the way REA's instructions describe.

5.3 Step 3: Run the setup command

The repository gives this configuration command:

npx rea-agents setup

Follow the prompts and the documentation to configure your agent client and install whatever your target needs.

Setup is only the first step. Depending on the target software and the analysis tools involved, some workflows will still need more installation before they can run.

5.4 Step 4: Pick an investigation task with a clear scope

For a first try, pick software you own or are authorized to analyze, and ask one specific question. Start smaller than "explain this whole application." For example:

• How does a certain function relate to other modules?
• How does an Electron app pass requests from one process to another?
• Which components are likely responsible for handling a particular user action?
• How does a supported binary exhibit a particular behavior?

Specific questions make it easier to tell whether the results are useful.

5.5 Step 5: Check the evidence before implementing anything

Treat the agent's conclusions as claims to check, and look at the reasoning behind them. Ask yourself:

• Is the available evidence sufficient to support this explanation?
• Are any important links missing from the call path?
• Does the agent distinguish confirmed findings from unverified assumptions?
• Can code written on the basis of these findings be verified through testing?

If the evidence is thin, narrow the question or keep investigating related components until the evidence supports the explanation.

5.6 REA's strengths and limitations

REA is most useful when you need to investigate unfamiliar software and want an agent that can use specialized analysis tools, rather than one working only from a description of the requirements. It has limits:

• Analysis doesn't recover full source code. For compiled software you may get assembly, pseudocode or partial structural information, without the original source, comments or development history.
• Results depend on the target and the available tools. Different formats need different methods, and some tasks need extra tools or specialist expertise.
• The agent's conclusions need checking. Analysis results can be incomplete or ambiguous, so verify the evidence behind important conclusions and test anything you build on them.
• Authorization and compliance matter. Use reverse engineering only for legitimate, lawful purposes, and follow applicable laws, software licenses and third-party rights. Being technically able to analyze an application with REA doesn't give you the right to analyze, copy or redistribute it.

Within those limits, REA is a tool for investigation, analysis and evidence gathering. Technical judgment stays with the developer.

6. From REA to A2Agent: building more flexible AI application workflows

REA shows how external tools extend what an AI agent can do. Tool calling is only one part of building an AI application, though. When a workflow combines reasoning, code analysis, data processing and calls to external services, you also have to choose the underlying model and decide how to access it.

Large language models differ in code understanding, complex reasoning, response speed and cost. Comparing them, or matching a model to each use case, needs a flexible way to reach them. A2Agent provides one way to access supported large language models, so developers can try different models and use them in their own AI development workflows.

REA and A2Agent work at different layers:

• REA covers the software analysis and tool layer. It helps agents investigate target software and understand its behavior from analysis results.
• A2Agent covers the model access layer. It gives developers one entry point to supported large language models so they can find a model that suits each use case.

They're different kinds of tools, and neither substitutes for the other. They answer two separate questions in AI application development: how to give a model enough reasoning ability, and how to give a workflow the tools it needs to finish its tasks.

Model access doesn't automatically mean REA support. Whether a particular MCP service or external tool works with A2Agent depends on the interfaces, client architecture and integration methods A2Agent currently supports.

Thinking about the model layer and the tool layer separately is a good place to start when designing a flexible AI workflow. If you're comparing large language models and looking for a way to access them in your AI projects, you can learn more about A2Agent.

Conclusion: from code generation to software investigation

AI coding tools have made it easier to generate and modify code, but understanding an existing application is still a separate and difficult task. Without the original source, developers have to investigate implementation details, trace how components relate, and test their explanations against evidence.

REA connects AI agents to software analysis workflows through MCP. Agents can investigate supported targets and use the results to explain software behavior or guide implementation.

The Notion clipboard case shows why that matters. Understanding the feature took more than finding a clipboard API. It meant tracing the layers a request passes through and how the application handles the data involved.

REA doesn't remove the difficulty of reverse engineering, and it can't guarantee a perfect reproduction of an application. What it gives an agent is a more structured way to investigate a target before trying to reproduce its behavior.

AI applications need both tools and models. Developers need tools to gather information and carry out tasks, and they need to choose and access the right models for their actual needs. For anyone studying unfamiliar applications, solving compatibility problems or building more flexible AI workflows, the shift from generating code to investigating software with evidence is worth following.