Introducing Atlas: an agreement layer for enterprise AI

Today we launched Atlas.

An agreement layer is where an organization settles what a question means before anyone, including AI, answers it. Atlas is that layer. It produces a Definition of Record: a plain-English, versioned, attributed statement of what your organization has agreed a term means, published to your AI tools over the open Model Context Protocol.

The problem we keep seeing

Everything your organization knows falls into three buckets, and they are wildly different sizes.

• Written down and agreed. It lives in Notion, Confluence, or a catalog. It exists because someone did the work, and that work is always experienced as overhead. There is never much of it.
• Settled in a meeting, then gone. Somebody needed a definition to move a project forward. A few people talked. Everyone agreed it was good enough. Nobody wrote it down. The next project starts the same conversation over.
• Never written down, never even asked. Roughly 80% of it. The question surfaces at the exact moment somebody needs the answer.

Governance fails the way flossing fails. Everyone agrees it matters. Nobody does it on a schedule.

Every serious attempt to fix this has come from the technical side: add tooling, automate the problem away. Anthropic ran that experiment on itself and published the result. The same Claude answered 21% of its internal analytics questions correctly, and above 95% once the business context and data foundations around it were encoded and governed. The model was identical in both runs. Read their write-up.

The bottleneck was never the model. It was the context nobody had agreed on.

Why this got urgent

None of the above is new. What changed is that AI makes wrong answers cheap.

Ask how many active vendors we have. In the past, only the technical team could answer that, and they could not answer it alone. They would write some SQL, hit a judgment call, go talk to the business, arrive at a shared understanding, and come back with a number.

Today we cut those people out. A business user asks an agent directly. The agent finds a vendor dimension, sees a status flag, decides that must be what you meant, and returns a number with total confidence.

Maybe that is what you meant. Maybe you meant vendors with purchasing activity, in which case the answer is different and nobody will catch it.

What used to be a problem for a small technical subset is now a problem for everyone in the building.

Atlas holds the why. Which table, which metric, which query, that is all the how.

How Atlas works

Here is the same question with Atlas in front of it.

1. Ask. How many active vendors do we have? Atlas checks whether a Definition of Record exists. There is none.
2. Surface the ambiguity. Atlas comes back with what it does know. There is a vendor dimension with a status flag, and that is one reading. There is another reading based on purchasing activity, POs and invoices. Which one do you mean?
3. Narrow it. You pick the behavioral reading. Atlas asks the next question that changes the number: over what window? You choose the trailing year. Atlas returns 19 vendors, with the list.
4. Put it on the record. Atlas offers to make that a Definition of Record, confirms the specifics, drafts it, and routes it to procurement for approval. Once approved it is versioned, attributed, and readable by any MCP client.
5. Reuse it. Months later someone else asks the same question. Atlas does not ask anything. It answers, links the definition, and shows the logic it applied. If that person needs eighteen months instead of twelve, they are changing something rather than guessing from scratch.

Two things worth noticing.

Governance is a byproduct here, not a project. Nobody was handed a backlog of terms to define. The definition exists because somebody needed an answer, which is also why it stays current. The next person who needs it is the next person to review it.

That conversation can involve one person or several. In practice it is however many people hold the competing definitions, in one room, with AI helping them research and draft rather than ruling on their behalf.

Atlas also routes what it cannot resolve. If the vendor data does not exist yet, it does not invent an answer. It opens a task for data engineering to build it.

This is not only about analytics

Shared understanding is not a data problem that happens to involve people. It is a people problem that happens to surface in data.

What is our PTO policy is probably documented somewhere. Is it governed? Does anyone know it is still true? Same mechanism: the people who own the answer settle it, and anyone can then ask from Atlas, from Slack, or from a coding agent and get the governed version.

The same holds for questions nowhere near a warehouse. Planning a leadership offsite means agreeing who is involved and what the agenda is before anyone books anything. That is an agreement problem with a backlog of tasks.

Agreement comes before implementation

Semantic layers, context layers, data contracts, and catalogs are technical implementations of something. They are answers to a need the organization has.

Writing the YAML for a data contract is the easy part. Pouring the concrete is never what delays a building. Arguing about where the building goes is.

The hard part is upstream: what are we governing, how, what are the expected values, who decides. That takes months, and no tool addresses it.

So get agreement first. The technical work gets dramatically easier once the people involved actually share an understanding, instead of two teams passing a problem back and forth while each waits on the other.

That is the layer Atlas occupies. It is also why we think this is a category and not a feature. Every initiative in an organization, technical or not, starts with somebody agreeing on something.

Watch the conversation

I walked through all of this, including a full demo of the active vendor flow above. Watch the interview with Stéphane Heckel on the Data Sommelier show.

Working with design partners

Atlas is in design-partner stage. We are working with a small number of teams to get the flows and the AI's responses right, before we open it more widely. That feedback already shapes the product, down to cutting jargon that makes sense to a data engineer but not to the person asking the question.

If that sounds like your organization, book a demo. Bring a question two of your teams answer differently. We will show you where the disagreement is, and how Atlas turns it into a definition of record.

Related reading: why data platform implementations fail, what a data operating model is, and how to implement DataOps.

‍