Shared knowledge, separate behaviour
The things that should differ between bots are behavioural: tone, scope, permission, handover point. The things that should never differ are the facts. Splitting on that line avoids both failure modes.
Support Channels
Multiple AI bots
One assistant covering every product, segment and channel serves all of them slightly badly. Several bots, each tuned to what it is actually for, over a single shared knowledge foundation — so behaviour differs where it should and nobody ends up maintaining the same answer in four places.
- A bot per product line, segment or channel
- Behaviour tuned separately, knowledge shared
- No maintaining the same fact in four places
- Add a bot without rebuilding the foundation
One bot for everything is a compromise nobody chose
A company with several products, a partner channel and a range of customer sizes does not have one support conversation.
A single assistant has to average across all of it, and averaging produces something generic — the state in which everybody agrees the bot is fine and nobody relies on it. The obvious fix is worse: four bots means four knowledge bases, and a corrected fact that has to be updated in four places will be updated in two.
Separate where it matters, shared where it does not
The split is behaviour on one side and facts on the other.
- Step 1
One knowledge foundation
Every bot reasons over the same indexed manuals, resolved cases and knowledge articles, so a fact is maintained once.
- Step 2
Scoped to what each one covers
A bot is given the products and content that belong to it, so nobody is answered out of another line’s documentation.
- Step 3
Behaviour set per bot
Tone, what it asks first, how far it goes before handing over and what it may do are configured per bot.
- Step 4
Deployed where it belongs
Each bot goes to its own surface — a product portal, a partner site, a channel.
Why this beats both alternatives
It avoids the generic assistant and the four diverging knowledge bases at once.
Scope is a control, not just a quality setting
Giving a bot only the content that belongs to it is how a partner-facing assistant is prevented from reaching internal material, and it is normally the first question anyone asks.
Adding one is cheap
Because the foundation already exists, a bot for a new product or segment is a matter of scope and behaviour rather than a new project.
Why the usual approaches fall short
Either the behaviour is wrong everywhere, or the facts drift apart.
A single general assistant
Averages across every product, segment and channel and is mildly wrong for all of them.
Four separately built bots
The behaviour is right and the knowledge diverges immediately. A corrected fact becomes four edits.
One bot with a very large prompt
Tries to encode every audience’s rules in one place, and becomes unpredictable.
A bot per channel with no shared index
The web bot and the Slack bot answer the same question differently.
What things are called
Scope and behaviour are the two things being set per bot.
- Knowledge foundation
- The shared index of manuals, resolved cases and articles every bot reasons over.
- Scope
- The products and content a particular bot is allowed to answer from.
- Behaviour
- Tone, opening question, handover point and permitted actions — configured per bot.
- Surface
- Where a bot is deployed: a portal, a website, a partner site, or a messaging channel.
- AI Resolve
- The pluggable Gen AI component that can be dropped into any website or portal.
Frequently Asked Questions
Because one bot has to average across audiences that genuinely differ. The tone for a self-serve customer is wrong for an enterprise account, and one product line’s vocabulary is meaningless on another. Averaging produces something nobody finds useful.
Where this fits
Support Channels
Map your bots to your audiences
Tell us the product lines, segments and channels you support and we will show you where one bot would be a compromise, and where it is genuinely enough.
Talk to us