# What Is Atlan? The Data Catalog as an AI Context Layer

> Atlan is a cloud data catalog and governance platform that gives teams and AI agents lineage, ownership and vetted context for the data they rely on.

Source: https://camnangai.com/en/engineering/what-is-atlan  
Published: 2026-09-04

**[Atlan](https://atlan.com)** is a data catalog and governance platform that helps organizations
  discover, document and manage the data assets scattered across warehouses, pipelines and BI tools.


It works as a unified control plane, stitching metadata from cloud data platforms like Snowflake and
Databricks together with operational systems like Salesforce into a single queryable graph.


  For AI systems, that catalog becomes a source of vetted context — the thing that decides whether
  an [AI agent](https://camnangai.com/en/knowledge/what-is-an-ai-agent) answers from data that is current and governed,
  or from some stale duplicate nobody remembered to delete.


![The enterprise data catalog becoming a vetted context layer for AI agents](https://camnangai.com/articles/atlan-la-gi/01-infographic-en.webp)

## What is Atlan?

Atlan started in 2020 as an internal project before it grew into a dedicated enterprise platform, and
in May 2024 the company raised a $105 million Series C led by GIC, Singapore's sovereign wealth fund,
and Meritech Capital, at a valuation above $750 million. The number that tells you more about the
product is not the round, though, but the architectural commitment underneath it: Atlan builds on
open formats such as Apache Iceberg, which lets it treat metadata as queryable infrastructure rather
than a proprietary store. That is its answer to vendor lock-in, and it is the one decision I would
want a vendor in this category to get right, because a catalog you cannot query with your own tools
is just another silo with better search.

![Atlan's layered architecture: the Metadata Lakehouse at the base, the Enterprise Data Graph in the middle and the trust layer on top](https://camnangai.com/articles/atlan-la-gi/02-en.webp)

The base layer is what Atlan calls a Metadata Lakehouse. Native connectors sync metadata in real time
from warehouses, transformation tools and CRMs, so the catalog reflects the estate as it actually is
rather than as someone documented it a year ago. Because that metadata lives in open table formats,
engineers can write SQL directly against governance metadata, build dashboards on lineage data, and
manage the metadata layer with the same rigor they apply to production systems.

Sitting on top is the Enterprise Data Graph, which pulls context from across the estate into a single
living representation. By mapping technical, social and operational metadata into one queryable
graph, Atlan gives you a view of how assets move, who uses them, and what business logic sits behind
them. Everything else in the product reads from that graph, which also means that when the graph is
wrong, every feature above it is confidently wrong with it.

## The problem a data catalog solves

Large organizations run on data chaos. Dozens of tools generate structured and unstructured data at
different levels, some of it landing in a warehouse and the rest sitting in silos nobody owns. At
that scale a company routinely holds hundreds of thousands of undocumented assets, which creates a
cold start problem the moment anyone tries to build on top of them, because nothing carries the
description, owner or definition a person or an agent would need to start from.

![Data chaos: many undocumented data assets while every AI tool assembles its own conflicting context](https://camnangai.com/articles/atlan-la-gi/03-en.webp)

Manual documentation fails here, and it fails for a structural reason rather than a lack of effort.
Traditional cataloging depends on data stewards typing descriptions by hand, and no team of humans
keeps pace with the rate at which modern pipelines generate new columns. This is the wall that stops
AI pilots from reaching production: the models are capable enough, but the data around them lacks the
business context, trust signals and security metadata that autonomous execution requires.

The problem compounds with agent sprawl. When every AI tool assembles its own private notion of what
the data means, definitions drift, and two agents answer the same question differently — which is a
worse failure than either of them being plainly wrong, because now somebody has to referee. Without a
shared [context layer](https://camnangai.com/en/engineering/what-is-the-context-layer), an agent works blind, reading raw
tables without the business rules hiding behind them.

## What Atlan actually does

Atlan runs a trust layer above the Metadata Lakehouse that handles access management, classification
and tagging. The platform stitches metadata from more than 80 connected systems, spanning cloud
warehouses, transformation tools like dbt, and BI environments. Where the older generation of
catalogs, Collibra and Alation among them, grew up around manual curation, Atlan automates metadata
capture largely through SQL parsing, which is the difference between a catalog somebody has to feed
and one that feeds itself.

The guiding philosophy is active metadata: context is delivered where you already work instead of
requiring a trip to yet another tool. The clearest example is the Atlan Chrome extension, which
surfaces metadata, lineage and governance policy directly inside the Snowflake and Tableau
interfaces, so nobody has to context-switch to find out whether a table can be trusted. That sounds
like a small feature, and in my experience it is the one that decides whether a catalog gets used at
all, because the tab nobody opens is the tab nobody reads.

To close the documentation gap, the platform uses AI agents that read query history, access patterns
and existing documentation to generate descriptions and map business terms. Atlan reports that during
a two-week program, 50 teams used these agents to create over one million asset descriptions, and
claims the system can cut the time practitioners spend finding and understanding data by as much as
95%. Both figures are the company's own. A million descriptions in two weeks also raises the question
of how many of them a human ever checked.

## Data lineage: where the data came from

Atlan reconstructs provenance at column-level granularity, not just table to table. That distinction
matters because a column-level view shows which fields flow where and what happens to them in
transit, which is what stops an agent joining on the wrong column and returning nulls. The platform
builds this from three feeds: a SQL parser that reverse-engineers transformation logic out of
millions of queries, native API crawling for tools where SQL parsing does not apply, and OpenLineage
events — the open standard's record of which job ran, which datasets it read, and which it wrote —
ingested from orchestrators like Airflow, Spark and dbt Cloud.

![Column-level data lineage reconstructed from SQL parsing, native BI APIs and OpenLineage events](https://camnangai.com/articles/atlan-la-gi/04-en.webp)

Column-level lineage is what makes reliability checkable. Tracing a metric back to its source
identifies exactly which transformations were applied and surfaces upstream failures — a schema
change, a failed quality check — that would otherwise silently corrupt an answer. Silently is the
word to sit with, because a broken pipeline announces itself while a quietly wrong number does not.
An agent can query the lineage graph to establish where a data point came from and whether it is
trustworthy before using it in a reasoning chain.

Lineage also reaches into the development lifecycle through impact analysis, which connects to GitHub
and GitLab pull requests so engineers see the blast radius of a schema change before merging it.
Atlan reports that supplying agents with this governed context improved text-to-SQL accuracy by 38%.
That benchmark is the company's own and has no independent corroboration, so I would read it as a
direction of travel rather than a figure to plan against.

## Governance: who is allowed to use which data

Governance context propagates along the lineage graph automatically. When a column is tagged as PII
(personally identifiable information) or carries a security label at the source, that classification
travels downstream to every dependent asset without anyone re-tagging it. This is what turns
governance from a human-readable compliance task into a machine-readable framework: the policy
travels with the data instead of trailing behind it in a spreadsheet.

![A PII tag propagating automatically from a source column down to every dependent downstream table](https://camnangai.com/articles/atlan-la-gi/05-en.webp)

Access control runs through a data marketplace that supports zero-touch provisioning, which in
practice means nobody sits in the middle granting access by hand. Policies attach directly to assets
and are enforced at query time, with tag-based masking and row-level security pushed down into
execution engines like Snowflake. Access decisions therefore happen where the query runs, rather than
in an approval queue behind somebody's inbox.


  The same restrictions apply to agents and to people, so an agent cannot read what the person
  operating it is not allowed to read.


That symmetry is the part worth internalizing, and it is also why governance and AI enablement are
not opposing goals here: the policy layer is what makes it safe to point an agent at production data
at all. Take that layer away and the only responsible answer to "can the agent read this?" is no.

## Atlan for AI agents: the MCP server

The Model Context Protocol server is the bridge between Atlan's context layer and AI execution
environments such as Claude or Cursor. An [MCP server](https://camnangai.com/en/engineering/understanding-mcp-servers)
lets an agent query the Enterprise Data Graph while it is reasoning, instead of guessing from a
prompt. In a single call an agent can retrieve a context chain for a column: provenance, quality
scores, governance policy and ownership.

![The MCP server returning a column's provenance, quality score, governance policy and owner in a single call](https://camnangai.com/articles/atlan-la-gi/06-en.webp)

That access changes which questions an agent can answer. Instead of only reading rows, it can ask
infrastructure questions — whether a table is currently failing a quality check, who owns a metric,
what a business term actually means in this organization. Making metadata directly consumable by
machines removes a whole class of manual verification steps, the ones a careful analyst runs
half-consciously before trusting a number.

The architectural shift underneath is that responsibility for knowing the data moves out of the
prompt and into the managed context layer. Hardcoded prompts break the moment the data below them
changes, while an agent reading from the context layer does not. Teams can also generate semantic
models and test suites in the Context Engineering Studio to validate agent behavior before it reaches
production, which is the step most teams skip and then wish they had not.

## From data catalog to context layer

The clearest way to state the shift is by audience: the old data catalog served humans reading
policy, while a context layer serves machines enforcing it. At Activate 2026 on 29 April 2026, Atlan
introduced the Context Lakehouse, an Iceberg-native architecture reachable through MCP, API or SQL,
which the company reports logged 8 billion reads within 90 days. The stated goal is to stop each AI
tool from rebuilding its own conflicting context.

![A comparison: the old data catalog serves humans reading policy while the context layer serves machines enforcing it](https://camnangai.com/articles/atlan-la-gi/07-en.webp)

Alongside it are Context Repos: version-controlled, portable bundles of business context that behave
like a GitHub repository, so teams build, validate and certify context before shipping it to
production. The intended effect is compounding context, because as agents interact with data,
decision traces and user feedback surface patterns that further enrich the graph. Whether the
compounding actually happens still depends on somebody reading that feedback, which is the quiet
dependency every metadata product has always had.

The architectural payoff is that business knowledge becomes portable. An organization can swap or
upgrade the underlying model without losing the institutional knowledge encoded in the context layer,
and that matters in a field where the model you standardize on today is unlikely to be the one you
run in two years.

## A managed cloud product, not self-hosted

Atlan is delivered as cloud-native SaaS, and there is no self-hosted edition, which rules it out for
some regulated buyers before the evaluation even starts. It addresses enterprise security
requirements through a Secure Agent architecture: the management plane runs in Atlan's cloud, but a
lightweight component runs inside the customer's own environment, such as a Kubernetes cluster, and
handles the connection to data sources. Metadata crawling and SQL parsing happen behind the
customer's firewall.

![The managed cloud model: raw data stays inside the customer's environment while only metadata reaches Atlan's cloud](https://camnangai.com/articles/atlan-la-gi/08-en.webp)

The practical consequence is that raw data never leaves the organization's perimeter — only the
metadata needed for the context layer is transmitted. That satisfies data residency requirements
without forcing a company to operate a complex platform itself. The trade-off is the usual one for
managed software: the vendor sets the update cadence and the maintenance windows, and you live with
both.

## Limits and what users actually report

Independent reviews on PeerSpot praise the lineage and automation while pointing at features that
need work. Users report that Playbooks, the workflow automation feature, is hard to configure for
tasks with complex logic and sometimes requires Atlan's own support team to get right, which is a
fair description of most workflow builders and not much comfort when you are the one filing the
ticket.

The feedback also names practical gaps: no scheduled email reports for managed assets, and duplicate
detection that needs work to avoid polluting the metadata graph. Several reviewers describe
governance customization as basic, with limited flexibility in access approval workflows, and some
find cross-team collaboration less intuitive than they expected. Taken together, that suggests the
social and orchestration side is still maturing relative to the technical integrations, which tracks,
because the connectors are the half a vendor can build without its customers.

On cost, Atlan prices as a platform rather than per asset, which contrasts with Microsoft Purview's
consumption model of roughly $0.50 per governed asset per day. For an estate of millions of tables
the platform model usually works out cheaper, and it avoids penalizing full coverage, which is the
last thing anyone should be charged extra for. It remains enterprise software, though, with no tier
aimed at a small team, and that is the most honest boundary on who this is for.

## When you actually need Atlan

Atlan fits organizations running a modern cloud stack around Snowflake, Databricks and dbt that have
started to feel metadata chaos as a real cost rather than an irritation. It becomes the necessary
piece once you intend to scale AI agents seriously, in an environment where a context error produces
an operational consequence rather than an amusing wrong answer. Deployment typically runs in months,
which the vendor comparisons frame as quick for this category, although I have not found independent
timings against the legacy governance suites, so I would treat that framing as an impression rather
than a measurement.

The inverse is worth saying plainly. If your estate is a few dozen tables and one person holds all of
it in their head, an enterprise data catalog is not the tool you need yet, and buying one early
mostly gives you a second thing to keep documented. The problem Atlan solves only appears at the
scale where nobody remembers what a column means.


  The standard a context layer aims at is simple to state and hard to reach: the same question gets
  the same answer in every tool.


When your infrastructure needs that, needs policy enforced automatically, and needs a way to
[evaluate the context](https://camnangai.com/en/engineering/what-is-context-evaluation) an agent is reading, that is when
a product like Atlan earns its place.

## References

- [What is a Data Catalog? Definition and 2026 Guide — Atlan](https://atlan.com/what-is-a-data-catalog/)
- [Data Lineage on the Context Layer — Atlan](https://atlan.com/data-lineage/)
- [Active Data Governance: Built on the Context Layer for AI — Atlan](https://atlan.com/active-data-governance/)
- [How Atlan MCP Server Builds Context For Your AI Tools — Atlan](https://atlan.com/know/what-is-atlan-mcp/)
- [Activate 2026: Context Just Went From Hype to Reality — Atlan](https://atlan.com/know/context-layer-stopped-being-theoretical-activate-2026/)
- [Atlan scores $105M to address enterprise 'data chaos' with a unified control plane — VentureBeat](https://venturebeat.com/data-infrastructure/atlan-scores-105m-to-address-enterprise-data-chaos-with-a-unified-control-plane)
- [Atlan: Pros and Cons 2026 — PeerSpot](https://www.peerspot.com/products/atlan-pros-and-cons)
- [Data Governance Tools Comparison: Collibra vs Alation vs Atlan vs Purview (2026) — Promethium](https://promethium.ai/guides/data-governance-tools-comparison-collibra-alation-atlan-purview/)
- [The Shape and Feel of the Post-AI Data Stack — Ian Macomber](https://www.iandmacomber.com/blog/post-ai-data-stack/)