# Nine tools. Time to split.

> Route by role in code, not by a model.

- **Format:** short video, 9 steps, ~51 seconds
- **Topic:** Multi-agent handoff orchestration for Microsoft Foundry agents: split one overloaded agent into customer, partner and rider specialists, route by role in code before any model runs, and gate every write behind approval.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Published:** 2026-07-09
- **Tags:** microsoftfoundry, azureai, aiagents, dotnet, flutter, azure, aicoding, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/foundry-route-by-role-in-code/

---
## What you'll learn

- When one agent is no longer enough
- Why routing by role belongs in code
- What handoff costs

## Understand it one step at a time

### 1. Nine tools, one agent

Routing accuracy started falling at around nine tools.

### 2. The wrong tool

"How many orders are waiting" called track_delivery, not get_pending_orders.

### 3. Split by domain

Three specialist agents, each with only its own tools.

### 4. Route in code

The router reads the role from the validated JWT before any model runs.

### 5. Never the wrong handoff

A rider must never be handed to the partner agent because a question sounded operational.

### 6. Writes need approval

Anything that writes pauses for a human approval step.

### 7. What handoff costs

Each handoff is another model call, and more latency.

### 8. Accuracy back

Three focused agents, routed by role, with writes gated.

### 9. Route by role, in code

Split when routing accuracy falls, and never let a model choose the caller’s role.

---

## The takeaway

**Route by role. In code.**

Split agents by domain when routing accuracy falls; route by role before the workflow starts.