Knowledge and conversation flows

An avatar is only as good as what it knows and how tightly its conversation is shaped. Two mechanisms cover that: a knowledge base for open questions, and flows for procedures that must go a specific way.

Knowledge base

Your documents — policies, FAQs, product data, service catalogues, site content — are indexed and searched at conversation time. The relevant passages go to the language model with the user's question, so the answer is grounded in your material rather than in whatever the model remembers about the world.

Practical guidance, learned the hard way:

• Curate, do not dump. A tight, current set beats a large stale one. Three contradictory versions of the same policy produce confidently wrong answers.
• Structure helps. Clear headings and short sections retrieve better than wall-of-text PDFs and scanned documents.
• Say what you do not answer. An explicit "we do not handle X, contact Y" is a better answer than a graceful evasion.
• Refresh on a schedule. Re-indexing is routine; agree a cadence during onboarding.

Answers cite what they came from, so a reviewer can trace a wrong answer back to the document that caused it.

Flows

Some conversations cannot be freeform. Verifying an identity, filing a request, booking a slot — these have required fields, an order, and rules. A flow defines that as explicit steps: what to ask, what counts as a valid answer, when to confirm, what to do when the user changes their mind halfway.

Inside a flow the avatar still sounds conversational — it will accept "the fourteenth of next month" for a date, cope with the user answering two questions at once, and re-ask when an answer is unusable — but it will not skip a required field or invent one.

Flows are authored with us today, not self-serve. In practice this is fine: they change infrequently, and a flow that touches identity or money deserves review before it ships.

Calling your systems

A flow step can call an external system — look up a booking, verify an identity, create a ticket, check a balance — and continue the conversation with the result. What we need from you:

• An HTTP endpoint, its authentication, and a test environment
• The request and response shape
• Timeout and failure behaviour — what the avatar should say when your system is slow or down. Do not skip this. Real systems fail, and a user standing at a kiosk deserves a clear sentence rather than an avatar frozen mid-flow

Calls run inside your network on on-prem and kiosk deployments; credentials never transit our infrastructure.

Language model choice

Any model reachable over an HTTP API: OpenAI, Anthropic, Google, Mistral, an open-weights model you self-host, or one of ours. It is a configuration change, not a re-architecture, so switching later is cheap.

The trade-off is straightforward. Hosted frontier models give the best quality and send your prompts to that provider. Self-hosted open-weights models keep everything on your hardware and cost latency and, usually, some answer quality. Regulated deployments usually run self-hosted; that choice is per deployment, and we will tell you honestly what it costs.

Guardrails

• Answers are grounded in retrieved content, which is the strongest defence against invention.
• Topic boundaries: define what is out of scope and what the avatar says instead.
• Escalation: hand off to a human, a phone number, or a form when the conversation is beyond the avatar's remit.
• Transcripts are reviewable, so drift is visible rather than theoretical.

Weekly transcript review during the first month is the single highest-value activity in a deployment. Real users ask things nobody internally thought to test.