Building multiple AI personas for one product catalog

When you look at real customer transcripts from any product-based business, one thing becomes immediately clear — customers speak completely different languages about the same products. A sysadmin asks "do you have E-2288G with 64GB ECC?" A startup founder asks "what do I need to run a Node.js app with 10K daily users?" A browser asks "show me your cheapest dedicated server."

These three people want the same category of product. They need completely different conversations to get there. Building one AI agent that serves all three without alienating any of them is one of the hardest design problems in conversational AI.

Why one prompt doesn't work

The natural starting point is a single system prompt that tries to be all things to all people. In our experience, this produces answers that are either too technical (confuses the casual buyers) or too simplified (annoys the experts). You end up optimizing for the average customer, which means you're optimal for nobody.

The sysadmin who asks about ECC RAM doesn't want a paragraph explaining what ECC stands for. The first-time founder who says "I need a website" doesn't want a table of CPU benchmarks. A single prompt can't hold both of those constraints without collapsing into a mediocre middle ground that frustrates everyone.

We've tried temperature tuning, few-shot examples, and instruction layering. All of them shift the tone in one direction at the expense of the other. The fundamental issue isn't the prompt — it's that a multi-audience problem is being treated as a single-audience problem.

The three persona archetypes

We've settled on three distinct generation personas that cover the spectrum of how people interact with product catalogs. Each has its own system prompt, formatting rules, and vocabulary constraints:

• Expert — Assumes technical knowledge. Uses spec shorthand. Responds with tables. Skips explanations of basic concepts. When an expert asks about a server, the response leads with CPU model, core count, and benchmark scores. Jargon is expected, not avoided. The tone is peer-to-peer.
• Goal-oriented — Translates use cases into specs. "10K daily users on Node.js" becomes "you need at least 4 cores and 8GB RAM, here are two plans that fit." Never dumps raw specs without context. Every technical detail is framed around what the customer is trying to accomplish.
• Explorer — Warm, comparative. "Here are three options from affordable to high-performance." Uses plain language, avoids jargon, leads with use-case fit rather than specs. Presents options as a guided tour, not a spec sheet.

The critical insight: all three personas pull from the exact same retrieval layer. The facts don't change. The catalog data is identical. Only the generation prompt changes — the voice, the structure, the level of assumed knowledge.

How we classify without asking

We don't ask the customer which persona they want. The first message reveals it. Classification looks at three signals: vocabulary density, question specificity, and technical term frequency.

• "E-2288G with 64GB ECC" — High technical term density, specific part numbers. Maps to Expert.
• "What do I need to run a Node.js app with 10K daily users?" — Use-case framing, moderate specificity, no raw spec references. Maps to Goal-oriented.
• "Show me your cheapest dedicated server" — Comparative language, low specificity, no technical terms. Maps to Explorer.

The classifier runs on the first substantive message in each session. It's a lightweight scoring function — no LLM call, no external API. Vocabulary gets matched against a curated term list built from product catalogs and industry glossaries. The whole classification takes single-digit milliseconds.

Boundary cases cluster at the line between Goal-oriented and Explorer — customers who frame a specific need in vague language. We've found that defaulting to Goal-oriented in ambiguous cases reads as helpful from either direction. It's easier to recover from slightly over-helpful than from slightly dismissive.

Same facts, different framing

Here's the same dedicated server presented through all three personas. The underlying catalog row and retrieval context are identical — only the generation layer differs.

-- Expert -----------------------------------------------
Intel Xeon E-2288G | 8C/16T | 3.7 GHz base / 5.0 boost
64 GB DDR4 ECC @ 2666 MHz
2x 1 TB NVMe (RAID-1 available)
1 Gbps unmetered | IPMI access included
Geekbench 6 single: ~1,820 | multi: ~9,400

-- Goal-oriented ----------------------------------------
For a Node.js app serving 10K daily users, you'd want
at least 4 cores and 8 GB RAM. This plan gives you 8
cores and 64 GB — plenty of headroom for traffic spikes
and background jobs. Storage is NVMe, so your database
reads will be fast. Two drives available for redundancy.

-- Explorer ---------------------------------------------
This is one of our mid-range dedicated servers — a good
fit if you want reliable performance without going all-in
on enterprise hardware. It handles websites, apps, and
databases comfortably. Includes fast SSD storage and a
high-speed connection. A step up from VPS, with full
control over the machine.

All three cite the same specs from the same catalog row — but the framing, ordering, and language are different. The factual layer (RAG retrieval) is identical. Only the generation prompt changes. This separation is what makes the system maintainable: updating a product spec in the catalog automatically updates all three persona outputs.

The eval challenge

Three personas means three times the eval surface. Each eval case gets tested against the persona it would naturally trigger. A product comparison query from an explorer-type message must produce explorer-tone output. The same query phrased with specific CPU references must produce expert-tone output.

Some edge cases — a customer who starts technical then switches to exploratory mid-conversation — require special handling. We've added persona-shift detection at the session level. If vocabulary density drops significantly between turns (perhaps a colleague takes over the phone), the persona can downshift from Expert to Goal-oriented. Upshifting is rarer but also supported.

The eval rubric for each persona is different. Expert responses are graded on spec completeness and conciseness. Goal-oriented responses are graded on use-case mapping accuracy. Explorer responses are graded on clarity and jargon avoidance. A single rubric across all three would mask persona-specific failures.

The persona layer is one of those systems where the architecture is simple but the calibration is everything. Getting the classifier thresholds right, writing three distinct system prompts that don't drift into each other, building eval cases that test tone as rigorously as they test facts — that's where the real work lives.

For a deep-dive on the waterfall architecture underneath all of this, see Inside InboxWa's automation engine. For more on how we test AI agents before launch, see our eval framework.