Reverse engineering is now a commodity: what REA means for platforms like Wetel

The repo is called REA — Reverse Engineer Anything. As of this week it has 171,000 GitHub stars and forty thousand forks. The README shows a Windows Calculator decompilation, a DOS game reconstructed from 16-bit instructions, and a Chrome Dinosaur game cloned from its live JavaScript.

The hype says software is done. The reality is more interesting — and more relevant if you run a platform like Wetel.

What REA actually is

REA is not a new decompiler. It is a Model Context Protocol (MCP) server that gives AI coding agents (Claude Code, Codex, Cursor, Gemini CLI) a unified interface to drive the tools reverse engineers have used for decades:

graph TD
    Agent[AI Agent] --> REA[REA MCP Server]
    REA --> Ghidra[Ghidra Headless]
    REA --> Hopper[Hopper Python Bridge]
    REA --> IDA[IDA Pro via ida-pro-mcp]
    REA --> Static[Static Parsers: ASAR, PE, Mach-O, JADX, Binwalk...]
    REA --> Browser[Chrome CDP / Playwright]

The innovation is the orchestration layer. REA keeps disassembly state alive across calls (Ghidra projects stay loaded, Hopper graphs stay hot), returns evidence contracts with every finding (content-addressed IDs, explicit unknowns, authority levels), and injects investigation workflows into the agent’s context.

The output is not source code. It is pseudocode + assembly + cross-references + a list of what the tool could not resolve. The agent uses that to write its own implementation and test it against the original.

What REA can extract from Wetel today

We pointed REA at our own public surface. Here is the honest breakdown:

Cloning outcome: An agent using REA could reproduce our entire frontend integration layer in hours. The result would be a visually identical dashboard that cannot execute a single workflow — the graph engine, connectors, knowledge bases, and voice processing remain completely opaque.

The moat shifted years ago

REA makes the boundary visible. It does not create it.

graph LR
    subgraph "Commoditized by REA"
        FE[Frontend Code]
        Schema[API Schemas]
        Docs[Public Architecture]
    end
    subgraph "Still requires building"
        Engine[Deterministic Graph Engine]
        Connectors[Certified Connectors]
        Infra[Operational Scale]
        Compliance[Data Isolation]
    end
    FE -.->|Hours to clone| Engine
    Schema -.->|Hours to clone| Connectors
    Docs -.->|Hours to clone| Infra

What Wetel sells is not the schema. It is:

1. Certified connector catalog — 170+ enterprise integrations (Lark, …, etc.) that have been vetted for security, credential rotation, and scaling. REA sees the connector names in the schema. It cannot see the OAuth flows, the rate-limit handling, the pagination logic, or the error-recovery code.
2. Operational scale — Thousands of background AI workers on cron schedules, supervising agents delegating to worker agents, bounded runs that fail diagnosably instead of burning budget silently. REA cannot observe runtime behavior it cannot reach.
3. Compliance guarantees — Workspace data isolation, dedicated single-tenant databases, audit logs that satisfy enterprise procurement. These are infrastructure commitments, not code patterns.

What this means for platform builders

1. Assume your frontend is public

If it runs in the browser, it is extractable. REA’s analyze_javascript_application and browser observation tools make this trivial. Do not put secrets in the client. Wetel’s avatarToken is short-lived (~24hr) and scoped to a single session by design — the long-lived API key never touches the frontend.

2. Assume your API schema is public

GraphQL introspection is a feature, not a bug. Wetel leans into it: agentConfigOptions lets integrators discover valid avatarGlb filenames and curated TTS voices without leaving GraphQL. Design schemas as public contracts. The value is in the execution behind them.

3. Invest in what cannot be observed

• Deterministic execution — Wetel’s graph engine processes Action nodes, Router nodes, LLM conditional switches, and Sub-agents with no hallucination. That reliability is built on a custom runtime, not prompt engineering.
• Credential isolation — Credentials live outside prompt spaces. SSO mapping, tenant routing, workspace token caps — these are cloud applications with their own security boundaries.
• Media infrastructure — True mid-sentence interruption, live 3D avatar streaming, HOSTED_API photorealistic video. The low-latency sync between voice and avatar is specialized infrastructure, not a library call.

4. Use REA as a regression test

REA is a legitimate tool for your own team:

• Capture Evidence bundles of your own binaries/widgets
• Compare Evidence across versions (rea compare-evidence)
• Verify reconstructions against original behavior (verify_reconstruction prompt)
• Audit residual unknowns before shipping

This turns REA from a threat into a quality gate.

What REA cannot do (yet)

For Wetel’s stack, the critical gap is dynamic analysis. Our graph engine, connector runtime, and voice pipeline are server-side. REA sees their signatures in the schema. It cannot trace their execution.

A checklist for any platform, Wetel included

1. Can REA clone your frontend in an afternoon? If yes, is the clone functional without your backend? (Wetel: yes / no)
2. Is your API schema introspectable? If yes, does the schema reveal execution logic or only contracts? (Wetel: contracts only)
3. Where does deterministic execution happen? Client or server? (Wetel: server — graph engine, connectors, voice)
4. What credentials touch the client? (Wetel: short-lived avatarToken only; API key stays backend)
5. Can a competitor replicate your operational scale from your public artifacts? (Wetel: no — cron workers, supervising agents, bounded runs are invisible)
6. Are your compliance guarantees code or infrastructure? (Wetel: infrastructure — single-tenant DBs, audit logs, data isolation)

Related Wetel reference docs

• Core API Flow: sdkStart, sdkSendMessage, sessionEvents subscription — the exact surface REA can observe
• Authentication: API keys, avatarToken delegation, dashboard JWT separation
• Agents: The 7-part model (Control flows, Knowledge bases, Skills, Identity, Channels, Audit logs, Initiative) — fully documented, not hidden
• Voice Interface: VAD/STT/TTS pipeline architecture — client-side wiring visible, server processing opaque
• MCP Connectors: How certified integrations work — execution logic never exposed
• Observability: Run traces, what you can inspect, what stays internal
• Roadmap reading guide: How to distinguish live features from direction

The bottom line

REA is a workflow breakthrough, not a scientific one. It commoditizes the operation of reverse engineering tools. The technology stack (Ghidra, Hopper, IDA) is decades old; the innovation is making them usable in an agentic loop.

For platforms like Wetel, REA validates a design principle we already follow: push the value into the cloud execution environment. The frontend, the schema, the docs — those are marketing surfaces. The engine, the connectors, the scale, the compliance — that is the product.

REA can clone the marketing surface. It cannot clone the product.

This analysis is based on REA v6.x (Oct 2026), Wetel public documentation, and hands-on testing. REA source: github.com/morluto/rea. Wetel docs: wetel.dev/docs.