Skip to content
MirrorFirm

What tool actions, reset and logging would a mismatch environment expose?

A simulated environment can expose read and write tools with role authority checks, reset to a seeded snapshot, log every action with state hashes, and offer state-diff and grading hooks.

A simulated environment for this workflow exposes the business systems as tools, with state held in a store that can be reset.

Typical read actions are `search_records(system, filters)`, `get_record(system, record_id)`, `list_links(record_id)`, `get_policy(policy_id)` and `read_document(doc_id)`. Typical write actions are `post_adjustment(system, target_id, amount, reason_code, linked_ids)`, `amend_record(system, record_id, field, value)`, `raise_request(team, case_id, body)`, `add_note(case_id, text)` and `close_case(case_id, outcome)`. Each write checks the acting role's authority and returns either a result or a policy refusal that the model can read.

State is initialised from a seed file per task: a snapshot of every table plus the role the agent acts as. `reset(task_id, seed)` restores that snapshot exactly, so repeated runs start identically. Every action is appended to an event log with a sequence number, the arguments and the resulting state hash.

Evaluation hooks sit beside the tools. `get_state_diff()` returns the changes since reset, and `grade(task_id)` runs the checker against the end state and the log. Time can be a fixed clock set in the seed, so timing differences such as pending clearances behave predictably. The interface can be exposed as function-calling schemas, an MCP server or a plain HTTP API; confirm the form in a pilot.

Deterministic reset plus an action log with state hashes makes runs repeatable and lets you grade the route as well as the end state.

Audience:
Model labs
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Reconciliation mismatch