Context Layer: Feature or Platform? - Extended Version

A condensed version of this argument is here. This is the long form, which works through each question in detail.

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 for a one-off, for a proof of concept, or where one platform can genuinely see every store that matters and your agents work inside it. Record the choice where your sponsor will see it, and re-run it every six months, because the conditions expire quietly.
• A platform pays for machinery up front and must earn adoption rather than inherit it; if the machinery proves general, the tenth context is largely configuration, and the crossover point is organization-specific. One that cannot ship a business-visible use case in its first eight to twelve weeks is being mismanaged.
• 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. Test whether each can be answered from a single platform and will return the same answer next quarter, and whether you can show which definition and sources produced it. The count 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.

I also think an argument that only convinces people who already agree with me is not worth writing. So for each question below I set out the feature-based answer and the platform-based answer, and for each of those I set out where it is strong and where it costs you. Several of these questions 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. That is the requirement behind the context layer, and being precise about it changes how the rest of the analysis reads, because for several of the questions below, the answer is different for an agent than it would have been for an analyst.

Talking to data reliably requires five things:

• Breadth. Reaching every system that holds an authoritative fact about the entity in question
• 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 which 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, and why so many organizations have concluded that their context problem was tolerable.

An agent has no such faculty. It answers confidently from whatever it can reach, without telling you the picture was partial, and it is then asked to act on the result. The error-correction layer is gone, and the requirements above stop being desirable properties and become preconditions. That shift in consumer is why this architectural question has become urgent rather than academic, and it is the thread running through everything below.

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.

Two things a context platform is not, because these are the reasons half the room stops listening. It is not a new copy of your data: if it requires you to move every row into a new store, it is a warehouse with extra steps, and a context layer should resolve against sources and point back to them. And it is not one canonical model of the enterprise. That second point is where most of the scar tissue in this industry sits, and I return to it under question 9.

The question that comes before the others

Before working through the comparison, 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 the appropriate choice and the rest of this analysis does not apply. You would spend three quarters on infrastructure to serve one dashboard, and you would deserve the reaction you got.

The same holds for a proof of concept. Building context as a feature is one of the least expensive ways to learn what your context actually needs to be. You will discover that your product hierarchy has four exceptions nobody documented and that two departments define an active customer differently. Your most authoritative source for one entity will turn out to be a spreadsheet. That learning is worth having before you commit to anything larger.

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 several partial implementations that were never designed to work together, and agents that answer differently depending on which one they happen to reach. Nobody decides to build that estate; it accretes one reasonable decision at a time, because the thing that was meant to be discarded turned out to be load-bearing and nobody wanted to say so. Two disciplines prevent it: record explicitly that the work is disposable, in a place your sponsor will see, and set a date for its removal or replacement.

Ten questions, and both answers to each

Question 1 is the gate above. The remaining nine are grouped below into demand, economics and control.

Part I: Demand

Who consumes this, and how far does it have to reach?

2. Who and what will resolve against it?

The feature-based answer. Consumers are already inside the tool. Context defined there needs no new interface, no additional login and no migration, and it inherits permissions that are already provisioned and already audited. Adoption is the single most common reason context work fails to deliver, and a feature begins with that problem solved. Latency is also predictable, because there is one engine and one plan. Where the agents you intend to build operate inside that platform and on that platform's data, a feature supplies breadth, consistency and latency perfectly adequately.

Where it costs you: a tool's internal model is not designed as an integration surface. An agent needs an addressable endpoint, a contract that remains stable across releases, deterministic resolution, and predictable latency when a fleet of agents is asking rather than one analyst. A semantic model reached through a BI tool's reporting API is not a versioned contract, and it was never intended to be one. If your agents will run outside that platform, and most agent frameworks do, they either cannot reach the context at all, or they reach it through a bespoke shim that you now own, maintain and version yourself.

The platform-based answer. A platform is built as that interface from the outset. It can be versioned, tested against consumer contracts, and queried by anything holding credentials, which means one endpoint serves analysts, applications and agents without a translation layer for each. Adding a new class of consumer is a permissions question rather than an integration project.

Where it costs you: adoption has to be earned rather than inherited. An analyst who is already productive in their BI tool has no particular reason to move, so you may run two paths to the same answer for years, which is exactly the inconsistency the layer was meant to remove. A new endpoint also brings its own authentication, rate limiting and quota management, and somebody has to own the client libraries and keep them current.

3. How many stores must it reach across?

The feature-based answer. Context wants to live next to compute, and this is a sound engineering argument rather than a marketing one. You get query pushdown, no data movement, no additional network hop, one security model and no cache to invalidate. Every hop you add is latency you will be asked to explain and a boundary at which governance can leak. Where the estate genuinely sits inside one platform, this argument is close to decisive. And if your organization is deliberately consolidating storage, a feature aligns with the direction of travel rather than building a layer to span an estate you are actively trying to eliminate.

