Enterprises don’t run one AI agent, they run a portfolio: a Sierra-style support agent, a Harvey-style legal agent, a Decagon-style service agent, a Writer-style writing agent, and in-house builds for retail, HR, or SDLC. Left alone, each one re-derives the same four things from scratch: what terms mean, who an entity is, what compliance rule applies, and what already happened last time. Atlan’s Context Agents auto-bootstrap 690K+ descriptions across 50+ enterprises by resolving that once, at a shared Enterprise Data Graph, instead of rebuilding it per agent.
That fragmentation is structural, not accidental. Every vertical agent, whether it’s a purchased platform or an in-house build, inherits whatever definitions and access rules its own team wired in, and none of that work carries over to the next agent an enterprise stands up. Atlan’s Enterprise Data Graph resolves entities and vocabulary once, Context Repos package that resolved context per team or vertical, and Atlan’s MCP server exposes all of it through one integration surface instead of building a new one per agent.
What a shared context layer resolves once for every vertical agent:
- Entity resolution: what “customer” or “SKU” means, consistently, across every agent that reads it
- Domain vocabulary: metric and term definitions, governed once instead of re-derived per agent
- Per-vertical policy enforcement: HIPAA for a healthcare agent, PCI for a retail agent, checked once at the shared layer
- One delivery surface: MCP serving every agent instead of a bespoke integration per agent
| What It Is | Key Requirement | Best For | Delivery Mechanism | Core Components |
|---|---|---|---|---|
| A governed layer that resolves entities, vocabulary, and policy once for every vertical AI agent | Entity resolution, domain vocabulary, and per-vertical policy enforcement | Enterprises running two or more specialized AI agents (Sierra-, Harvey-, Decagon-, Writer-style, or in-house) | Model Context Protocol (MCP), one integration surface for every agent | Enterprise Data Graph, Context Repos, MCP server, policy enforcement layer |
What is a vertical AI agent?
Permalink to “What is a vertical AI agent?”A vertical AI agent is an AI system built and trained for one industry or function, unlike a general-purpose agent that works across many domains at once. According to IBM (2026), vertical AI agents provide tailored experiences by analyzing user behavior and preferences within a specific context, trained on specialized datasets and workflows so they handle industry terminology, edge cases, and regulatory constraints a generic model would miss. That specialization is real engineering, not a marketing label, as the four named vendors below show.
Named vertical agent examples: Sierra, Harvey, Decagon, and Writer
Permalink to “Named vertical agent examples: Sierra, Harvey, Decagon, and Writer”Sierra builds customer-support agents and publishes its own evaluation benchmarks to prove conversation quality at the agent level. Harvey builds legal agents; its Head of Applied Research has publicly described the “agent harness,” the orchestration layer that decides which tools a model calls, vocabulary that is now spreading well beyond legal AI. Decagon builds customer-service agents on a user-memory abstraction that, in the company’s own words, “captures conversational context without creating a duplicative data layer,” scoped to a single agent’s own conversations. Writer builds an agent-construction framework aimed at enterprise writing and workflow automation. Each of these vendors solves its own agent’s reliability with substantive engineering, not a strawman gap.
Vertical agents vs. in-house vertical builds
Permalink to “Vertical agents vs. in-house vertical builds”The same specialization pattern repeats for in-house builds. Enterprises stand up their own vertical agents for retail merchandising, legal review, HR case management, insurance underwriting, sales enablement, healthcare workflows, finance operations, and software delivery, each one trained on a single team’s vocabulary and workflows rather than the whole enterprise. Whether a vertical agent is bought from Sierra, Harvey, Decagon, or Writer, or built in-house, it optimizes for one job well. What none of them do on their own is share that context with the other vertical agents running alongside them, covered next.
Why do vertical AI agents become isolated context islands?
Permalink to “Why do vertical AI agents become isolated context islands?”Left alone, every vertical AI agent re-asks the same four questions from scratch: what terms mean here, who this entity is across systems, what this vertical’s compliance rule is, and what already happened last time someone asked. Answering those four questions per agent, instead of once for the whole portfolio, is what risks turning a well-built vertical agent into an isolated context island, a structural risk each enterprise still has to manage, not an outcome any of these agents are doomed to.
Most write-ups on this topic pick one lane or the other. LinkedIn’s closest existing framing describes vertical AI as “a pattern that packages intelligence with context and rules,” but stops at the concept, without naming vendors or a requirements checklist an enterprise could actually use. DataHub covers the components a context layer needs, interpreting requests, acting on current state, explaining decisions, but doesn’t address what happens once an enterprise runs several vertical agents side by side, which is the harder and more common problem than choosing or building any single agent well.
This isn’t a doom prediction. Sierra, Harvey, and Decagon are actively building real context and knowledge architecture of their own: evaluation benchmarks, harness vocabulary, memory abstractions. A sufficiently sophisticated vendor can reduce its own agent’s reliability risk substantially on its own. What none of that solves is the cross-agent problem: duplicated integrations, inconsistent entity resolution between agents, conflicting per-agent compliance rules, and no audit trail spanning more than one agent, the same fragmentation this enterprise context layer and multi-agent memory silos both describe at the infrastructure level, applied here to named vertical agents specifically.
| Aspect | Isolated Per-Agent Context (Status Quo) | Shared Context Layer |
|---|---|---|
| Definitions | Redefined per agent | Resolved once, reused everywhere |
| Entity resolution | Per-agent mapping, inconsistent | Cross-system, consistent |
| Compliance/access rules | Re-implemented per agent | Enforced once at the shared layer |
| Integration surface | N bespoke integrations | One, via MCP |
| Audit trail | Fragmented per agent | Unified, cross-agent |
| Vertical Agent | What It Solves at the Agent Level | What Still Breaks Across Agents |
|---|---|---|
| Sierra | Customer-support conversation quality, own evaluation benchmarks | No shared entity or definition layer with other enterprise agents |
| Harvey | Legal “agent harness” orchestration and tooling | Legal-specific compliance rules aren’t reused by other verticals |
| Decagon | User-memory abstraction scoped to its own conversations | Memory stays inside Decagon, not shared enterprise context |
| Writer | Agent Builder framework for constructing agents | Governance and context defined per Writer deployment, not enterprise-wide |
What breaks when multiple vertical agents each build their own context
Permalink to “What breaks when multiple vertical agents each build their own context”Each additional vertical agent an enterprise deploys multiplies the same four unresolved questions instead of reusing an answer. A support agent’s definition of “active customer” drifts from a billing agent’s definition of the same term; a legal agent’s access rule for a contract doesn’t carry over to a sales agent reading that contract’s metadata. At five or six vertical agents, an enterprise isn’t running five specialized systems, it’s running five separate, unaudited definitions of its own business, the same pattern covered in context management for multi-agent systems, in context management versus memory management, and in why MCP alone doesn’t stop each agent building its own island.
The single-industry version of this problem is already documented per vertical: context layer for retail AI covers the SKU and inventory instance, context layer for data analytics teams covers the metric-drift instance, and context layer for data governance teams covers the policy instance. This page’s argument is what those three have in common once an enterprise runs more than one of them side by side, a generalization also framed in what is a context layer and why AI systems need it and in common context problems data teams face building agents.
The CIO's Guide to Context Graphs
A primer for leaders deciding how to govern context once, underneath a growing portfolio of vertical AI agents.
Get the GuideWhat does a vertical AI agent need from a context layer?
Permalink to “What does a vertical AI agent need from a context layer?”Any vertical agent, whether it’s Sierra, Harvey, Decagon, Writer, or an in-house build, needs exactly three things built once at a shared layer instead of rebuilt per agent: entity resolution, domain vocabulary, and per-vertical policy enforcement. The fourth question from the previous section, what already happened last time someone asked, isn’t a separate build; it’s the audit trail those three requirements produce as a byproduct once they’re centralized, covered under auditability later in this page. Skipping any one of the three requirements doesn’t make an agent fail loudly; it makes the agent produce a confidently wrong answer that looks correct until someone checks it, the context layer AI agents actually need according to Graphlit’s own framing of the same three-part problem.
Entity resolution across systems
Permalink to “Entity resolution across systems”“Customer” in the CRM has to mean the same thing to a Sierra-style support agent, a Harvey-style legal agent, and a Decagon-style service agent, or each one produces a plausible but different answer to the same question about the same account. Atlan’s Enterprise Data Graph resolves that identity once, across systems, so every agent that reads it inherits the same answer instead of building its own lookup table.
Domain vocabulary, resolved once
Permalink to “Domain vocabulary, resolved once”Metric and term definitions need the same one-time resolution, the same job a semantic layer for AI agents does for a single surface, applied here across every vertical agent instead of one. The clearest evidence of what happens without it comes from a narrower, well-measured surface: according to dbt’s 2026 benchmark, grounding text-to-SQL generation in a governed semantic layer moved NL-to-SQL accuracy from 90.0% to 98.2% for Claude Sonnet 4.6, and from 84.1% to 100% for GPT-5.3-Codex. That’s evidence that ungoverned, per-surface grounding produces confidently wrong output even in one narrow use case, and the same failure compounds across a portfolio of vertical agents that each define “active user” or “churn” differently.
Per-vertical policy and compliance enforcement
Permalink to “Per-vertical policy and compliance enforcement”HIPAA applies to a healthcare agent, PCI to a retail agent, and SOX and other regulatory regimes apply to a finance agent, and re-implementing each rule inside every agent that touches regulated data multiplies both the compliance surface and the audit burden. Checking policy once, at the shared layer, means a new vertical agent inherits the right rule automatically instead of a team re-deriving it from scratch.
MCP is the delivery mechanism that makes this practical at scale. Instead of a bespoke integration for every vertical agent, Atlan’s MCP server exposes the same resolved entities, vocabulary, and policy to Sierra-, Harvey-, Decagon-, and Writer-style agents alongside in-house builds, through one open protocol. Context Repos then package that resolved context per team or vertical, so a healthcare agent and a retail agent each inherit their own policy slice without re-deriving the underlying resolution work.
Vertical AI agents vs. general-purpose AI agents: do they need different context?
Permalink to “Vertical AI agents vs. general-purpose AI agents: do they need different context?”The context-layer requirement is symmetric: a Claude Code or Codex-style general-purpose agent needs the same entity resolution, vocabulary, and policy enforcement a vertical agent does, just applied more broadly.
A vertical agent specializes in one job and one vertical’s terminology, an angle Domo’s own horizontal-versus-vertical comparison frames as a choice between specialization and reach. A general-purpose agent works across many domains at once, but it still reads from the same underlying systems, the same customer records, the same metric definitions, and the same compliance rules a vertical agent touches. SymphonyAI argues that vertical AI wins specifically because it packages intelligence with the context and rules a general-purpose model lacks by default, evidence that the requirement doesn’t disappear for general-purpose agents, it just has to cover more ground. The requirement doesn’t change with agent type; only the surface area does. A general-purpose agent needs the context layer to generalize correctly across every vertical at once, instead of specializing correctly in just one.
This page and its companion on general-purpose AI agents both argue for one shared layer, not two different architectures bolted together. It’s the same shape of requirement covered by a model-agnostic context layer and a multi-cloud context layer, just applied to agent vertical instead of model choice or cloud provider. The full breakdown of what general-purpose agents specifically need, and why the requirement doesn’t shrink just because the agent is broader, lives on that sibling page.
How to give multiple vertical agents one shared context layer
Permalink to “How to give multiple vertical agents one shared context layer”Closing the isolated-context-island gap takes three moves: resolve entities and vocabulary once at a shared graph, expose it through one open protocol, and package it per team or vertical instead of per agent.
Build the shared entity and vocabulary layer, Atlan’s Enterprise Data Graph, before onboarding any individual vertical agent, not after. Expose it through MCP so Sierra-, Harvey-, Decagon-, and Writer-style agents, plus in-house builds, all read the same layer through one integration surface instead of N bespoke ones. Then package context per team or vertical using Context Repos, reusable context packages sitting atop the shared graph, so a healthcare vertical agent and a retail vertical agent each get their own policy slice without duplicating the underlying resolution work.
The common pitfall is sequencing. Standing up the shared layer after several vertical agents are already live, each with its own definitions already baked in, forces a costly reconciliation pass later. Sequence the shared graph first, then onboard each vertical agent into it, not the reverse.
How to choose a context layer that serves multiple vertical agents
Permalink to “How to choose a context layer that serves multiple vertical agents”Evaluating a context layer for multi-agent use means checking five things: entity resolution, vocabulary governance, per-vertical policy enforcement, integration protocol, and auditability. Tellius frames the underlying shift as a move toward a “Context OS” that stops agents from giving confidently wrong answers on enterprise data, and the criteria below are what separate a layer built for one agent from one built for a portfolio.
| Criterion | Why It Matters | What to Look For |
|---|---|---|
| Entity resolution across systems | Prevents “customer” or “SKU” from meaning something different per agent | Graph-based identity resolution, not per-agent lookup tables |
| Domain vocabulary governance | Stops metric and definition drift across agents | Centrally governed vocabulary wrapping existing semantic layers, not hardcoded per-agent prompts |
| Per-vertical policy enforcement | HIPAA for a healthcare agent, PCI for a retail agent, and so on | Policy checked once at the shared layer, not re-implemented per agent |
| Integration protocol | Determines how many bespoke integrations you build | Open protocol (MCP) vs. proprietary per-agent SDKs |
| Auditability | Needed for compliance and trust across many agents | Unified decision trace across all agents, not per-agent logs |
Four questions surface the gaps a vendor demo won’t. Does this resolve entities once across systems, or per agent? Does it wrap an existing semantic layer or replace it? Can a new vertical agent onboard without rebuilding vocabulary from scratch? What is the audit trail across agents, not just within one? A context layer that answers all four with “once, across every agent” is built for a multi-agent portfolio. One that answers “per agent” on any of them has just moved the isolated-context-island problem one layer down, the same evaluation lens how to implement an enterprise context layer, agent context layer design, and context layer 101 apply more broadly.
AI Agent Context Readiness Checklist
Score whether the context behind your Sierra-, Harvey-, or Decagon-style agents, or your in-house builds, is resolved once or rebuilt per agent.
Check Your ReadinessHow Atlan approaches context for vertical AI agents
Permalink to “How Atlan approaches context for vertical AI agents”A company can deploy four excellent vertical agents, Sierra for support, Harvey for legal, Decagon for service, and an in-house retail build, and still not fully trust any of them, because each one carries different assumptions about meaning, sources, and policy. In sales conversations, enterprise data teams including Lowe’s, JPMorgan Chase, Palo Alto Networks, World Kinect, and Verizon describe doing context engineering separately into each deployed agent, producing inconsistent definitions across a portfolio that should share one truth.
Atlan is the governed context layer underneath that portfolio. The Enterprise Data Graph resolves entities and vocabulary once; MCP exposes it as one integration surface to every vertical agent and framework; Context Repos package reusable context per team or vertical atop the shared graph, so a new agent inherits resolved definitions instead of rebuilding them from scratch.
Atlan’s Context Agents have auto-bootstrapped 690K+ descriptions across 50+ enterprises, evidence that context built once compounds across many agents and teams rather than being rebuilt per deployment. Workday’s Joe DosSantos describes shared business language that “can be leveraged by AI via Atlan’s MCP server,” concrete evidence that the one-build-many-agents mechanism runs in production today, not just in theory.
Real stories from real customers: context across many AI agents
Permalink to “Real stories from real customers: context across many AI agents”"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
"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
Neither quote names a vertical agent vendor specifically; both point at the same portfolio-level shift this page argues for, one shared layer under every agent a team deploys.
Context Layer ROI Calculator
See what resolving entities, vocabulary, and policy once, instead of per vertical agent, is worth in engineering hours saved.
Calculate the ROIThe real question once you’re running more than one vertical agent
Permalink to “The real question once you’re running more than one vertical agent”The question isn’t whether Sierra, Harvey, Decagon, or Writer build good agent-level context. They do, and the engineering behind their evaluation benchmarks, harness vocabulary, and memory abstractions is genuine. The real question is whether the enterprise running several of them at once has one shared layer answering entity resolution, vocabulary, and policy questions, or is paying to answer them N times over. A portfolio of well-built vertical agents without a shared layer underneath doesn’t fail dramatically; it just quietly produces N slightly different answers to the same question. The general-purpose agent sitting alongside that portfolio needs the identical fix, applied more broadly, not a separate one.
FAQs about vertical AI agent context layer requirements
Permalink to “FAQs about vertical AI agent context layer requirements”1. What is a context layer for AI agents?
Permalink to “1. What is a context layer for AI agents?”A context layer is a governed layer, sitting between enterprise systems and any AI agent, that resolves entity identity, business vocabulary, and access policy once and serves the resolved answer to every agent that reads from it, instead of each agent rebuilding that work on its own.
2. What is a vertical AI agent?
Permalink to “2. What is a vertical AI agent?”A vertical AI agent is an AI system built and trained for one industry or function, like Sierra for customer support, Harvey for legal work, or Decagon for customer service, rather than a general-purpose agent that works across many domains at once.
3. How is a vertical AI agent different from a general-purpose AI agent?
Permalink to “3. How is a vertical AI agent different from a general-purpose AI agent?”A vertical agent specializes in one job and one vertical’s terminology. A general-purpose agent, like Claude Code or Codex, works across many domains, but both need the same entity resolution, vocabulary, and policy enforcement from a shared context layer, just applied at different scope.
4. How do you prevent AI agents from becoming isolated context islands?
Permalink to “4. How do you prevent AI agents from becoming isolated context islands?”Resolve entities, vocabulary, and policy once at a shared graph before onboarding any individual agent, expose that resolved context through one open protocol like MCP, and package it per team or vertical instead of letting each agent rebuild its own version.
5. Do vertical AI agents like Sierra, Harvey, and Decagon need their own data infrastructure, or can they share one?
Permalink to “5. Do vertical AI agents like Sierra, Harvey, and Decagon need their own data infrastructure, or can they share one?”They can share one. Each vendor builds real context engineering for its own agent’s reliability, but none of that solves cross-agent consistency, so the entity resolution, vocabulary, and policy layer underneath them is a shared requirement, not a per-agent rebuild.
6. Who should own the context layer, the data platform team or the agent vendor?
Permalink to “6. Who should own the context layer, the data platform team or the agent vendor?”The data platform team, because it is the party with visibility across every vertical agent an enterprise runs. An agent vendor can only govern context for its own agent, which reproduces the isolated-island problem instead of solving it.
7. What is agent sprawl?
Permalink to “7. What is agent sprawl?”Agent sprawl is the state where an enterprise has deployed many specialized AI agents, each with its own integration, its own entity mappings, and its own compliance logic, with no shared layer resolving definitions or policy consistently across them.
8. How does Atlan’s context layer serve multiple vertical AI agents at once?
Permalink to “8. How does Atlan’s context layer serve multiple vertical AI agents at once?”Atlan’s Enterprise Data Graph resolves entities and vocabulary once, its MCP server exposes that resolved context to any vertical agent or framework through one integration surface, and Context Repos package reusable context per team or vertical on top of the shared graph.
Sources
Permalink to “Sources”- What Are Vertical AI Agents?, IBM. https://www.ibm.com/think/topics/vertical-ai-agents
- User memory, Decagon. https://decagon.ai/blog/user-memory
- Context Layer Components for AI Agents, DataHub. https://datahub.com/blog/context-layer-components/
- Vertical AI: Context-Rich Systems for Enterprise Execution, LinkedIn Pulse, AI Realized. https://www.linkedin.com/pulse/vertical-ai-context-rich-systems-enterprise-execution-ai-realized-jeskc
- Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, dbt Labs. https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026
- The Context Layer AI Agents Actually Need, Graphlit. https://www.graphlit.com/blog/context-layer-ai-agents-need
- 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
- The Context Layer, SymphonyAI. https://www.symphonyai.com/blog/the-context-layer/
- What Is a Context Layer for AI Agents? The 2026 Definitive Guide, Tellius. https://www.tellius.com/resources/blog/what-is-a-context-layer-for-ai-agents-the-definitive-guide-for-2026
