From a Feature Question to an Investigation
REA’s value appears when an agent has a question that is narrower than “tell me everything about this application” but broader than “show me one function.” This chapter follows how REA turns that question into a sequence of evidence-bearing actions. The focus is not a preferred command sequence; it is the lifecycle of an investigation: define the target, find candidate clues, connect relationships, preserve the resulting Evidence, and decide what question the next action should answer. That approach helps a reader choose tools by purpose rather than by familiarity.
Start with a question, not a tool
A reverse-engineering session becomes difficult when its first decision is a tool choice. “Use the decompiler” is not a question. “Where does offline search turn a query into stored-record matches, and what evidence would distinguish local indexing from a remote request?” is a question. The second formulation gives the investigation a subject, a boundary, and a reason to combine several kinds of observation.
It also gives the target a role. The target is not merely a path supplied to a command; it is the artifact, page, process, or scenario to which a later claim must refer. A native binary, an application directory, an archive, and a live browser page do not expose the same objects. An operation that is meaningful for one may be irrelevant or unavailable for another. Starting with the target and question prevents an agent from treating a familiar command as universally applicable and then interpreting whatever it returns as the answer.
REA’s documented example follows this pattern. The agent opens and identifies the target, searches strings and procedures for clues, follows cross-references to connect a clue to executable code, reconstructs callers and callees, and decompiles the routines that deserve closer attention. Each action has a different job. Opening establishes what is being investigated. Search creates candidates. References relate candidates to code. Callers and callees add control-flow context. Decompilation makes a selected region easier to inspect. The sequence is useful because each step narrows the next uncertainty.
Each step reduces a different uncertainty. A string search can suggest vocabulary but usually produces many candidates. A cross-reference can show where a value is used, but not necessarily why. Callers and callees expose context, while a function dossier or pseudocode view can make one portion of the path readable. A graph can reveal that several pieces are connected, yet still leave a dynamic dispatch or runtime condition unresolved. The investigation becomes reliable when these observations agree around a specific question and when their disagreements remain visible.
The sequence is not a ritual. A search may produce no useful candidate, or too many. A string that looks relevant may belong to an error message rather than the feature. A procedure may be reachable from several paths. A decompiler may expose a readable routine while leaving an indirect call unresolved. When that happens, the correct next move is determined by the unresolved question. The investigator might search for a related symbol, inspect data references, compare a second build, use a different artifact view, or collect a separately authorized runtime observation. The workflow is progressive because it follows evidence gaps, not because every target must pass through every operation.
This question-first approach also prevents an agent from confusing interface breadth with understanding. REA’s generated catalog contains many operations across native, artifact, browser, managed, Android, firmware, application, and session families. That breadth is useful only if the agent can select a capability that answers the current question. A page inspection, a managed member inventory, and a native call trace are not interchangeable ways to ask “what does this feature do?” They observe different objects under different authorities.
A lifecycle of narrowing
An investigation can be understood as a series of state transitions. It begins with a question and a target whose identity must be made explicit. The target may be a binary, an application directory, an archive, an assembly, a page, or a declared process scenario. Before a result can be interpreted, the system needs to know which object the result refers to and which provider is allowed to inspect it.
The next state is candidate discovery. Search and inventory operations are valuable here because they expose possible entry points without requiring the agent to assume one. A native string, an IPC channel, a module path, a class name, a resource, or a route can become a seed. At this stage, a candidate is not yet an explanation. It is a reason to ask a more discriminating question.
The investigation then enters relationship tracing. Cross-references, callers, callees, application-graph edges, incoming references, and artifact relationships connect the candidate to surrounding structure. These edges can turn an isolated name into a possible route. They also expose ambiguity. If two targets satisfy the same static condition, choosing one because it appears first is not a discovery; it is an unrecorded assumption. REA’s result contracts are designed to preserve competing candidates and unresolved paths where they matter.
A later state is focused inspection. The agent may request a function dossier, pseudocode, assembly, CIL, a method body, a page capture, or a process observation. The right representation depends on the target and the question. Readable output is often helpful, but it remains tied to the provider and its coverage. A static result can support a new hypothesis; an observed event can confirm behavior within a specified window; a comparison can show a difference under a shared contract. None of these should be promoted into a stronger authority simply because it is easier to read.
What persists across these transitions is not an invisible conversational memory. It is the target identity, the Evidence record, and the relationships that the next workflow is allowed to consume. What changes is the question being asked and sometimes the authority needed to answer it. A session may retain records while the active target changes, but closing the binary clears the retained ledger and residual-unknown registry. A fresh connection cannot use an old identifier merely because the identifier looks well formed. The lifecycle therefore has both analytical states and ownership states: a result can remain useful only while the system can verify where it came from and which session still owns the reference.
The final state is not always “solved.” It may be a useful Evidence record plus an explicit residual unknown. That outcome can still guide implementation. An agent might have enough evidence to reproduce a data shape while knowing that an unobserved error path remains uncertain. It might identify the native handoff from a JavaScript module while needing a selected deep provider to inspect the native export. It might compare two application graphs and classify some nodes as changed while keeping partial one-sided absence unknown. A lifecycle that ends with a bounded unknown is healthier than one that ends with a confident but unsupported story.
The following sequence captures the control flow without implying that every investigation uses the same number of calls:
The diagram has two important properties. First, the shared workflow sits between the interface and provider, so the CLI and MCP server do not need separate interpretations of the same investigation. Second, the ledger is part of the lifecycle, not an afterthought. A follow-up can use the complete record or a retained reference, while the original producer and limitations remain attached.
Prompts guide; they do not authorize
A coding agent can still need help discovering the right starting point. REA exposes guided investigation prompts such as feature investigation, application-version comparison, reconstruction verification, crash tracing, residual-unknown auditing, and bounded process-capture preparation. These prompts are provider-neutral suggestions. They can point to relevant tool names or ask for useful context, but they do not invoke a tool, broaden a request, or act as permission.
That boundary matters because a prompt can be mistaken for an execution plan. A suggestion to inspect a browser target does not authorize navigation. A suggestion to compare two artifacts does not identify those artifacts. A completion value for a procedure or Evidence record is a starting point, not a call. The actual operation still receives its own target, lifecycle, input, and effect contract. This keeps discovery assistance separate from authority over a process, browser, file, or analysis provider.
Session-aware completion is useful for a different reason: it reflects the current state rather than inventing a global directory of names. Documents, procedures, providers, retained Evidence, artifact occurrences, process-capture records, and residual unknowns can become suggestions when they are actually available in the current session. Opening or switching a target changes those suggestions; closing it clears the session’s Evidence ledger and unknown registry. If a provider fails or a proposed identifier cannot be verified, completion returns no trusted identifier rather than guessing.
This statefulness makes the agent’s investigation more coherent, but it does not remove the need for judgment. The session can preserve a result; it cannot decide whether the result answers the feature question. The agent still has to compare the returned authority with the claim it wants to make. If the next action needs runtime evidence, a retained static graph is not a substitute. If the next action needs a native provider, a prompt’s suggestion does not silently start one.
One workflow, two interfaces
REA’s CLI and MCP server expose equivalent application workflows. The distinction is how the agent or operator reaches them, not a second set of semantics. A one-shot CLI command can read an Evidence record from a file for a later comparison. An MCP session can retain compatible records and accept a reference to one already produced by the same connection. In both cases, the result is expected to remain understandable inline; the caller should not have to fetch a hidden resource simply to discover what happened.
This parity has practical consequences. It prevents a convenient terminal command from making stronger claims than its MCP equivalent. It also makes an investigation portable. An operator can use the CLI to create a saved Evidence record, then pass that record into a later workflow; an agent can keep a target and its records in a session while iterating. The underlying provider may still have different prerequisites or coverage, but the application-level contract describes those differences rather than allowing interface drift to conceal them.
The retained ledger also gives lifecycle events meaning. Opening another target can preserve records in the active connection, while closing the binary clears them. A fresh connection cannot infer whether a missing Evidence reference was never recorded, was cleared, or belonged to another session. The caller must supply the complete record, repeat the producer, or import a bundle. That rule may seem strict, but it prevents an opaque identifier from becoming a false link to evidence that the current investigation cannot verify.
The same principle applies to cancellation and failure. A provider call receives the request’s cancellation signal, and cleanup reports when owned resources cannot be verified. A timeout is not automatically evidence that a feature failed, just as a prompt is not evidence that a provider ran. The lifecycle needs distinct states for completed observation, cancellation, provider unavailability, and incomplete cleanup so the agent can choose a meaningful next step.
The investigation as a reusable habit
The durable lesson is a compact set of questions. What feature or relationship is being investigated? What exact target and scope are in play? Which operation can reduce the current uncertainty? What authority will produce its answer? How will the result connect to the previous Evidence? If the result is incomplete or ambiguous, what new observation would change the conclusion?
This habit turns REA’s breadth into a coherent system. It also keeps an agent from taking the shortest path to a plausible answer when the shortest path crosses an unmarked boundary. The next design problem is architectural: if many target families and analysis engines participate in one lifecycle, how can the system keep ownership, contracts, and provider differences clear? That is the role of REA’s layered architecture.