Don't train your AI Agents to repeat the past

Meta recently published a detailed account of how they built their internal Analytics Agent — an AI system that can autonomously run SQL, reason about results, and trace root causes across a data warehouse with 70,000+ users and millions of tables. It's a significant engineering achievement, and their candid writeup is worth reading.

But buried inside the architecture is a design assumption that we'd push back on for most organisations - particularly the SMEs and growth-stage companies we work with. Their core insight is simple: 88% of analyst queries rely solely on tables they've queried in the preceding 90 days. So the agent builds a personal "domain" for each user from their query history, learns which tables they use, and uses that bounded context to make the problem tractable.

It works. But it works by doing something subtle: it trains the system to optimise for what each analyst has done before.

"A constrained environment is where AI excels." That's true. But the wrong constraint teaches your agent to automate the past - not illuminate the future.

The local optima trap

In optimisation terms, a local optima is a solution that's better than all its immediate neighbours but worse than the globally best solution.  The global optima is clear if you step back far enough, however, it remains inaccessible if the steps you take are never large enough to break out of your current context.

This is precisely what happens when you build an AI agent's context from an individual's query history. The agent gets very good at helping an analyst do the things that analyst already does. It surfaces tables they've used, generates SQL in their style, and anticipates questions in their usual direction.

The problem is that data analysis is supposed to challenge existing assumptions - not codify them. When a sales analyst has always extracted revenue by region from a transaction log, an agent trained on their history will prioritise this pattern. It will be fast and accurate. But it will inherently fight against suggesting using a new revenue-by-region rollup table, looking at cohort retention, or cross-referencing product usage data with support ticket volume, because those connections weren't in the training signal.

The core tension:

Individual query history tells an agent what questions were asked. Semantic foundations tell it what questions could be asked and why some would matter more than others. These are fundamentally different kinds of analytical workflows.

What Meta got right and where the model breaks

To be fair, the Meta approach is appropriate for their context. They're not always generating net-new analytical hypotheses -  they're trying to give data scientists a capable assistant for their repetitive, domain-specific work. At Meta's scale, even automating the 88% of repetitive queries frees enormous capacity for higher-value exploration.

But for a 50-person retail company trying to understand whether their customer acquisition strategy is actually working, or a logistics firm wondering why their margin on certain routes keeps eroding, the problem is different. You don't have thousands of SQL-proficient staff generating a rich signal to learn from. You have five people.  They're doing their best, but don't know what they don't know.  Training an agent on that history doesn't give you a smart assistant. It gives you an automated version of your existing blind spots.

---

Build context, not habit

The alternative is starting from the context - the business language you and your team speak every day. Instead of building from individual query history, build from semantic foundations: the conceptual model of the business itself.

Semantic foundations answer different questions than query history does:

In practice, this means investing in the unglamorous work before you deploy your agent: defining what a "customer" means in your specific business context (not just as a row in a database), what the canonical metrics are and how they're calculated, what the key business processes are and how they flow through your data, and - critically - what questions the business should be asking but isn't yet.

---

Freedom within structure

There's a reason our logo is a grid of dots, not a blank canvas. The grid is the foundation - the reliable, well-modelled structure that makes signal possible. The accent dots are the areas of focus - the topics that matter for today's analysis. The implicit pattern between them is the insight.

You can't connect the dots unless you've built the grid first.

An AI analytics agent works the same way. The semantic layer is the grid: it defines the conceptual space, the valid entities, the canonical metrics, the business logic. Within that structure, an agent has enormous freedom to explore, combine, and surface connections because it's not constrained by what any individual has done before.

The goal shouldn't be to automate the analyst's existing workflow. It's to give every analyst access to the accumulated conceptual knowledge of the whole organisation and then break down the productivity barriers that stop us asking questions.

What this means in practice

For most organisations thinking about AI analytics agents in 2026, the bottleneck isn't a large language model. It's the semantic layer underneath. Before you wire up an agent to your data warehouse, we'd ask these questions:

Do you have defined metrics? Not just names, but definitions. What counts as a customer? What is "active"? When does a deal become revenue? If different people in your organisation would give different answers, your agent will too.

Do you have a shared conceptual model? The key entities, how they relate, which tables are authoritative for which facts. This is what makes the difference between an agent that finds the right table and one that confidently queries the wrong one.

Do you have governance around change? Semantics will need maintenance. When your business model shifts, the definitions need to follow.  When your upstream systems change, their data will too.  A data operating model can manage these changes and ensure your agents remain productive over time.

---

Meta's analytics agent is a serious piece of engineering built for a specific, large-scale context. The query-history approach makes sense when you have millions of tables, tens of thousands of analysts, and enough historical signal to learn from reliably.

But most organisations aren't Meta. They're trying to build analytical capability from a standing start and for them, the highest-leverage investment isn't the agent. It's the semantic foundation that lets the agent reason about the business, not just the database.

Build the grid. Define what the dots mean. Then let the agent find the connections you haven't thought to look for yet.

That's not automating the past. That's how you illuminate the future.