How to set up memory layer for AI agents
A memory layer for AI agents is external infrastructure that persists context across sessions. It lets a stateless model recall prior interactions, learned facts, and governed organizational knowledge at the start of each new run.
In Atlan, the closest product fit is a context repository built in Context Studio and served to agents through the Atlan MCP server. A context repository is a bounded, versioned package of governed context for a specific domain.
This guide is for teams building context-aware agents on runtimes that connect to Atlan through MCP, such as Cursor, Claude, ChatGPT, VS Code, Windsurf, Microsoft Copilot Studio, and Google ADK.
To learn about Atlan's built-in context agents for metadata enrichment, see Understand context agents. The currently available agents are Description, README, and SQL Intelligence. Link Terms is coming soon.
Prerequisites
- An Atlan workspace with at least one connected source.
- An AI tool or runtime that can connect to Atlan through MCP.
- OAuth credentials or an API key for your Atlan workspace.
- Admin permissions if you want the agent to update metadata through MCP write tools.
Agent memory is commonly split into short-term memory, which lives inside the active context window for one run, and long-term memory, which persists across runs. This page is about long-term memory.
Set up Atlan MCP for your agent runtime
Connect your AI tool to the Atlan Remote MCP server. Remote MCP is hosted by Atlan, enabled for all tenants, and supports interactive tools and automation platforms including Cursor, Claude, ChatGPT, Gemini, VS Code, Windsurf, Microsoft Copilot Studio, and Google ADK.
Use the setup guide for your runtime:
Authenticate with OAuth when possible, or use an API key when the connector supports it.
Create context repository
In Context Studio, create a context repository for the domain, team, or agent use case you want to support. Describe the domain in plain language, and Context Studio searches your Atlan catalog, selects the most relevant tables and columns, and generates an initial semantic model.
The repository must hold the domain context your agent needs to answer correctly: business definitions, the semantic model, custom instructions, and any supporting question sets.
Scope repository to one domain or use case
Keep the repository bounded. Context repositories are versioned, certified units of context scoped to a specific domain or use case. A good starting pattern is:
- One repository per business domain.
- One repository per agent use case.
- One repository per agent role.
Narrow scope keeps context governable, keeps accuracy high, and reduces definition conflicts across teams. The Atlan glossary stays the shared source of truth, so a term carries consistent meaning across every repository that uses it.
Configure agent to read repository context at runtime
Point the agent's MCP client at Atlan and configure it to retrieve the governed context it needs to use before answering. The result is a shared, governed context source that multiple agents can consume, instead of each agent reconstructing business meaning from scratch.
Use MCP write tools when agent needs to update metadata
Atlan MCP supports both read-only and write operations. Documented write capabilities cover asset metadata, custom metadata, tags, lifecycle, glossary, domains, and data quality.
Use these write tools when your workflow needs the agent to:
- Update descriptions or READMEs.
- Add or remove tags.
- Update custom metadata.
- Manage glossary content.
- Change asset lifecycle or data quality metadata.
Treat those documented metadata operations as the supported write-back surface.
Test, deploy, and observe
Before rolling the repository out broadly, validate it with real business questions. Context Studio runs a Build, Simulate, and Deploy loop, with Observe as the feedback channel:
- Test whether the agent answers correctly with the repository loaded.
- Identify missing definitions, relationships, or edge cases.
- Refine the repository.
- Redeploy and observe production behavior. Observe is currently available for Snowflake Cortex deployments.
Start with one domain and one repository. It's easier to split or add repositories later than to untangle one repository that tries to cover every team and every definition.