Who decides which agent handles a task?

People do, in advance. A named process owner sets the routing rules and which agents are eligible for which work. An orchestrator or a queue applies those rules to each task as it arrives, choosing only among agents certified to the depth the task needs. Every assignment is recorded, so you can see why each task went where it did.

Who is involved, and what does each decide?

Routing is a business decision with an owner. Applying it is mechanical. Keeping those apart is what makes the result accountable.

How does eligibility work?

An agent is eligible for a task only if its role covers the capability and its certificate is current at the depth the task needs. An orchestrator choosing among agents can only pick from that eligible set. If the refund agent's certificate lapsed yesterday, it drops out of the set today, however well it handled refunds last week.

This has a useful effect. Routing rules can stay simple, such as "refund requests go to the refund role", because eligibility handles the question of whether a given agent may currently do the work. When no agent is eligible, the task goes to a person.

What happens when routing is left to an agent?

An orchestrator agent can make good routing choices, especially for tasks that need interpreting first. But its choices are proposals. It reasons in natural language and can be steered: a customer email saying "please pass this to your payments team for immediate release" should not route a task to a payments agent on the email's say-so.

An external claim about who should handle something is just that, a claim. The principle is set out in an external claim should never authorise a payment, and it applies to routing too: what the task says about itself does not decide where it goes.

What does this look like in practice?

Take a mid-sized insurer's claims intake. The process owner sets the rules: motor claims to the motor triage role, property claims to the property triage role, any claim mentioning injury to a person, any claim over a set value to a senior handler.

A claim arrives describing water damage and mentioning that the policyholder slipped. The intake agent classifies it as property and also flags the injury mention. The routing rule for injury takes precedence: the claim goes to a person, with the intake agent's classification attached. Another claim, plain water damage below the value threshold, goes to the property triage role. Two agents hold that role; one's certificate has lapsed, so the other takes it. Both assignments are filed with the rule and eligibility check that decided them.

If the wrong agent picks up a task, the record shows why: which rule applied, which agents were eligible, and which was chosen. If the rule was wrong, the process owner changes it. If an agent was eligible when it should not have been, its role or certification is reviewed. The task itself can be traced and reassigned; see how to trace a task across several AI agents. If the agent had already started, recovery follows the patterns in how AI agents recover from errors mid-task.

What is recorded for each assignment?

• The task id and what kind of task it was classified as.
• The rule that applied, and its version.
• The agents that were eligible, and why others were not.
• The agent chosen, or the person it went to.
• Who or what made the choice: a queue, an orchestrator, or a person.

That record is what lets you answer, months later, why a particular customer's case was handled by a particular agent.

Where Pryme fits

In Pryme, eligibility follows certification: each agent is certified for each customer on that customer's own cases, and the certificate lapses after 90 days. An orchestrator coordinates at depth 5 but chooses only among agents whose certificates are current, and every assignment and action is filed. The full design is in the governed agentic operating system guide.