There’s an argument to be made that we’re making a fundamental architectural mistake with enterprise AI agents. In our rush to make large language models useful within the enterprise, we’re repeating the same missteps of the early web by treating the problem as a retrieval task based on curated taxonomies. Organizations are effectively trying to build a 1994 Yahoo! for the enterprise, when what we actually need is an organic, link-driven architecture that mirrors how humans actually move data and intent.
The current consensus in enterprise architecture leans toward building a beautifully structured, intentional semantic layer or an enterprise-wide knowledge graph to guide our agents. This is a nice idea in theory but really a beautiful illusion. In reality, the enterprise is a messy, sprawling and stale ecosystem of Jira tickets, half-abandoned Confluence pages and decaying legacy systems. Frustrating, but almost impossible to change. Forcing an intentional schema onto this chaos is unsustainable and an anti-pattern for agentic autonomy.
The layered context model: Separating the map from territory
To build an infrastructure where autonomous agents can actually deliver value without collapsing under the weight of context window saturation, we need to separate context into distinct layers. The most successful implementations don’t attempt to feed raw data into an LLM's context window; instead, they follow a tripartite approach:
The metadata layer (the discovery plane). This is the lightweight map. It defines data products, system boundaries, schemas and API locations. It tells the agent where things live and what they mean structurally, rather than what the data itself contains.
The common reference layer. These are your universal primitives; they include things like currency codes, country codes, system records and core entities. These are pushed or made explicitly available as well-known static entities to save an AI agent from continuous exploration.
The unstructured and transactional data layer. These are petabytes of data that capture operational reality. This layer is never consumed before being organized and structured; it’s strictly pulled when needed through targeted sub-queries.
The key decision point: Push vs. pull autonomy
Pushing massive amounts of reference data into an agent's context window upfront wastes tokens and primes the model with noise. This is why architectures need to pivot toward a strict pull model, which treats the AI agent as a goal-seeking entity equipped with a map and the API tools to traverse it dynamically.
The fallacy of the monolithic graph
A common trap for organizations is attempting to build a singular and comprehensive enterprise-wide knowledge graph. This is a recipe for engineering failure. Just as domain-driven design (DDD) taught us that a single unified data model across a company is impossible, agentic context must be carved along clear boundaries.
The enterprise should be divided into self-contained, federated sub-graphs. For instance, Salesforce might own opportunities and accounts, an ERP might own the inventory, while a custom system owns product logic. The agent should then navigate between these distinct sub-graphs using a decentralized, web-like architecture. By presenting agents with a federated index rather than a centralized data lake, individual domains can govern their own schemas, freshness and credibility.
Don't build the map; build the harness
If subject matter experts are required to manually map every link and relationship within a knowledge graph, the graph will unfortunately be dead on arrival. The rate of data decay inside an enterprise far outpaces human curation; documentation is almost always an inaccurate reflection of operational reality.
The breakthrough lies in moving away from intentional structuring and embracing unintentional signals. Every day, humans leave a digital trail of relationships: an email links to a sales opportunity; a Slack thread references a specific GitHub commit; a Google Doc cites a legacy database table. Agents are now sophisticated enough to harvest these passive telemetry signals.
Instead of building the map, engineers need to build the harness. This is the infrastructure that observes human and system behavior, clusters the linkages and dynamically derives the semantic graph.
Storing reason: The next data frontier
The next significant shift in data strategy may not be around how past data is indexed, but instead how we index our agents' future actions.
When an agent executes a multi-turn task, it makes decisions, executes tool calls and encounters errors. If these reasoning traces are thrown away, the agent is doomed to repeat itself. That’s why reasoning traces need to be treated as first-class data citizens.
By storing agentic traces as graph-shaped or skill-shaped historical projections, network algorithms can be run to optimize workflows:
Trace compression. Identifying independent tool calls within a trace and collapsing multi-turn invocations into a single batch step, cutting token costs and latency.
Algorithmic pruning. Automatically isolating and discarding reasoning paths that led to dead ends or failed executions.
The risk of hallucinatory drift
As web-like graph algorithms (such as PageRank or neighborhooding) are applied to enterprise context, there's a risk of introducing inadvertent enterprise SEO. To put it another way, if incorrect assumptions, a stale design document or a hallucinated metric is cross-referenced or repeated multiple times across disparate systems (e.g., across emails, Slack messages and old Confluence pages), graph ranking algorithms will naturally weight that node as highly credible.
Semantic pollution
Unlike the public web, where volume often correlates with relevance, enterprise data volume often correlates with bureaucracy. Relying purely on link-weight algorithms risks elevating institutional noise over empirical ground truth.
To combat this, our graph algorithms must incorporate strict temporal decay metrics and provenance scoring. A node's authority must be heavily penalized by its age and validated against hard transactional boundaries, rather than just its citation count.
Replicating tasks vs. seeking goals
The ultimate goal of enterprise AI isn't to automate existing processes; it's to make them obsolete.
Many current software engineering initiatives fail because they attempt to force agents into mimicking human workflows. These are invariably workflows that were originally designed precisely because humans are inconsistent and inefficient. Humans need rigid check-gates, multi-layered approvals and hand-offs.
Agents, however, need to be understood as goal-seeking entities. If we provide them with a high-fidelity map of our metadata, a clear set of operational boundaries and a measurable target, they will find paths toward that goal that a human process would never have conceived.
Too many data strategies try to teach agents how to follow an old handbook. What's needed is to open up the federated semantic layer and provide this new technology provide the necessary infrastructure to create a more efficient path forward.