IBM Builds Its AI Operating Model Around Always-On Agents

Agents that keep acting after the prompt is answered change what an enterprise has to run. Ritika Gunnar, chief performance marketing officer at IBM, argues that the operating model has to start from that fact. Once AI is doing real work, those workloads don't switch off, and the business depends on them staying up, staying accurate and staying affordable.

Success creates always-on pressure

Gunnar describes a dynamic that many teams will recognize. The more useful an agent becomes, the more it gets used, and the less acceptable downtime or drift becomes. "You are incented to be always on because those agents are always taking action for you," she said. That shifts the work from building a pilot to running a service with production expectations, including monitoring, capacity planning and clear ownership.

Four components that have to work together

IBM's AI operating model groups its approach into four parts: data, workloads, automation and hybrid cloud. Data supplies current enterprise knowledge. Workloads cover applications and the workflows that connect them. Automation handles oversight and optimization. Hybrid cloud lets operations run across distributed environments. Enterprises often buy each of these from different vendors, which is why Gunnar stresses that the value comes from how the pieces interact rather than from any single one.

Integration with what already exists is the first test. Most large companies have years of investment in systems of record, and they aren't going to rip those out. "You need to be able to integrate with your existing systems," Gunnar said, pointing to ERP and CRM platforms as examples. Her question for buyers is practical: how do you connect agent workloads to the past and the future of your operations at the same time?

Observability is where the four parts meet. Gunnar's concern is that clean data feeding a system isn't enough if automation doesn't give you visibility across every AI-enabled workload. Without that visibility, she argues, teams can't reliably choose the right model or the right agent for a given task. That's a point worth dwelling on, because model selection is often treated as a one-time decision rather than something to revisit as workloads change.

Governance has to travel with the data

An agent's decision may draw on operational systems, data from edge devices and context produced by other agents. That raises two questions: is the information complete, and do the permissions attached to it move along with it? Governed context is IBM's term for keeping both intact.

Gunnar's position is that governance should move earlier in the pipeline. "If you can take data and if you can shift left a lot of the governance," she said, the question of who can access which data at what time gets answered as the data flows, along with its provenance and ownership. Her claim is that agents making decisions on that basis produce better results. That's a reasonable hypothesis, though it's one enterprises will need to verify in their own environments rather than take on faith.

Human judgment still fills gaps

A lot of what keeps an organization running lives in people's heads. Experienced staff know exceptions, edge cases and unwritten rules that never made it into a system. Prompts and supporting context can carry some of that judgment, but capturing it fully is still an open problem.

Gunnar is candid about the limits. Many workloads will become autonomous, she says, but for essential systems, humans stay in the loop to supply tacit knowledge that AI hasn't yet learned to reproduce. That's a more measured stance than the fully autonomous framing common in product marketing, and it matches what most risk-conscious teams are doing now.

Feedback loops and what counts as performance

Agent activity produces logs of decisions and actions. Prompts record the instructions behind them. Put together, that record can feed an ongoing loop that connects enterprise data with AI behavior. Gunnar describes evaluation loops that check an agent's decision after the fact and ask whether a better path existed, one that was more accurate, faster or cheaper.

That framing matters because performance isn't a single number. Gunnar lists accuracy, timeliness and cost, and says the intended business result should determine how each is weighed. A fast, cheap answer that is wrong in a high-stakes process is a failure, and a slow, expensive one can be the right call when the outcome justifies it. Measuring this well means evaluating the work itself, not only the model underneath it.

Start with the process, not the technology

Gunnar's closing message is that the hard part is organizational. Teams need all the elements in place, and they need to start from business process transformation rather than from the tools. "That's really where it's at," she said.

IBM plans to take these themes into its TechXchange 2026 event, and the practical questions it raises will likely define a lot of enterprise AI roadmaps over the next year. The metrics to watch are less about model benchmarks and more about whether organizations can observe their agents, trace what they're allowed to see, and tell whether a given outcome was worth the cost.