REA
REA architecture: route a question to evidence
Follow an agent request through MCP, sessions, providers and returned limits
What you will learn
- Separate orchestration from observation
- Track provider identity
- Return qualified evidence
Before you start
- A target you own or are authorized to examine
- Node.js and npm
- A selected local provider only if native analysis is needed
Use a harmless artifact to test setup, provenance, limitations and cleanup
Key takeaways
- MCP and CLI share evidence contracts.
- Provider selection is session-specific.
- A timeout does not always end provider work.
Separate orchestration from observation
The MCP server exposes discovery and analysis operations; the CLI uses the same workflow and evidence contracts. A request identifies a target and an operation, then the appropriate adapter or provider performs local inspection.
For binaries, a session binds a provider to the target. For JavaScript artifacts, a separate analysis workflow maps modules, imports and application boundaries. Browser observation requires its own running context.
Track provider identity
The session router does not make Hopper, Ghidra and IDA interchangeable. Provider availability, supported operations and target formats determine the route; explicit selection resolves cases where several qualify.
A provider may keep working after a client-side timeout. The CLI guide tells readers to inspect activity and recovery state rather than interpreting every timeout as a failed analysis.
Return qualified evidence
The MCP contracts distinguish evidence records, provenance, limitations and presentation summaries. A summary view is useful for reading but should not erase the underlying constraints.
The architecture can help an agent ask better follow-up questions. It cannot turn an unsupported provider operation or ambiguous observation into a fact about the original source code.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Identify target, operation and provider.
- 2
Trace session state and evidence record.
- 3
Read limitations with every conclusion.
Copy-ready example
agent or CLI -> operation -> session router -> local provider
provider result -> evidence + provenance + limitations -> readerFrequently asked questions
Can a summary substitute for raw evidence?
No. The CLI guide distinguishes a presentation view from the retained evidence and limitations.
Can I switch providers mid-session?
The CLI guide says a provider stays bound until an explicit switch.
Sources
- REA / README.mdSource checked 2026-10-14
- REA / docs/cli.mdSource checked 2026-10-14
- REA / docs/mcp-contracts.mdSource checked 2026-10-14
- REA / src/application/binary/SessionProviderRouter.tsSource checked 2026-10-14
- REA / src/application/javascript/JavaScriptArtifactAnalysis.tsSource checked 2026-10-14
- REA / src/server/EvidenceMcpServer.tsSource checked 2026-10-14