Putting an LLM on a database creates a great demo but a poor product

The year of AI chatbots

2026 has been the year of the LLM wars, and it's unlikely to let up any time soon. It feels like almost every week a new “frontier” model is being released. With AI hitting the mainstream at fever pitch, it's no surprise that many technology companies are shifting to label themselves “AI-first” or “AI-native.”

One of the most common approaches we are seeing is slapping an AI chatbot directly onto a database full of company information.

This results in an improved search function that can turn questions into SQL, allowing non-technical users to query a database, and it makes for an excellent demo.

But once people begin relying on it to make decisions, the cracks appear quickly. Data itself is not intelligence. AI chat can surface data, but it cannot recommend responsible actions without making up context to fill in the blanks.

The LLM may select a plausible but inappropriate metric. If you repeat questions on the same topic, it surfaces different results. Or worse, it confidently explains patterns that have nothing to do with your product at all.

Chat solved the wrong hard problem

Let's dig into this a little deeper. AI chat made data easier to access, but it didn't turn it into intelligence.

It pushed the ball forward on how we let non-technical users query a database, but it didn't solve the harder problems. For example:

• Does the user know what to ask?
• Does the system understand what their words mean in the context of the data?
• Are the available metrics appropriate for the question?
• Does the AI know the exceptions?
• Can it distinguish “zero occurred” from “not supported”?
• Can it explain why the result matters?
• Can it recommend a responsible next step?

In the case of analytics, a user who does not understand retention analysis will not suddenly know which cohort, time window, eligibility rules, or confounding variables matter simply because the input box accepts English and can load numbers onto a graph.

The product appears intelligent when the answer is obvious, and it becomes unreliable precisely when the question is valuable.

The missing link

In one simple word, we can summarize the missing link between data and intelligence: context.

Context is the background, setting, or surrounding circumstances that help you fully understand an event, statement, or idea.

It's the information around the data that gives it meaning in the here and now. Data alone does not contain its own meaning.

For example, the database might say, “40% completion rate for step three.” We may interpret this in a few different ways:

• The step is confusing.
• It only applies to enterprise customers.
• Returning users have already completed it.
• A recent product version removed the requirement.

The true context may be that step three is, in fact, optional. That may be obvious to you if you designed the application and database. However, others using the AI chatbot on top of the database won't have the same context and may misinterpret the results.

One supporting layer: verified facts

Behind the scenes, Gamers Lab uses many different supporting layers, but one that shouldn't be overlooked is our verified fact system. These are small, verified chunks of information structured in a formal way.

At its simplest, a fact contains three parts: Subject → Predicate → Value.

• Mission 3 → is optional → true
• Game → supports mode → online co-op
• Game → maximum supported players → 4

Facts can contain further supporting information to define the context of the fact itself:

Subject

The thing we are describing

Predicate

The specific statement we can make about it

Value

The answer

Scope

Where or when the answer applies

Authority

Who confirmed it

Evidence

What supported the confirmation

A simple fact

{
  "subject": {
    "type": "game",
    "id": "mullet-cop"
  },
  "predicate": "game.core_gameplay_unit",
  "value": {
    "type": "entity",
    "key": "run",
    "label": "Run"
  },
  "authority": {
    "status": "confirmed",
    "source": "developer"
  }
}

This tells us that, for the game Mullet Cop, the primary unit of play is a “run,” and that this has been confirmed by the developers themselves.

A more narrowly scoped fact

Sometimes facts need to be scoped more narrowly.

{
  "subject": {
    "type": "game",
    "id": "maelstrom"
  },
  "predicate": "game.supports_mode",
  "value": {
    "type": "entity",
    "key": "online_coop",
    "label": "Online co-op"
  },
  "scope": {
    "platform": "pc"
  },
  "authority": {
    "status": "confirmed",
    "source": "developer"
  }
}

In this case, we can see that the game Maelstrom supports online co-op, but this has only been confirmed for the PC platform. It's important to note that this does not mean other platforms are unsupported. It simply means we do not yet know.

A proposed fact

The fact system can also pull information from other sources using AI, but proposals are not considered facts until approved by a human moderator.

{
  "predicate": "game.maximum_supported_players",
  "proposed_value": 4,
  "source": {
    "type": "design_document",
    "reference": "multiplayer-design-v2"
  },
  "proposal_status": "awaiting_review"
}

They should follow a few rules:

• Small enough to verify quickly
• Confirmed by a human
• Do not contain metrics, such as “72% of players used weapon A”
• Do not contain hypotheses, such as “Level 4 may be causing churn”
• Do not contain raw telemetry, such as “run started”
• Do not contain operational state, such as “the API key is connected”

This structure is more deliberate than dropping documents into a prompt, but much smaller than constructing a complete digital model of every game. That balance became one of the most important design decisions we made for Gamers Lab.

Why the obvious alternatives fall short

RAG is the most likely tool that developers looking to enrich telemetry would reach for. However, it falls short in a few areas. Specifically, the information may be outdated, contradictory, or aspirational rather than actually implemented.

Its structure doesn't naturally lend itself to a hierarchy of values that can be quickly surfaced to the end user, updated, and managed in bite-sized chunks. Similarly, it doesn't lend itself to strong governance of the provenance of each fact independently.

Knowledge graphs are also a popular tool in the AI information ecosystem. They help solve a real problem involving complex traversals of large ontologies. Some combination of a knowledge graph and a fact system may be the best solution for certain applications.

For Gamers Lab, we needed something narrower. We didn't require as many relationships, and we needed to support thousands of facts per game rather than millions.

Gamers Lab's fact system is built around PostgreSQL. It already provides excellent performance using battle-tested technology natively within our stack, without the need to introduce a new one. Knowledge graph or RAG systems typically require introducing new systems, complicating the stack, or even running a side stack specifically for data retrieval.

From chatbot to intelligence product

A database chatbot waits for a question, while a real intelligence product can help determine what is worth investigating.

An intelligence product should get better as it accumulates a verified understanding of the customer's product and terminology. A fact system is one piece of this puzzle, without overcomplicating the systems behind it.

Gamers Lab uses two approaches to gather and confirm facts.

1. Progressive disclosure

Progressive disclosure is a design pattern that shows or asks for only the essential information as it is needed, rather than overloading the user with too much at once.

When a user first creates a new game on Gamers Lab, we ask them for the basic facts about their game. As they enable more features on the platform, we ask them more fact questions. Ideally, they never face more than three minutes' worth of questions at a time, so we don't deter them from entering the information.

2. A loop to confirm information

This information is inferred from other places, such as the current chat, AI-scraped information like the game's Steam page, or the game telemetry itself. A basic loop looks like this:

1. 01Gamers Lab interprets telemetry more accurately
2. 02Features discover useful missing context
3. 03Gamers Lab asks focused follow-up questions
4. 04Reports and recommendations improve
5. 05Product understanding compounds

This creates a self-compounding loop of facts over time.

What's in the future?

LLMs will improve. Natural-language-to-SQL will become common. Adding a chatbot to a database will become easier and cheaper.

This means that chat interfaces, and even the interpretation layers, will change over time. However, the facts of each game, or product, will remain relatively stable and should find a way to compound in value over time.

At Gamers Lab, our Fact Authority system began with a game-specific problem: telemetry could tell us exactly what players did while still failing to tell us what their behaviour meant. But the underlying problem is much broader.

Every database records a simplified shadow of a product, business, or customer. AI can search that shadow. It cannot automatically reconstruct the reality behind it. It needed something more.

The chat box is not the product. The product is the understanding that makes the conversation worth having.