# Stop serving every request through one prompt: build an AI router in 90 minutes

Source: https://getstartedwithai.net/tutorials/ai-router-agent
Site: Get Started With AI
Tagline: Build AI automations that actually run your business.
Audience: solo professionals, freelancers, consultants and AI implementers in training
Contact: hello@getstartedwithai.co.uk

This Markdown companion is generated from the prerendered page for AI crawlers.
# Stop serving every request through one prompt: build an AI router in 90 minutes

The first chatbot I built for a client handled sales enquiries, support tickets and billing questions through a single prompt. It produced mediocre answers on all three. Six months later the client asked me to rebuild it. The rebuild took a day. The single do-everything prompt became four specialist prompts and a short classifier in front of them. Response quality went up, maintenance time went down, and the client could update each prompt without touching the others. That is the router pattern. This build takes about 90 minutes using n8n, Make or a Python script.

## Prep before you build (5 minutes)

Write down three to five request types your workflow currently receives before you open any tool. For a client-services business this is usually: sales enquiry, support request, billing question, partnership approach, general query. For an e-commerce operator: order status, returns, product question, complaint, press contact. You need the categories written down before you write a single line of routing logic, because the router is only as good as the destinations it points to.

## What you need on the bench

- Three to five request categories, written down as plain English labels. Not slugs, not codes. The classifier prompt uses the same wording, so vague labels produce vague routing.
- One specialist prompt per category, scoped to that job alone. Write at least one before you wire anything. A router with no destinations is latency with better naming.
- An LLM API (OpenAI, Anthropic) or a chat assistant you can call programmatically via a system prompt.
- n8n, Make, Zapier or a Python environment with the requests library. n8n is the cleanest option if you want the routing logic visible and auditable.

## Step 1: Write the classifier prompt

The classifier is a short system prompt that returns a category label and nothing else. Keep it under 100 words. But longer classifier prompts introduce the kind of ambiguity you are building the router to eliminate, so resist the urge to add context or hedging language to make the classifier feel more complete.

Example classifier prompt:

You are a request classifier. Read the user message below and return exactly one label from this list: sales, support, billing, partnership, general. Return only the label. No explanation, no punctuation, no other text.

Test this against ten real incoming messages before you wire anything else. The billing route on one client build kept misfiring on upgrade requests. The classifier was treating plan upgrades as billing rather than sales. Two words changed in the prompt fixed it. Run ten test messages and check every label before you build the routing layer.

If the classifier occasionally returns sales query instead of sales, tighten the instruction: return exactly the word, lowercase, with no suffix.

## Step 2: Build the routing logic

In n8n, the routing logic lives in an IF or Switch node placed after the classifier call. One branch per category, each branch calling a different prompt or HTTP webhook.

In Make, use a Router module. One route per label, each route firing a different AI module or downstream step.

In Python, the routing logic is a short dictionary mapping each label to a handler function, with a fallback to the general route for any label the classifier returns unexpectedly. Without that fallback, a misclassification breaks the workflow and you will not find out until a client asks why a message went unanswered. And that conversation, at month two of a retainer, is not the one you want to be having.

## Step 3: Write the specialist prompts

Each specialist prompt does one job and one job only. The sales prompt handles qualification and next steps. The support prompt handles resolution and escalation. The billing prompt handles account status and payment options. Keep each specialist prompt under 200 words.

The usual objection at this point is: why not write one very detailed prompt and trust the model to handle everything? I have tried it. Detailed prompts fail on edge cases at the worst possible moment. A billing prompt that mentions escalation will apply the escalation logic to a routine sales enquiry, maybe 8 percent of the time. Categories enforce the separation the model cannot reliably maintain on its own, and 8 percent wrong is unacceptable in a client-facing workflow.

If a specialist prompt is trying to handle two jobs, the routing categories are too broad. Split the route, not the prompt. So before you touch the specialist prompt wording, check whether the category definition is the real problem.

## Step 4: Test the full path end to end

- Send ten messages through the complete router, covering each category.
- Check that the classifier returns the right label for each message.
- Check that the right specialist prompt fires.
- Check that the output stays within scope for that category.
- If a billing question is hitting the support route, tighten the classifier. If the support prompt is offering refunds it should not, tighten the specialist. These are separate problems needing separate fixes.
- Keep a short log of the ten test messages and their outcomes. This is the handover document when you pass the workflow to a client.

