How does this workflow map onto environment state, tool actions and observations?

A cash-matching environment can be described as a few pieces of state, a handful of tools and a defined observation.

**State tables**

- `account`: identifiers, terms, status and linked contacts. - `open_item`: item id, account id, amount due, amount outstanding, due date, dispute flag. - `payment`: payment id, received amount, value date, channel, raw remittance text, payer reference. - `allocation`: payment id, open item id, amount, reason code, actor, timestamp. - `case` and `audit_log`: queries, notes and every state-changing call.

**Tool actions**

- Read-only: `get_payment`, `search_open_items`, `get_policy`. - State-changing: `apply_allocation`, `hold_unapplied`, `reverse_allocation`, `open_query`, `escalate`.

**Observation**

Each call returns structured JSON, and the payment carries free-text remittance, so the agent must read as well as look up. Errors are part of the design: applying more than the outstanding amount returns a rejection with a code rather than silently clamping.

**Invariants** the environment enforces regardless of agent behaviour: allocations never exceed the payment amount, outstanding amounts never go negative, and every change writes one audit row.

This mapping is a starting point. Exact tables and tools are scoped in a pilot to match your harness. The records are generated, and their grounding should be inspected before use.