Skip to content
MirrorFirm

What reset, logging and grading hooks should an evaluation environment expose?

An evaluation environment needs snapshot reset, a structured action log, an end-state diff and named check functions so runs can be replayed and compared.

An environment built for evaluation needs a defined start, a record of what the agent did, and a way to compare end state to expected state.

**Reset.** Each task loads from a `start_snapshot` identifier. Reset restores all tables and queues to that snapshot, clears the action log and re-seeds any random elements, so repeated runs begin identically.

**Action log.** Every tool call is written as a JSONL event: `run_id`, `task_id`, `step`, `tool`, `arguments`, `result`, `state_version`. This supports replay and step-level review.

**End-state diff.** After the run, a hook exports changed rows: allocations created, item balances changed, cases opened, queue entries added or removed. The grader compares this diff against `expected` or against a rule for acceptable outcomes.

**Check functions.** Small named checks, such as `allocations_sum_to_line`, `no_post_over_threshold` and `followup_before_deadline`, return pass or fail with a message. They can run alone or be combined into a score.

**Hidden state.** Some facts, such as a payer's call recorded in a case note, can be placed in records the agent must choose to read, so you can test information-seeking behaviour.

Ask for the check functions as readable code so you can extend them with your own rules.

Deterministic reset, a replayable log and readable check functions make results reproducible and let you add your own rules.

Audience:
Agent developers
Content type:
Integration
Buyer question:
How to evaluate it

Content release: r-a220eb6e099b243b

More on Payment allocation