## Step 5: Add confidence handling for edge cases

Some messages are genuinely ambiguous. Please sort out my renewal could be billing or support depending on the business. Ask the classifier to return a confidence score from 1 to 5 alongside the label. If the score is 3 or below, route to a disambiguation step that asks one clarifying question before proceeding.

In practice, fewer than 10 percent of real messages need disambiguation once the categories are well defined. The disambiguation path catches the edge cases without slowing down the 90 percent that are obvious. Yet most builders skip this step and then wonder why confidence drops when ambiguous messages arrive in volume.

## What you charge

A three-route classifier build bills at 800 to 1,500 pounds. A five-route build with disambiguation handling and a client training session runs 1,800 to 2,500 pounds. Package it as three deliverables: Audit (identify categories, write specialist prompts), Build (classifier plus routing logic), Handover (test log, maintenance guide, 30-day check-in). The test log from Step 4 is the handover document. Most builds take one full billable day once the specialist prompts are agreed.

Maintenance retainers run 200 to 400 pounds per month: quarterly testing, prompt updates when the product changes, monitoring for classification drift. Clients who skip the retainer often ask for one after the first quarter when they discover the prompts need tuning as their service evolves.

## What you ship

A working classifier that reads incoming requests and returns a category label. A routing layer in n8n, Make or Python that fires the right specialist prompt for each label. Three to five specialist prompts, each scoped to one job. A fallback route that catches misclassifications. A test log of ten messages with outcomes as the handover document.

## What to build next

Add session memory so the router tracks the category of the last three messages from the same contact. Someone who has sent two billing questions this week routes directly to billing without re-classifying. The RAG knowledge base tutorial shows how to attach a document store to each specialist prompt so answers draw from real product documentation rather than model memory alone.

## Related builds

More tutorials in Automation. Each one runs in 60 to 90 minutes and ships a finished asset.

### Capture every lead automatically: a 30-minute Zapier build

30 to 60 minutes. Solo Pro.

[Open tutorial](/tutorials/first-zapier-automation-30-min)

### Decide between native AI Steps and a Custom GPT in 10 minutes

60 to 90 minutes. Solo Pro.

[Open tutorial](/tutorials/zapier-ai-features-vs-custom-gpt)

### Run automations Zapier cannot: the first Make scenario

60 to 90 minutes. Solo Pro.

[Open tutorial](/tutorials/first-make-scenario-visual)

### Self-host the automation stack: when n8n is worth the effort

60 to 90 minutes. Solo Pro / Implementer.

[Open tutorial](/tutorials/n8n-self-hosted-when-worth-it)

## Questions people ask before they start

### How many routes should I build?

Start with three: sales, support, general. Add billing and partnership once the three-route version is running cleanly for two weeks. More than six routes in a first build usually means the categories overlap. If two routes keep misfiring on the same messages, merge them and sharpen the shared prompt.

### Can I use this inside a Zapier workflow?

Yes. Call the classifier via the AI by Zapier step or a Code step hitting the OpenAI or Anthropic API directly. Use Zapier Paths for the routing logic. The pattern is identical to n8n; only the interface differs. Zapier adds a couple of extra configuration steps for the API call but nothing that changes the underlying logic.

### What do I charge a client for this?

Three-route build: 800 to 1,500 pounds. Five-route build with disambiguation and training: 1,800 to 2,500 pounds. Ongoing maintenance: 200 to 400 pounds per month. Quote the category audit separately at 400 to 750 pounds if the client does not yet know their request categories. The audit often surfaces categories they had not considered, which justifies the separate line.

### What happens if the classifier mislabels a message?

The fallback route catches it and sends it to the general specialist prompt. Build the fallback on day one, not as an afterthought. Beyond that, review the test log monthly and adjust the classifier prompt when a pattern emerges. Two or three wording changes usually fix a recurring misclassification. If the same type of message keeps misfiring, the category definition is wrong, not the prompt.

### Is this the same as an AI agent?

No. A router is stateless: one message in, one label out, one prompt fires. An agent maintains state across a multi-step task and takes actions beyond generating text. The router is the right build when you need consistent triage. An agent is the right build when you want the system to pursue a goal across several steps. Most client workflows that claim to need an agent actually need a well-built router first.
