Where does an agent sit among the systems in a payment matching process?

An agent in this workflow usually sits between a bank feed and a ledger, with a case queue beside it. A simulated environment can expose that layout as a small set of tool actions so you can see what the agent reads and what it changes.

A typical read surface: - `get_bank_line(line_id)` returns amount, value date, payer text and channel. - `search_open_items(customer_id, status)` returns invoices, credit notes and instalments with due dates. - `get_policy(customer_id)` returns the allocation order and any hold or hardship flags.

A typical write surface: - `propose_allocation(line_id, splits[])` records intent without changing balances. - `post_allocation(proposal_id)` applies it and may require approval above a threshold. - `open_exception(line_id, reason_code, note)` parks the payment as unapplied. - `request_approval(proposal_id, approver_role)` routes the proposal to a person.

Separating propose from post lets an evaluation score the reasoning before any state changes, and lets you test whether the agent respects the approval step. Every call is logged with its arguments and the environment state version it saw, so a reviewer can replay a run.

The exact tool names and fields are set in scoping. Match them to your own agent framework where you can.