Why separate a routing recommendation from the action that assigns work?

A routing benchmark can expose a decision interface followed by a dispatch interface. The first returns fields such as `request_id`, `proposed_queue_id`, `reason_code` and `evidence_refs`. The second applies the decision through an action such as `assign_request`.

This separation makes different failures observable. An agent can identify the right queue but submit an invalid identifier. It can also call the assignment tool successfully while choosing a queue that cannot resolve the request. A single success flag would conceal that distinction.

A generated environment can link each recommendation to an `action_id` and record the resulting `assignment_event_id`. Evaluation hooks can inspect the proposed owner, tool arguments and committed state separately. Dispatch success should depend on the environment accepting the action, rather than on the agent saying that it assigned the work.

For training, the same structure supports feedback on the precise stage that failed. For evaluation, it allows teams to compare reasoning quality across agents whose tool interfaces differ. The recommendation remains an intermediate artefact; the committed assignment establishes whether the operational task was completed.