One Interface, Many Analysis Engines

REA’s investigation workflow only stays coherent if its architecture answers a basic systems question: who owns each decision when the same user-facing question may involve a CLI, an MCP server, a session, several providers, and more than one kind of Evidence? This chapter maps those responsibilities without turning the source tree into a catalogue. The goal is to understand why overlapping deep engines need deliberate selection, while artifact readers and observation providers can contribute alongside them without pretending that all results came from the same place.

From entry points to evidence

At the outside are two ways to ask REA for work. The one-shot CLI is suited to a bounded command from a terminal. The MCP server provides a stdio interface through which an agent can maintain a session and make related calls. They differ in transport and lifetime, but the project’s design gives them the same application workflows and Evidence contracts. That shared layer is important: a terminal command should not quietly define a different meaning for “compare,” “trace,” or “inspect” than the corresponding MCP operation.

The application layer owns those user-facing workflows. It translates a task-shaped request into operations over narrower ports: inspect one target, search for candidates, trace a relationship, compare two authenticated inputs, or observe a declared runtime. It can combine several provider results into an investigation record, but it should not need to parse every provider’s native protocol. Keeping that composition separate from transport lets an agent move between CLI and MCP without rewriting the reasoning model.

A request therefore crosses a meaningful boundary at the application layer. The caller names the target, operation, and lifecycle it intends to use. The application decides which contract applies and which provider capabilities are required. The provider returns its own observation and limitations, and the application projects that result into the shared Evidence vocabulary. At each boundary, state has an owner: the caller owns the question and supplied paths, the session owns active target context and retained records, and the provider owns the engine-specific interpretation of the target.

This also explains why target-free discovery is a separate responsibility. A caller may need to know which providers are configured or which operations are available before any target is imported. That discovery can inspect configuration and declared capabilities without creating a long-lived analysis process. Once a target is opened, the same architecture can refine the answer using target support and profile resolution. Separating these stages keeps “the adapter exists” from being confused with “this provider can answer the question for this target.”

A session layer sits between the application workflow and the active providers. It owns target transitions, retained Evidence, navigation context, residual unknowns, and the relationship between an open target and its provider binding. This is where lifecycle questions become concrete. When does a target become active? Which provider owns a deep operation? Which records remain available after a target switch? What happens when a call is cancelled or a provider cannot be closed cleanly? The session is not merely a convenience wrapper around a client; it is the place where the investigation’s state and provenance are kept together.

Below that boundary are providers and adapters. A provider understands a particular engine, format, protocol, or observation authority.