Meet D.A.V.E.: The Graph-Grounded, Context Aware AI Data Analyst

The bottleneck: why one simple question takes days

Every company's data lives in a mess of different places: a sales database here, a pile of Excel reports there, PDFs full of contracts, and years of email threads no one has time to re-read. Getting a straight answer usually means pinging a data analyst, waiting days, and hoping they interpreted the question the way you meant it.

The cost of that pattern is not abstract. Data professionals routinely spend around 80% of their time finding, cleaning and organising data, leaving only a fifth for the analysis anyone actually asked for — and nearly two-thirds depend on someone else to complete a step of the process. Across the wider workforce, McKinsey finds employees lose on the order of nine hours a week each searching for and gathering information. Put bluntly: the question is easy; reaching the answer is the expensive part.

D.A.V.E. is built to remove that wait. Connect your data sources once into a single Profile — one workspace that knows about everything you have given it access to — and from then on you simply ask questions in simple English. D.A.V.E. figures out where the answer lives and brings it back, usually in seconds.

What D.A.V.E. actually is

Under the hood, D.A.V.E. is a natural-language-to-SQL agent built on Agno — a Python multi-agent orchestration framework — running on Anthropic's Claude models via AWS Bedrock. Everything described below is real, working architecture, not a roadmap slide. The point of walking through it is that the interesting part of an AI data analyst is not the language model that writes the SQL; it is everything that makes the SQL correct, remembered, complete and safe.

That distinction matters because of a hard, well-documented truth about this category. On clean academic benchmarks, text-to-SQL looks close to solved — leading systems score around 90% on the classic Spider benchmark. But when researchers rebuilt the test around real enterprise conditions — large schemas with hundreds or thousands of columns, cryptic abbreviations and multi-step queries — accuracy fell off a cliff, to roughly 21% on Spider 2.0. The reason is almost always the same: the model cannot reliably work out which tables relate to which, and how to join them. D.A.V.E.'s architecture is a direct answer to that problem.

In one line: D.A.V.E. is an AI analyst built on a graph-grounded understanding of your data and a temporal memory of your business — it answers questions across your databases, spreadsheets and documents in the time it takes to ask, and gets faster the more you use it.

How D.A.V.E. works, step by step

Why the knowledge graph is the real breakthrough

This is the engineering choice that separates a demo from a dependable analyst. Instead of embedding your schema as flat text and retrieving tables by similarity, D.A.V.E. maintains a Neo4j graph of your tables and columns, with typed relationships — foreign keys and join paths — as explicit edges between them.

When a question needs data from more than one table, D.A.V.E. runs a graph traversal — a shortest-path query across JOINS_WITH edges — to find the correct join path. This is a GraphRAG pattern, where retrieval is grounded in an actual relationship graph rather than similarity search alone. It matters because column-name similarity can lie: a customer_id in two unrelated tables looks joinable to a similarity model and produces a plausible, wrong answer. A graph traversal only returns real, declared relationships, so the join logic is structurally correct, not guessed.

Framed against the text-to-SQL "performance cliff", this is precisely the gap D.A.V.E. is engineered to close. The enterprise queries that break similarity-based tools are the ones that require correct multi-table joins across large, messy schemas. Grounding retrieval in a relationship graph is how D.A.V.E. keeps join logic trustworthy where flat-text approaches fall apart.

A memory that knows when a fact was true

D.A.V.E. has two distinct memory layers, and the split is deliberate.

Session memory (PostgreSQL-backed) keeps a conversation coherent. Within a chat, D.A.V.E. retains recent turns plus a rolling, AI-generated summary of everything earlier, so a follow-up like "now just the West region" works without you restating context — and without replaying every past SQL result (some of them huge) on every call.

Long-term memory is where it gets genuinely interesting. It is built on Graphiti, a temporal knowledge graph that stores facts bi-temporally: every fact carries both a valid time (when it was true in the real world) and a transaction time (when D.A.V.E. learned it). When something changes, Graphiti does not overwrite the old fact — it invalidates and supersedes it, keeping the historical record intact.

