Source: Elastic Blog — https://www.elastic.co/blog/5-data-tech-stack-gaps-stalling-ai-agents
AI agents do not fail only because the model is weak. They often fail because the enterprise stack around the model cannot supply clean data, current context, safe tools, usable integrations, or enough monitoring to tell when the agent has gone wrong.
Elastic’s post frames this as five gaps blocking agentic AI: data accessibility and quality, context engineering, legacy integration, AI performance monitoring, and governance. The useful part is not the vendor framing. It is the sequence. Before an agent can act safely, it needs a system that can tell it what is true, what it is allowed to do, where to act, and how failure will be detected.
That is a harder problem than adding a chatbot to a workflow.
The stack around the agent is now the real constraint#
The shift from AI assistants to AI agents changes the infrastructure burden. A suggestion engine can be wrong and still leave the final decision to a person. An agent that acts on behalf of a user needs stronger assumptions. It needs reliable data. It needs current context. It needs defined tools. It needs guardrails. It needs observability after deployment.
Elastic’s example is small but telling. The company says a laptop refresh automation effort exposed the need for more precise data before the agent could be rolled out more widely. The response was not “use a better prompt.” It was to build an asset management system that could provide a more structured foundation.
That is the pattern many teams will hit. Agent projects surface old data debt quickly because the agent depends on the record being accurate enough to act. A stale owner field, a missing asset state, a duplicated identity, or a vague policy document can move from “annoying backlog item” to “automation blocker.”
The lesson is blunt: if the system of record is not trusted by humans, an autonomous agent will not magically make it trustworthy.
Gap 1: agents need accessible, governed data#
Elastic’s first gap is data accessibility and quality. This is the least fashionable part of AI infrastructure and probably the most decisive one.
Agents need data that is accurate, reachable, current, and governed. If the relevant information is scattered across dozens of systems with inconsistent schemas and uneven quality, the agent will either miss the right context or produce confident nonsense. The source uses the word hallucinate here, but in enterprise settings the failure can be more mundane: the agent retrieves the wrong record, acts on a stale status, or cannot reconcile conflicting sources.
Elastic recommends a unified data access layer, real-time pipelines instead of slow batch processes where freshness matters, automated data quality monitoring, and semantic search so agents can retrieve concepts rather than only exact keyword matches.
The practical judgment: teams should not treat “connect all the data” as a single milestone. The useful question is narrower. Which decisions will the agent make, which fields determine those decisions, and which source is authoritative for each field? Without that mapping, a unified access layer can become a faster route to messy data rather than a cleaner foundation.
Gap 2: context engineering is not prompt decoration#
Elastic’s second gap is context engineering. The core point is sound: an LLM’s useful output depends heavily on the external information and tools supplied at inference time. The model’s training data is not enough for live enterprise work.
This is where retrieval-augmented generation, memory design, tool selection, and ranking matter. RAG lets a system retrieve internal documents, records, or public sources just in time. Memory controls what survives across a single conversation and what persists longer. Tool selection limits which actions the agent can attempt. Ranking and rescoring help decide which retrieved material deserves priority.
The failure mode is not only a bad answer. Elastic notes risks such as hallucination, wrong tool selection, drift from the original objective, and “context poisoning,” where earlier errors compound across later interactions.
That deserves attention. Many agent demos look clean because the context window is small, the tools are few, and the test path is friendly. Real enterprise environments are the opposite. Policies conflict. Similar documents exist in several versions. Tools overlap. Permissions vary by user and region. If the retrieval layer cannot separate relevant from merely similar, the agent may sound reasonable while following the wrong source.
A useful control is to minimize the available toolset for a given task. More tools can mean more capability, but also more confusion. An agent with twenty possible actions may be less reliable than one with three well-scoped actions and strong retrieval.
Gap 3: legacy systems decide how much autonomy is real#
The third gap is legacy integration. Agents need to retrieve context from existing systems and, if authorized, take action inside them. Old systems without clean interfaces make both tasks harder.
This is where agent strategy collides with enterprise architecture. A company can buy isolated AI features inside SaaS products, but those features may not see enough cross-system context. Or it can build custom agents, but then it inherits the full integration problem. Neither path is free.
Elastic argues for a durable architecture that connects distributed source systems and SaaS applications, while still recognizing that SaaS tools remain useful as systems of record, workflow engines, and domain-specific applications.
The important distinction is between UI automation and real integration. An agent that clicks through screens can be impressive in a demo, but it is brittle as a control plane. For durable use, the agent needs stable APIs, event flows, permission boundaries, audit trails, and clear ownership of write operations. Otherwise the “agent” becomes another fragile layer sitting on top of already fragile systems.
Gap 4: monitoring has to cover agent behavior, not just uptime#
Elastic’s fourth gap is inadequate AI performance monitoring. The source material emphasizes that agents need monitoring beyond conventional application health.
That is correct. A normal service monitor can tell you latency, error rates, CPU load, and availability. It will not automatically tell you whether an agent selected the wrong tool, retrieved irrelevant context, escalated a task incorrectly, or produced an answer that appears fluent but violates internal policy.
Agent monitoring needs task-level signals. What did the user ask? What context was retrieved? Which tool was selected? What action was taken? Was the output grounded in the retrieved material? Did a human override it? Did the same class of failure repeat?
This is not just a reliability issue. It is also a trust issue. If a team cannot reconstruct why an agent acted, the organization will struggle to expand the agent’s authority. Auditability becomes part of the product, not a compliance afterthought.
Gap 5: governance is where autonomy gets bounded#
The fifth gap is missing governance and organizational structure. This is the least exciting item and one of the most important.
Autonomous systems need rules before they need scale. Which use cases are allowed? Which actions require human approval? Who owns the agent’s failures? How are permissions inherited from the user? Which data can be retrieved? Which systems can be written to? When does a model response become an official business action?
Without answers, agent adoption becomes a patchwork of experiments. Some will be useful. Some will be risky. Most will be hard to measure.
Governance should not mean freezing every project until a committee approves perfect policy. It should mean tiering risk. A read-only research agent has a different control burden than an agent that changes customer records, approves refunds, rotates credentials, or modifies infrastructure. The level of autonomy should match the quality of data, integration, monitoring, and rollback available.
What teams should check before scaling agents#
The Elastic post is vendor-authored, so readers should separate the general architecture advice from any implied product path. The strongest point still stands: agent readiness is mostly a foundation problem.
Before expanding an agent beyond a controlled pilot, teams should check:
- Which source systems the agent depends on, and whether those systems are authoritative.
- Whether key data is fresh enough for the decisions being automated.
- How retrieved context is ranked, filtered, and traced back to source material.
- Whether the toolset is scoped to the task or overloaded with options.
- Whether legacy systems expose stable interfaces for read and write operations.
- What telemetry exists for tool choice, retrieval quality, task completion, and human override.
- Which actions require approval, logging, rollback, or prohibition.
The practical takeaway is simple. Do not measure agent maturity by the sophistication of the demo. Measure it by the weakest system the agent must trust when it acts.