Is Your AI Learning Yesterday's Operating Model?

Organizations across every industry are investing heavily in AI agents for IT operations. The discussion often centers on selecting the right model, building better agents, improving prompts, or implementing retrieval-augmented generation. These are all important discussions. But I believe there is a more fundamental question that receives far less attention: what reasoning model are we teaching AI?

Enterprise knowledge is a tremendous asset

Every mature IT organization has accumulated years of operational knowledge: incident records, resolution notes, runbooks, knowledge articles, problem records, standard operating procedures. These repositories represent thousands of hours of engineering experience. They contain valuable operational knowledge and should absolutely play an important role in enterprise AI. Ignoring this knowledge would mean ignoring decades of enterprise learning.

However, these repositories contain more than knowledge. They also capture the operating model that produced that knowledge.

Historical knowledge also reflects historical operating models

Every incident tells two stories. The first is what caused the problem. The second is how the organization eventually found the answer. Those two stories are not always the same.

Historical incidents often reflect organizational boundaries, escalation paths, tool limitations, manual investigation steps, human workarounds, existing support models, and technology constraints that existed when the incident occurred.

As a result, an AI agent trained solely on historical operational knowledge may learn not only the solution, but also the lengthy investigative process humans historically followed to reach it.

The AI isn't making a mistake. It is faithfully learning the reasoning model it has been given.

Context changes how AI reasons

One of the most important observations from my experience building AI for IT operations was that AI agents initially reasoned exactly as experienced operations engineers did.

A resource became unavailable. The agent attempted to ping it. The ping failed. The conclusion was simple: "The server is down."

The problem wasn't the AI. The AI was following the same operational reasoning that had evolved over years of enterprise IT.

Everything changed when we introduced context before reasoning. Instead of asking "What do I do when a server is unreachable?" we first asked: what kind of resource is this? Is it a cloud workload, a software-defined networking device, a hyperconverged infrastructure platform, a Kubernetes workload, or a storage platform?

That single question fundamentally changed how the investigation began.

Example 1 — Cloud infrastructure

Consider a monitoring alert indicating that a virtual machine is unreachable. A traditional investigation might ping the virtual machine, check the operating system, verify the application, review monitoring alerts, escalate to another infrastructure team, engage the cloud provider, and eventually determine that the VPN tunnel connecting the enterprise network to the cloud environment had failed. The incident is resolved. The documentation is updated. Future AI systems learn from that history.

Now consider the same situation with platform awareness. The AI first recognizes that the workload is hosted in a cloud platform. Before following a traditional runbook, it consults the cloud control plane, which reports that the virtual machine is healthy, compute resources are available, and the operating system is running normally.

Immediately the reasoning changes. The workload was never the problem. The monitoring platform reported the symptom. The cloud platform already knew the operational state. The investigation shifts immediately toward network connectivity instead of spending valuable time investigating a healthy virtual machine.

Example 2 — Software-defined networking

The same pattern appears in software-defined networking. Imagine a network device reported as unreachable. Traditional operations often begin with connectivity tests, ping requests, escalation to network engineers, and manual troubleshooting.

But if the AI understands that the device is managed by a software-defined networking platform such as Cisco Meraki, the reasoning changes. Instead of assuming the device is unavailable, the AI first queries the platform's APIs and control plane, which can immediately provide device health, uplink status, connectivity, configuration state, and management status.

Rather than relying on generic troubleshooting steps, the AI reasons using the platform's own operational intelligence and determines the appropriate corrective action — or initiates it through the platform itself. Again, the monitoring platform reported the symptom. The control plane already understood the operational state.

Example 3 — Hyperconverged infrastructure

The same principle applies to hyperconverged infrastructure. Consider an alert indicating that storage utilization has crossed a predefined threshold. Traditional operations often execute a standard runbook: generate an alert, create an incident, assign an engineer, review storage utilization, add capacity or perform cleanup.

Many modern hyperconverged platforms already provide programmable interfaces capable of orchestrating storage expansion, capacity management, and policy-driven operations. When AI understands that the environment is a hyperconverged platform, the reasoning changes. Instead of executing a generic storage runbook, the AI evaluates platform health, available resources, quota policies, utilization trends, and automation capabilities before determining the appropriate action. It may recommend or execute capacity expansion, optimize quotas, or rebalance workloads.

More importantly, it can recommend preventive actions that reduce the likelihood of similar alerts occurring again. The objective shifts from reacting to incidents to continuously optimizing the environment.

A better reasoning model for enterprise AI

These examples reveal a consistent pattern. Traditional monitoring tells us that something appears to be wrong. Modern platforms often know what is actually happening. Historical incidents tell us how humans solved similar problems in the past. Platform intelligence tells us the current operational truth. Neither is sufficient on its own.

Enterprise AI becomes significantly more effective when it reasons across multiple sources of knowledge: historical incidents and resolution notes, knowledge articles and documented operational experience, live platform intelligence, current operational state, architectural context, and enterprise policies and governance.

Each contributes something different. Historical knowledge provides experience. Platform intelligence provides reality. Architectural context explains how the environment is designed. Together they enable AI to reason differently — not simply faster.

Beyond static runbooks

For decades, IT operations has relied on runbooks. First, humans executed them manually. Today, many organizations are asking AI agents to execute those same runbooks automatically.

I believe the larger opportunity lies elsewhere. Rather than asking AI to execute yesterday's playbooks more efficiently, we should enable AI to determine which reasoning path best fits the environment it is operating in. Sometimes that means selecting an existing playbook. Sometimes it means combining multiple sources of knowledge. Sometimes it means dynamically constructing a new investigative path based on live operational intelligence and architectural context.

That represents a fundamental shift — from workflow automation to context-aware operational reasoning.

The future of AI-native operations

The future of enterprise AI is not about choosing between historical operational knowledge and real-time operational intelligence. It is about combining both. Historical knowledge captures valuable experience. Platform intelligence provides current operational truth. Architectural context explains how the environment is built. LLMs synthesize these perspectives, and AI agents determine the most appropriate reasoning path and execute the right course of action. That is fundamentally different from simply reproducing historical investigations.

As enterprises continue investing in AI, I believe the goal should not be to teach AI how we solved problems yesterday. It should be to enable AI to reason using the best knowledge available today. That, to me, is one of the defining characteristics of an AI-native operating model.