Ordinary chatbots remember the conversation. D.A.V.E. remembers your business — and, crucially, when each fact was true — so history stays accurate even as the present changes.

One answer across databases, spreadsheets and documents

A Profile can span a live database, uploaded spreadsheets and email records — and D.A.V.E. runs a single federated query across all of them. Structured sources are joined together in memory at query time, regardless of which system they physically live in, so you are not manually exporting and reconciling data before you can ask a question.

Documents such as PDFs sit in a separate hybrid retrieval layer that fuses vector similarity with keyword search. D.A.V.E. calls both retrieval paths in the same turn and composes one coherent answer, so structured facts and document context show up together in the response — even though they are retrieved through two different mechanisms. In practice, that means a question can pull a figure from your database and the clause that explains it from a contract, in a single reply.

Faster and cheaper the more you use it

Two independent efficiency layers stack here, and both compound with adoption.

The semantic query cache embeds validated question-to-SQL pairs and stores them. A new question that is semantically close to one D.A.V.E. has already answered correctly is matched by vector similarity, letting it reuse a proven query pattern instead of generating one from scratch — cutting both latency and model cost as usage grows.

Prompt caching (via AWS Bedrock) caches D.A.V.E.'s system instructions at the model level, so the "who D.A.V.E. is and how it should behave" portion of every request is not re-processed — or re-billed at full price — on every single call. Only the parts of the prompt that genuinely change per question are.

Safe by construction, not by good behaviour

Rather than relying on the model to "behave", D.A.V.E. enforces safety where it counts — at the query-execution layer. Every generated SQL statement is parsed and validated before it runs:

• only read-only SELECT statements are permitted — no DROP, DELETE, UPDATE or DDL of any kind;
• queries are restricted to the exact tables in your Profile;
• result sets are automatically capped, so nothing runs away.

Conversational input also passes through a prompt-injection screening layer on the standard chat path. The design principle is simple and important: safety is a structural query-execution control, not a request to the model to be careful. That is what makes it defensible to point an autonomous analyst at real business data.

Why this matters for the business

The stack, for the curious

Where D.A.V.E. fits in DeepRoot

D.A.V.E. is the conversational analyst layer of Innoflexion's DeepRoot platform — the same platform that provides orchestration, connectors, an agentic workbench and a secure walled-garden environment for enterprise AI. That is why D.A.V.E. does not have to reinvent the foundation an enterprise agent needs: it inherits DeepRoot's governance, security and integration posture, and adds a plain-English interface on top. And because DeepRoot begins every engagement with a Data Readiness Index assessment, you know before you connect a source which of your data is genuinely ready to answer questions on — and which needs work first.

Glossary of key terms

AI data analyst

A system that answers plain-English business questions directly from a company's live data, without requiring SQL, table names or query syntax.

Natural-language-to-SQL (text-to-SQL)

The task of translating a plain-English question into a precise, executable SQL query against a real database.

Knowledge graph / GraphRAG

A graph of entities (here, tables and columns) and their typed relationships; GraphRAG grounds retrieval in that graph so join paths are real rather than guessed.

Bi-temporal memory

A store that records both when a fact was true (valid time) and when the system learned it (transaction time), so facts are superseded, never silently overwritten.

Federated query

A single query answered across multiple physical sources — databases, spreadsheets, email — joined together at query time regardless of where they live.

Hybrid retrieval

Document search that fuses vector similarity with keyword matching to retrieve the most relevant passages, used here for PDFs and other unstructured content.

Semantic query cache

A store of validated question-to-SQL pairs matched by meaning, so semantically similar new questions reuse a proven query instead of generating one afresh.

Profile

One workspace that connects all of the data sources D.A.V.E. has been given access to, so every question is answered across them together.

Frequently asked questions