AI capabilities / Chatbots
Chatbots that answer from what you actually publish
Support and lead qualification chatbots grounded in your own published content, running inside your federation rather than a rented vendor widget that says it cannot help.
What a federation chatbot does
A federation chatbot answers operational questions, qualifies leads, and routes real conversations to a person, citing the answer back to your own published content so the customer can trust it.
Most chatbot deployments are vendor widgets bolted onto a website, answering from a canned script and defaulting to "I am sorry, I cannot help with that." A chatbot running inside a federation is different. It reads from the same reasoning core and the same document store that answers every other query in your federation, so its answers stay consistent with what your organization actually publishes, whether that is hours and pricing, a service catalog, or a policy document.
The chatbot does four things well: it answers operational questions like hours, service areas, and published policy; it qualifies a lead by gathering name, contact, and basic intake; it routes an urgent message to a person immediately; and it captures a structured intake for staff to follow up. It does not give legal advice, medical advice, or quote pricing on custom work, because those boundaries are set in the system prompt at deploy, not discovered by trial and error in production.
The architecture, end to end
A chatbot is a retrieval augmented generation system running on the same substrate as the rest of the federation. An embedding model converts your published content into vectors held in your own vector store. When a visitor asks a question, the question is embedded and the closest matching chunks are retrieved, then passed to the reasoning core along with a system prompt that constrains the response. The reasoning core writes the answer with a citation back to the source.
The system prompt is where most of the engineering lives. It defines what the organization does, what topics the chatbot may discuss, what topics it must defer, and how citations are formatted. The prompt is tuned against real questions and edge cases before launch, and refined again from real conversations in the weeks after.
Further reading: Anthropic Claude documentation, OpenAI platform docs, pgvector, and the Lewis et al. retrieval augmented generation paper behind the pattern.
Stack
What the chatbot layer is built from
The federation's reasoning core
Claude, GPT class models, or open weight models like Llama and Mistral, already running inside the federation.
Vector layer
BGE or E5 embeddings, run locally so published content never leaves for an outside embedding API.
Storage
Self hosted pgvector or Qdrant, the same store the knowledge base capability reads from.
Hand coded UI
Streaming responses over SSE or WebSocket, no embedded third party widget on your site.
Where this fits
Industries that benefit most
Client portal question and answer
Client intake and IRS publication retrieval, answered from what the firm has actually published.
MedicalFront desk deflection
Hours, address, and accepted insurance answered without pulling staff off the phones.
InsurancePolicy explainer
Certificate requests, claim status, and policy language explained from the actual policy documents.
EcommerceOrder and returns deflection
Order status, shipping, and returns answered from your published policy, day or night.
FAQ
Chatbot questions
Will the chatbot make things up?
Properly architected retrieval does not invent answers. It cites the source chunk it drew from, and every deployment is tested for hallucination before launch, with the system prompt tuned to defer when the answer is not in the indexed content.
What if a customer asks something I do not want answered?
Topic boundaries are set in the system prompt at deploy. The chatbot defers and points to a person for anything outside those boundaries.
How does it handle personal information?
For workflows where medical, financial, or legal information is involved, the chatbot runs entirely inside your federation, so nothing sensitive is ever sent to an outside model API.
What about usage running away?
Session and daily limits are set per deployment, and anomalies trigger an alert. Because it runs inside your federation you can see and adjust those limits directly, not wait on a vendor support ticket.
Can I export the conversation log?
Yes. Conversations are logged with timestamps, and because the log lives in your own data store, export is not gated behind a vendor plan tier.
Begin
Should a chatbot be part of your federation?
The readiness assessment covers that question directly, along with everything else your federation would need to run.