Writer Knowledge Graph vs Enterprise Context Layer

---

Writer’s Knowledge Graph answers one question well: what do our documents say? A governed enterprise context layer answers a different one: what does the business mean, and which definition wins when two agents disagree? Atlan is the Context Layer for AI, and it sits next to Writer rather than inside it, serving the same approved definitions to WRITER Agent, a warehouse-native analyst, and a custom-built agent through one interface.

---

What is Writer’s Knowledge Graph, and what does it ground?

Writer’s developer documentation describes Knowledge Graph as a retrieval-augmented generation system that uses graph-based relationships, a network of connected entities and ideas that avoids relying on keyword matching or vector similarity alone. In the API, a Knowledge Graph is a collection of files used to answer questions. It can be org-wide or deployed to specific teams. For the mechanics of graph retrieval, see GraphRAG and knowledge graphs for AI agents.

Data sources that go into the graph

• File uploads: PDF, TXT, Word, PowerPoint, CSV, Excel, EML, HTML, and SRT files, per the concepts page.
• Data connectors: Confluence, Notion, Google Drive, and SharePoint.
• Website content: specific URLs or entire domains, with page inclusion and exclusion rules and automatic content updates.

How the graph processes and serves that content

Writer describes a five-stage pipeline:

1. Content ingestion: files, connected sources, and URLs come in.
2. Graph construction: the system identifies entities, concepts, and relationships.
3. Indexing: it builds a searchable graph structure.
4. Query processing: a question triggers a traversal of the graph.
5. Response generation: retrieved content is combined with the model’s output.

Agents reach the graph in two documented ways. The question endpoint takes one or more graph IDs and returns an answer with source citations. The chat completion tool adds a graph object to the tools array so the model decides when to query it. That tool is documented for Palmyra X4 and later models, and the same page lists X4 and X5 for deprecation on December 14, 2026. Writer’s model guide names optimized Knowledge Graph integration as a reason to choose Palmyra models. For the platform around the graph, see the guide to what Writer AI is.

The documentation frames the graph as retrieval over content. In the pages we reviewed, the operations are adding and removing files, connecting sources, and tuning query parameters. Metric definitions, column-level lineage, and a review workflow for definition changes do not appear. That is where a context layer picks up.

---

Where does in-platform grounding stop?

Platforms build retrieval for their own agents because tight coupling pays off: setup is fast and retrieval is tuned to the platform’s models. The limits show up when a second platform arrives. Ask these questions of any in-platform graph.

Question to ask	Why it matters
Who owns and approves a change to a definition?	Replacing a file updates content. A metric definition needs an owner, a review step, and a record of approval
Do other platforms read the same definition?	Context stored in one platform does not keep a second platform’s agents aligned
Can an agent see the SQL and pipelines behind a number?	Document retrieval knows what a file says. Lineage shows where a number came from
Do policy rules travel with the context?	Writer applies team scoping and guardrails on its own surfaces. Every other platform needs its own copy of those rules
What flags a definition when an upstream table changes?	A shared layer can tie definitions to lineage so a schema change surfaces the definitions it touches

What changes when three agent platforms replace one?

Picture marketing and sales running content agents on Writer, finance asking questions through Snowflake Cortex Analyst, and support running a custom agent built on LangGraph. Writer can already reach some of those systems. The Snowflake connector connects WRITER Agent to a Snowflake MCP server you create and configure with OAuth, and its documented setup exposes Cortex Analyst against a semantic view. The Salesforce connector lets agents run reports and SOQL searches. Access is solved, but agreement is a separate problem. In this example, “churned account” could be a non-renewal at term end in the Snowflake semantic view, a closed-lost renewal opportunity in a Salesforce report, and no login for 60 days in the support agent’s prompt. WRITER Agent sees two of those answers with no rule for which one is authoritative.

Writer’s connector documentation adds a second constraint: MCP connectors are available for WRITER Agent, and they do not currently support Agent Builder, no-code agents, or API integrations.

The cost compounds:

1. Definitions diverge. Finance updates the churn logic in the semantic view while the Salesforce report and the support prompt keep the old rule.
2. Policy rules multiply. Access and approval rules get rebuilt on each platform.
3. Audit fragments. Reconstructing what an agent knew on a given date means checking three platforms.

Connectors solve access. A shared context layer settles which definition every agent should use. The split is explained in context management for multi-agent systems.

---

What is an enterprise context layer, and why does it sit above the knowledge graph?

An enterprise context layer is the shared tier between an organization’s systems and every AI agent that acts on them. It holds what the business means by its terms, where each number comes from, and which rules apply, then serves that context to any agent through open interfaces. A knowledge graph is one structure inside that tier, as the page on context layer vs knowledge graph explains.

What it holds

