What is Conversational Analytics?

The conversational interface is the part that looks similar. Everything underneath is different. A generic chatbot pasted onto an enterprise warehouse fails in three structural ways — each predictable within the first week of use.

1. The numbers are wrong.Without a live warehouse connection and an anti-hallucination layer, the LLM produces numbers that look authoritative but aren’t reproducible. Once an executive cites a wrong number in a meeting, the entire program loses credibility.
2. The schema is invisible.Your warehouse has hundreds of tables, weird column names, denormalized joins, and business definitions that aren’t in the data itself. A generic LLM doesn’t know which join to use, which column means “active customer,” or that “revenue” is GAAP not gross.
3. There’s no governance.Row-level security inherited from the warehouse, audit trails, prompt-injection guards, AI observability per tenant — none of these exist in a chatbot architecture. For regulated industries this is disqualifying.

Purpose-built Conversational Analytics platforms make each of these impossible by design. The platform is a system, not a single LLM call.

A platform earns the “conversational analytics” label when it ships all five layers. Most chatbot-grade attempts ship the first three.

1. Natural-language understanding. Parsing user intent: what kind of question is this? A retrieval? An aggregation? A comparison? A what-if? An LLM (OpenAI, Anthropic, Google, Groq) is typically the engine here.
2. Schema awareness via a Semantic Knowledge Graph.The platform’s mental model of your warehouse: tables, columns, joins, foreign keys, business definitions, denormalizations, and the relationships between them. Without this, the LLM is guessing every time.
3. Natural-language to SQL (NL-to-SQL). Translating the parsed intent and the schema knowledge into a query that will execute correctly against your warehouse, with row-level security applied. We have a dedicated explainer for how NL-to-SQL works in practice.
4. Verification (anti-hallucination).Every numerical claim in the answer is verified against the source query result before it appears on screen. If the LLM’s narrative says “sales were $4.2M” but the query returned $3.8M, the verification layer blocks the answer or corrects it.
5. Governance. Row-level security, audit trail, AI observability tracking cost / latency / hallucinations / prompt-injection attempts per tenant. Encrypted credentials at rest, multi-cloud deployment, SOC-2-aligned operational controls. Without this layer, the platform is a science experiment, not an enterprise system.

Two architectural patterns dominate. The single-LLM approach asks the model to do everything: parse intent, generate SQL, execute, summarize, decide. This is what most early ChatGPT-on-data demos look like. It’s fragile because it stacks all the failure modes into one call.

The multi-agent approach decomposes the work into specialist agents, each with a narrow scope and verifiable outputs. Diwo Catalyst’s architecture is multi-agent by design:

• Diwo Supervisor Agent— orchestrates the conversation, routes sub-questions to specialists.
• SQL Generator Agent— writes schema-aware SQL and executes it.
• Anti-Hallucination Agent— verifies every numerical claim against the source query result.
• Document Retrieval Agent— surfaces relevant excerpts from PDFs, contracts, and policy documents.
• Visual Agent— selects appropriate chart types based on data shape.
• Recommendation Agent— produces ranked, dollar-quantified next-best-actions.
• Decision Observer Agent— logs decisions to the audit trail and tracks outcomes.
• Insight, Arithmetic, Help, Feedback agents — specialists for narrative writing, numerical reasoning, onboarding, and continuous learning.

Each agent is testable in isolation. Each has a verifiable output. The architecture means a single hallucination in the LLM doesn’t cascade into a wrong answer — the verification agents catch it before it reaches the user.

Conversational Analytics is an interface, not a destination. In the modern AI-decision stack, it sits at the top — the human-facing surface — and feeds into the layers below: a semantic data layer, a multi-agent orchestration layer, a Decision Intelligence engine, and outbound execution.

In Diwo’s architecture, Catalyst is the Conversational Analytics surface and Decide is the underlying DI engine. The two are integrated: every conversational answer can produce a decision-shaped output — recommended action, quantified impact, three AI-validated alternatives, and an outbound push into Salesforce, Slack, Microsoft Teams, Mailchimp, ERP, or ticketing — not just a chart.

This integration is the difference between conversational analytics that produces insights and conversational analytics that produces decisions. The interface is the same; the output shape is the discriminator.