Every serious LLM application has three layers. The model generates tokens. The harness wraps it with tools, state, and an orchestration loop. The context layer is the structured context the harness reads on every call. Two of the three have settled builder categories: foundation labs ship models, agent SDKs ship harnesses. The third does not. Most teams still build their context layer by hand.
The cost is visible in the data. a16z partners Jason Cui and Jennifer Li argued in March that "data and analytics agents are essentially useless without the right context." MIT NANDA's 2025 study put a number on it: 95% of enterprise AI pilots returned no measurable ROI. The post-mortems converged on the same diagnosis. The models, harnesses, and data were fine. The context layer wiring them together was not.
Part One
A model produces tokens. A frontier LLM in a chat box does plenty of useful work; hundreds of millions of people use ChatGPT and Claude every day. What it cannot do alone is take action, read your files, execute tools, or hold state across turns. The category that builds models is mature: foundation labs sell them, or you run open weights.
A harness is the runtime that wraps the model and turns it into an agent. Hashimoto coined the term in February 2026: every time an agent makes a mistake, you engineer the environment so it does not make that mistake again. The mechanics are tools, the system prompt, output parsing, retries, state, prompt caching, and the orchestration loop. Anthropic calls a closely related practice context engineering. The category is the agent SDK: Claude Code, Cursor, LangGraph, OpenAI's Agents SDK, Google's ADK, Anthropic's Agent SDK, CrewAI, AutoGen, Letta, AWS AgentCore. Picking one is no longer where you spend your engineering budget.
The smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.
The context layer is the third: the structured context the harness reads on every call. Resolved entities, business definitions, lineage, metadata, provenance, the rules a domain expert keeps in their head. It exists in every production AI application. What does not exist around it is a settled category of tools that builds it. Most teams still hand-write the layer the way analysts hand-wrote SQL before dbt. That gap is the subject of this paper.
Part Two
This is not a new problem. Semantic layers tried to solve it in the 2000s by codifying metrics in MicroStrategy and Looker. Master data management tried it through the 2010s with canonical entities for customer, product, and employee. Knowledge graphs and ontology platforms tried it by modeling relationships. Data catalogs tried it by indexing metadata and curating glossaries. Enterprise search tried it by indexing every document. Memory systems tried it at the conversation level. Every category got real adoption. None produced a usable enterprise context layer at scale.
The failure mode was identical: human curation does not scale to a modern data estate. A semantic layer with two hundred metrics is maintainable; one that covers the analytical surface of a 5,000-person company is not. A knowledge graph that represents the org chart can be hand-curated; one that represents every customer, entitlement, and decision cannot. Catalog completeness above 30% is rare. Curation costs cross the data-growth curve early and stay there.
That is why most teams today still wire context together by hand. Somebody picks a vector store, runs documents through an embedder, adds a Slack connector, names the important tables in a system prompt, drops in a glossary, and calls it done. That is a context layer. It is built by humans in code and YAML and Notion pages, and the harness reads it on every call. It exists in every shipped AI product. What does not exist around it is a settled category of tools that builds it for you.
This works for the demo. In production it produces failures anyone who has shipped an agent recognizes. The agent uses the wrong definition of a business term because two departments define it differently and both versions are embedded. It references stale schema because the embedder ran in March and nobody re-embedded after April's migration. It misses entity resolution because "Acme Corp" in Salesforce is the same customer as "Acme, Inc." in Stripe and cosine similarity has no way to know. It hallucinates a deprecated product feature because the deprecation lives in a Confluence page that ranked below the original spec. None of these are model failures. All of them are context failures.
Gorgias's engineering team described the modern version clearly. The model and the harness were the easy parts. The hard part was giving the agent enough context to answer questions correctly across the company. They ended up building a context layer with structured metadata, when-to-use guidance, and examples, versioned alongside their dbt models.
OpenAI reached the same conclusion. Their published architecture has multiple layers of grounding: table-usage metadata, human annotations from domain experts, Codex-powered code enrichment, and a memory that captures user corrections. They built a context constructor before the term existed, because none of the off-the-shelf categories could deliver the layer they needed.
You can run a small AI product on a hand-built context layer. You cannot run a serious one. The question is whether to keep hand-building, in defiance of twenty years of evidence, or adopt the category that finally has the unit economics.
Part Three
A context constructor is an AI-powered system that builds and maintains a context layer. It ingests heterogeneous sources, extracts entities and relationships, resolves the same entity across systems, maintains the layer as sources change, surfaces conflicts for human review, and exposes the result through an interface any harness can read on every call. The constructor is the new category. The context layer is what it produces. Keeping the two straight is the point.
The load-bearing word is any. If the layer is bound to one agent framework, what the constructor produced is a feature inside that framework, not a layer. A real constructor is interface-shaped on the output side. The harness should not care whether the layer was built by Snowflake's Cortex stack, by Palantir's Ontology, by DataHub, or by a Python script. The layer is the contract.
One word deserves a defense. Constructor sounds build-centric, the way a constructor in object-oriented code runs once. That is not what the term means here. A context constructor is a continuous operational system. It runs daily ingest passes, refreshes definitions on every code commit, surfaces conflicts when sources disagree, and ships human corrections back into the layer. "Construct" is shorthand for the ongoing building and maintenance, not a bootstrap phase. Some analysts use "enterprise context platform" as the broader umbrella; context constructor is the specific AI-powered builder role within it.
The category deserves a longer defense, because the obvious objection is that all of this is just semantic layers and catalogs with an AI wrapper on top.
It is not. The older categories share components with a context constructor: semantics, ontology, lineage, metadata, retrieval. They are not the same category because they failed at the job. Atlan, Collibra, DataHub, Palantir, and Stardog spent the last decade proving that human curation does not scale. What an AI-powered constructor adds is the unit economics those categories never had. It can ingest a Slack thread and pull the pricing policy embedded in the eighth message. It can propose entity resolution across Salesforce, Stripe, and the warehouse at a scale no stewardship team could staff. It can refresh a metric definition the moment a dbt model rebuilds. It can ship corrections from human review faster than a steward could file a ticket. None of that was operationally possible before 2024. The convergence the older vendors are now executing is the evidence the category is real, not the counter-argument. Collibra ships semantic agents. Alation refounded around agents. Databricks shipped Genie Code in March. dbt exposes its semantic layer through an MCP server. They did not wake up in 2026 and decide to AI-wash; they moved because the unit economics of building on their existing primitives finally collapsed.
The model is table stakes. The harness is converging. Context is the moat.
A few things this is decidedly not.
A vector store is not a context constructor. Pinecone, Weaviate, and Chroma are containers. They hold vectors. They do not know that ARR and annual recurring revenue are the same metric, that finance's revenue definition diverges from GTM's, or that "Acme Corp" in Salesforce is the same legal entity as "Acme, Inc." in Slack. A constructor sits on top of a vector store and gives it a schema.
A RAG pipeline is not a context constructor. RAG is a retrieval strategy. A constructor decides what goes in the corpus to begin with, how the pieces relate, and what metadata travels with each chunk. "RAG is dead" became a fashionable claim through 2025 once teams discovered that top-k cosine similarity was insufficient on its own. RAG is not dead; it is subsumed. Retrieval is one operation a constructor exposes, alongside lookup, graph traversal, structured query, and prompt-cached blocks served by an MCP server.
A connector library is not a context constructor. Pulling rows out of Salesforce or messages out of Slack is the easy half. Making those sources speak a common semantic language, resolving entities across them, and capturing the implicit rules a domain expert keeps in their head is the hard half. Connectors feed the constructor; they do not replace it.
The output is the point. A context constructor produces a thing the harness can read. That is the contract. The diagram below shows it. Part Four describes what the layer has to do once it is built.
Part Four
The layer the constructor produces has to do four jobs, not one. A product that does one job well is a useful component; a product that does all four is a context constructor. Most vendors today do two.
Semantic resolution. What "active customer" means in finance is not what it means in growth. What "MRR" means at the start of the quarter is not what it means at the end. A real layer holds governed definitions, metric formulas, and glossary terms, and the agent reads them instead of guessing from column names. This is dbt's territory with the Semantic Layer and MCP server, Collibra's with its semantic agents, and Atlan's with governed business meaning.
Identity and relationship modeling. The "Acme Corp" account in Salesforce, the "Acme, Inc." customer in Stripe, the contract in Notion, and the ticket in Zendesk are the same entity. A real layer resolves them once and exposes the relationships. Palantir's Ontology has done this for a decade as an operational layer, with actions and decision lineage bound to canonical objects. Stardog centers the enterprise knowledge graph as the substrate agents need. Snowflake reports that adding even a plain-text data ontology lifted final answer accuracy by 20% in their internal tests. Without identity resolution, agents hallucinate relationships the source systems already know.
Permissions, policy, and provenance. A layer is only safe if the agent sees what the user is allowed to see, computed at query time, and only useful if every claim it surfaces traces back to a source. Credal built its product around permission inheritance from source systems. Databricks Unity Catalog is the governance layer Genie reads through. Microsoft Graph grounds Copilot in user-scoped data and refuses access the user does not have, returning traceable sources. Skip this job and your context layer is a leak surface.
Freshness and change management. Definitions, schemas, ownership, and policies change every day. A layer that does not change with them is wrong by Tuesday. DataHub frames this as living context: event-based sync from a hundred-plus systems so the graph reflects operational reality, not stale documentation. OpenAI runs a daily offline refresh plus runtime retrieval. Collibra's semantic agents keep the layer alive as circumstances change. A constructor that builds once and never updates is not a constructor; it is a snapshot.
A useful test is to walk any vendor pitch through these four jobs. Most are excellent at one, plausible at a second, aspirational about the rest. gbrain, Garry Tan's MIT-licensed personal stack, is interesting because at the scale of one person's life it visibly does all four: Markdown files for semantics, Postgres + pgvector retrieval that resolves people and projects across 13 years of calendar data and 3,000 contact pages, per-repo trust policies for access, and 20+ cron jobs for freshness. The vendors in Part Seven do the same at company scale, with permission inheritance, multi-tenant isolation, and audit trails added.
Part Five
The shape of this category is easiest to read by reference to what dbt did for analytics. The two situations rhyme.
Before dbt, analytics inside most companies was a swamp. Analysts wrote SQL directly against raw warehouse tables. The same metric was defined three ways in three dashboards. No tests, no version control, no shared semantics. Reports contradicted each other and nobody could tell which one was right.
dbt did not store the data (Snowflake, BigQuery, Redshift did) or visualize it (Looker, Tableau, Mode did). What dbt did was sit between the warehouse and the BI tools and turn raw tables into a tested, modular, version-controlled, documented schema. It compiled SQL, ran tests, generated lineage, and handed the BI tools a clean, governed thing to read. The category is called the transformation layer of the modern data stack, and dbt defined it.
It worked. Forty thousand companies run dbt in production. The analytics-engineer job title exists because of it. dbt went from "a script Tristan Handy wrote" to a billion-dollar company in seven years, with Coalesce, SQLMesh, and others built around the same idea.
The analogy maps cleanly. The transformation layer is to analytics what the context layer is to AI. In both cases the layer existed before any tool that managed it. The transformation layer existed in stored procedures and views; the context layer exists today in glossaries, Notion pages, and bespoke ETL. dbt turned the transformation layer from a hand-built mess into a managed system. Context constructors are doing the same for the context layer.
The shape rhymes, with two differences that matter.
The first is that the inputs are not just SQL. They include documents, conversations, tickets, code, calendar events, and whatever else carries meaning inside a company. A constructor has to handle a much wider class of source material than dbt ever did. This is also why LLM-assisted extraction is necessary in a way it was not for dbt: a deterministic parser cannot make sense of a Slack thread the way a model can.
The second is that the consumer is not a BI tool but an agent that can act. The agent is faster than a human analyst and worse-calibrated. Bad analytics produces a wrong number on a dashboard that someone might catch. Bad context produces a wrong action against a real system before anyone notices. Same shape, much higher stakes.
Part Six
Three forces converged in the last twelve months.
Models got good enough to expose the context bottleneck. The frontier did not stop moving. Stanford's 2026 AI Index reports agent task success on OSWorld jumped from 12% to roughly 66% in a year, and SWE-bench Verified from 60% to nearly 100%. The same index describes the "jagged frontier": the model that wins an olympiad reads an analog clock correctly half the time, and agents still fail one task in three on real computer-use benchmarks. The defensible read is not that capability is solved. It is that capability has crossed a threshold where the next biggest gain on a production agent comes from fixing what the model reads, not from upgrading the model. Picking a model is now a decision about price, latency, integration surface, and which provider's safety policies your legal team will tolerate.
The harness consolidated. OpenAI shipped Agents SDK in early 2026. Google shipped ADK. Anthropic shipped Agent SDK with Claude 4.6. LangGraph passed CrewAI in GitHub stars. Cursor and Claude Code defined the shape of an interactive coding harness. The vocabulary stabilized across all of them. The marginal engineering hour spent picking a harness produces less than it used to.
Context emerged as the actual constraint. Anthropic positioned context engineering, not prompt engineering, as the next discipline, defined as finding the smallest set of high-signal tokens that produces the desired behavior. Chroma's "Context Rot" study showed performance degrading as input length grows across 18 frontier models. Stanford's "Lost in the Middle" showed long-context models use information unevenly, with retrieval failing when relevant facts sit in the middle. More context is not better; beyond a point, excess context degrades reasoning. Datadog's 2026 State of AI Engineering report, from real customer traces, found 69% of input tokens are spent on system prompts repeated on every call, with only 28% of calls using prompt caching. The waste and the quality penalty are both enormous.
Karpathy's Software 3.0 framing makes the cost concrete. The LLM is the CPU. The context window is the RAM. Anything outside the window is on disk. The harness is the runtime, deciding what to load into RAM before each step. A context constructor decides how the disk is organized in the first place: what gets paged in, with what schema, what relationships, what provenance. Get that wrong and the CPU runs on garbage.
A common mistake: MCP solves none of this. The Model Context Protocol is a transport: the wire connecting LLM applications to external data and tools. It does not produce semantic meaning, resolve identities, enforce permissions, or maintain freshness. "MCP-enabled" is not "context-ready." Shipping an MCP server is useful plumbing; whether the vendor has a context constructor depends on whether the data flowing through that pipe is structured, governed, and current. dbt's MCP server is interesting precisely because it sits on top of dbt's existing semantic layer, lineage, and tests.
At the March 2026 Gartner Data and Analytics Summit, Rita Sallam framed it in the way that moves boards: about one in five enterprise AI investments shows measurable ROI, and the determinant is whether context has been treated as critical infrastructure on par with cybersecurity. The model is table stakes. The context is the moat. The vendors in the table below are positioning around exactly that thesis, from six different starting points.