Is your AI analyst actually a fetcher?

It’s Monday morning, and checkout conversion dropped 8% over the weekend.

Your exec team wants to know why, and they want it before the standup. So you turn to the “AI analyst” your analytics vendor sold you. It hands back the dashboards you already had, restates the drop you already saw, and helpfully suggests you “investigate further.”

It told you what happened. It couldn’t tell you why.

And so the work lands exactly where it always did: on a human, three days and six Slack threads later.

Every analytics platform ships “agentic AI” now. The word has become noisy enough that it’s stopped meaning much, so it’s worth being precise about what you’re actually buying.

Because when you put an AI agent to work on your data, there are only two kinds you can end up with, and the gap between them is enormous.

The fetcher: When AI only retrieves what already exists.

The first is a fetcher.

It retrieves things a human already built: a dashboard, a saved metric, a segment someone defined last quarter. Or it reads a summary a pipeline generated and hands it back to you in a nicer wrapper. This is genuinely useful. Plenty of enterprise teams want exactly this: curated metrics, governed definitions, one source of truth. We’re not knocking it.

But a fetcher is the fast-food model. The menu is fixed, everything on it was decided in advance, and the experience is fast and consistent as long as you want something that’s already on the board. Ask for anything that isn’t, and there’s no path to it. The kitchen was never set up to make it.

That ceiling is easy to miss, because a good fetcher is impressive right up until you hit it. It may proactively surface friction, summarize sessions, quantify issues, and recommend next steps. All valuable. All still bound by what someone anticipated and built for.

The moment you ask a question no one pre-built, it’s stuck.

And it tends to get stuck at the worst possible time.

The pre-built questions are the ones you already had answers to. The question that actually matters, the one from the exec on a Monday, the one behind a revenue miss or a broken release, is almost by definition the one nobody thought to build for.

When that question is urgent and the answer is “not on the menu,” the cost isn’t abstract. It’s a conversion window closing while you wait, a fix that ships days late, revenue you don’t recover, and one more cross-functional fire drill to work out by hand the very thing the AI was supposed to do for you.

The analyst: What real AI analysis should be able to do.

The second kind is an analyst.

You give the model room to do what it’s actually good at: reason about a problem, decide what it needs to know, and go get it using the tools at its disposal. It doesn’t depend on the metric already existing or the definition already being written. It understands the data well enough to build the query itself.

When you ask something new, it goes and figures it out.

That’s the private chef model. You can ask for a dish that’s not on any menu, and a chef who knows the ingredients builds it for you from scratch. The value isn’t a longer list of pre-set options. It’s that there’s no list at all, just someone who understands the raw materials well enough to make exactly what you asked for.

Take that Monday-morning question: why are mobile bookings down for loyalty members this week?

A fetcher checks whether “mobile bookings by loyalty tier” is a metric someone already built. If it isn’t, you’re done. It shows you total bookings and leaves the rest to you.

An analyst treats it as an investigation. It finds the relevant events and segments, builds a query for mobile loyalty members, compares this week against the baseline, and follows the signal. It narrows to the checkout step, then the device, then the release that shipped Thursday, then the specific point of friction, until it reaches an actual answer.

This is the standard we held Felix AI to.

Felix takes a question in plain language and builds the query against your data itself, down to the structured detail on individual events. The metric doesn’t have to exist yet. The definition doesn’t have to be written yet. Felix can search what’s there, reason about it, and construct the raw query on the spot.

Ask it something no analyst on your team has ever pulled before, and it does the analysis rather than telling you it isn’t on the menu.

Felix can work this way because of what sits underneath it. It reasons over Quantum Metric’s first-party experience data, meaning every session, event, and interaction captured directly, not sampled or reconstructed after the fact. The raw material for a brand-new question is already there. It has the context to understand what that data actually means for your business. And its reasoning is auditable: you can see the query it built and the path it took to an answer, instead of trusting a number that appears from nowhere.

