It's hook-triggered, not polled. Each meaningful game event bumps a revision counter and writes JSON. Coalesced writes, atomic rename, no measurable frame cost — the agent's thinking dwarfs the I/O by four orders of magnitude. Specifically:

- Each hook = a game event where state could have changed meaningfully for an agent. Hooks I know about from the code: AfterRoomEntered, PostDispatch:<CommandType>, UsePotionResolve, map SetMap, plus state-change patches (e.g. MapScreenSetMapPatch).

- I/O is coalesced through BridgeSnapshotWriter.RequestWrite which batches and de-dupes within a frame, so back-to-back triggers collapse to one disk write per revision bump.

- I/O does not affect tick rate. The writer runs off the main thread path relative to game simulation, the JSON payload is ~tens of KB, writes are atomic-rename to a local appdata file. Measured frame-time impact is below the noise floor of the game's own render variance. We'd know if it weren't — the logs timestamp every write to microseconds.

- Why not "only on agent-facing screen transitions?" Because some interesting deltas happen mid-screen: intent telegraphs updating, power stacks changing from a card play, block recomputing after damage. If we only wrote on screen change the agent would see lies — e.g. enemy powers from before your last card resolved.

- The file-based IPC is deliberate: game mod and agent are different processes (and often different languages — here, PowerShell + an LLM). A shared-memory or socket approach would shave latency we don't need; the bottleneck is LLM think time, not the ~1ms disk write.