• Business definitions and metrics: what counts as an “on-time shipment”, scoped per domain.
• Lineage: which tables, pipelines, and dashboards produce a given number.
• Policy context: classifications, approval rules, and access requirements attached to each asset.
• Quality signals and traces: whether a source is trustworthy right now, and what agents answered and humans corrected.

A context layer sits outside any single platform so that Writer, a warehouse-native analyst agent, and a custom support agent all read one approved definition. That is the argument in single-stack lock-in vs a neutral context layer and in the comparison of a full-stack AI platform with a best-of-breed context layer.

Writer Knowledge Graph vs enterprise context layer at a glance

Dimension	Writer’s Knowledge Graph	Governed enterprise context layer
Scope	Agents built on Writer, with graphs scoped org-wide or to specific teams	Every agent and AI tool in the enterprise, across vendors
Source of context	Uploaded files, Confluence, Notion, Google Drive, SharePoint, and website URLs	Systems of record, warehouses, BI tools, and knowledge tools, plus runtime signals such as query history
Who authors it	People upload files and connect sources, and Writer constructs the graph	Context Agents draft definitions from existing signals, and people review them
Versioning and rollback	Files can be added or removed. The Knowledge Graph pages reviewed describe no definition versioning or rollback	Context repositories carry version history, staged rollouts, and rollbacks
Model coupling	Graph chat tool documented for Palmyra X4 and later	Model-agnostic, so any model or framework reads the same context
Delivery	Question endpoint, chat completion tool, and Writer’s agents	MCP, A2A, SQL, REST, and graph APIs
Portability	Source files can be downloaded. Export of the constructed graph is not described in the pages reviewed	Open storage formats keep context queryable outside the vendor
Policy rules	Team scoping, tool-level permissions on connectors, and guardrails on agent inputs and outputs	Policy context attached to each asset and returned with it
Change handling	Guidance to update content regularly, plus automatic updates for web content	Lineage shows upstream and downstream dependencies, and traces show drift

---

How does Atlan approach context for agent platforms?

Context works as shared infrastructure that every agent platform consumes, Writer included. Each capability below maps to a gap in the table above.

Connectors and the Enterprise Data Graph

Atlan’s connector reference lists 110 connectors. They pull metadata from warehouses, BI tools, and other systems into the Enterprise Data Graph, so context starts from the systems where definitions already live.

Data lineage

Lineage tells an agent whether a number is trustworthy and what breaks if a definition changes. Atlan’s lineage documentation describes column-level lineage derived from SQL query history and SQL parsing for warehouses such as Snowflake and BigQuery, plus lineage from BI tools such as Power BI and Tableau.

Context Agents

Context Agents are nine specialists: Scout, Scribe, Lexis, Doc, Nexus, Sage, Atlas, Vera, and Orion. They write table and column descriptions, build glossary terms, link columns to business terms, resolve conflicting metric definitions, tag domains, and score quality. High-confidence outputs apply automatically, and lower-confidence outputs route to people. The Context Agents Studio documentation covers setup.

Context Engineering Studio

Context Engineering Studio is where teams build context repositories, test them with simulations, and deploy them. A repository references governed Atlan assets instead of copying them. Atlan’s product page describes a Bootstrap, Simulate, Deploy, Observe loop, with Context Repos as versioned units with branching, staged rollouts, and rollbacks. Domain experts approve context before production.

Context Lakehouse

The Context Lakehouse stores context on Apache Iceberg, which gives it time travel and queryable historical states. It serves that context through MCP, A2A, SQL, and REST and graph APIs, and Atlan describes the stored formats as open and queryable independently of Atlan. See MCP vs A2A.

---

How do Writer’s Knowledge Graph and a context layer work together?

The Knowledge Graph keeps the documents Writer agents draft from. Writer reads shared business context from the context layer through MCP. Atlan’s MCP documentation describes a hosted MCP Server that lets AI clients and automation platforms use Atlan as a context layer, and the Model Context Protocol is the open standard behind it. On the Writer side, admins create a custom connector in AI Studio by choosing an MCP server and entering its URL, with no-auth, API key, and OAuth options. The two documented halves line up, but the client list in Atlan’s MCP docs does not name Writer, so test the connection and its permissions before you rely on it.

A division of labor that holds up

• Keep in Writer’s Knowledge Graph: brand guidelines, product documentation, approved messaging, and other content Writer agents generate from.
• Keep in the context layer: metric definitions, glossary terms, lineage, ownership, quality scores, and policy rules that more than one agent will state as fact.

Atlan’s hosted MCP server supports OAuth, which runs tools with each person’s own permissions, and API keys for automation and service accounts. The how-to guide covers the build-out, and the MCP gateway explainer covers shared endpoints.

---

Five questions to ask before one platform owns your definitions

