The semantic layer is the foundation
AI adoption is limited by trust. A user who gets burned by a confidently wrong answer will double-check the next one, eventually routing consequential work around the system entirely. Once that happens, AI remains a tool at the edges rather than infrastructure at the center… useful, but never trusted with the workflows where its value compounds. Before a company can benefit from more capable agents, those agents need a reliable way to know what the company considers true.
A semantic layer tells an agent which tables are sources of truth and how they relate. That's the floor. It is necessary, and it isn't sufficient.
A semantic layer is not plumbing. It is the first act of governance for an AI-native company: the shared definitions of the business, the canonical metrics, the sources of truth, and the relationships an agent is allowed to rely on. Without it, an agent does not have a data problem. It has a language problem: several tables can each look plausible, and the model has no grounded way to know which one means "revenue," "active user," or "customer."
Getting that floor right changes the shape of everything above it. A semantic layer is not the product; it is the shared contract that lets a company safely add a system of specialized capabilities instead of one generic chatbot. Once an agent can ground itself in the right entities, metrics, and relationships, it can reliably run multi-step workflows, call focused tools, retain reviewed knowledge across runs, reuse validation and analysis code, and operate through durable services where work already happens.
Access isn't the hard part. Governing truth is.
The goal was straightforward: let anyone in the company ask a business question and get a reliable answer, without turning the data team into a permanent query queue. If the system could handle the mechanical work of finding the right data, applying the right definitions, and validating the result, the team could focus on improving the system itself.
The difficulty is that a model can write flawless SQL against a schema it fundamentally misunderstands. A column called revenue does not explain whether refunds or banned users are included. A table marked "canonical" does not reveal that it was quietly deprecated. And a plausible number does not tell the model that the correct answer requires three tables rather than one.
The problem was not access to data; it was governing what the company considered true.
We began solving that problem in late 2025 by building a system of record for data meaning and corrections. Instead of treating each mistake as an isolated failure, we capture what went wrong, how it was corrected, and why, so the next agent inherits the lesson. This makes Michele Catasta's point in Continual Learning for Agents concrete: in production, much of an agent's learning lives not in its weights, but in its knowledge and memory.
That distinction matters because most companies cannot start over. They inherit years of renamed events, shadow dashboards, partial migrations, contradictory definitions, and institutional knowledge trapped in people's heads. Traditional documentation struggles to keep up because it sits outside the work. Here, investigations and corrections continuously update the same reviewed corpus the system uses on its next run.
The industry is converging on this path
Everyone serious about this problem is converging on the same finding.
First, the shared conclusion: the durable value lies not merely in the model, but in the accumulated, validated knowledge layer around it. Second, Anthropic, OpenAI, and Meta each help establish that pattern. Third, our specific bet is narrower: treat operational truth as shared company infrastructure. That means a version-controlled, human-reviewed, model-independent corpus of definitions and corrections, validated before use and shared across every agent that touches data.
Anthropic's Building effective agents gave the field a practical vocabulary for agent architecture: tools, retrieval, memory, evaluation, and human checkpoints. We build on that work; our data agent is not a competing framework.
In January 2026, OpenAI described their own in-house data agent, and it is convergent with our approach. It addresses the same problem: thousands of near-duplicate tables plus silent join and filter traps. It also arrives at a similar answer: layered context that includes code-derived table meaning and human-curated annotations.
Meta's Analytics Agent points in the same direction. It combines continuously refreshed context from analysts' query histories with semantic models, reusable analytical recipes, custom validations, documentation, and memories. The architecture differs, but the signal is consistent.
We think that convergence is the story, not a claim of novelty. Our specific bet is auditability and governance: operational truth should be a version-controlled, human-reviewed, model-independent corpus, validated before use and shared across every agent that touches data.
The foundation unlocks a dependable truth layer
Semantics matter because they do not merely improve a single answer. The semantic layer makes the system legible; the operational-truth layer makes it dependable. Together, they let every agent start from the same reviewed understanding of the business. Every correction then improves every future workflow. That is what makes it possible to safely compound knowledge, tools, skills, workflows, and automation instead of compounding errors across them:
- Knowledge is the long-term record of corrections, business definitions, and playbooks that survives any individual conversation (e.g. what counts as a user or revenue).
- Tools expose deterministic code through reliable interfaces: validation, visualization, parsing, and integrations are reused instead of being rebuilt for every question.
- Skills package on-demand procedures and context: data-quality checks, metric definitions, and report-generation guidance load only when relevant.
- Workflows coordinate repeatable multi-step processes: investigate a metric move, analyze an experiment, validate evidence, and produce a report.
- Automation runs those workflows continuously where teams already work: telemetry records what happened, scheduled checks watch for problems, and auto-fix proposes repairs.
How the system produces a trustworthy answer
Trusted building blocks are only useful when they operate as one governed loop. Our data agent records corrections as durable knowledge, requires human review before they become canonical, validates evidence before making a claim, and distributes each approved correction to every agent. Together, these four mechanisms turn shared semantics into a trustworthy answer, and they make the next answer better.
1. The knowledge layer is a git repository. A correction isn't a saved memory; it's a reviewed pull request. The failing case, the fix, and the rationale are committed together; the result is diffable, revertible, and attributable months later. The corpus is the asset; the model underneath is swappable. The format is also part of the mechanism. A doc or a table-description field can hold the same facts, but an agent can only read them top to bottom. A repo lets an agent navigate operational truth the way it navigates a codebase (e.g. file trees, grep, diffs, blame, commit history…) with the standard tools it's already good at. Truth in a repo isn't just versioned; it's traversable.
2. Every correction is merged by a human. New truth enters the shared corpus through code review, not an auto-save prompt. It's slower on purpose: what becomes canonical is deliberate and inspectable, which is the property you want most when the numbers feed decisions.
3. Validation happens before the claim. The data agent checks whether a number can be trusted using row counts, metric definitions, and the failure modes that have burned us before; it returns the evidence with the answer. A correctness gate, not a safety filter.
4. One reviewed corpus, read by every agent. The correction from a finance investigation is inherited by the next question, the coding agent, the support agent, and anything else that touches data; the company converges on one number for one metric.
What happens when an organization can trust its data
Trust spreads fast. When answers can be relied on, people stop rationing their questions. Our in-house data agent went from launch to well over 1,000 warehouse-backed questions a week.
That growth didn't come from a mandate. It spread by word of mouth because the answers held up, and today every team at the company uses it. Questions that used to wait days for an analyst, or quietly go unasked, now get answered in minutes with the evidence attached. The whole organization got a capability that used to belong to a handful of people.
That adoption changes the team's role. The system now encodes the mechanical work: which table to use, what a metric means, how to validate it, and how last night's pipeline actually broke. That frees the team from being a query queue and human cache, so instead the team runs the system that answers questions correctly. A broken pipeline gets a triaged draft fix before anyone is awake; failures that could mask a real data problem are refused and routed to a human with the reasoning attached. Every correction makes every future answer, from every agent, a little more trustworthy. The leverage compounds instead of walking out the door.
The contrast is the classic failure mode: a data team's hardest-won knowledge lives in people's heads and Slack channels. Someone leaves; a definition rots; two dashboards disagree; trust erodes; and access contracts around the few people who still know how everything works.
A building block towards a self-driving company
A self-driving company runs on agents that act without a human re-checking every number. That only works if those agents share one governed understanding of what's true, which is why we think the operational-truth layer is infrastructure rather than tooling: it's the piece that lets everything built on top of it be trusted.
To be clear about what this is: not a new agent framework, since we build on what exists. Not "a semantic layer," which is the floor. And not a finished, autonomous system; we're not going to pretend it is. It's an early build with a flywheel that's turning: every investigation and every repair leaves it a little smarter than it found it, and every correction is one more reviewed line in the record of what's true.
The hard, unglamorous problem is keeping an agent honest about data that changes underneath it. That's the problem we're working on. If it's yours too, come build it with us.
Sources
- Michele Catasta, Continual Learning for Agents
- Amjad Masad, The Self-Driving Company
- Anthropic, Building effective agents
- OpenAI, Inside OpenAI's in-house data agent
- Meta, Inside Meta's Home Grown AI Analytics Agent
