SuperAstra's investigate-then-commit loop is a blueprint for grounded agent design

SuperAstra is a desktop agent that sits alongside BizHawk and modifies a running SNES game in response to plain-language requests. The mechanism is more interesting than the pitch: the agent doesn't just poke memory addresses you hand it. It builds a working model of the game's mechanics from scratch - reading live screenshots, cartridge headers, CPU registers, WRAM scans, OAM, VRAM, and audio RAM - then forms hypotheses, creates a checkpoint, runs a controlled experiment against that checkpoint, and only commits a change once it has verified the result. Older tool evidence stays searchable; verified findings are kept separate from unconfirmed hypotheses. The whole investigation can resume after a restart.

The context table in the README is the most honest part of the documentation. It lists exactly what the agent can see and do with each data source, and the caveats are stated plainly: this is a v0.3.2 prototype, live engine behavior has been tested through Snes9x, and a full end-to-end desktop test with native BizHawk and a live Astra request hasn't been confirmed yet. Controlled experiments can visibly interrupt play for up to 300 emulated frames per trial because the prototype reuses the same emulator instance rather than running a silent background copy.

The undo model is worth noting on its own terms. Every committed memory mutation gets a full emulator checkpoint. Undo restores the entire game state - including gameplay since that moment - and also rolls back the loaded-cartridge byte journal. Up to eight undo states are held in memory. Cartridge edits are bounded at 4,096 bytes per operation and 64 KiB of distinct journaled offsets per bridge session. The original ROM file is never touched.

The stated limits are specific and credible. The agent cannot expand a ROM, export a patch file, synthesize new artwork, or debug every special chip. Some requests need assets or cartridge space that simply aren't there. The README says directly that "any game, any prompt" describes the interface goal, not a success guarantee, and that an unfamiliar game may require multiple requests, user observations, or additional reverse-engineering work.

For anyone building agents that interact with live software state rather than static files, the architecture here is instructive. The investigation loop - observe, hypothesize, checkpoint, experiment, verify, retain - is a concrete implementation of the kind of grounded tool use that most agent frameworks describe abstractly. The persistent game notebook, bounded transcripts, and separation of hypotheses from verified findings are design choices that address real failure modes in long-running agentic tasks. Whether the underlying model actually delivers on the harder requests is a question the README wisely leaves open.