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
Related questions
- How do I judge whether generated remittance and allocation records are realistic enough?
- Which failure modes should I test for in a payment matching agent?
- How would an evaluation score an agent on a hospital insurer remittance?
- How should scoring handle cases where several allocations are defensible?
- How do I check generated data for grounding and disclosure risk?
- How do invariant and link checks catch a wrong allocation in a clinic billing environment?