Where it costs you: reach ends where the host platform's reach ends, and it does not fail cleanly at that boundary, which is the part that matters. Asked about an entity assembled from the warehouse, an operational store and a third-party system, it answers from the portion it can see, with no indication that the picture was partial. When a person reads that answer it is an annoyance. When an agent acts on it, it is a defect. Every additional store also means another implementation, another set of definitions and another seam to reconcile.

There is a test I like here, and it takes fifteen minutes. Draw your estate on a whiteboard: every store that holds an authoritative fact about your top five entities. Then ask which single platform can see all of it. Usually the answer is none, and organizations are one acquisition away from the answer being none even when it is currently yes.

The platform-based answer. Reach becomes a configuration question. Connect a source and the layer extends; entities resolve across systems while sensitive data can stay exactly where it is. Acquisitions, business units with their own tooling and jurisdictional constraints all become additions rather than rewrites.

Where it costs you: federated query performance across heterogeneous stores is genuinely difficult, and both cost and latency are harder to predict than they are inside a single engine, which is precisely the property that a fleet of agents will stress. Connectors need maintaining as source schemas move, and that is ongoing work rather than a one-time build. You also now have a second security model to reconcile with the ones you already run, and reconciling two models is harder than inheriting one.

Part II: Economics

What does it cost to build, to repeat, and to own?

4. Is the tenth context cheaper than the first?

Two ideas get conflated here and are worth separating. Reuse means one context serving many consumers: marketing, finance and an agent all resolving customer against the same definition. Repeatability means many contexts built on the same machinery: is the tenth ontology cheaper to stand up than the first?

The feature-based answer. Each context is purpose-built and fits its use case exactly. There is no lowest-common-denominator compromise, and no negotiation with five other teams about what a shipment is before anybody can ship anything. Every generalization is a bet on a future requirement, and speculative generality has a worse record in this industry than almost any other habit. Ten purpose-built contexts may genuinely serve ten use cases better than one generalized model would.

Where it costs you: there is no shared machinery, so what carries forward from one engagement to the next is mostly the team's own learning rather than tooling. The tenth context resembles the ninth: the same discovery interviews and hand mapping, and the same argument about definitions, from scratch. And the ten contexts are not independent. They overlap on exactly the entities that matter most, which means the compromise you avoided by building separately does not disappear; it reappears wherever two use cases have to agree, and it gets settled there by whoever is in the room, undocumented, repeatedly. Unfortunately, going the feature route usually means you will lose out both on reuse and repeatability. And that is very costly.

The platform-based answer. Repeatability is machinery: how you generate a model from sources you already have, how you map it, how you resolve entities across systems, how you test that it still holds when a schema shifts, and how you deploy and version what changes. Reusability is built in to the platform approach: define it once, use it everywhere. Build your contexts reusing as much as possible and the tenth context is largely configuration.

Where it costs you: the machinery has to actually be general. If it was built around the first two use cases and hardened there, the eighth will fight it, and you will have paid the up-front cost without earning the amortization. Generalizing too early is a real failure mode, and the honest version of this argument is that a platform's economics depend on the machinery being good, which is not guaranteed by choosing the architecture. Reusability does come with the cost of managing, curating and ensuring the models are truly general and reusable. There is no such thing as a free lunch here.

5. How quickly does it deliver first value?

This is the strongest argument the feature-based answer has, and it deserves to be made at full strength.

The feature-based answer. A feature ships in weeks. You add a model to a platform you already run, describe tables you already have, and something works by the end of the month. Momentum is the mechanism by which data initiatives survive. A team that shows a working answer in week three secures its next round of funding and its next round of goodwill. A team that spends three quarters on infrastructure with nothing queryable has usually lost the room, and frequently gets cancelled at exactly the moment it was about to start paying off. I have watched genuinely well-designed platform efforts end this way. The architecture was right and it made no difference.

Where it costs you: speed can encode a definition that finance or risk will not accept, and unwinding that once people depend on it is harder than building it was. Fast to wrong is still wrong, and the faster you shipped, the more consumers are attached to the wrong answer by the time anyone notices.

The platform-based answer. Once the machinery exists, subsequent delivery is fast, and the definitional rigor a platform forces up front is work you would otherwise do later, under pressure, with production consumers attached.

Where it costs you: the lead time before anything is queryable is real, and “we are building the foundation” is the most common cover for a platform team that has produced nothing. So let me state the obligation plainly: a platform that cannot deliver a real, business-visible use case within its first eight to twelve weeks is being mismanaged rather than misconceived. The shape that works is a thin vertical slice: one entity, resolved across two real sources, answering one question a named person actually cares about, running on the machinery that will carry everything after it. The second use case, on the same machinery and in a fraction of the time, is where the economic argument becomes visible rather than theoretical. If a vendor or an internal team cannot describe that first slice concretely, the objection about time to value is correct and should be pressed hard.

