Real support surfaces are not one bot. They are a front door with a billing specialist, a technical specialist and an escalation path behind it — and every inbound message needs somebody to decide who answers. Most platforms make that decision a configuration field they never actually read. Botmanor makes it a runtime.
A bot app declares a routing strategy, and each attached agent link carries the material a router needs: a priority, trigger keywords, intent patterns, a fallback agent, and its own execution counters. Single dispatch always uses the default agent. Round-robin spreads load across the linked agents and advances its state on the link itself, so the rotation survives restarts. Custom evaluates the routing rules you authored on the link. Intelligent is the interesting one: it scores the message against each candidate's keywords and patterns first — cheap, deterministic, unit-testable — and only escalates to a model classifier when that scoring is inconclusive.
That ordering is a cost and reliability decision as much as a quality one. Most messages are routed by a keyword match that costs nothing and behaves identically on every run; inference is reserved for genuinely ambiguous text. And when the classifier is unsure, the router does not guess — it falls back deterministically to the link's fallback agent or the app's default, so an ambiguous question reaches a human-configured destination instead of a coin flip.
The routing decision does not evaporate once the message is dispatched. The run that follows is recorded like any other agent execution, and the routing service is written as a pure function with no database or network dependency, which means every strategy is exercised by deterministic tests rather than hoped about. When someone asks "why did the billing agent answer a shipping question", the strategy, the candidates and the scoring are inspectable rather than folklore.
Two honest boundaries. The intelligent strategy is rule-and-classifier routing, not a trained model — there is no learned routing model and no A/B routing experiment framework, and Botmanor does not claim either. And linking specialist agents to an app with their keywords and priorities is an API operation today; the app's strategy and default agent are editable in the bot screen, while the per-link routing configuration is authored through the GraphQL API until that editor lands in the UI.
Today routing decisions run in the execution layer, but creating App→Agent links with keywords, patterns, priorities and fallback agents is API-only in the current UI. Because a real user cannot complete the full story by clicking through the web app alone, this page is presented as a narrative pattern rather than a clickable "Do it yourself" section.
Ready to make this your story?
