ReAgentLive

The live, in-process probe for AI-driven game reversing.

Static tools tell you what the code does.
ReAgentLive tells you what is true in the running game, right now, and lets
you test it without breaking anything.

Live. It runs inside the game and answers from live memory, on the
game's own tick.
Safe. References that know when an object died, writes that check
first, changes that undo themselves.
Immediate. No database, no hours of analysis: questions about code
are answered from live bytes in milliseconds.

First-class Unreal Engine support. Build the Unreal pack against the
SDK Dumper-7 generates for your
game, and work by name: find objects, read and follow reflected fields,
call functions, list every instance of a class, all on the game thread.
Everything else (memory, code, native structs) works in any game.

The problem

Point an AI agent at a running game with the usual tools and it hits the
same walls:

• Reads from outside are torn. Two values read a moment apart never
  came from the same frame.
• Pointers go stale. An enemy respawns and yesterday's address is now
  someone else's memory.
• Raw writes crash things. One wrong byte, no undo.
• Static analysis is slow. Hours of whole-program analysis before the
  first answer, and again after every patch.
• Huge tool surfaces eat context. A hundred tools cost an agent its
  budget before it does anything.

ReAgentLive is built around those walls.

30 seconds of it

Load one DLL into any x64 process, here a running Python interpreter, and
ask. No game, no SDK, no database. Output condensed from the JSON the
console prints:

> reagentlive -c "search text PYTHONPATH --module python313.dll --paged --timing"
  hits: python313.dll+0x2c1ca8                               4.9 ms

> reagentlive -c "xrefs python313.dll+0x2c1ca8 --timing"
  lea  python313.dll+0x12ff02  in function +0x12fd64..+0x1301ce
  scanned all of python313.dll                               29.6 ms

> reagentlive -c "disasm python313.dll+0x12ff02 3"
  +0x12ff02  lea rdx, [0x7FF827981CA8]   string: "PYTHONPATH"
  +0x12ff09  mov rcx, rbx
  +0x12ff0c  call python313.dll+0x1301d0

A string, every place the code uses it, and the code around it: three
commands, well under a second, straight from the bytes the process is
running. Every address comes back as module + rva, ready to paste into
your disassembler.

Why it is different

No single one of these is new. The combination is.

Low footprint

ReAgentLive is quiet. It answers when asked and otherwise stays out of the
game's way:

• No hooks of its own. The core never patches code or swaps a pointer;
  where the tick comes from is the host's business.
• No threads of its own. It runs on a thread the host already has. The
  own-thread example adds exactly one, its tick; background search adds a
  worker only when the host allows it.
• No process handle. The client never opens the game process: no
  OpenProcess, no ReadProcessMemory, no debugger. Requests travel
  through one named shared-memory section.
• Next to nothing while idle: one atomic increment and one compare per
  tick. Fixed buffers, no allocation at load.

Low footprint means it does not disturb the game. It does not mean hidden:
see what it is not.

What you can do

Try it in five minutes

The own-thread example is a DLL that works in any x64 process: no mod,
no SDK, no game knowledge.

# From a Visual Studio x64 developer shell, in the ReAgentLive folder:
cmake -S examples/own_thread -B build/own-thread -G Ninja -DCMAKE_BUILD_TYPE=Release
cmake --build build/own-thread
# Load reagentlive-own-thread.dll into the target with any DLL loader, then:
reagentlive -c "status; modules"

You get memory, the fast lane and native objects (vtable, pointer chains,
region, strings): the core, which needs no SDK. Unreal pack commands are
refused here, and status says which packs a host offers (packs). With
no pid the console finds the process on its own.
More: own-thread example.

Best on the game thread

The own-thread DLL is the fast way in. ReAgentLive is at its best when the
host ticks it on the engine's game thread, from a mod or a hook you
already own:

status says which one you have (host_thread). How to get onto the game
thread is the host's business; what each choice gives is in
hosting.

Go further

• Unreal games: the Unreal pack over your Dumper-7 SDK adds objects,
  reflected fields, function calls, census (what exists, what just
  spawned) and each (one field across every instance, in one tick).
  Unreal pack
• Your own mod as the host: tick the agent from the game thread and get
  all of the above. Hosting
• Logic outside the game: keep a tool or a mod's logic in its own
  program and use the core as a lean in-process proxy.
  Outside programs
• AI agents: the reagentlive skill teaches the investigation method:
  rules, workflow, pitfalls. Skill

Where it can grow

The core knows no engine. Everything engine-specific lives in a pack:
today one, for Unreal. Memory, the fast lane and native objects already
work in any engine; a pack adds objects, fields and calls on top.

Natural next packs are Unity (Mono and IL2CPP) and Source 2. They
are candidates, not promises: one gets built when a real project needs it
(backlog).

Plays well with others

ReAgentLive is a friendly neighbour, not a replacement. Keep your IDA or
Ghidra MCP for the static side and your Cheat Engine MCP or Frida for
scanning and hooking; ReAgentLive is the extra tool for what only the
running process can answer, and it hands every address over as
module + rva so the agent can carry it between them.

The safety model

• Writes check first. A write can require the bytes you expect to still
  be there; otherwise it is refused and shows what it found.
• Identity, not just addresses. An object reference carries its table
  slot and serial, so a replaced object is refused instead of written into.
• Changes that end on their own. Pins expire; a trial write restores the
  original bytes when it expires or is cleared, and stops writing as soon as
  its owner is replaced.
• Engine calls only on the engine's thread. A host that ticks elsewhere
  gets memory commands, and engine commands are refused.
• Approval stays yours. Anything that can change game state is a
  separate, explicit command.

What it is not

• Not an injector. Something inside the process has to call its tick:
  your mod, or the example DLL loaded however you like.
• Not "every engine" out of the box. Memory and code work in any
  process; objects, fields and calls need an engine pack, and today there
  is one, for Unreal (UE5 layouts, built against your SDK dump).
• Not a debugger, decompiler or signature maker. It checks and reports;
  analysis stays with your static tool and your agent.

Status

Version 0.1.0 (changelog): usable, and the API can still
change before 1.0. Windows x64, C++23. Shipped: the in-process agent, tick-accurate reads,
guarded writes, pins and trials, the Unreal pack, the fast lane, native
objects, the console, the Python client and the own-thread example.
Planned items wait for a real need (backlog).

Docs: start at docs/INDEX.md: pages by task, every
command and its page, and a glossary.

License

MIT (LICENSE). Dependencies, all MIT: nlohmann/json and Zydis
(with Zycore) for the console, fetched at configure; doctest for the tests,
in third_party/.