Answers your team will stand behind.

No. Atlas is the layer where your organization agrees on what a number means and records who signed off. Your BI tools keep rendering dashboards, now from those same definitions: one definition, every chart. Atlas draws a chart inside a room when that is the quickest way to see an answer, and drawing it is part of answering the question. Nobody has to move a dashboard.

No. If you already have one, keep it. A semantic layer is the calculator: it computes a metric the same way for every tool that queries it. What it never held is the agreement behind that metric, meaning who settled it, why, and what happens when someone disputes it. That is the layer Atlas adds. If you don't have a semantic layer, nothing here waits on one. The slow part of building one was always getting people to agree what a metric means, and that agreement is what Atlas produces. When you want the semantic layer, any MCP client can read those settled definitions and generate it.

Atlas has one, and you don't need another. Those other tools assume the agreement already exists and set out to serve it, and reaching the agreement is the hardest part. In Atlas a definition gets proposed in the room where the question was settled, signed off by the group that owns it, and every version records who agreed. Where you do run a catalog or a context layer, Atlas feeds it over MCP.

Those are places to put a definition. What none of them records is how it was reached: who settled it, what was ruled out, and whether anyone outside the author ever agreed. Piping that definition to an agent does not make it current. Nobody is on the hook when it quietly stops being true. Atlas keeps the conversation, the sign-off and every version, then serves them back to your catalog and your AI tools over MCP, so it feeds what you already run instead of adding another place to look.

That is a reasonable first move and it will help. What it does not do is keep the definition alive. You would be maintaining the rules yourself, the documents drift without anyone noticing, and the model still picks between three versions of the same policy on every query with no way to tell you it did. Atlas settles the ambiguity once, records who agreed, and versions it from then on. That comparison is worth running on your own questions, and it is one we will help you measure.

It says so. When two readings both fit a question, Atlas states the judgment calls and asks the owner instead of picking one quietly. A trustworthy "not sure yet" beats a confident wrong number.

Most organizations haven't, and Atlas doesn't ask you to fix that first. Every definition already has an owner in practice: whoever had to make the call so the work could continue. Atlas records who that was as the definition is reached, so ownership is captured from the decision rather than assigned in advance. If you formalize it later, the record is already there to formalize from.

You do. Every agreed definition is plain English, versioned and attributed, and stored in your knowledge base, which exports whole to open formats. If you leave, it leaves with you.

Agents read it. They do not write to it. Reads are scoped by role and reach, read-only and entitlement checked, and when an agent needs to materialize something to check its own work it does that in an isolated scratch schema, never in your production tables. Anything that reaches production goes through review by the people who own it.

Yes. Atlas deploys into your own AWS or Azure account, with storage in your own Postgres and object store, so regulated data never leaves your network. Bring your own model too: Claude or OpenAI. There is a multi-tenant SaaS for teams without that constraint. Both run the same product.

Through your stack's own interfaces. Warehouses, git, docs, files and orchestrators feed the knowledge base. Any MCP client reads the agreed definitions back out, including Claude, ChatGPT, Gemini and your BI tools.

The first room can reach its first agreed definition on day one, and a guided workflow builds your knowledge base step by step from what you already have: docs, warehouse schemas, dbt models, existing metric definitions. Value compounds from there: each agreed definition makes the next question cheaper to answer.