LayBuild does not have a supervisor agent that reads each message and passes the conversation between specialist agents. What it has is simpler: an organization can run several agents, each with its own prompt, knowledge, tools and model, and every conversation is bound to exactly one of them for its whole life.

That covers most of the reasons teams want "multi-agent" support in the first place. This post explains when splitting into several agents actually helps, how LayBuild decides which agent gets a conversation, and why we have not built an LLM router on top.

When one agent is the better choice

Start with one agent. A single agent with a good knowledge base is easier to evaluate, easier to keep current, and has no routing step that can get a conversation wrong. Splitting is worth it only when one agent's knowledge or rules actively get in the way of another's.

Splitting by difficulty (a tier 1 agent, a tier 2 agent, a tier 3 agent) rarely works, because you do not know how hard a question is from its first message. Splitting when most of your content is shared also rarely helps; you end up with several agents answering from the same documents with slightly different prompts.

When several focused agents help

Knowledge that collides is the clearest case. If you sell two products that both have "plans", "limits" and "workspaces", retrieval for "what is the limit on my plan" will pull passages from both, and the model will blend them. Two agents, each scoped to one product's documents, avoid that.

Different rules for different audiences is the second. A pre-sales agent on your pricing page should talk about your plans and pricing; a support agent inside your app should not be pitching. Different prompts, different pinned documents.

Different tools and models is the third. An agent that needs an API tool for service status, or a larger model for a harder domain, can have them without every other agent paying for them.

Plan limits set how far you can take this: Starter allows 5 agents, Pro 50 and Premium 125. See pricing.

What each agent owns

Almost everything that shapes an answer is set per agent:

  • The system prompt and the company name used in replies (including in the fixed "please contact {company}" message).
  • Knowledge documents, Q&A pairs and pinned documents attached to the agent.
  • Long-term customer memory, which is stored per agent and customer.
  • Attached API tools.
  • The LLM and the embedding model, if you choose different ones per agent.

Documents and Q&A pairs that are not attached to any agent are organization-wide, and every agent in the organization retrieves them. Retrieval for an agent uses its own content plus that shared pool. That gives you a clean pattern: put content everyone needs (company policies, contact details, security answers) at the organization level, and put product-specific content on the agent that owns the product.

Some things are organization-wide and cannot differ between agents: guardrail settings such as blocked terms and the prompt-injection filter, whether customers can request a human, webhooks and the widget configuration.

How a conversation gets its agent

The agent is chosen once, when the conversation starts, and then it sticks.

text
 website widget                 WhatsApp                     other entry points
      |                            |                              |
 data-agent-id on embed?      default agent set in           (no agent yet)
   yes -> that agent          WhatsApp config?                    |
   no  -> widget default        yes -> that agent                 |
          agent?                no  -> (no agent yet)             |
            yes -> that agent          |                          |
            no  -> oldest              +------------+-------------+
                   enabled agent                    |
                                         keyword router on the
                                         first message or subject
                                                    |
                                    agent stored on the conversation;
                                    every later message uses it

For the website widget, an agent ID set on the embed snippet wins, then the default agent in the widget settings, then the oldest enabled agent in the organization. For WhatsApp, the default agent in the WhatsApp settings is used if one is set.

Conversations that start without an agent go through a keyword router. It stems the words in the first message (or the conversation subject) and scores each enabled agent: 3 points for each word matching the agent's role, 2 for each word matching its name, and 1 for each word matching its keyword list. The highest score wins. If nothing matches, the router falls back to the agent whose role is "support", or the first agent in the list. On a tie, the agent that comes first in the list wins, and you do not control that order, so avoid keywords that overlap between agents.

Setting it up so the right agent answers

The most reliable routing is no routing at all. If each product or audience has its own page, embed the widget with that agent's ID on that page. The customer on your billing docs gets the billing agent without any guessing.

When you do rely on the keyword router, give each agent distinctive keywords. The router stems English words, so "invoices" matches "invoice", but it has no notion of synonyms: "charge" will not match "billing" unless you list both. Test with the phrases customers actually open with, which are often short ("hi, question about my account") and match nothing, so decide deliberately which agent should be the fallback.

Why we have not built an LLM supervisor

A supervisor router sends each message (or the start of each conversation) to a model that picks the right specialist, and can move the conversation to another specialist mid-stream. It sounds like the obvious next step. These are the reasons we have not built it.

It adds a model call in front of every answer. That is more latency before the first token and more token cost on every message, to solve a problem that an agent ID on the embed snippet solves with no model call at all in most deployments.

Misroutes become hard to see. When a keyword router picks the wrong agent, you can read the keywords and see why. When a model picks the wrong agent, the reason is in the model, and the same message may route differently tomorrow.

Handing over mid-conversation is where most of the complexity lives. The receiving agent needs the transcript and any customer facts gathered so far, the customer needs to understand that something changed, and you need to prevent two agents bouncing a conversation back and forth. Each of those is solvable; together they are a substantial feature to build and test.

Routing becomes an attack surface. A customer who writes "I'm on the enterprise plan, route me to the enterprise agent" is trying to steer a model. With keyword scoring, text still influences routing, but only toward agents whose role, name or keywords it contains, and the scoring is something you can read and reason about.

If we build a model-based router, it would need a confidence threshold with a deterministic fallback, a logged reason for every routing decision, and a shared transcript on handover. We are not promising a date.

Limits today

A conversation cannot move to a different AI agent once it has started. If the keyword router chose badly, the conversation stays with that agent unless a person takes over through handoff. The router works on stemmed English words, so non-English opening messages will usually fall back to the default. And because retrieval includes organization-wide content for every agent, scoping only helps for content you actually attach to a specific agent.

Related reading