Which systems and tool actions does a scheduling agent touch, and how do they map to an eval?

In most organisations, scheduling spans four systems. A simulated environment can expose each as a small tool surface.

- **Agreement store.** Holds principal, rate, term and permitted variations. Read-only for most tasks. Tool: `get_agreement(agreement_id)`. - **Schedule service.** Holds schedule headers and instalment lines with versions. Tools: `get_schedule`, `create_schedule`, `propose_adjustment`, `commit_adjustment`, `cancel_schedule`. - **Ledger.** Records postings against instalments. Usually read-only to the agent. Tool: `list_postings(schedule_id)`. - **Case log and approvals.** Holds notes, customer requests and approval states. Tools: `add_note`, `request_approval`, `get_approval`.

A useful split is **propose then commit**. The agent drafts an adjustment, the environment returns the computed lines and any policy flags, and only `commit_adjustment` changes state. This gives the harness a clean point to score reasoning before the write.

For evaluation, record three things per run:

- The ordered tool calls with arguments. - A before and after snapshot of schedule, lines and approvals. - The final message sent to the customer or requester.

Keep the environment resettable from a seed plus a scenario identifier so runs are repeatable. Which systems to mock, and how closely the tool names should match your own stack, are scoping choices to settle in a pilot.