Scaling AI-Native Analytics Patterns at Meta
Author: Benjamin Wan Rothschild
At Meta, we found that a small set of recurring patterns could answer most product analytics questions, yet teams repeatedly reimplemented core measurement primitives, such as metrics, retention calculations, experiment tables, growth accounting, and funnels. As product launches and measurement combinations multiplied, near-duplicate pipelines accumulated in the data warehouse, creating inconsistencies faster than teams could turn the data into actionable insights.
Our solution was to standardize popular measurement primitives as parameterized pipeline patterns and ensure every output ships with an agent-readable data model. This design had benefits beyond just standardizing metric calculations across the company. These parameterized patterns create a unified interface where humans and agents operate as peers. Agents can reliably author every pattern using skills and consume them via deterministic query-generation APIs, removing much of the non-determinism and hallucinations we observed with LLM-generated SQL. Now, agents can operate across the analytics stack with precision.
By treating agents as first-class producers and consumers of our data assets, we created a flywheel of increasingly powerful analytics capabilities, including automated dashboard creation, sophisticated analysis recipes, and accurate metric Q&A agents, described in more detail below.
Most analytics is a remix of a few patterns.
Most analytics is a remix of a few patterns: How active are our users? Are they coming back? Where do they drop off? What is driving topline movement? We found a power law in measurement: a small set of analytical patterns covers the vast majority of what product teams actually need.
We cataloged our most common measurement primitives into seven core patterns:
While your specific measurement catalog may vary, it will likely be equally concise. Standardized, predictable primitives foster trust and confidence by providing a stable interface that AI agents can use to produce and consume insights.
Standardization is powerful, but not universal. It pays off for recurring, high-trust measurements, but fails when teams need flexible, exploratory, or one-off analyses. Forcing early-stage exploration into rigid schemas can stifle discovery and innovation. Additionally, maintaining governed libraries and asset catalogs requires a continuous investment from a stable team. Organizations should balance when to enforce rigid primitives with when to allow unconstrained exploration. Standardizing a pattern helps only when widespread reuse offsets the maintenance cost.
What we built: Analytics Libraries
If a pattern is repeated often, define it once. That is the idea behind Analytics Libraries: reusable, parameterized, governed implementations of each canonical pattern. Instead of writing custom SQL for retention or funnels, you declare your requirements, such as your activity event, window size, and key dimensions, and the library generates the underlying SQL and pipelines. Because these declarations use structured input, an AI agent can easily generate them. Having the patterns in parameterized libraries means that essential logic, such as SQL strings and pipeline task types, cannot be hallucinated because it is generated deterministically, in our case, in a Python library used in the data pipeline.
Metric Materialization is a canonical example of this strategy. Historically, metrics were scattered across fragmented, plain SQL snippets with inconsistent calculations. Now, they live in governed artifacts that are produced using the same logic across the company.
Here is what that looks like in practice:
Since these specifications are declarative and strongly typed rather than free-form SQL, agents consistently and accurately author pipelines that match human accuracy, turning a vague request into a production-grade pipeline. The metric materialization library alone now supports over 3,250 production pipelines, with over 9,000 pipelines powered by the full catalog of Analytics Libraries.
Why standardizing the patterns pays off
Encoding a pattern once and reusing it empowers your team, making analytics faster, more accurate, and easier to manage. It pays off in the following ways:
- Correctness by default. The subtle, easy-to-get-wrong parts are solved and reviewed once, then inherited everywhere. Correctness stops being something that each analyst or agent has to relearn.
- Speed. Authoring a parameterized pipeline with an agent is now minutes of configuration.
- Discoverability and governance. Standardized outputs are registered and described in a database (more details on that below), so people and agents can find them, trust them, and stop rebuilding what already exists.
- Compounding reuse. Every new pipeline built on a shared, well-understood primitive makes it easy to roll out new features across all pipelines.
One hidden tax of analytics is duplicated work. Standardizing the patterns is how you stop paying it, and it is the precondition for handing any of this work to an agent for consumption. If you point an agent at a pile of bespoke, undocumented pipelines, it is more likely to drown in irrelevant context and land on the wrong calculation. If you point the agent at a clean catalog of governed output tables, each with a self-describing schema and a registered semantic model, it behaves like a domain expert.
An AI-native foundation
With a standardized foundation, agents can produce, consume, and analyze analytics questions with ease. We created skills for pipeline generation, deterministic SQL generation for querying data models, and analysis recipes for interpretation. None of this would be possible without the robust, standardized layer that Analytics Libraries support.
Get Analytics at Meta’s stories in your inbox
Join Medium for free to get updates from this writer.
End-to-end, the full workflow looks like this:
Produce Pipeline and Model: skills that let anyone build a pipeline.
The first layer is a set of plain-language skills that serve as entry points, turning a request into a production pipeline. Anyone can say “I want to measure retention for this sign-up event, split by country,” and the agent maps that request onto the right library to produce the pipeline. Before the agent starts, it also checks whether a similar measurement exists in the model database to decide whether to reuse it or start from scratch. The agent then fills in the parameters and generates the pipeline using the governed specification. This pipeline generation process leverages the automated code generation and validation loops developed for DEmate, ensuring generated code and configurations adhere to Meta’s data engineering standards before deployment.
In addition to the materialized table, each pipeline outputs a data model in YML format that encodes a strongly typed representation of dimensions, metrics, and data sources for query generation.
Query Model: a deterministic query generator the agent calls as a tool
The hardest problem in analytical AI is trust. A large language model will happily write SQL that looks right and returns a wrong number. For this part, we try to make the SQL generation as deterministic as possible. We built a deterministic query generator and exposed it as a command-line tool. We found that an agent learns much better to use a simple API to generate SQL than to generate SQL directly. The agent calls this CLI instead of writing SQL by hand. The model handles the fuzzy part, understanding the question and choosing the inputs, while the deterministic tool turns those inputs into correct SQL.
The deterministic query generator does two main things. Data source selection and query generation. At Meta, there are often multiple tables that can resolve to the same metric, for example, a cube table vs. a fact table. We encode logic to prioritize data sources based on table retention, partition row count, and the storage layer when determining the best source to query for a metric.
Here’s an example of a CLI request for a metric.
Analyze Model: analysis recipes for the questions after “what happened”
Analysis recipes encode the procedures a senior analyst would follow to investigate questions such as “what’s driving the retention drop?” or “why did this metric increase?” Recipes walk through procedures using the deterministic query generator, and the LLM will help analyze and summarize the results. We have found that analysis recipes are good at answering questions about metric movements, analyzing reasons for funnel drop-offs, and finding product-market fit for new products among user demographic dimensions. For us, recipes with encoded procedures have produced more reliable results than asking agents free-form questions.
Consume Model: dashboards that build themselves.
Finally, the dashboard. Because each library has a standard YAML output and a deterministic query generator, we can easily power consumption experiences, such as dashboards, and provide many dashboard templates for metric investigations, growth, retention, and funnel analytics.
What’s next?
We’re still early in building an AI-native analytics stack at Meta. Currently, we’re extending the libraries to support more patterns, auto-generate richer semantic models, and create more analysis recipes. The goal is easy to state but hard to achieve: anyone at Meta should be able to describe what they want to measure and receive a correct, governed answer, whether they ask a colleague or an agent.
For any analytics org, the lesson is the same: find your patterns, standardize them early, and document them well. The teams doing the unglamorous standardization work now are the ones whose agents will actually work later. You can’t automate a mess. A small set of well-defined patterns, encoded once, is a foundation you can build almost anything on, including the agents that are starting to do the work for us.
