Which systems does an agent touch when changing a schedule?

A schedule change rarely lives in one system. When you design an agent integration, expect at least four surfaces, each of which a simulated environment can represent.

- **Schedule or ledger store.** Holds `schedule_id`, `account_id`, `status` (`active`, `superseded`, `cancelled`), instalment rows and `supersedes_id`. - **Payment instruction service.** Holds debit or invoice instructions keyed by `account_id`, with `amount`, `next_collection_date` and `state`. - **Notification service.** Queues reminders and confirmations that reference a `schedule_id` and must be cancelled or regenerated after a change. - **Case management.** Holds `case_id`, requested change, assigned role, approval state and notes.

Typical tool actions an agent would call:

- `get_schedule(account_id, include_history)` - `get_policy(product_code)` - `propose_schedule(account_id, params)` - `request_approval(case_id, role, reason)` - `commit_schedule(proposal_id)` - `update_instruction(account_id, schedule_id)` - `cancel_reminders(schedule_id)` - `add_case_note(case_id, text)`

A useful design separates `propose` from `commit`, so a grader can see what the agent intended before state changed. Each tool should return structured errors for refused actions, such as `approval_required` or `policy_violation`, so agent behaviour on refusal can be scored as well as behaviour on success.