WTF Is the Context Layer? The Missing Infrastructure for Production Agents

Why can an increasingly capable AI still struggle to do useful work inside a company? That is the problem behind Atlan co-founder Prukalpa Sankar’s context-layer question. Atlan works on giving AI the business knowledge it lacks, with customers Sankar names including GitLab, Zoom, Discord, Affirm, Mastercard and General Motors. She invokes Bill Gates’s formulation that content is king, then proposes its agentic-era counterpart: context will be king. By her account, 2026’s enthusiasm for context graphs reflects a problem that stronger models alone have not resolved.

In Sankar’s conversations, the question is often whether AGI is one year away or three. Inside a business, the question is whether greater capability produces better outcomes. Sankar illustrates the gap with a claimed progression from failing the bar exam to scoring in the top 1%. That chronology needs qualification: the GPT-4 Technical Report already reported GPT-4 passing a simulated bar exam around the top 10% in March 2023; the talk does not identify the model or evaluation behind its top-1% figure.

Sankar says only one in five AI use cases reaches production, without identifying the underlying study. The displayed slide instead describes one in five reporting significant value, which is a different outcome. Her financial-benefit example has a firmer source: PwC’s 2026 Global CEO Survey found that 56% of 4,454 surveyed CEOs reported no significant financial benefit from AI through revenue or cost outcomes. That is narrower than saying AI delivered no benefit at all.

The human analogy is useful even without a precise equation. Sankar cites IQ as explaining only 10% of job-performance variance, without establishing the study behind that figure. But consider the practical distinction: the teammate with the highest SAT score is not necessarily the one who works most effectively, incorporates feedback or learns fastest. Real-world performance depends on both intelligence and context—the knowledge, skills and expertise acquired on the job.

Sankar describes intelligence as having grown 1,000× over a decade and 2× in six months, without specifying a measurement scale. Her architectural point is that business context has not advanced in parallel. Moving data to the cloud does not extract the situated knowledge still trapped in dashboards, Slack threads or the head of an analyst who might leave next week. To understand what agents need, start with how that analyst learns to work.

Maya is the fictional data analyst at McContext Burgers whom everyone messages when they need an answer. One morning, a franchisee asks why drive-through time is up this week. The question sounds like a straightforward comparison. Before querying anything, however, Maya has to establish what the comparison means.

First, finance and operations may mean different things by drive-through time. The week might run Monday through Sunday, but even that leaves Pacific versus Eastern Time unresolved. These are business facts: the map that makes a query meaningful. Next comes the diagnostic playbook. Maya knows to check third-quarter weather seasonality and the product launched in the previous quarter. Finally, she scopes the response to the person asking. Her useful output includes the explanation and root cause, not just a changed number.

Maya joined only a year earlier. Initial training gave her a start; shadowing an experienced teammate taught her why particular checks mattered. Mistakes, manager feedback and unfamiliar edge cases refined that judgment. Building an agentic Maya therefore requires more than packaging an onboarding document. It requires a way to acquire, correct and retain expertise through work.

Atlan’s first approach, roughly 18 months before the talk, began with a jobs-to-be-done map of its customer-experience team. Which activities filled the day, and how much could AI help with each? Documentation and meeting preparation looked promising. Relationship management looked much less amenable to automation. The team used those judgments to assign scaling factors and build narrowly focused agents. Hermione became the health intelligence lead; Moneypenny became the financial risk analyst. Each agent was optimized to do one thing well, and initially that worked.

By the middle of the preceding year, Sankar says building an agent took about five minutes, while preparing the business context needed for accuracy remained slow. Agent quality depended heavily on context-engineering quality, and mistakes cost stakeholder trust. The difficulty shifted from creating an agent to keeping it correctly informed.

A positioning change exposed the coordination problem. In a human organization, marketing can announce new positioning at a town hall, and sales development representatives know to change their pitch. Atlan’s marketing agents received changes, but its website SDR agent kept pitching the old version. The agents had no equivalent shared communication infrastructure, and the team lacked visibility into how their contexts were connected. When something went wrong, it was hard to distinguish a model problem from an agent problem or a context problem.

Separate memory systems made the problem worse. Agents learned independently and differently, making a single version of truth difficult to establish. Portability then added another failure mode. Over the preceding year, the team moved from Relevance to Google ADK, then tried Glean, moved to Claude Code at the start of the year, and eventually used roughly equal parts Claude and Codex. Each transition left context trapped in the previous system. The emergence of general-purpose agents prompted a different question: could the business knowledge live independently of the agent running the task?

Maya’s effectiveness also comes from her team. Strong teams share language, a picture of what is true today, playbooks and decision rights. They learn together. A failed launch becomes collective memory rather than a lesson each person must rediscover. Atlan’s revised approach translated that arrangement into domain experts responsible for skills, a common company brain holding their contributions, and retrieval mechanisms that make those contributions available to general-purpose agents. This shared infrastructure is the context layer.