6. How does marginal cost behave?

The feature-based answer. You pay only for what was actually required. Nothing sits half-used, no capability was built for a use case that never arrived, and every cost traces to something somebody asked for. In an environment where data budgets are under real scrutiny, that traceability has value beyond the arithmetic.

Where it costs you: marginal cost declines slowly, because what you reused was learning rather than machinery. Two costs then accumulate quietly. Change absorption grows with each context, since a source schema change touches every context that referenced it. Reconciliation, establishing why two contexts disagree and deciding which is correct, appears in no business case and eventually dominates. With agents in the picture, reconciliation also arrives sooner and more publicly, because the disagreement surfaces in front of the business the first time two agents answer the same question differently, rather than in a quarterly reporting cycle.

The platform-based answer. The curve is front-loaded and then flattens, because the expensive part was the machinery and change is absorbed once at the layer rather than in every context that touched the source.

Where it costs you: the crossover point is uncertain at the moment you have to decide, and if your portfolio never reaches it, you have overspent. Look at the shape rather than the numbers, and measure the crossover against your own roadmap rather than assuming it.

7. Who owns and maintains it in year three?

The feature-based answer. This is the most underrated argument on the feature side. Context built inside a platform you already run inherits a great deal of unglamorous work: upgrades, patching, backups, disaster recovery, an SLA, an on-call rotation that already exists, and the certifications your auditors have already accepted. Somebody else's product team maintains the runtime, and there is no new headcount line to defend every planning cycle.

Where it costs you: individually, features are easy to maintain. The problem is that nobody is assigned to maintain them, because a feature does not look like a system. A semantic model with sixty measures is a system: it has dependencies, drift, and consumers who will notice when it breaks. But it lives inside somebody else's tool, it never got an owner, and the analyst who built it changed teams eighteen months ago. Nobody can tell you what depends on it, so nobody can safely change it, so it slowly becomes wrong while continuing to answer questions. An orphaned platform is at least visible; somebody notices the bill. An orphaned feature keeps working just well enough that nobody looks.

The platform-based answer. Ownership is explicit, which is uncomfortable and correct. There is a named owner, a funded team, a version history and a deprecation policy. You know who to call, and you can enumerate what depends on a definition before you change it.

Where it costs you: you own the runtime, which means upgrades, disaster recovery and on-call, plus a headcount line that has to be justified annually. Key-person risk also concentrates: a small platform team holds a disproportionate amount of the organization's knowledge about what its data means.

Part III: Control

Consistency, change, and explanation.

Consistency and explainability were negotiable when a person read the answer. They are not when software acts on it. This is where the shift in consumer bites hardest.

8. Will the same question return the same answer twice?

The feature-based answer. Within a single context, yes. Resolution is deterministic and inspectable, the model is small enough to reason about, and a person reading the output can sanity-check it against what they know.

Where it costs you: across several contexts, not necessarily, and nothing in the architecture reveals the divergence. An agent asking how many customers there are gets a different answer depending on which context it reaches, and it cannot report which definition it used. Context also goes stale silently. A model built in March still answers confidently in September, after a migration has repurposed two fields and a subsidiary has been consolidated. Staleness fails quietly: it becomes wrong while continuing to look correct, which is the failure mode hardest to catch and most damaging when an agent is acting on the result.

The platform-based answer. One definition, resolved centrally, so consistency is a property of the architecture rather than of anyone's discipline. Resolving at query time also means the agent reads the current state of sources rather than the state they were in when the model was written, and each resolution leaves a record.

Where it costs you: a layer that everything resolves against is a layer where one bad change reaches every agent at once. Versioning, contract testing and staged rollout become requirements rather than refinements, and you need to be able to say which consumers a proposed change would break before you make it. If a platform cannot answer that question, this objection stands.

9. How are overlapping definitions handled?

This is the objection I take most seriously, and if you have been in this industry a while it is probably the one already forming as you read.

The feature-based answer. Domain autonomy is a genuine virtue, and the history favors it. A generation of master data management programs set out to define the customer, product and material, and many consumed years and very large budgets producing models so negotiated that they described nobody's actual business. The pattern is well understood: centralized modeling cannot keep pace with decentralized change, the model becomes a bottleneck, the business routes around it, and the model becomes an expensive document. Letting the team that owns the data own its meaning is the lesson drawn from that experience, and it is pattern recognition rather than cynicism, drawn from something that genuinely burned people.

Where it costs you: overlaps get discovered rather than managed. Definitions that ought to agree get settled ad hoc, in a meeting, with no mechanism for recording the outcome, so the same disagreement recurs every time two use cases meet. In practice the worst overlaps sit precisely on storage boundaries: the same customer in the CRM store and the billing store, with no shared key and two different answers to when they became a customer.

