Everyone Is Racing to Build the “Agent OS” for Enterprise Context Engineering

IBM named the shape. ServiceNow can ground it. The edge is the governed business context already in the platform .

IBM published a video on YouTube earlier this month titled Why AI Agents Need an Operating System.1 It does not waste time on warm-up. “Right now, somewhere in the world, an AI agent is booking flights, writing code, and answering customer questions, and it has absolutely no idea what it did 5 minutes ago. It’s like giving a genius goldfish the keys to your company.“

The framing lands. Agents are doers, not chatbots. They book flights, file expenses, write and run code, send email, talk to other agents. They are being deployed across customer service, IT operations, finance, HR, and engineering at a pace that has outrun the supervision infrastructure required to make them reliable.

Once a system can act, the enterprise has to answer a harder question than which model are we using? It has to answer: what is this agent allowed to believe, decide, and do?

IBM’s argument: this gap has a name. The gap is the absence of an operating system for AI agents.

That diagnosis is worth holding still on, because it is more honest than most of the public conversation. No platform has shipped an agent operating system. Not ServiceNow. Not Salesforce. Not Microsoft. Not IBM itself. The vocabulary is settling and the architectural shape is becoming legible, but the thing itself — a coherent, shipping, end-to-end operating substrate for autonomous AI agents in the enterprise — does not yet exist as a product anyone can buy.

What exists is a race. Every major enterprise platform is moving toward the same abstract shape, from different starting points, at different velocities. IBM’s video gives the shape. The race is what is actually visible on the market today.

For organisations whose operational core runs on the ServiceNow platform, this matters in a specific way. The race is not the only thing that determines the outcome of your AI investment. The foundation you built before the race started — the configuration data, the service ownership, the workflows, the controls — may determine whether the operating system, once it does ship in a recognisable form, lands on a substrate strong enough to hold it.

The shape IBM named

IBM’s video walks through six elements of what an agent operating system would need to do. The framing is abstract — not a product specification. It is the kind of useful organising shape a vendor with a long enterprise-architecture lineage is good at giving the market:

  1. Scheduler / orchestrator — decides which agent does which work, in which order, with which priority.
  2. Memory manager — short-term memory for the current task; long-term memory for what has happened before; episodic memory for what worked last time and what didn’t.
  3. Tool manager — the catalogue of what tools an agent can use, with sandboxing so it cannot accidentally touch what it shouldn’t.
  4. Identity manager — who the agent is, what it is authorised to do, on whose behalf, with audit attached.
  5. Observability — every decision, every tool call, every response, logged and traceable.
  6. Guardrails / governance — input checks, output checks, and human-in-the-loop gates for the consequential decisions.

The video closes: “Without an agent operating system, teams risk deploying unreliable and inefficient AI agents.” The point is not new to anyone running production AI. The framing as six discrete components is what is useful — it gives an organisation a shape to think with, not a roadmap to buy against.

IBM had made a similar move at Think earlier in May, describing an operating model for the agentic enterprise.2 The pattern matters: IBM is naming the enterprise architecture required to manage AI, the market still has to ship it.

Why ServiceNow still matters: the “Constants” beneath the agent

ServiceNow’s enduring role is that the platform holds the organisation’s “constants” — the things the organisation agreed on when it architected its solution and has committed to live by. The configuration items in the CMDB. The relationships across the system of record. The service owners and their underpinning contracts. The change-management workflow. The approval policy. The compliance controls. These are not features on an AI roadmap. They are the business context the organisation has put on the platform, deliberately, over time.

This is why the operational-trust distinction matters: a populated CMDB and a trusted CMDB are different assets.3 An agent grounding on the populated record acts on whatever shape the data happens to be in. An agent grounding on the trusted record acts on the shape the organisation has actually agreed to operate by.

That is not a side issue. It is the difference between an agent that merely has access to enterprise data and an agent that can operate inside enterprise authority.

The “constants” are the trusted data, management structures and business logic that agents need to be reliable. Agents are stochastic: they respond to context with probabilistic decisions. The “constants” are deterministic: they are what the organisation has agreed to be true. An agent grounded on trusted data behaves consistently with what the business has already committed to. An agent grounded on something else — vendor defaults, hallucinated context, a stale dataset — behaves consistently with something the business never agreed to.

Two consequences fall out of this framing:

The application interface is still where humans read controlled data. The agent’s job is not to replace the controlled path between a human and the platform; it is to act on the data the platform exposes, within the controls the platform enforces. The human user retains the controlled read path; the agent operates alongside it, not around it.

Any change to a “constant”, i.e. controlled data, management structures and business logic — goes through the platform’s control processes. Change management. Approval workflows. Service-owner sign-off. The agent is not above this control process; it operates inside it. An agent amending a configuration record, changing a service-owner mapping, or altering a workflow definition must pass through the same validation the platform has always required of changes that consequential.

