How can generated account state be packaged for repeatable agent runs?

A generated package can separate relatively stable entities from changing events. Parquet tables can hold accounts, obligations, teams and policy metadata. JSONL can hold contact events and tool-visible updates, with event_id, entity_id, occurred_at, sequence_number and event_type fields.

A manifest should identify the schema version, fixture identifier and required joins. Foreign-key checks can confirm that every obligation belongs to an account and every event references an existing entity. Where timestamps tie, an explicit sequence number can preserve replay order.

For an executable environment, reset_fixture can restore a named starting state, clear prior run mutations and initialise a controlled clock. A buyer can ask for a state digest before execution and a separate digest after the agent finishes. Resetting should also restore queued events; otherwise repeated runs can receive different external developments accidentally.

MirrorFirm could scope this package around a small set of account states before adding broader variation. The practical acceptance check is reproducibility: the same fixture and declared event schedule should expose the same starting information and permitted actions, independent of what a previous agent run changed.