AI Agents Can Query Your Data. That's Not the Hard Part.

By The Meet Patel · 2026-08-20 · updated 2026-08-20

Summary

Putting an LLM on top of a database answers questions someone already thought to ask. The harder problem is autonomous investigation: deciding what deserves attention before any query runs. That decision depends on relationships that span the CRM, payments, product analytics, ads and warehouse — relationships no single system records. The argument is that autonomous analytics needs a continuously maintained map of the business (entities, metrics, relationships, sources, definitions, history) sitting between the data and the agent, feeding a fast loop that filters signals and a slow loop that investigates them.

Originally published on the Dan blog.

We've gotten surprisingly good at putting LLMs on top of databases. Give an agent a schema, a SQL tool, and some business context, and it can answer a lot of analytical questions. This is already useful.

Anthropic recently shared how it built an internal analytics stack around Claude, reporting that roughly 95% of its business analytics queries are automated with ~95% aggregate accuracy. The interesting part isn't just the accuracy it is how much of the system is dedicated to context, verification, procedural knowledge, and keeping that context up to date. I think there's a harder problem hiding underneath:

What happens when the agent has to investigate something it wasn't explicitly asked about?

Consider:

Why did revenue drop last week?

The SQL isn't necessarily the hard part, it's figuring out where to look. Revenue might be down because:

The evidence for these hypotheses may live in five different systems.

An agent can be given access to all of them. But access isn't understanding.

The problem with the "agent + tools" architecture

A common pattern today is roughly:

User
  ↓
Agent
  ↓
Tools / MCP
  ├── CRM
  ├── Payments
  ├── Warehouse
  ├── Ads
  └── Product analytics

This works reasonably well when the user already knows what to ask. But the agent often has to rediscover the structure of the business at runtime.

The agent has the data. But it doesn't necessarily have the map.

Your data is not your business

Most companies don't have one database that represents the business. They have a collection of systems that each represent part of it.

              Business
                  │
     ┌────────────┼────────────┐
     │            │            │
    CRM       Payments      Product
     │            │            │
     └──────┐     │     ┌──────┘
            │     │     │
          Warehouse / Lake

Humans implicitly understand many of the relationships.

An analyst knows that:

Account → Customer → Subscription → Transaction

and:

Campaign → Lead → Opportunity → Customer

and:

Customer → Product usage → Support ticket → Churn risk

These relationships are often not represented anywhere in a form an agent can reliably use.

The agent has the data. It doesn't have the map.

That gap is annoying for user-initiated questions and blocking for a fully agentic analytical system.

Self-service analytics starts when a human decides something is worth asking. An autonomous system has to make that decision itself: what deserves investigation? You cannot answer that by querying one table. A revenue drop might matter because it correlates with a churn spike in the CRM, a payment failure trend in Stripe, or a campaign change in ads but only if the system already understands how those pieces connect.

Why autonomous analytics needs a maintained map

We have semantic layers that tell us:

What does revenue mean?

We have data catalogs that tell us:

Where does this table come from?

We have APIs and MCP servers that tell agents:

How do I access this system?

Those help once you know what to investigate. They do not tell you what is worth investigating, or which relationships to follow when a signal appears.

An always-on system needs something different: a maintained map of how the business fits together entities, metrics, relationships, and sources so the system can decide where to look before it starts an expensive investigation.

That map might look like:

Business Context
      │
      ├── Entities
      │     ├── Customer
      │     ├── Account
      │     ├── Product
      │     └── Transaction
      │
      ├── Metrics
      │     ├── Revenue
      │     ├── CAC
      │     └── Churn
      │
      ├── Relationships
      │     ├── Customer → Account
      │     ├── Account → Subscription
      │     └── Subscription → Transaction
      │
      └── Sources
            ├── CRM
            ├── Payments
            ├── Warehouse
            └── Product analytics

Call this a federation layer, a business graph, an ontology, or something else. The name is less important than the job it does.