The marketing experiment connected data systems, social and community platforms, advertising platforms and analytics. Its agent side deliberately remained open: Claude Code and Cowork, an internally deployed Claude interacting in Slack, and external products including Qualified and Artisan. Between those systems and agents sat the shared repository. The best SEO practitioner contributed an SEO skill; the competitive-intelligence expert contributed that domain’s skill. Expertise could be maintained in one place and used by different agents.

The repository needed more than instructions:

• Data graph: An autonomous ads agent doing daily analysis needs to know which tables to query.
• Skill library: Domain playbooks describe how to perform the work.
• Semantics and metrics: Definitions establish how ARR is measured and what counts as a qualified lead at this company.
• Organization and entities: Organizational structure and business entities supply additional context.

Sankar reports that the marketing team built about 300 skills and 40 agents over six months. Those counts describe the experiment’s scale; they do not measure its accuracy.

Centralizing context did not eliminate operational problems. It made their structure clearer. A competitive-intelligence skill learns what is changing in the market. Its output feeds category positioning, which feeds the sales battle card. Each skill can improve locally while disrupting a downstream consumer. Context needs to be managed like code because changes have dependencies.

A minimal JSON representation makes the dependency direction explicit: each skill names what it consumes. This illustrates the chain described in the talk, rather than an Atlan API.

{
  "skills": [
    {
      "id": "competitive-intelligence",
      "dependsOn": []
    },
    {
      "id": "category-positioning",
      "dependsOn": ["competitive-intelligence"]
    },
    {
      "id": "sales-battle-card",
      "dependsOn": ["category-positioning"]
    }
  ]
}

A change to competitive-intelligence has a direct consumer in category-positioning and an indirect consumer in sales-battle-card. Recording those relationships gives a reviewer a concrete impact path to inspect.

The team also encountered outdated skills, drift and unclear ownership of quality. Security and governance became difficult: Sankar describes secrets hardcoded in .env files and people downloading public skill repositories. Portability across agent systems remained necessary. A common repository solves distribution only partially; it still needs responsibility for what enters it, what changes and who can rely on it.

Sankar frames the next infrastructure question as what a GitHub for context would look like. Company knowledge needs lifecycle management, collaboration and versioning. That includes deciding which context is local, which is global and how each stays current. A proposed skill PR flow would combine learning with quality checks and security posture management, rather than treating every edit as immediately trustworthy.

Dependency visibility should answer what else a change affects. Explicit roles should identify the approver, maintainer and contributors. Together, these capabilities would create a human-plus-AI workspace in which shared skills can evolve without losing accountability. These are the capabilities Sankar proposes for the context layer, not a claim that every part was already implemented.

Agent interactions then become inputs to that development process. Sankar describes using a specialized harness to read traces and reconstruct candidate improvements. The important boundary is between discovering a possible lesson and accepting it into shared context:

1. Read the traces of agent work.
2. Reconstruct candidate context or skill changes.
3. Present those changes to a maintainer.
4. Have the maintainer approve or reject them.

The learning loop compounds through reviewed improvements. An observed interaction supplies evidence for a change; it does not automatically authorize that change.

Where should a company begin if its business is spread across dozens of systems? Sankar poses the example of an organization with 60 systems, then points to context already embedded in their connections. Salesforce, HubSpot, the data warehouse and the application layer each contain parts of the business’s operating logic. Context gets lost at the hops between them. Reconstructing those relationships gives AI a basis for seeding the first company brain.

Sankar reports strong accuracy from this reconstruction approach, but supplies no numerical evaluation in the spoken explanation. The slide connects an Enterprise Data Graph and an Enterprise Semantic Graph to column descriptors, joins, filters, business questions, metrics, KPIs, entities, relationships and a bootstrapped ontology. Its visible 89% callout has no established metric or evaluation conditions in the supplied explanation, so it cannot serve as an accuracy result here. The mechanism is the useful part: recover relationships across systems before asking an agent to reason over isolated fragments.

The resulting architecture turns Maya’s knowledge, expertise and norms into machine-usable context. It continually mines business systems and feeds a shared company brain. Teams develop and maintain skills through a context lifecycle as they deploy agents. Agents retrieve what they need through MCP, SQL, vector retrieval or hybrid assembly; traces return evidence to the learning loop. Retrieval is one part of the architecture, alongside acquisition, maintenance and feedback.

Hardcoding business context into individual agents makes that loop difficult to sustain. The familiar disagreement in which sales and finance report different revenue numbers becomes more consequential when autonomous systems act on those definitions. Without shared context and visible ownership, organizations risk reproducing their inconsistencies at machine speed and scale.

Context is also intellectual property. If competitors can use the same models, their distinctive capabilities must come partly from how they conduct business. A customer-support agent at American Express should not be interchangeable with one at Amazon: each should embody its company’s practices, culture and norms. Sankar closes by inviting collaboration with teams building company brains. The infrastructure challenge is to make that accumulated expertise usable by autonomous systems while preserving the judgment that makes it the company’s own.