This is the substrate that makes any future agent operating system trustworthy in a ServiceNow environment. Whatever the eventual scheduler, memory manager, tool manager, identity manager, observability layer, and guardrails look like when they ship in a recognisable shape, they will operate on top of a trusted platform.

Where the discipline gap lives

Three patterns are worth naming, because they are the patterns that separate organisations whose agent deployments work from organisations who are owners of the platform pieces but not yet operators of them.

Pattern 1 — The data layer beneath the controls. A ServiceNow practitioner published a sharp piece at K26 titled “Your AI Controls Don’t Govern the Data That Feeds Them.“4 The argument: the AI-governance plane (controls on the model, the agent, the prompt) is necessary but not sufficient. The data layer beneath — what the agent grounds on — is not routinely governed in most enterprise implementations, even when the AI governance is in place.

Pattern 2 — The operating-model trap. ITSM.tools ran a piece this month titled “Your ITSM Operating Model Is Blocking AI Adoption.“5 The argument: IT teams tasked with AI implementation remain blocked by traditional ticket-queue operating models. Some platform pieces of the future agent OS are emerging; the operating model is what determines whether they are used as anything other than expensive new defaults.

Pattern 3 — Decision distribution without accountability distribution. CIO published a piece this month under the headline “AI is spreading decision-making, but not accountability.“6 Agents now make decisions across the operating model, often within valid permission boundaries, but the accountability layer for those decisions has not caught up. Whatever the future agent OS looks like, it will be able to show you what happened. It will not be able to tell you who is supposed to answer for it. That answer lives in the operating model, not the platform.

Five questions a CIO can take to the next board cycle

For the CIO or CTO reading this and recognising the shape of the problem in their own organisation:

  1. What are your “constants” today, and are they current? The configuration items, service ownership, workflows, approvals — the things any future agent OS will ground on. If your CMDB is populated but not trusted, the rest of the agent OS does not have a substrate to land on.
  2. Where is coordination happening above individual workflow triggers? If the answer is “nowhere,” the organisation has not yet designed the work layer agents will need to operate inside.
  3. What tools can your agents touch, and who decided that? If the answer requires a meeting to assemble, the tool boundary is implicit and probably underspecified.
  4. Who has identity-and-access for each agent class in your environment? If the answer is “the user who started it,” you have a chain-of-authority problem that will scale linearly with the number of agents you deploy.
  5. Is your observability layer being read? Most organisations capture it. Fewer review it. Even fewer have established remediation paths from observation to action.

None of these are platform questions. They are operating-model questions on top of the foundation you may already own.

The practical work is not to declare that the “agent operating system” has arrived. The practical work is to make the platform’s existing business context reliable enough for agents to use.

This is the work specialist partners do. Operating-model design that anticipates the abstract elements as they ship in pieces. Translating platform moves — Context Engine, AI Control Tower, Veza, Traceloop, and the moves yet to come — into decision boundaries that match the customer’s real risk posture. Building the observability discipline that turns captured into acted upon. Holding the consulting independence — on deployment design and success criteria — that lets the customer’s AI investments be measured against the customer’s outcomes, not the platform vendor’s roadmap.

The opportunity is sharper than it has been for years. IBM named the question. The market is racing to ship the answer. The foundation work — the “constants”, the operating model, the controls discipline — is where the next decade of enterprise AI value will be unlocked.

By Kristina Petrić and Michel Conter

At Conter.biz, we work with enterprise leaders on architecture, service-management, and operating-model practices that turn AI capability into real organisational value.

Sources

  1. IBM — Why AI Agents Need an Operating System, YouTube video, published 2026-05-12. URL: https://www.youtube.com/watch?v=IVGjBxqygmI. ↩︎
  2. IBM Think 2026 announcement — IBM unveiled what it called “a new operating model for the agentic enterprise” at its Think conference on 2026-05-05. URL: https://www.cio.com/article/4166941/ibm-unveils-its-blueprint-to-help-enterprises-run-ai-at-the-core-of-their-business-2.html. ↩︎
  3. Operational Trust: Measuring the Real Usability of the CMDB — ServiceNow architect blog, Steven Meissner, May 2026. URL: https://www.servicenow.com/community/architect-blog/operational-trust-measuring-the-real-usability-of-the-cmdb/ba-p/3536079. ↩︎
  4. Your AI Controls Don’t Govern the Data That Feeds Them — sncdevelopment.com, James (@ecostratus), 2026-05-04. URL: https://sncdevelopment.com/2026/05/04/your-ai-controls-dont-govern-the-data-that-feeds-them/. ↩︎
  5. Your ITSM Operating Model Is Blocking AI Adoption — ITSM.tools, John Mathieu, 2026-05-05. URL: https://itsm.tools/itsm-blocking-ai-adoption/. ↩︎
  6. AI is spreading decision-making, but not accountability — CIO, Pat Brans, 2026-05-06. URL: https://www.cio.com/article/4160986/ai-is-spreading-decision-making-but-not-accountability.html. ↩︎

Related Posts