Autonomous analytics needs a maintained map of the business because an agent has to decide what to investigate before it can investigate it and that decision depends on understanding relationships across the business.

In practice, we've been building toward this as a continuously maintained layer, not a static data catalog. As sources are connected, relationships are documented; as definitions change, the map is updated; and when a signal appears, the system uses those relationships to decide whether it matters, where to look first, and what hypotheses are worth testing.

The hard part of autonomous analytics is not the investigation. It is the decision about what deserves one and that decision depends on relationships across the business.

There's another problem with treating this as a one-time modeling exercise: The business changes.

Sources change. Teams reorganize. Metric definitions evolve. New products launch. The source of truth moves. A business map that was accurate six months ago can quietly become wrong. So the layer itself has to be maintained, refreshed, and validated as the underlying business changes. Otherwise, you end up with a system that is confidently reasoning from yesterday's understanding of the company.

This is where the two-loop architecture comes from

For a user-initiated query:

Why did revenue fall?

the human has already supplied the starting point.

For a proactive system, the first question is harder:

What should I investigate?

That question comes before SQL, before MCP tools, and before hypothesis testing. Answering it requires knowing how metrics and systems relate: which changes might explain each other, which sources to check first, and which signals are probably noise.

Now imagine monitoring 10,000 metrics. You can't run a deep agentic investigation on every change. The system needs to continuously separate meaningful signals from noise:

Only then should an expensive investigation begin. The architecture starts to look like two loops:

Fast loop
─────────
Monitor
Detect
Filter
Prioritize
      │
      ▼
Slow loop
─────────
Investigate
Cross-reference
Test hypotheses
Validate
Explain

The fast loop decides what is worth looking at. The slow loop decides why it happened.

The fast loop is where a proactive system succeeds or fails. Filtering seasonality, correlated alerts, and immaterial changes is not just a cost optimization it requires the same relationship knowledge the slow loop needs. If revenue drops but the system does not know that enterprise accounts in the CRM map to subscriptions in the payment system, it cannot judge whether the signal is isolated or part of a broader pattern worth investigating.

Without a maintained map, every signal forces the agent back into discovery mode:

Every signal
    ↓
Rediscover entities
    ↓
Rediscover relationships
    ↓
Guess what might matter
    ↓
Maybe investigate

With one, the fast loop can prioritize and the slow loop can investigate directly:

Maintained map of the business
            ↓
       Detect signal
            ↓
   Decide what deserves investigation
            ↓
      Investigate with hypotheses

This is where I think autonomous analytics is heading

I don't think the winning architecture is:

LLM + SQL

or even:

LLM + SQL + MCP

Those are useful primitives for answering questions someone already thought to ask.

It needs something else: a maintained map of the business that sits between the data and the agent not as another tool the agent discovers at runtime, but as the layer the system reasons from when it decides what deserves investigation and where to look first.

That map has to include entities, metrics, relationships, sources, definitions, and history. It also has to evolve as the business evolves. A map that was accurate six months ago can quietly become wrong and then the system starts prioritizing the wrong signals.

My bet is that better models will improve agentic analytics at the margins.

The bigger step change comes from giving these systems a maintained map of the business because something has to decide what to investigate before it can investigate, and that decision depends on understanding relationships across the business.

That's the part we're most interested in building.

Where Dan fits

Dan is your entry point to a specialist data team with shared business context. When you connect a source, Dan documents schemas and relationships, runs background monitoring workflows, and publishes evidence-backed investigations to an Activity Feed — so your team decides what deserves attention and investigates across sources without waiting for someone to ask the right question first.

If you're building or evaluating autonomous analytics systems, the question worth pressure-testing is simple: how does your system decide what to investigate and what does it know about your business when it makes that decision?

Sources

Written by Meet Patel — founder of Company 8, building Dan (usedan.com). Dubai, UAE.

Read on themeetpatel.com