> ## Documentation Index
> Fetch the complete documentation index at: https://docs.armin.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# Router and specialists

> Build one clear entry agent with focused specialists.

Use one **First Level router** as the broad entry point for customer requests, then let focused specialist agents handle deep support jobs.

## Why this setup works

The First Level router keeps one agent responsible for the customer conversation. It decides which job the customer needs, consults the right specialist, and sends the final reply.

Specialists stay narrow. A returns specialist can validate return eligibility. An order specialist can check delivery data. An address specialist can update an order. They do not each need to repeat your brand voice, general routing policy, or human-escalation rules.

This gives you:

* one place to maintain routing decisions
* fewer competing AI triggers
* smaller, clearer specialist instructions
* one consistent customer reply
* easier testing when you add another support topic

## Configure the First Level router

Give the router a broad exact scope, such as all supported email channels. Do not add an AI trigger to the router. Exact channel filters are checked before meaning-based AI triggers, so this router becomes the stable entry point for those channels.

The router should:

1. identify the customer's immediate request
2. ignore incidental, negated, or already solved topic mentions
3. consult the specialist whose scope fits
4. combine the specialist result with shared policy and brand voice
5. reply to the customer or hand the ticket to a human

<Warning>
  Keep one First Level router. Multiple broad routers can overlap and make routing depend on which
  agent was created most recently.
</Warning>

Consult specialists. Do not hand the customer conversation to another AI Agent. A handoff is only for a person, team, or human queue.

## Configure specialists

Give every specialist one support job and a detailed AI trigger. The trigger should include:

* the customer outcome the specialist owns
* typical phrases in your customer languages
* explicit exclusions for adjacent specialists
* edge cases such as short follow-ups or negated mentions

Keep specialist instructions focused on business policy, required data, actions, and the result they must return. If the specialist is only consulted by the router, it does not need separate tone, reply-style, or general escalation instructions.

Read [Triggers and filters](/ai-agents/triggers-and-filters) for a complete AI-trigger example.

## Add a specialist safely

<Steps>
  <Step title="Create the specialist">
    Go to [AI Agents](https://armin.cx/app/_/ai/agents-v2) and ask Ask Torben to create the focused
    support job.
  </Step>

  <Step title="Write a clear AI trigger">
    Define what belongs to the specialist and what belongs to adjacent agents.
  </Step>

  <Step title="Update the router map">
    Add one branch to the First Level router that names the specialist. Ask Torben proposes this
    router edit after creating the specialist; review it before applying it.
  </Step>

  <Step title="Test both sides of the boundary">
    Test requests that should use the specialist, adjacent requests that should not, and ambiguous
    requests that should reach a human.
  </Step>
</Steps>

## Keep the router current

When you change a specialist's scope, update its AI trigger first. Then update the matching branch in the First Level router. The router branch should be based on the specialist's full trigger, not a short label such as “Returns” or “Orders.”

Use [Testing and run history](/ai-agents/testing-and-runs) to verify which specialist was consulted. Learn how the consultation works in [Subagents](/ai-agents/subagents).