The platform-based answer. The distinction that resolves the objection is that a platform should be shared machinery rather than a shared schema. What belongs in the center is the machinery: generation, mapping, entity resolution, versioning, lineage and policy. What stays with the domains is the modeling itself. Claims owns what a claim is; finance owns what recognized revenue is; neither has to negotiate with the other to move. And where domains genuinely overlap, the objective is to make the overlap explicit and resolvable: record both definitions, trace each to its sources, and state the relationship between them. A schema requires agreement before it can be used. A model expressed as a graph can hold a disagreement precisely, describe it, and let the query select the definition it needs. Master data management failed because of what it centralized: the model instead of the machinery, with agreement demanded as a precondition for delivery.

Where it costs you: if a platform is implemented as a canonical enterprise model, it repeats that failure, and then the objection is correct. The test is simple and worth applying to any vendor, mine included: does this require my domains to agree on one definition before anything ships? If the answer is yes, walk away. Separately, making conflict visible means somebody has to arbitrate it. That is better work than leaving it buried, but it is work, it needs a named owner, and it appears on a plan where the feature-based version of the same problem never did.

10. How is an agent's answer explained afterwards?

The feature-based answer. Permissions, audit logging and compliance approvals already exist in the host platform and have already been through review. If explaining an answer largely means showing who was entitled to see what, a feature starts from a strong position, and reproducing that on a new layer is a large and thankless project.

Where it costs you: explaining why an agent produced a particular answer is a different question from access control. It requires showing which entities were involved, which definition was applied, which sources were resolved, who approved that definition, and what all of that looked like on the date in question. Across several tool-local contexts that is one reconstruction per platform involved, plus a reconciliation, repeated every time anyone asks. Semantics encoded in a vendor's model is also not portable: you can export the tables, but you cannot export the meaning, which quietly turns your accumulated business logic into a switching cost.

The platform-based answer. A single point of control means one place to set policy, and one lineage graph and version history to consult. I think this is the strongest single argument on the list. Asking why an agent answered as it did becomes a query against a governed layer rather than a coordinated investigation across systems, and the answer is reproducible for a date in the past rather than reconstructed from memory.

Where it costs you: that point of control has to be built and certified rather than inherited. The host platform's existing approvals do not transfer to a new layer, and that is real elapsed time before anything is production-ready in a regulated environment. It also concentrates access to the meaning of data across your whole estate into one system, which makes it a high-value target and something your security team will rightly want to examine closely.

When a feature is genuinely the right answer

I said I would not rig this, so here is the honest list. Build the feature if:

• It is a one-off, and you will record that in writing.
• It is a proof of concept, with a date set for its removal.
• One platform can see every store that matters for the entities in scope, today and plausibly in three years.
• You are consolidating storage onto a single platform, you will finish inside a year, and you have the air cover to hold that line.
• Your consumers are people, and agents operating inside that platform, and cross-estate agents are not on the roadmap.
• You need something in four weeks and the cost of being wrong is low.
• You can name the person who owns it in year three.

That is not a narrow list, and a meaningful number of organizations sit inside it. If you do, a platform is an expensive answer to a question you do not have.

What I would ask is that you re-run the list every six months, because the conditions expire quietly. The second use case, the first agent operating outside the platform, or the first acquisition moves you into a different column, and the cost of noticing late is everything described under questions 6 and 9.

Where the analysis leads me

Context built as a feature is a good decision roughly once: for the first use case, or for the proof of concept that teaches you what your context actually needs to be. It is a poor default, because the properties that make it inexpensive at use case one are the same properties that make it expensive by use case seven: bounded to one platform, frequently unowned, invisible to reconciliation, and difficult to change safely.

A platform costs more up front and that cost is real. It amortizes only if two things hold: the machinery is genuinely reusable, and something of value ships within the first two months. Where either fails, the argument for a platform is theoretical and the feature-based answer is the better one for you specifically.

But the consideration that settles it for me is the one I opened with. For twenty years the consumer of context was a person who could compensate for a partial or inconsistent answer, and that compensation is why weak context was survivable. From here the consumer is increasingly software that cannot compensate, 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 inside one tool. Where an agent's work stays within 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 the exercise I would suggest to any team making this decision is a concrete one. Take the ten questions you most want an agent to answer for your business, 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? Count how many pass all three. That count, rather than an architectural preference, tells you what you need to build.

The follow-on question is how you make models and knowledge graphs inexpensive enough to generate and maintain that the platform curve starts low enough to matter in the first place. That is the argument that decides much of the above, and it is a topic for another post.

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

Sofus Macskassy is a co-founder of zaimler, the runtime context layer for AI agents.

A condensed version of this argument is here.