--- title: "What Is the Context Layer for General-Purpose AI Agents?" url: "https://atlan.com/know/ai-agent/context-layer/context-requirements-for-general-purpose-ai-agents/" description: "Claude Code, Codex, Cursor, and Copilot solved agent harness security. Learn what enterprise context layer general-purpose AI agents still need to be correct." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-07-28" updated: "2026-07-28T00:00:00.000Z" --- --- General-purpose AI agents, Claude Code, OpenAI Codex, Cursor, and GitHub Copilot, have solved harness readiness: the sandboxing, approvals, and audit logging that keep an agent from doing something catastrophic. According to Atlan's Context Agents data, 87% of AI-generated context across its customer base already rates on par with or better than human-written descriptions, evidence that agent accuracy traces to context quality, not harness sophistication. What none of the four harnesses solve is context readiness: the business vocabulary, data ownership, and lineage that decide whether a sandboxed, approved change is actually correct. Atlan is the enterprise context layer serving Claude Code, Codex, Cursor, and internal agents from one governed source, so the same vocabulary, ownership, and lineage move with a team no matter which harness it adopts next. --- A harness decides whether an agent is allowed to run in your environment. It never decides whether the agent understood your business well enough to be trusted with the change it just made. Atlan's Enterprise Data Graph, MCP server, and Context Agents close that second gap without asking a team to rebuild the same context pipeline for every new tool it adopts. Four things a harness alone cannot supply: - What a business term or metric actually means, and who certified it - Who owns a table or pipeline, and who an approval routes to - What already broke the last time someone touched this system - Whether the rules the agent is following reflect actual company policy, not just a system prompt | Handles | What it solves | Works with | Time to shared context | Core categories | |---|---|---|---|---| | Enterprise context layer | Business vocabulary, ownership, lineage, and policy for any agent | Claude Code, Codex, Cursor, GitHub Copilot, and custom internal agents, via MCP | Hours to days once the Enterprise Data Graph is connected, not a rebuild per harness | Business vocabulary, data ownership, policy and access, lineage | --- ## What is the enterprise context layer for general-purpose AI agents? *The enterprise context layer for general-purpose AI agents is the governed source of business vocabulary, ownership, lineage, and policy an agent reads from at runtime, independent of whether it runs inside Claude Code, Codex, Cursor, or another harness entirely.* It answers a question none of those tools' own documentation is built to answer: not whether the agent is allowed to run a command, but whether it actually understands what the data it's touching means and who is accountable for it. That distinction is why an [enterprise-ready AI agent](https://atlan.com/know/ai-agent/enterprise-ready-ai-agents/) needs more than a clean deployment checklist to be trusted with production work. This is easy to conflate with a "context window," the token budget a model can hold in a single call. A context window is a memory constraint. The enterprise context layer is an infrastructure decision: what gets fed into that window, and whether it's the current, governed version of a definition rather than whatever a stale wiki page says. [Context engineering](https://atlan.com/know/what-is-context-engineering/) is the practice of assembling that input deliberately; the context layer is the persistent, queryable substrate it draws from. Worth naming what this isn't, too: an [AI context platform](https://atlan.com/know/ai-agent/context-layer/ai-context-platform/) is not [RAG over a document store](https://atlan.com/know/ai-agent/agent-context-layer-vs-rag/) or a plain [knowledge base](https://atlan.com/know/ai-agent/agent-context-layer-vs-knowledge-base/); both retrieve content, while a context layer resolves ownership, policy, and lineage on top of it. Atlan delivers this through its MCP server: one integration surface serving the same business vocabulary, ownership, and lineage to Claude Code, Codex, Cursor, and any internal agent, instead of a separate context pipeline per tool. That portability is the practical test any [model-agnostic context layer](https://atlan.com/know/ai-agent/context-layer/model-agnostic-context-layer/) has to pass, the same reason [what is the enterprise context layer](https://atlan.com/know/what-is-the-enterprise-context-layer/) treats it as a requirement, not a bonus. For a general-purpose agent, whose whole job is operating across teams it doesn't specialize in, this is the difference between an agent that's technically capable and one that's actually safe to trust with production work. --- ## Harness engineering vs. context engineering: what's the difference for Claude Code, Codex, Cursor, and Copilot? *Harness engineering, making an agent safe to run at all, is a solved problem for the four biggest general-purpose coding agents. Context engineering, making sure that safe agent is also correct, is mostly still open, and the gap between the two explains most "technically fine, actually wrong" failures.* Anthropic's Claude Code ships with a default read-only permission mode, requires explicit approval before edits or shell commands, and offers an optional sandbox constraining filesystem and network access. According to Anthropic's Claude Code security documentation (2026), the product is also SOC 2 Type 2 and ISO 27001 certified via Anthropic's Trust Center. OpenAI's Codex takes a comparable approach: sandboxed execution, configurable approval policies, role-based access control, and OpenTelemetry exports that log approval decisions, tool results, and MCP usage for audit. Cursor and GitHub Copilot have converged on the same shape of controls, the same territory [how to build an AI agent harness](https://atlan.com/know/how-to-build-ai-agent-harness/) and [what is harness engineering](https://atlan.com/know/what-is-harness-engineering/) cover in depth, and where an [agent harness differs from an agent framework](https://atlan.com/know/ai-agent/agent-harness-vs-agent-framework/) in practice. Anthropic's own engineering team frames the same problem from the model side: according to Anthropic Engineering's "Effective context engineering for AI agents" (2025), context is a critical, finite resource that has to be curated deliberately for an agent to work well, not simply expanded or left to a bigger context window. None of the four harnesses' security architecture tells an agent what a business term means or who owns a table, a gap [agent harness failures and anti-patterns](https://atlan.com/know/agent-harness-failures-anti-patterns/) documents from the other direction. That's not a harness gap. It's a category the harness was never designed to cover. | Aspect | Harness alone (Claude Code, Codex, Cursor, Copilot) | Harness + governed context layer | |---|---|---| | Can the agent run the command? | Yes, via sandbox and approval gate | Same, unchanged | | Does the agent know what the data means? | No, whatever's in its prompt or repo files | Yes, governed business vocabulary at runtime | | Who owns this table or pipeline? | Not tracked by the harness | Resolved from an ownership record | | What broke here before? | Not visible unless someone wrote it down | Lineage and change history, queryable | | Same context across tools? | Rebuilt per harness, per team | One governed source served via MCP | Atlan's MCP server serves the same business vocabulary, ownership, and lineage to all four harnesses, so a team standardized on Claude Code today and Codex next quarter isn't rebuilding its context pipeline, it's pointing a different client at the same governed source, a distinction [best AI agent harness tools](https://atlan.com/know/best-ai-agent-harness-tools-2026/) credits each vendor for honestly rather than treating them as competitors. The harness is where vendors compete on developer experience; the context layer is where the accuracy problem actually gets solved. Harness layer: Claude Code, Codex, Cursor, Copilot Sandboxing, approvals, RBAC, audit logging Context layer: Atlan, served via MCP Business vocabulary, ownership, policy, lineage context, fed at runtime *The harness decides whether an agent can act. The context layer decides whether that action is correct. Neither substitutes for the other.* ### When a well-maintained CLAUDE.md file is enough, and when it isn't Instruction files, `CLAUDE.md`, `AGENTS.md`, `.cursorrules`, `.github/copilot-instructions.md`, genuinely work at single-team, single-repo, single-harness scale. A small team maintaining one well-reviewed instruction file for one coding agent doesn't need a separate context layer; the file is small enough to keep current by hand. That approach can break down once a second harness enters the picture: two instruction files with their own drifting copy of the same business definitions, and no shared audit trail of what either agent knew when it took an action. That's a scale and governance argument, not a claim that instruction files never work, and it's worth being honest about which one this actually is. --- See the full AI context stack Get the brief on how business vocabulary, ownership, lineage, and policy come together as one layer any agent can query, no matter which harness it runs in. Get the AI Context Stack --- ## How are general-purpose AI agents different from vertical AI agents when it comes to context? *General-purpose and vertical AI agents both need a context layer, on top of whatever harness runs them. They need it in different shapes, because a general-purpose agent is asked to cross every team's data and vocabulary in a way a narrow agent never is.* A vertical agent, built for one function, claims processing, contract review, customer support, inherits a context problem scoped to one domain. A general-purpose coding agent like Claude Code or Codex doesn't get that scoping for free: the same session might touch a billing pipeline, a marketing attribution model, and a customer support schema in one afternoon. That breadth is what makes it more exposed to the context gap, not less, the same asymmetry behind the [AI agent cold-start problem](https://atlan.com/know/ai-agent-cold-start-problem/) when an agent lands in an unfamiliar domain with no bootstrapped context. The horizontal-versus-vertical debate active in practitioner circles, framed by outlets like Domo's "Horizontal vs. Vertical AI" and Hatchworks' "General Purpose vs Vertical AI Agents" (2026), usually asks which architecture wins. That's the wrong question for context specifically. Both need the same governed substrate, just from different entry points: a vertical agent bakes it into a narrow workflow, the way [context layer for SDLC](https://atlan.com/know/ai-agent/context-layer-for-sdlc/) specifies it for one function, while a general-purpose agent pulls it in fresh for whatever it's asked to do next. Atlan serves both from the same Enterprise Data Graph, which is why the requirements for [vertical AI agents](https://atlan.com/know/ai-agent/context-layer/context-layer-requirements-for-vertical-ai-agents/) and the requirements described here aren't competing specs. They're the same context layer, read differently depending on how narrow or broad the agent in front of it is. --- ## What context does a general-purpose AI agent need before it touches production? *Before a general-purpose agent touches production, it needs four categories of context no harness supplies on its own: business vocabulary, data ownership, policy and approval rules, and lineage. Skip any one and the agent can still pass every sandbox check while producing a confidently wrong answer.* According to the NIST AI Risk Management Framework, governance and audit expectations apply across the full AI lifecycle to any autonomous system, coding agents included. And according to Mei et al.'s "A Survey of Context Engineering for Large Language Models" (arXiv, 2025), context is best treated as a deliberately assembled, managed input, independent of which harness or model is running it. | Context category | What it answers | What happens without it | |---|---|---| | Business vocabulary and metric definitions | What does this field or metric mean, and who certified it | Agent applies a plausible but wrong definition | | Data ownership and stewardship | Who owns this table or pipeline, who approves a change | Agent has no one to route a risky change to | | Policy, approval, and access rules | What is the agent actually allowed to touch, and under what conditions | Rules live only in a prompt, and prompts get overridden | | Lineage and change history | What already broke here, and why | Agent repeats a fix that already failed once | Atlan's Enterprise Data Graph unifies all four into one structure an agent can query at runtime, rather than a team hand-assembling the same context in a different instruction file for every harness, the same principle [how to give AI agents access to enterprise data](https://atlan.com/know/ai-agent/how-to-give-ai-agents-access-to-enterprise-data/) applies to the access side specifically. ### Business vocabulary and metric definitions A billing pipeline is the clearest version of this failure. "Amount" means pre-tax revenue in one table and post-tax revenue in another, a distinction no schema enforces and no sandbox catches. An agent fixing a discrepancy between the two can pass every test, get explicit approval, and still be wrong, because it resolved "amount" using whichever table's convention was in its context at the time. This is "looks right, is wrong" in its most literal form, and it's why the [semantic layer](https://atlan.com/know/semantic-layer/) an agent reads from has to be governed, not assumed. ### Data ownership and stewardship When an agent proposes a change to a table it doesn't own, someone needs to be notified, or the change needs to route to an approval the agent can't grant itself. Without an ownership record, that routing either doesn't happen or happens to whoever's name is on an outdated wiki page, which is functionally the same as not happening, the exact gap [AI agent identity](https://atlan.com/know/ai-agent/ai-agent-identity/) addresses when an agent's own access inherits from a role nobody reviewed. ### Policy, approval, and access rules Practitioners on Hacker News and Reddit are explicit about a related failure: prompt-level rules cannot enforce corporate policy, because the model eventually breaks them once context gets messy enough. Guardrails enforced in tooling, an MCP server acting as a policy checkpoint rather than a suggestion, are the difference between a rule and a request, the same distinction [AI agent governance](https://atlan.com/know/ai-agent-governance/) and [AI agent risks and guardrails](https://atlan.com/know/ai-agent-risks-guardrails/) draw. This is the mechanism behind most cases of [AI agent hallucination](https://atlan.com/know/ai-agent-hallucination/) that trace back to missing context rather than a model defect. ### Lineage and change history An agent with no visibility into what already broke the last time someone touched a pipeline repeats the same mistake with more confidence than the human who made it the first time. Lineage is the one input that tells an agent this exact change has a known failure mode before it makes the change again, the same trail [AI agent observability](https://atlan.com/know/ai-agent-observability/) depends on to reconstruct what an agent actually did. --- Not sure where your own context gap sits? Run the Context Gap Calculator to see which of these four categories, vocabulary, ownership, policy, or lineage, is thinnest for your team's agents right now. Try the Gap Calculator --- ## How to give Claude Code, Codex, and Cursor the same enterprise context *Giving every harness the same enterprise context starts with treating context as something a team owns once, not something each tool rebuilds for itself.* The four categories above, vocabulary, ownership, policy, and lineage, only help if every harness reads the same version of them. A billing pipeline where "amount" means two different things is only fixed once, not once per tool, if the definition lives in one governed place every harness queries at runtime. Atlan's MCP server is the practical mechanism, one integration surface serving governed business vocabulary, ownership, and lineage to Claude Code, Codex, Cursor, and any internal agent, instead of six bespoke connectors, the reason [why MCP matters for AI agents](https://atlan.com/know/mcp/why-mcp-matters-for-ai-agents/) treats the protocol as infrastructure, not a convenience feature. [Context Repos](https://atlan.com/know/ai-agent/context-repository-for-ai-agents/) carry that context as portable, versioned, model-agnostic units, the same portability argument [multi-cloud context layer](https://atlan.com/know/ai-agent/context-layer/multi-cloud-context-layer/) makes for infrastructure spanning more than one cloud. That portability shows up in how customers use it. At Justworks, a team runs Atlan MCP alongside Snowflake MCP inside Claude Code, with Atlan acting as what one PMM described as a compass, validating which tables are trustworthy before the agent touches the warehouse. At King, a team connected Atlan to both Claude and Codex, and a user defaulted to Codex for license-availability reasons, not because the context underneath had to change. Same governed source, different client. That's the actual test for whether a context layer is doing its job: does the answer change when a team switches from Claude Code to Codex, or does only the interface change? [Atlan's MCP server](https://atlan.com/know/what-is-atlan-mcp/) exists specifically so the second answer is always true. --- ## How to evaluate a context layer for general-purpose AI agents *Evaluating a context layer for general-purpose agents means checking for portability and auditability before checking for feature depth, because a layer that only works inside one harness just moves the rebuild problem instead of solving it.* | Criterion | Why it matters | What to look for | |---|---|---| | Cross-harness portability | Teams switch or run multiple harnesses in parallel | Context reachable via a standard protocol like MCP, not a proprietary plugin | | Auditability and traceability | Every agent action needs a source it can be traced back to | Every context read logged against a specific definition, owner, or lineage record | | Business-vocabulary grounding | Definitions have to be certified, not scraped | A governed glossary with an owner of record, not an auto-generated guess | | Policy enforcement point | Rules need to live in tooling, not just a prompt | Access and approval rules enforced at the MCP layer itself | | Evaluation before production | Context needs testing the same way code does | Evals generated from real organizational questions, run before rollout | The questions worth asking a vendor directly: can context move if the team switches harnesses next year? Is every agent action attributable to a specific context source, not just a model's confidence? Is the context itself tested before it reaches production, the same discipline [how to test an AI agent harness](https://atlan.com/know/how-to-test-ai-agent-harness/) applies on the harness side? A pass through [agent context layer tools compared](https://atlan.com/know/ai-agent/agent-context-layer-tools-compared/) and [context layer evaluation criteria](https://atlan.com/know/ai-agent/context-layer/context-layer-evaluation-criteria/) is a reasonable starting checklist, and worth weighing against a [DIY context layer](https://atlan.com/know/ai-agent/context-layer/diy-context-layer/) if a team is deciding whether to build this internally. Atlan's own answer to that last question is the Context Engineering Studio, which generates tests from real organizational questions so a team can see whether its context holds up before an agent acts on it in production, not after, the same certified-glossary and MCP-enforced-policy standard the table above sets for any vendor. [Implementing an enterprise context layer](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/) is the next practical step once a team has decided what to evaluate for. --- ## How Atlan approaches context for general-purpose AI agents *Atlan's approach is to let harness vendors compete on developer experience while it centralizes business vocabulary, ownership, and lineage in one place every harness reads from.* A large lottery and gaming operator's Lead Data Scientist put it plainly after evaluating agent harnesses across the business: the harnesses were "still missing a part." They didn't solve the accuracy problem or reduce hallucinations, because sandboxing and approval gates were never designed to. A harness-approved, sandbox-verified, test-passing change can still be the wrong change, because passing those checks was never the same question as understanding the business. Atlan's wedge is deliberately narrow: let harness vendors compete on developer experience, and centralize business context in one place every harness can read from. The Enterprise Data Graph, Context Agents, MCP server, and Context Repos work together as that place, generating and maintaining business vocabulary, ownership, and lineage so no single harness has to. Sridher Arumugham, Chief Data & Analytics Officer at DigiKey, describes it as more of a context operating system than a catalog. Joe DosSantos, VP of Enterprise Data & Analytics at Workday, points to the same MCP server as what lets Workday's shared language be reused by AI, not rebuilt for it. At Intuit, the framing is direct: context should be open and interoperable enough that a team can swap from Claude Code to Codex or Cursor without starting over. Live Oak Bank is seeing the same pattern from the customer side: teams building their own harnesses on top of general-purpose agents, with Atlan as the context layer underneath all of them. --- ## Real stories from real customers: One context layer, every harness "We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products." — Joe DosSantos, VP of Enterprise Data & Analytics, Workday Watch Now → "Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models." — Sridher Arumugham, Chief Data & Analytics Officer, DigiKey Watch Now → See what a governed context layer is worth Run the Context Layer ROI Calculator to estimate what rebuilding context per harness costs versus governing it once, across Claude Code, Codex, and Cursor. Try the ROI Calculator --- ## Why harness-ready isn't context-ready Harness readiness is a solved problem, and Anthropic, OpenAI, Cursor, and GitHub deserve the credit for solving it. Sandboxing, approval workflows, and audit logging across all four are mature enough that "can this agent run safely" is no longer the open question for most enterprise deployments. Context readiness is the problem that's still open, and it's sharper for general-purpose agents than for narrow ones, because a general-purpose agent crosses every team's data and vocabulary rather than specializing in one domain's. A single well-kept `CLAUDE.md` can hold that context for one team on one harness; it stops scaling the moment a second harness or a second team enters, which is exactly the point at which a governed layer, not a better instruction file, is the fix, the same standard [enterprise-ready AI agents](https://atlan.com/know/ai-agent/enterprise-ready-ai-agents/) and [why AI agents need an enterprise context layer](https://atlan.com/know/why-ai-agents-need-an-enterprise-context-layer/) hold every agent to, general-purpose or not. The distinction that decides whether an AI-assisted change ships safely isn't which harness ran it. It's whether the context feeding that harness was governed in the first place, and whether that context still holds up after the team's tooling changes. Book a Demo --- ## FAQs about enterprise context for general-purpose AI agents ### 1. What is the difference between an agent harness and enterprise context? An agent harness is the runtime that lets an agent execute safely: sandboxing, approval workflows, permissions, and audit logs. Enterprise context is a separate layer entirely, the business vocabulary, ownership, and lineage that determine whether an approved, sandboxed action is actually correct. A harness can be flawless and an agent can still be wrong if the context layer underneath it is missing. ### 2. What is the difference between general-purpose and vertical AI agents? General-purpose agents like Claude Code, Codex, and Cursor operate across whatever data and vocabulary a task touches, rather than specializing in one domain. Vertical agents are built for one function, such as claims processing or contract review, and inherit a context problem scoped to that function alone. Both need a governed context layer; a general-purpose agent is simply more exposed to gaps in it, because it crosses more ground. ### 3. Is Claude an AI agent? Is ChatGPT an AI agent? Yes, when deployed with tool access, sandboxing, and autonomy, such as Claude inside Claude Code or ChatGPT paired with function calling, rather than as a plain conversational assistant. The agent label depends on what surrounds the model at runtime, not on the model alone. ### 4. Can one context source serve Claude Code, Codex, Cursor, and internal agents at once? Yes. A context layer delivered through a protocol like MCP can serve the same business vocabulary, ownership, and lineage to Claude Code, Codex, Cursor, and custom internal agents simultaneously, without a separate context pipeline for each. Customers already run Atlan MCP alongside multiple harnesses this way, including Claude Code paired with Snowflake MCP and teams split between Claude and Codex. ### 5. Do general-purpose agents need the same governance as vertical or custom AI agents? Largely yes, applied at a different scope. Both need governed business vocabulary, clear ownership, enforced policy, and traceable lineage; a general-purpose agent needs that context assembled across many domains at once, while a vertical agent needs it deeply specified for one. Neither is safe to run on instruction files alone once more than one team or harness is involved. ### 6. How do you audit what a general-purpose agent knew when it took an action? Auditing requires a record that ties the action back to the specific context source the agent drew from, not just a model's confidence score or a chat transcript. That means logging which business definition, ownership record, or lineage entry the agent consulted at the moment it acted, which a context layer enforced at the MCP or tooling level provides and a system prompt alone cannot. --- ## Sources 1. Claude Code security architecture, Anthropic. https://code.claude.com/docs/en/security 2. Codex security documentation, OpenAI. https://learn.chatgpt.com/docs/security 3. Effective context engineering for AI agents, Anthropic Engineering. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 4. AI Risk Management Framework, NIST. https://www.nist.gov/itl/ai-risk-management-framework 5. A Survey of Context Engineering for Large Language Models, Mei et al., arXiv. https://arxiv.org/abs/2507.13334 6. Horizontal vs. Vertical AI Agents: What's the Difference and When to Use Each, Domo. https://www.domo.com/learn/article/horizontal-vs-vertical-ai-agents 7. General Purpose vs Vertical AI Agents: The Playbook Leaders Are Using Now, Hatchworks. https://hatchworks.com/blog/ai-agents/general-purpose-vs-vertical-ai-agents/