April 2026 · 8 min read · Part 3 · The Agentic Enterprise
Your Data System Should Have an Opinion
The next generation of analytics doesn't wait to be asked. It monitors, detects, recommends, and acts. But agentic AI without a governed foundation is automated chaos.
Every analytics system I have ever built has the same fundamental limitation. It waits to be asked.
Someone opens a dashboard. Someone runs a query. Someone requests a report. The data sits there, organized and governed and correct, and it does nothing until a human decides to look at it. The value is gated by the curiosity and availability of the person asking.
This has been fine for twenty years. It is about to stop being fine.
The shift that is coming, and in some organizations has already started, is from analytics systems that answer questions to analytics systems that have opinions. Systems that monitor your data continuously, detect when something meaningful changes, form a judgment about what it means, and surface that judgment to the person who can act on it, without being asked.
That is what “agentic AI” means in a data context. Not chatbots on your warehouse. Not AI-generated dashboards. Systems that watch, reason, and recommend, on their own cadence, against your business logic.
And most companies are not remotely ready for it.
What an agent needs
The word “agent” gets used loosely right now. A chatbot that queries your database is not an agent. An LLM that summarizes a report is not an agent. An agent, in the sense that matters for enterprise analytics, is a system that operates autonomously within defined boundaries: it monitors a data environment, detects conditions that match predefined or learned patterns, evaluates those conditions against business context, and takes or recommends action.
That definition has four dependencies, and each one maps to a layer this series has been building.
The agent needs to know what things are. Not table names and column headers. Business entities with defined boundaries, lifecycle states, and relationships. When the agent detects that a customer’s order volume dropped 40 percent, it needs to know whether that customer is a $500K enterprise account or a free trial that converted last month. It needs to know whether the drop correlates with a support escalation, an account team change, or a seasonal pattern. That is the entity model from two posts ago. Without it, the agent cannot distinguish signal from noise.
The agent needs to know what matters. Not every change in the data is worth surfacing. The agent needs a framework for evaluating significance: which metrics the business watches, what thresholds trigger concern, how different signals combine into a judgment. That is the metric and decision layer from the AI layering post. Without it, the agent either alerts on everything, which means it gets ignored, or alerts on nothing meaningful, which means it gets abandoned.
The agent needs to know who cares. A churn signal for an enterprise account should reach the VP of Customer Success. A pipeline velocity drop in the mid-market segment should reach the segment leader. A pricing anomaly should reach finance. The agent needs a model of the organization: who owns which decisions, what information they need, and when they need it. Without this routing layer, the agent’s output lands in a shared channel and dies the same death as every other notification.
The agent needs to know what to do. The most mature version of an agentic system does not just alert. It recommends a specific action, or takes one within predefined guardrails. A churn-risk detection triggers a CSM assignment and populates a retention playbook. A pipeline coverage gap triggers a campaign recommendation to the marketing team. A forecast deviation triggers a reforecast workflow. The action layer is what separates an agent from a sophisticated alert.
Why most companies will fail at this
The dependencies I described are cumulative. You cannot build the action layer without the routing layer. You cannot build the routing layer without the metric layer. You cannot build the metric layer without the entity layer. Each one requires the previous one to be in place and functioning.
Most companies do not have a clean entity model. The previous post was about that. Most companies do not have aligned metrics across functions. The decision systems post was about that. Most companies do not have analytics that change behavior. The dashboards post was about that.
An agentic system layered on top of those gaps does not produce intelligence. It produces automated noise. Alerts that fire on inconsistent data. Recommendations based on metrics that different teams define differently. Actions triggered by signals that do not mean what the system thinks they mean.
The result is worse than having no agent at all, because the organization now has a system that acts with confidence on flawed premises, and the humans in the loop learn to distrust and ignore it within weeks.
This is the pattern I expect to see play out widely over the next two years. Companies will deploy agentic AI because the market pressure demands it. Most deployments will fail not because the AI is immature but because the foundation is not there. And the failure will be attributed to “AI not being ready” rather than to the unglamorous truth that the entity model, the metric layer, and the decision workflows were never built.
What the early versions look like
The organizations that are getting this right are not building general-purpose agents. They are building narrow, high-value agents with tight boundaries and clean foundations underneath them.
One pattern I find compelling is the anomaly-plus-context agent. The system monitors a specific metric, say pipeline velocity by segment, on a continuous basis. When it detects a deviation from the established trend, it does not just fire an alert. It pulls context: what changed in that segment’s activity, whether there were rep changes, whether the deviation matches a seasonal pattern from prior years, whether related metrics are also shifting. It packages that context into a brief and routes it to the segment leader with a recommended action.
This is not science fiction. The components exist today. Modern cloud warehouses already support dynamic materialized views, embedded ML functions, and event-driven triggers. Combined with a well-modeled data layer and a lightweight orchestration framework, you can build this now. The technology is not the bottleneck. The entity definitions, the metric alignment, and the decision workflows underneath are.
Another pattern is the goal-tracking agent. The organization sets quarterly objectives. The agent monitors the leading indicators tied to each objective on a weekly basis. When a leading indicator suggests an objective is at risk, the agent generates an assessment: what the trend shows, what the likely outcome is if the trend continues, and what interventions have historically moved the relevant metrics. The assessment goes to the objective owner, not to a dashboard.
The common thread is specificity. These agents have a defined scope, a clean data foundation, a clear output format, and a specific recipient. They are not trying to be a general intelligence layer on top of the warehouse. They are trying to make one decision better, faster, and more informed than a human could manage alone given the volume of data involved.
The ontology beneath it
There is a deeper question underneath all of this that I have been circling for the past several posts. Entity design is where data strategy starts. But the reason entity design matters for agentic systems goes beyond data consistency.
When you define entities and their relationships, you are building an ontology: a formal representation of what your business knows about how things connect. Customer relates to order. Order contains product. Product belongs to category. Account is managed by team. These are not just database joins. They are knowledge structures.
The next generation of AI systems, the ones that will reason across your business rather than just query it, will need this ontological layer to function. Not as a nice-to-have. As a requirement. An agent that understands the relationship between a customer’s support history, their contract timeline, their account team’s recent changes, and the competitive dynamics in their segment is operating on a knowledge graph, not a data warehouse. The warehouse stores the facts. The ontology gives those facts meaning.
This is where the conversation starts to shift from data strategy to something larger: how do organizations represent knowledge in a way that both humans and AI systems can reason over? How do the semantic structures we build for business analytics connect to the memory and reasoning architectures emerging in AI?
That is not a question I can answer in the closing section of a blog post. But it is the question I find myself working toward, and it is the thread I intend to pull on next.
The series, restated
This series started with a claim: the hard part is not the technology. The tooling is commoditized. The models are capable. The infrastructure is available.
The hard part is the system: the entity definitions, the metric alignment, the decision workflows, the organizational design that either enables or prevents the data from informing action.
Agentic AI is the sharpest version of this argument. Because an agent that operates on a strong foundation is transformative. It compresses the time between signal and response. It surfaces patterns humans would miss. It turns a data system from something the organization consults into something the organization collaborates with.
And an agent that operates on a weak foundation is faster at being wrong.
Build the system. Then let it think.