How to tell whether your AI analyst can actually investigate.

Here’s the hard part of buying agentic analytics: everything demos well.

Everyone says “agentic,” everyone says “autonomous,” everyone shows an agent gracefully answering a question on stage. The substance underneath varies enormously, and the demo is almost always staged on the exact questions the product is good at.

So evaluate for the one thing that actually separates an analyst from a fetcher: can it investigate beyond what was anticipated?

A few concrete ways to test that:

1. Ask a question with no metric behind it. Not “summarize this session” or “flag this drop in conversion,” because those are table stakes now. Ask something specific that no one pre-built a report for, and watch whether the agent builds the analysis from the underlying data or quietly falls back to what was already defined.
2. Follow the “why.” A fetcher tells you what happened. An analyst pursues why it happened. Ask a follow-up that goes a level deeper than any dashboard, then another, and see how far it can actually go.
3. See if it can define a new metric on the fly. If every answer depends on a metric or segment someone built in advance, you have a very capable retrieval layer, not an analyst.
4. Ask it to show its work. Can it surface the query it ran and the reasoning it followed? If it can’t, you can’t verify the answer, and you can’t catch it when it’s wrong.

Run those tests and the category sorts itself out quickly. A product that can only handle the anticipated is a fetcher with good manners: useful, but not the thing you were promised.

The same test applies when agents connect through MCP.

In plain terms, MCP (the Model Context Protocol) is a standard that lets an AI agent plug into a product and use it directly. Think of it as the port your analytics exposes so an outside agent can work with your data.

That matters because more teams are beginning to connect their experience data to external agents, whether that is Felix, Claude, ChatGPT, or an internal AI workflow.

But MCP also creates a new version of the same old problem: is the agent being given the ability to investigate, or is it only being handed finished answers someone already created?

That is where the fetcher-versus-analyst standard becomes especially important.

The common shortcut is to wrap existing endpoints and pre-built reports as “MCP tools,” call it agent-ready, and let a customer’s ChatGPT or Claude pull your insights into their workflow.

That’s convenient, and it’s still fetching. If all you expose is your finished outputs, all you’ve done is put your menu inside someone else’s agent. The customer’s agent still can’t cook anything you didn’t already make.

We held Felix to the analyst standard here too. Through MCP, we don’t just pipe insights out. We give your agent, whether it’s Felix or one you bring, the same primitives Felix uses: the ability to understand the data model, discover what’s actually in it, reason, and build raw queries where the metric doesn’t exist yet.

In other words, the agent can create the analysis it needs, instead of waiting for someone to create the metric first.

The goal isn’t to make Quantum Metric callable. It’s to make your agent capable.

The part worth being honest about.

None of this matters if the answer is wrong.

“The agent can write raw queries” is a capability claim. “The agent writes the correct query against your real data model” is a much harder one, and it’s the whole ballgame. An analyst that confidently pulls the wrong number is worse than a fetcher that only returns vetted ones. It gives you the illusion of investigation without the trust to act on it..

That is why the deep work of understanding the data isn’t a footnote to the raw-query capability. It is the capability.

Giving Felix the primitives to genuinely understand your data — the events, the structure, the definitions — is what lets it write queries that are right, not just queries that run.

Correctness is the frontier here, for us and for everyone building in this space.

Anyone who tells you their agent freely writes raw analytics queries and won’t explain how those queries are grounded, validated, and inspected is selling you the easy half of the problem.

Ask the question no one prebuilt for.

Native agent, MCP, co-pilot, autopilot: the packaging is starting to look the same. The intelligence behind it is not.

The thing that actually separates one product from the next is whether the intelligence on the other end can reason like someone who knows the data, the business, and the question behind the question, or whether it can only serve what’s already on the menu.

That’s the bet we made with Felix.

If you’re evaluating agentic analytics right now, don’t grade the demo they’ve rehearsed. Bring the agent the question no one pre-built for, and see which of your options can actually cook.