Context Layer: Feature or Platform?

This is the condensed argument. The full version, which works through each question in detail, is here.

The short version

• Nobody argues about whether a context layer is needed anymore. The disagreement is about where context lives: inside a platform you already run, or as its own layer that many tools and agents resolve against.
• A feature is the right choice when the context powers a single solution, for one team, with nothing else expected to resolve against it, or when the work is a proof of concept. Its reach ends at its host platform's boundary, where it answers from the portion it can see with no warning that the picture is partial.
• A platform pays its machinery cost up front and must earn adoption rather than inherit it; built once, the tenth context is largely configuration. The crossover point is organization-specific.
• The consumer of context is shifting from a person, who compensates for a partial answer, to an agent, which cannot and is asked to act on the result.
• Take the ten questions you most want an agent to answer and test each for single-platform reach, repeatability next quarter, and a traceable explanation. The number that passes tells you what to build.

A question I increasingly get asked is: we know we need a context layer, but should we expect this to be a feature built in an existing solution, or should we consider this as a platform in its own right?

Nobody argues about whether a context layer is needed anymore. That discussion is over. Agents that hallucinate, that take too long and then fail to provide an answer, that keep giving different answers to the same question, or that can only work on small sets of data are demos. Everyone has now seen enough demos.

The disagreement is about where context lives. One camp says inside the tools you already run: a semantic model in the warehouse, a metrics layer in the BI tool. The other says it is its own layer, with its own lifecycle, that many tools and agents resolve against.

Let me say up front that I have a strong opinion on this topic based on more than two decades building technology in this space. I have been part of projects that were spectacular failures, great successes and everything in between. From these battle scars, I believe I have a good sense of what works and what the right questions to ask are when it comes to context layers.

So I set out both answers to each question below and leave you to weigh them. Several have a genuinely strong feature-based answer, and I say so where they do.

Start with what you are actually trying to build

Almost every organization asking this question wants the same two things: people who can ask questions of their data in plain language, and agents that can act on the answers. Being precise about what that requires matters, because for several of the questions below the answer differs for an agent and for an analyst.

Talking to data reliably requires five things:

• Breadth. Reaching every system that holds an authoritative fact about the entity
• Consistency. The same question resolving the same way twice
• A stable contract. An interface that does not change shape between releases
• Predictable latency under concurrency. Thousands of questions at once rather than twelve
• Explainability. A traceable account of which definition and sources produced an answer

A person compensates for the absence of most of these. They notice that a number looks wrong, or remember that a field changed meaning after a migration, and go and ask someone. Human judgment has been the error-correction layer in every analytics stack we have built, which is why weak context has been survivable for twenty years.

An agent has no such faculty. It answers confidently from whatever it can reach, without telling you the picture was partial, and is then asked to act on the result. That shift in consumer is why this question is now urgent rather than academic.

What are we actually choosing between?

Context as a feature is context that is built and maintained as a capability within a platform such as Snowflake, Databricks or Microsoft Fabric. Many platforms are indeed working on building such a feature. These contexts are governed by the permissions of those platforms, built and consumed by its users, and data is accessible only within its specific purview.

A context platform is an independently addressable layer with its own lifecycle. It sits on top of existing platforms and provides one data model over all your data, and ensures consistency across teams. It is a data plane that anything can query, with a clear opinion of versioning, owners, governance, and a data access policy.

Here is what both have in common, and it matters: neither invents data. Both stand on storage you already own. There is always a lake underneath; the argument is about how much of it the context can see. A feature lives inside a specific lake and is bounded by what is accessible within that lake. A platform sits above them, bounded only by what you connect.

The question that comes before the others

First establish whether you are building something durable. If the context you need powers a single solution, for one team, with nothing else expected to resolve against it, a feature is appropriate and the rest of this analysis does not apply. The same holds for a proof of concept, which is one of the least expensive ways to learn what your context actually needs to be.

The failure I see most often is choosing correctly and then not honoring the choice. A proof of concept that quietly becomes production is how organizations end up with partial implementations that were never designed to work together, and agents that answer differently depending on which one they reach. Two disciplines prevent it: record that the work is disposable where your sponsor will see it, and set a date for its removal.

Ten questions, and both answers to each

The three sections below group these questions; the full version works through all ten.

Demand: who consumes it, and how far must it reach