1. Where does a definition change get reviewed, and who approves it? A good answer names an owner per domain and a recorded approval step.
2. Can you roll back a definition and see what agents answered under the old version? Look for point-in-time history of the definition, paired with traces of its answers.
3. Which agents outside this platform can read the same definitions today? Ask for the protocol by name: MCP, A2A, SQL, or REST. “Through our API” means every consumer couples to one vendor.
4. What leaves with you if you switch vendors? Constructed relationships, tuned retrieval settings, and corrections usually stay behind. A model-agnostic context layer keeps them outside any one vendor.
5. How do policy rules follow the context? Attach classifications and approval rules to each definition so they arrive with it. See role-based access control for a context layer.

Bottom line

Documents that Writer agents draft from, such as brand guidelines and product sheets, belong in Writer’s Knowledge Graph. Definitions that more than one agent will state as fact, such as net revenue retention or a discount approval threshold, belong in a shared layer with an owner, a review step, a version history, and lineage to the tables that produce them.

Connect that layer to WRITER Agent through a custom MCP connector, connect your other platforms through the same interface, and send corrections back to one place. Teams still deciding how to structure the documents themselves can run the knowledge base shape picker in the panel above.

---

FAQs about Writer Knowledge Graph vs a governed enterprise context layer

1. What is Writer’s Knowledge Graph, and what does it ground?

Writer’s Knowledge Graph is a retrieval-augmented generation system that uses graph-based relationships. It ingests uploaded files, content from Confluence, Notion, Google Drive, and SharePoint, and website URLs, then builds a graph of entities and relationships that agents query at answer time. It grounds agents built on Writer.

2. Is Writer’s Knowledge Graph a context layer?

It is a retrieval layer for Writer’s agents. An enterprise context layer is shared across agent platforms and carries governed business definitions, lineage, ownership, and policy rules. Document retrieval is one input to a context layer, and Writer’s Knowledge Graph handles that input for Writer agents.

3. Can Writer agents read business context from outside Writer?

Yes, with limits. WRITER Agent can call MCP servers through custom connectors that admins create in AI Studio, with team scoping. Writer’s documentation says MCP connectors do not currently support Agent Builder, no-code agents, or API integrations, so those agents need another route to outside context.

4. Do you still need a context layer if you already run Writer?

If Writer is your only agent platform and your agents mostly draft from documents, its Knowledge Graph may cover the need. Once a second agent platform, an analytics agent, or a regulated metric enters the picture, a shared layer keeps definitions consistent and adds review, versioning, and lineage.

5. What happens to your business definitions if you move off Writer?

Writer documents a File API that downloads source files. The Knowledge Graph documentation does not describe exporting the constructed graph, so relationships and tuned query settings may need rebuilding. Definitions held in an open-format context layer stay readable by the next platform.

---

Sources

1. Connect your data to AI with Knowledge Graph, Writer Developer Documentation, 2026. https://dev.writer.com/home/knowledge-graph-concepts
2. Create and manage a Knowledge Graph, Writer Developer Documentation, 2026. https://dev.writer.com/home/knowledge-graph
3. Use a Knowledge Graph in a chat, Writer Developer Documentation, 2026. https://dev.writer.com/home/kg-chat
4. Configure Knowledge Graph query parameters, Writer Developer Documentation, 2026. https://dev.writer.com/home/knowledge-graph-query-config
5. Question endpoint, Writer API Reference, 2026. https://dev.writer.com/api-reference/kg-api/question
6. Choose a model, Writer Developer Documentation, 2026. https://dev.writer.com/home/models-overview
7. Configure connectors and the MCP gateway, Writer Developer Documentation, 2026. https://dev.writer.com/home/mcp-gateway
8. Custom connectors, Writer Developer Documentation, 2026. https://dev.writer.com/home/custom-connectors
9. Snowflake connector, Writer Developer Documentation, 2026. https://dev.writer.com/connectors/snowflake
10. Salesforce connector, Writer Developer Documentation, 2026. https://dev.writer.com/connectors/salesforce
11. Configure guardrails, Writer Developer Documentation, 2026. https://dev.writer.com/home/guardrails
12. Download file, Writer API Reference, 2026. https://dev.writer.com/api-reference/file-api/download-file
13. Connectors and capabilities, Atlan Documentation, 2026. https://docs.atlan.com/product/connections/references/connectors-and-capabilities
14. Lineage, Atlan Documentation, 2026. https://docs.atlan.com/catalog/lineage
15. Context Agents Studio, Atlan Documentation, 2026. https://docs.atlan.com/platform/context-agents-studio
16. Context Engineering Studio, Atlan Documentation, 2026. https://docs.atlan.com/platform/context-engineering-studio
17. Atlan MCP, Atlan Documentation, 2026. https://docs.atlan.com/platform/atlan-mcp-overview
18. Context Agents, Atlan, 2026. https://atlan.com/context-agents/
19. Context Engineering Studio, Atlan, 2026. https://atlan.com/context-engineering-studio/
20. Context Lakehouse, Atlan, 2026. https://atlan.com/context-lakehouse/