Where does an agent sit in a connected approval chain, and what can it call?

In a retail operations setting, take a price override request such as OVR-3310 raised by a store manager. The agent sits between the request queue and the systems that act on the outcome. A simulated environment can expose that position as a small set of tool actions.

- `get_request(request_id)` returns value, category, risk flags, requester and attachments. - `lookup_authority(role, category, amount)` returns the rule that applies and the role it requires. - `list_delegations(role, as_of)` returns active delegations with scope, start and end dates. - `find_role_holder(role, as_of)` returns who holds the role, including absence status. - `submit_for_approval(request_id, approver_id)` opens a decision task. - `record_outcome(request_id, decision)` applies the decision downstream. - `escalate(request_id, reason)` hands the request to a named next level.

Each call can read from or write to linked tables: requests, rules, delegations, role holders and an event log. The agent never needs free-text access to those tables, which keeps trajectories comparable across runs.

A clock value is part of environment state, so as_of lookups are deterministic. Downstream systems, such as a pricing table, change only when `record_outcome` succeeds.

For training, log every call with arguments and returned rows. For evaluation, compare the final state and the call sequence with the expected path. The environment is generated, so scope the tool names and fields to match your own connectors.