What tool actions and reset behaviour could a simulated schedule environment expose?

A simulated environment exposes schedule state through a small set of tool actions, so an agent can work as it would in a back-office system.

Typical actions:

- `get_schedule(schedule_id)` returns header, instalment lines and status - `list_amendments(schedule_id)` returns prior changes and decisions - `get_policy(policy_id)` returns text and structured thresholds - `propose_amendment(schedule_id, request_type, params)` returns a draft schedule without committing - `submit_for_approval(amendment_id, approver_role)` moves the draft into a queue - `commit_amendment(amendment_id)` applies it, and fails if approval is missing - `post_notice(schedule_id, template_id)` records customer communication

Each call returns JSON and writes to an event log with a timestamp, actor role and tool arguments.

**Reset.** An environment can start from a named snapshot, for example `snap_0412`, and reset to it between runs. A seed can control generated variation, such as pay dates and balances, so the same task can be run with different values. Ask for the snapshot format, which is commonly a directory of JSONL or Parquet files, and a reset command or API call.

**Evaluation hooks.** The event log and final state can be compared with an `expected_outcomes` file. Hooks can report step order, policy violations and final schedule differences.

For a reseller, specify which of these your customers can run themselves and which need hosting.