Skip to content
MirrorFirm

How does a mismatch workflow map onto an agent's tools and actions?

Describes the read, write and escalate actions a simulated environment could expose so an agent can investigate and resolve a mismatch case end to end.

A simulated environment for this workflow can expose a small set of typed actions. Separating reads from writes lets you log what the agent looked at before it changed anything.

**Read actions**

- `get_case(case_id)` returns the exception, the two records in conflict and the stated difference. - `get_record(system, record_id)` returns one record from a named system, such as bank feed or ledger. - `list_related(record_id, relation)` follows links such as `settled_by`, `reversed_by` or `amends`. - `get_policy(policy_id)` returns tolerance, approval limits and authoritative-source rules.

**Write actions**

- `post_adjustment(account_id, amount, reason_code)` changes ledger state. - `request_approval(case_id, approver_role, note)` routes a decision to a person. - `escalate(case_id, team, note)` hands the case on. - `close_case(case_id, resolution_code, note)` ends the run.

**State**

Each run starts from a seeded snapshot. Every call is appended to an event log with a timestamp, arguments and result, so a grader can reconstruct the path.

The tool names and arguments above are a pattern, not a fixed interface. Scope the actual set with the pilot, based on the systems you want the agent to work against.

A small, well-typed tool set lets you record every investigative step and every state change for scoring.

Audience:
Evaluation teams
Content type:
Integration
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Reconciliation mismatch