Enterprise infrastructure has evolved through three distinct generations. Each subsumes the previous one rather than replacing it. A well-designed context graph anchors itself to the canonical facts of a knowledge graph and the governed definitions of a semantic layer.

Nearly every organisation with a data team attempted to deploy some form of agentic workflow in 2024 and 2025: a customer support agent, a data analyst, an internal knowledge assistant. Most of those efforts failed.

An AI agent operates through a continuous cycle: perceive the environment, reason over memory, commit an action or observation back to storage. This loop runs in milliseconds, and it never stops.

Modern data platforms are optimised for analytical throughput. They are designed to answer questions about the past at scale. Fast ingest makes data queryable quickly; it does not provide the ability to lock a record, mutate it, and guarantee that the next agent in the loop reads the updated value within the same millisecond window. That requires read-after-write transactional consistency — a property that streaming ingest architectures are not designed to deliver.

What is missing from every existing data architecture — whether a traditional warehouse, a modern lakehouse, or a distributed data mesh — is a dedicated context layer. A context layer is an active, low-latency, transactional substrate that holds the live state of an agent's understanding: what it knows right now, what it is currently doing, and how that relates to everything else in the system.

The context layer must live at the database layer, not above it, because only at the database layer can context be kept consistent, governed, secured, and transactionally unified with the canonical knowledge that grounds it.

Context enters the system through multiple channels: automated pipelines that ingest canonical data from existing warehouses and semantic layers, agent-generated observations written back during the read-think-write loop, human-curated business definitions and rules contributed by domain experts, and self-updating flows where agent corrections are incorporated back into the context graph.

A multi-model foundation supports all of these ingestion patterns natively. Canonical facts arrive as structured documents. Relationships between entities are expressed as graph edges. Semantic embeddings are stored alongside the data they describe. Because all three models exist in the same transactional system, an update to a business definition, its relationships, and its embedding can be committed atomically — eliminating the synchronisation gaps that plague fragmented architectures.

Products such as Mem0 provide a useful abstraction layer, but are built on top of the same fragmented infrastructure: a vector store for semantic retrieval, optionally a graph layer for relationship tracking, and a relational store for metadata. The abstraction hides the complexity from the developer, but it does not eliminate it. When context changes in one underlying system, synchronisation to others is not guaranteed. The semantic drift problem persists underneath the abstraction.

Memory middleware treats context as something to be retrieved and injected into a prompt. It does not treat context as a live, transactional substrate that the agent reasons within. For autonomous agents coordinating complex workflows with enterprise governance requirements, the foundation must be deeper.

A native multi-model foundation — where the database engine treats documents, graphs, and vectors as first-class citizens of the same storage layer — solves the memory problem by providing atomic context. A single “memory” is not a collection of pointers across different systems; it is a unified record.

Most enterprises have spent the last decade building Knowledge Graphs as “dictionaries of truth.” They are excellent at defining what a company knows, but they are remarkably poor at helping an agent decide what to do now.

Modern vector databases such as Pinecone, Chroma, and Weaviate now support metadata filtering, hybrid search, and namespace scoping. These are genuine improvements. However, they remain fundamentally flat: they can tell an agent that two things are semantically similar, but they cannot model the structured relationships between entities, enforce transactional consistency across updates, or traverse impact paths through a connected graph. Similarity is not context.

Consider a concrete example. An agent monitoring a production system receives an alert about a failing API endpoint. With a vector database, the agent can search for documentation semantically similar to the error message. Useful, but shallow. With a graph-capable multi-model database, the agent can traverse from the failing endpoint to the upstream service that depends on it, to the team that owns that service, to the on-call engineer currently assigned, and simultaneously retrieve the vector-embedded runbook most relevant to this specific failure mode — all in a single query.

The structural traversal and the semantic search are not two separate operations stitched together in application code; they are one atomic operation.

As AI moves from single-task assistants to Multi-Agent Systems, the architectural challenge shifts from individual memory to shared state. When multiple agents — each with specific roles like “Researcher,” “Coder,” or “Reviewer” — work together, they require a common area where the current state of a task is visible, verifiable, and actionable by all participants.

The market has recognised the context problem. Several architectures are competing to answer the question of where the context layer should live. Understanding the distinctions matters for any organisation making infrastructure decisions.

The Enterprise Semantic Foundation (ESF) is the architectural response to semantic drift. It is not a single database or a rigid schema; it is a unified, multi-model substrate that serves as the common language for the entire organisation.

In a traditional “frankenstack” — vector store + graph store + document store — enforcing security is an operational nightmare. If a user's permissions change, those changes must be propagated and synchronised across three or four different systems simultaneously. If the synchronisation lags, an AI agent might inadvertently “remember” or “reason” over sensitive data it is no longer authorised to see.

An Enterprise Semantic Foundation solves this through record-level and field-level permissions native to the database.

A production context layer cannot exist in isolation. Enterprise data lives in Snowflake, Databricks, S3, and dozens of operational systems. SurrealDB is designed to complement existing data platforms. Canonical data from warehouses and lakehouses flows into the context graph through standard ingestion pipelines. Agents query the context layer for real-time state and relationships, while analytical workloads remain on the platforms best suited for them.

This is not a rip-and-replace proposition. It is an architectural addition: a transactional, multi-model layer purpose-built for the operational requirements that analytical platforms were never designed to meet. The data platform answers “what happened.” The context layer answers “what should happen next.”