The feature case, and its cost. Consumers are already in the tool, so there is no new interface to adopt and permissions are already provisioned and audited. Adoption is the most common reason context work fails, and a feature starts with it solved; colocation with compute adds query pushdown, no data movement and a single security model. Where an agent's work stays inside one platform's data, that is sufficient. What it gives up is reach. A feature's reach ends where its host platform's reach ends, and it does not fail cleanly at that boundary: asked about an entity spanning three systems, it answers from the portion it can see with no indication that the picture was partial.

The platform case, and its cost. A platform is built as an interface: versioned, testable against consumer contracts, queryable by anything with credentials, and extended rather than duplicated when a source is added. Against that, it adds a hop and a second security model to reconcile with the ones you already run, federated query performance across heterogeneous stores is genuinely difficult, and latency under concurrency, precisely what agents stress, is harder to predict than inside a single engine. Adoption must also be earned rather than inherited.

Economics: what it costs to build, to repeat, and to own

The feature case, and its cost. First value arrives in weeks rather than quarters, and momentum is how data initiatives survive funding cycles. A feature spends only on what was required and inherits upgrades, disaster recovery, an on-call rotation, and certifications your auditors have already accepted. What it gives up is that marginal cost declines slowly, since what carries between use cases is the team's learning rather than reusable machinery. Change absorption grows with each context, and reconciliation, establishing why two contexts disagree and which is correct, appears in no business case and eventually dominates. It also arrives sooner than it used to, because agents surface the disagreement immediately and in front of the business.

The platform case, and its cost. The expensive part is machinery: generating a model from sources you already have, mapping it, resolving entities across systems, testing that it holds when a schema shifts, and versioning what changes. Built once, the tenth context is largely configuration. Against that, the cost is front-loaded and incurred before any return, the crossover point is uncertain when you must decide, and if the machinery proves not to be general you pay the up-front cost without the amortization. You also own a runtime, and therefore a funded team.

This is also where I would hold a platform to account. One that cannot deliver a business-visible use case within eight to twelve weeks is being mismanaged rather than misconceived. The shape that works is one entity, resolved across two real sources, answering a question a named person cares about.

Control: consistency, change, and explanation

Consistency and explainability were negotiable when a person read the answer. They are not when software acts on it.

The feature case, and its cost. Domain autonomy is a genuine virtue, and the history favors it: a generation of master data management programs set out to define the customer and consumed years producing models so negotiated they described nobody's actual business. Change has a small blast radius, and nothing new has to be certified. What it gives up is that overlaps get discovered rather than managed, and are then settled in meetings with no record of the outcome. An agent asking how many customers there are gets a different answer depending on which context it reaches, and cannot say which definition it used. Context also goes stale silently, and explaining an answer means reconstructing it in every platform involved.

The platform case, and its cost. Governance is the stronger of two gains. A single point of control means one place to set policy, and one lineage graph and version history to consult when someone asks why an agent answered as it did. The other gain is consistency: one definition, resolved centrally, so the same question returns the same answer. Neither requires a canonical enterprise model. The machinery is shared, the modeling stays with the domains, and where two domains genuinely disagree the platform records both definitions and the relationship between them. The costs sit elsewhere: that point of control must be built and certified rather than inherited, change discipline becomes mandatory because a bad change now reaches every agent at once, and making definitional conflict visible means somebody has to arbitrate it.

Where the analysis leads me

A feature is the right decision in a narrower set of circumstances than it is currently chosen for, and outside them what makes it inexpensive for the first use case is what makes it expensive by the seventh.

But the consideration that settles it for me is the one I opened with. The consumer of context is shifting from a person who could compensate for a partial answer to software that cannot, and that will be asked to act on what it is told. Breadth, consistency, a stable contract and a traceable explanation are what make an agent trustworthy, and all four are properties of an interface rather than of a model embedded in one tool. Where an agent's work stays inside a single platform's data, a feature provides all four. Where it does not, no feature can, and the shortfall surfaces as a confident answer drawn from part of the picture, with no error raised.

So take the ten questions you most want an agent to answer, and for each ask three things: can it be answered from data inside a single platform, will it return the same answer next quarter, and can you show which definition and which sources produced it? The number that passes all three tells you what you need to build.

I would be interested to hear where others have landed, particularly from anyone who took the feature path deliberately and would choose it again.

The full version, which works through each question in detail, is here.