A one-million-token context window is still not an enterprise memory system.
Bigger context windows will not solve the real problem. Reliable agents need graph memory, domain ontologies and deterministic controls around probabilistic models.
AI agents look increasingly capable in demonstrations. They can plan, call tools, inspect results and continue working until they complete a task.
But the model is only one component of an agent.
Once agents move into enterprise environments, the harder problem becomes what the agent remembers, how it understands relationships and what prevents it from taking an action that is technically valid but operationally wrong.
The next phase of enterprise AI will therefore be less about building a smarter brain and more about building a reliable memory and control system around it.
Context Windows Are Not Memory
Most agent memory systems currently rely on a simple architecture.
Instructions, skills, observations and previous decisions are stored in markdown files. When the agent begins a task, some or all of those files are loaded into the model’s context window.
This is attractive because markdown is readable, portable and easy to debug. It is also sufficient for prototypes and narrowly scoped personal assistants.
But it does not scale cleanly.
As the number of memories, skills and operating instructions grows, the agent begins loading increasing amounts of repetitive text. One of the presentations described agents consuming roughly 100,000 tokens during individual rounds because they repeatedly loaded large collections of skills and memory files in the hope that something would be useful.
The problem is not merely token cost. The agent must also decide which fragments matter, which instructions remain current and which pieces of information refer to the same underlying person, system or transaction.
A larger context window lets the agent read more. It does not automatically help the agent understand how the information fits together.
Similarity Is Not Understanding
Vector databases improved this architecture.
Instead of loading everything, the system converts memories into embeddings and retrieves the text that appears semantically similar to the current request. This is the foundation of most retrieval-augmented generation systems.
But similarity is not the same as a relationship.
A vector search may retrieve documents that discuss the same server, customer or transaction. It does not necessarily understand that one server belongs to a particular network, exposes a specific port, runs a particular operating system and depends on another service that has reached end of life.
Those relationships matter when the agent is expected to perform multistep reasoning.
In the demonstration described in the second talk, the same home-lab information was placed into two memory systems. One used vector retrieval, while the other combined vector search with a knowledge graph.
When asked to identify internet-exposed systems running obsolete software, the vector system produced a generic response and recommended further investigation. The graph system identified the relevant server, operating-system version and exposure path.
A second query asked the systems to identify management ports exposed to the public internet. The graph-based system followed the relationship from the router to the connected services and returned the expected results. The vector system again provided incomplete guidance rather than a precise answer.
This was a demonstration rather than a controlled benchmark. But it illustrates an important architectural distinction.
Vectors find potentially relevant information. Graphs reconstruct the path connecting that information.
Graph Memory Gives the Agent a World Model
A graph represents information as nodes, relationships and properties.
A server can be connected to an application. The application can depend on a database. The database can run on a particular operating system. That operating system can have a support deadline, while the server may be connected to an internet-facing network segment.
The agent no longer needs to rediscover these connections from paragraphs of text during every interaction. The relationships become first-class elements of the memory system.
Vector and graph retrieval are not competing approaches. The stronger pattern is hybrid.
A vector search can locate promising starting points. The system can then traverse the graph to find connected entities, apply filters and return the small section of the graph relevant to the task.
This creates three advantages that matter in enterprise environments.
The answer becomes more precise because the retrieval process follows explicit relationships. It becomes explainable because the system can show the path that produced the answer. It also becomes auditable because the organization can preserve the facts and relationships supplied to the agent.
That is a significant shift from asking the model to explain its reasoning after the fact. The system can show the evidence path independently of the model’s narrative.
Ontologies Turn Connections Into Meaning
A graph tells the agent what is connected. An ontology tells it what those connections mean.
An ontology formally defines the entities, properties, relationships and constraints within a domain. In an enterprise, this could include customers, accounts, orders, refunds, employees, applications, servers, policies, approvals and regulatory obligations.
This is where symbolic AI returns to the architecture.
Large language models are probabilistic. They generate plausible outputs based on learned patterns. Ontologies provide a more deterministic representation of the organization’s domain.
Technologies such as RDFS and OWL can add rules and inference to the graph. A relationship can imply that an entity belongs to a particular class. Properties can be declared transitive. Certain entity classes can be defined as mutually exclusive, while other properties can be constrained to approved values.
These rules allow the system to catch mistakes that are difficult to prevent through English-language prompts alone.
An ontology could identify that a second refund is being issued against the same order. It could reject a payout directed to a support representative instead of the customer. It could prevent an agent from inventing an order status such as “probably shipped” when the permitted values are paid, shipped or refunded.
The prompt may tell the agent to behave carefully. The ontology defines what careful behavior means inside the actual business domain.
Agents Need a Control Plane
An agent is fundamentally a loop.
The model evaluates the current context, proposes an action, calls a tool, observes the result and decides what to do next. The loop gives the agent the ability to work through a problem rather than generate a single response.
It also creates risk.
Loops can drift. Agents can repeatedly call tools, consume tokens, modify systems and pass incorrect information to other agents. A small error early in the loop can become a series of increasingly confident actions.
The answer is not simply another system prompt telling the agent to avoid mistakes.
The loop needs deterministic checkpoints.
Inputs should be checked against schemas and data types before a tool is called. Tool results should be evaluated against the ontology before the next step is permitted. High-risk actions should remain free of side effects until the system has completed validation or obtained human approval.
In practical terms, the model proposes. The control plane decides whether the proposal is allowed to become an action.
The Simple Mental Model
The model proposes.
The vector store finds.
The graph connects.
The ontology interprets.
The validator decides.
The workflow acts.
The audit trail explains.
This is the architecture required when an agent moves from answering questions to operating business processes.
The Enterprise Moat Is the Domain Model
Model access will not remain a durable competitive advantage.
The same frontier models will be available to thousands of companies. Open models will continue improving, model routing will become standard infrastructure and inference will increasingly be treated as a utility.
The differentiator will be the system surrounding the model.
Organizations that formally capture their systems, policies, entities, dependencies and operating constraints will be able to deploy agents into more valuable workflows. Organizations that leave this knowledge scattered across documents, tickets, chat channels and employee experience will continue rebuilding context for every task.
This makes the knowledge graph more than a retrieval technology. It becomes an operational representation of the enterprise.
The ontology becomes more than a data model. It becomes an executable version of how the organization believes the business should work.
That is also where the real effort begins.
Building this layer requires identity resolution, data ownership, access controls, change management and continuous maintenance. An outdated graph can produce precise but outdated answers. A badly designed ontology can formalize the wrong assumptions. Automated extraction can create duplicate entities or incorrect relationships faster than humans can review them.
Graph memory does not eliminate governance. It makes governance visible.
From Prompt Engineering to Knowledge Architecture
The first wave of enterprise generative AI focused on prompts.
The next wave focused on retrieval, tools and agents. The emerging wave will focus on how knowledge, rules and execution controls are assembled around those agents.
That is a move from prompt engineering to knowledge architecture.
The most reliable enterprise agents will not be the ones given the largest context window or the longest instruction file. They will be the ones operating inside a structured representation of the business, with explicit relationships, permitted states, validation rules and escalation paths.
The model will still be probabilistic. That is useful because probabilistic systems can interpret ambiguity, generate alternatives and work across unstructured information.
But probabilistic intelligence should not be the final authority over deterministic business actions.
Enterprise AI will work when we stop asking the model to carry the entire system in its context window and start building the memory, meaning and control infrastructure it needs to operate safely.
The breakthrough will not be an agent that remembers everything.
It will be an agent that knows what matters, understands how it is connected and is prevented from acting when the facts do not add up.