The Context Layer Ends at the Front Door

Forrester analysts Boris Evelson and Indranil Bandyopadhyay have pinned down a term the industry has been using loosely. A context layer, in their definition, is "the next evolution of semantic layers and knowledge graphs, providing the foundation for neurosymbolic AI context engineering and agentic AI applications". It merges the business semantics and governance of the BI world's semantic layers with the ontological modelling of knowledge graphs, then keeps the model alive with runtime events, decisions, and outcomes.

This is useful work. When analysts settle vocabulary, buying conversations get shorter and vendors stop stretching one word over whatever they happen to sell. The substance is right too. A language model without grounding doesn't know your prices, your policies, or your product names; it produces plausible text about them. Run that across enough documents and eventually a wrong figure lands in a customer quote, and nobody can trace the number back to a source. Grounding agents in an explicit, governed model of the business is the correct response, and naming that idea clearly is a step toward building it well.

So I have no quarrel with the definition. My interest is in where it stops.

Everything in It Lives at Home

Read the definition again and notice the address of every component. The semantic layer comes from the analytics stack. The knowledge graph is built and curated by your data teams. The runtime feedback loop ingests your events, your decisions, your outcomes. The governance is embedded in your ontology, enforced by your platform, accountable to your people.

Every part of it operates inside the enterprise boundary, and all of it assumes the content it governs stays there. Ask the context layer a question from inside the building and you get a grounded, governed answer. That's exactly its job.

Your content doesn't stay inside the building.

The Moment the File Leaves

A buyer's agent fetches your spec sheet. A partner's copilot summarises your proposal PDF. A search agent reads your product page and decides whether to cite it, recommend it, or pass. An auditor's tooling parses the policy document you published last spring.

Each of these is a machine encountering your content outside the environment that produced it. The context layer that grounded the file at home isn't present at the point of reading. There's no graph to walk, no glossary to consult, no telemetry stream. The file is alone, and its reader can only work with what it declares about itself. When it declares nothing, the machine guesses, which is exactly what the context layer was built to prevent.

Machine Experience closes that gap. MX is a practice, not a product: metadata that records a file's provenance, its context, and its intended use, written so that it travels with the file. The parallel is deliberate. UX asks whether a human can understand and act on what's in front of them; MX asks the same for a machine. Inside the boundary, the context layer answers "what does this mean" on the file's behalf. Outside, the file has to answer for itself.

The Packet That Travels With the Content

In practice, answering for itself means a small, structured packet of metadata written into the content's own carrier. In a markdown file that's the frontmatter, and in a web page it's the declared block in the head. A PDF or an image carries it as an embedded XMP record, and a feed or a database as a field on the row. Same packet, whatever the carrier. It names the publisher and the date, the thing itself and what it belongs to, the audience it serves, and the reuse it permits.

Because the packet rides inside the file, it can't be left behind. The buyer's agent that fetches your spec sheet receives the provenance and the intended use in the same fetch as the content. Nothing phones home, and no lookup is needed, because the slice of context that matters at the point of reading arrived with the file.

Trust Doesn't Travel Either

There's a second thing that stays home: verification. Inside the enterprise you can trust the graph because you run it. Its governance is, as the Forrester definition has it, embedded in the model. Outside, an agent reading your file has no such comfort, and "trust me" isn't machine-readable.

Trust for a travelling file decomposes into questions a machine can actually check. Who published this, and when? Is this the current version, or a stale copy still circulating? Is the publisher still standing behind it? Does anyone authoritative independently agree? Those checks need infrastructure of their own, which is the territory of REGINALD, our registry implementation: MX makes content machine-readable, REGINALD makes it machine-trustworthy. Each is incomplete without the other. Readable but unverified is a formatted guess, and verified but unreadable is a locked box.

Complements, Not Rivals

None of this argues against building a context layer. If your agents act on enterprise data, you want them grounded, and Forrester's definition is a sound blueprint for grounding them. It's half the picture.

The other half starts at the front door. Every file you publish will eventually meet a machine you don't control, in a setting you didn't design, with your context layer nowhere in reach. What that file declares about itself, and what a reader can verify about it, is the only governance still operating at that moment.

The context layer is the brain at home. The MX packet, stamped into the content itself, is the passport. Plan for both.