Forget who has the smartest model. I think the Agentic AI platform war must ultimately become an infrastructure benchmarking problem, not just a model quality problem. Businesses are really looking for who can prove the most efficient execution fabric for orchestrating work at scale. Based on what I saw this week at ServiceNow’s flagship event, Knowledge 26, we’re a long way towards that goal.

For context, consider the mainframe era. The brands that dominated did not do so because people initially loved or understood mainframes. Or for that matter could easily differentiate. They won because enterprises needed confidence that mission-critical transactional workloads could execute reliably, repeatedly, and economically. AI is yet to arrive at that moment.

To achieve that confidence, a key measure of differentiation for mainframes was MIPS. It was the measure of computational throughput for the transactional era that helped businesses see that the technology coupled with their implementation model of it, was competitive. There is not yet to be an equivalent for the agentic era.

But I think TAPS (Tokens Attributed Per Second) could be that measure. And unlike raw token counts and costs which are understood, let’s call them TRU (token resource units), TAPS would allow the measurement of orchestration, flow, sequencing, exceptions, and execution efficiency across a business process.

Read on if Servicenow’s hockey stick moment is of interest.

Share

I just spent another week in the US at another amazing AI event. And while it was compelling, from all the conversations I had with both execs and regular customer delegates on the conference floor, it was also more evidence that there is still something strangely incomplete about the current AI market.

Every week we hear another declaration that one model is now marginally better than another. No better example than while I was at Knowledge, Anthropic separately announced “dreaming” as a new feature. And then there are the ever more agent announcements, and more autonomy opportunitues, more OOTB workflows, and more partnerships. It’s like wading through mud.

The market is behaving as though intelligence and scale and feature adoption alone will determine success and adoption. But it won’t. Enterprises do not really buy intelligence. They buy execution.

That distinction matters more than most sellers currently seem to realise. Because buried underneath the noise of the current AI cycle is a much older pattern that has played out across every major transition in technology history.

The early phase of every infrastructure market is dominated by excitement, expansion and marketing narratives as vendors chase adoption velocity. Investors on the other hand chase enormous growth curves. Buyers are left with possibility, through conversations dominated by potential rather than operational reality. That is exactly where AI sits today.

That matters because pre-IPO and hyper-growth environments reward very different things than mature infrastructure markets do. ServiceNow CEO Bill McDermott calls this the AI blind spot.

Right now the market is rewarding model capability, developer adoption, ecosystem gravity, consumer awareness, token growth, and perceived inevitability. Operational efficiency is discussed but still secondary though it will ultimately matter more once the dust from the big $1T IPO bubbles hopefully settles this year.

In many ways this mirrors the early days of the mainframe era. Mainframes were not initially sold because enterprises deeply understood computational theory. Years ago I worked with a guy who escorted ANZ Bank executives on a multi-month delegation through the United States ahead of their very first major mainframe purchase.

The stories were wild. Endless vendor briefings, demonstrations, dinners, dude ranches, and political theatre. But underneath it all was a very serious question. Could this new technology platform reliably run the bank’s critical transactional workloads repeatedly, safely and at scale? The trip was ultimately successful not because the executives suddenly became computer scientists, but because they gained confidence that the operational heart of the bank could execute on this new infrastructure.

What followed was transformational. Banks needed payment processing. Then airlines needed reservation systems. Then Governments needed records management and retailers needed inventory control. The mainframe became the operational backbone of the modern enterprise because it created confidence in execution. But not all mainframes were created equal. So eventually that confidence became competitively measurable. Through MIPS. Millions of Instructions Per Second.

I also worked with one of Australia’s pre-eminent benchmarking specialists who was still generating millions of dollars a year for analyst firms well into the early 2000s doing benchmarking projects for the country’s largest telcos, banks and state governments.

Anyone that has ever seen a benchmarking engagement up close knows MIPS were never perfect. There were endless arguments about weighting, workloads, utilisation patterns and what was really being measured. But that was never really the point.

What MIPS gave the market was a comparative language for discussing throughput, scale and operational capability. A way for organisations to compare not just machines, but the transactional confidence underpinning their organisations. Importantly for this story, enterprises were not really buying mainframes. They were buying confidence that the business itself could execute better. That same transition is now emerging with agentic AI.

Today the market still talks about AI primarily as though it is software, largely because it is abstracted through modern PaaS architectures and wrapped in applications, copilots and conversational interfaces. But true end-to-end agentic systems are operational infrastructure.

And like every major infrastructure shift before them, their value will ultimately be judged against the thing they are seeking to replace or outperform. That’s not humans. It’s decision chains and transactional processes and more.

The real promise of agentic infrastructure is not that it thinks better than people. It is that it executes work across complex organisational systems more efficiently, consistently and adaptively than the operational models we have built during the previous technology era.

What organisations actually care about is whether work flows more effectively through their value chain which, at some point through decomposition, standardisation and transformation, ultimately arrives at workflows. And workflows, including yours dear reader, are ugly things ripe for disruption.

They are not neat diagrams in strategy decks. They are living operational compromises accumulated over years or decades. They contain approvals, escalations, retries, integrations, policies, exceptions, governance controls (hopefully), human intervention, shadow processes, duplicated decisions, historical baggage and institutional chaos layered on top of one another through successive generations of technology and management thinking.

That’s how we are arriving at a consensus that the hard problem is not generating intelligence through models. It is actually orchestrating the work those models support. Which is why I increasingly suspect the AI market eventually needs its own MIPS moment.

It needs to be something capable of measuring how efficiently tokenised work moves through complex, multi-functional orchestrated operational environments. Something like TAPS. Tokens Attributed Per Second. Not as a metric for models, but as a benchmarking input for workflows executing across agentic platform environments.

Because the real challenge is not isolated prompts or single-agent interactions. It is the coordination and orchestration of work flowing across functions, systems, humans, policies, APIs, approvals, exceptions and decision layers in real operational environments. TAPS would attempt to measure how effectively tokens are consumed, routed, contextualised, validated, transformed and completed as work moves through these interconnected execution chains.

Not just “how many tokens were used”, but how efficiently the operational fabric itself converts tokenised reasoning into completed outcomes across the enterprise. That’s the unproven point of differentiation and why the current market conversation still feels incomplete. And part of the reason financial analysts are gutting software stock (the blind spot).

Right now the industry is obsessing over token pricing, and model scale, and inference costs. But enterprises run workflows which create entirely different economic pressures.

What happens when agentic systems begin running finance, procurement, HR, customer operation, compliance, field services and government processes at scale? Suddenly the important questions become which platforms minimise retries, and which orchestration layers, regardless of architectural partnerships, reduce token waste. Or as was evident at Knowledge 26 this week, the current red hot moment is which AI platforms govern complexity and risk most effectively? That is not a model intelligence conversation anymore. It is one purely focused an operational throughput.

I thought Paul Fipps, Servicenow’s President Global Customer Operations had a good message. CIOs don’t want ungoverned custom software running around the enterprise. But it doesn’t stop there. CEOs expect that as a baseline, but they are actually looking for something more.

In the transactional era, measurable packets of data moved through enterprise systems. In the agentic era, packets of tokens move through orchestrated workflows. And each of these workflows involves a complex model of multi-vendor agent approvals, retrievals, escalations, classification events, retries and contextual handoffs

All of it becomes part of a living token economy where attribution and not unit cost will unlock the difference between good and great agentic infrastructure. The enterprise itself will slowly transform into a token-routing environment. And once that happens, measurement and benchmarking becomes inevitable. Not because analysts like me invent new acronyms but because procurement eventually demands operational comparability.

Boards and CFOs will not tolerate fuzzy economics forever once these systems become embedded into critical operational processes. They’ll want to know if this new tech can execute work more efficiently than the alternatives. That is when the market changes. That is when the hockey stick happens for ServiceNow. When they don’t just orchestrate and govern better than anyone, but when they unequivocally show they minimise operational drag across tokenised workflows.

In other words, the winners may end up looking less like AI companies and more like operating system companies. And I think that is something that suits a company like ServiceNow. That’s operational reality and totally aligned with the base that propelled them to #1 in category.

So perhaps we simply are not there yet. But I think we are very close. Perhaps the market first needs to pass through this expansion-era phase where narrative dominance matters more than operational efficiency. Perhaps we need to get through the growth cycle, the valuation cycle and the platform land grab before the harder industrial questions (and answers) arrive. Because history suggests they always do.

Eventually every infrastructure market matures. And when it does, the conversation shifts from what can this tech do to how efficiently can this technology run the world?

That was the real story behind mainframes. And I increasingly suspect it will become the real story behind agentic infrastructure platforms too. MIPS helped sell the transactional age. TAPS, or whatever its equivalent may be, may yet define the agentic one.

Today’s AI narrative has been dominated by model breakthroughs, funding rounds, and product launches. It has felt like a glitzy, fast-moving, parallel universe. At times, more like watching the Oscars than understanding how work will actually change. Understanding, not shaped by Silicon Valley or Wall Street, has taken time to arrive.

I think what is starting to shift now is not the pace of innovation, but the quality of market thinking. The centre of gravity is moving away from the builders and toward the users who actually have to make this work.

From that perspective, whether you are an enterprise buyer or an institutional investor, these are ten observations about where I think the real AI market is heading, and why they will matter far more than the next model release or benchmark comparison.

1. The model is no longer the centre of the story

It initially looked like the model was the product. I think we are past that. Models are becoming powerful components. But they are increasingly interchangeable, increasingly abstracted, and increasingly hidden behind other layers. The centre of gravity is shifting upward into how models are applied, governed, and embedded into work, and the platforms that allow this to happen.

2. Software is still the distribution mechanism for AI

No matter how advanced the model becomes, the customer won’t just interact with a model. They’ll interact with software that relies on interfaces, workflows, approvals, forms, notifications, and dashboards. Bascially the same things that have always defined enterprise value. Nothing about that has changed yet. Because AI is an amplifier. It reinforce not replace the importance of the software systems through which work actually happens.

3. The “death of SaaS” is overstated, but the weak will disappear

We can debate the scale of the SaaS apocalypse, but surely all agree that there will be (and should be) casualties. A decade of proliferation has created a long tail of thin, single-purpose tools that exist largely because they could. Many of them will not survive. I’ve described this phase as “the application frat party” or “whatever-as-a-service.” Core systems, however, are not going away. If anything, systems of record become more important. They provide the structure, authority, and constraints that AI needs to operate safely. What disappears is not software itself, but the fragmentation. And that is long overdue.

4. The real enterprise problem is no longer integration. It is coordination

Connecting systems has been an observable challenge for most of my career, from the early days of “what the hell is middleware?” to today where APIs have largely solved that problem. But the harder challenge was never just about connecting systems. It was about following how work actually moves through a business. Defining who approves what, what triggers the next step, where decisions branch, how exceptions are handled, and how multiple functions interact in real time is still incredibly difficult. Where integration connects systems, coordination connects work, and delivers coherence back to the business. So to be valuable, AI has to sit inside a coordination layer.

5. Context matters more than data, and most organisations have lost it

At the exact moment AI arrives as a context-driven capability, most organisations have never had less clarity about themselves. Over the past decade, the rise of as-a-service has fragmented ownership, spread decision-making across functions, and steadily weakened enterprise architecture. Systems have multiplied, the CIO’s influence has diminished, and organisational coherence has declined as a result. At the same time, organisations have invested heavily in data lakes, warehouses, and pipelines, assuming that centralising data would unlock value. AI is now exposing the limits of that thinking. What remains is data without structure, systems without alignment, and organisations that struggle to explain how they actually operate end to end. That is the context gap, except it no longer a gap. It is a chasm.

6. Enterprise architecture is coming back, whether organisations are ready or not

The rise of SaaS decentralised technology decision-making (see #3). Buying groups emerged everywhere. Systems were acquired function by function. Architecture, as a discipline, quietly weakened. But AI does not tolerate that fragmentation. It forces organisations to confront how everything fits together and it exposes gaps, duplication, and incoherence. Architecture, that lost art, is no longer optional. It is being reintroduced by necessity.

7. The service layer is not shrinking. It is moving up the stack.

The belief that AI will shrink the services market and that automation will replace people, and the need for services will decline is just plain wrong. The service layer is actually becoming more valuable than the model layer. So the familiar pattern still holds. The one where the product arrives first, but the real value follows in services. The organisations that understand this will capture far more value than those focused purely on building models. Because AI doesn’t simplify the enterprise but it does make its complexity unavoidable. So the work moves, not disappears. It shifts toward far more demanding activities like stitching together models, workflows, governance, identity, and data into something that actually works inside an organisation. It is not implementation in the traditional sense but still services engineering.

8. Closed ecosystems will persist longer than expected

The case for open ecosystems built on a soft core and hardened shell has always been clear. But the market is not rational. Closed systems continue to win because many organisations are not equipped to manage multi-vendor complexity, so they default to simplicity. I see this consistently, particularly in government environments. That creates a paradox. Closed platforms are structurally weaker, but commercially durable. It is what keeps ERP vendors in the game. That durability buys time, but it is also finite. As the market evolves, remaining closed becomes harder than transitioning.

9. The AI bubble may need to dim before real progress accelerates

Right now, the model spotlight is too bright. It is drawing attention away from the harder, slower work required to make AI useful. That work is not in the models. It sits in process redesign, governance, data meaning, and organisational alignment. These are not headline topics, but they are the ones that determine outcomes. So the constraint is no longer capability, but focus. Progress will accelerate when the spotlight shifts, either because it fades, or because buyers (and investors) start dimming it themselves.

10. Most organisations are being sold the penthouse, not the front door

Vendors are pitching end-state visions replete with fully autonomous workflows, agentic enterprises and self-optimising systems. But organisations do not start there. They have always needed entry points in the form of clear, grounded, level one use cases that light the pathways into more mature adoption. Without that, the gap between ambition and execution remains way too wide (commercially and technically). The next phase of AI adoption will be defined by those who can show customers where to begin, not just where they could end up.

That’s it for now. So despite the tendency to believe that everything has changed (because this technology is so amazing), in reality, what is happening in the real economic markets, Monday to Sunday, is far more subtle. Almost recognisable?

What sits underneath these shifts is not a technology story at all, but a clear decision framework about where to invest, what to rationalise, how to architect, and how to execute. Things like “treat models as components, not strategy”, and “shift services investment up the value chain” and “rationalise the long tail of SaaS” are very practical steps to take.

AI extends what is possible, but it doesn’t rewrite the story. The fundamentals of software still apply, the complexity of organisations still matters, and the difficulty of execution hasn’t gone anywhere.

If anything, this may be the crowning achievement of the last 50 years of technology. It gives every organisation the potential to be great. But what happens next is not a technology question. It’s an organisational one.

One of the more interesting dynamics in the enterprise AI and workflow market is how it is beginning to reshape established ecosystem relationships. Take, for example, that between IBM and ServiceNow. This is not a marginal partnership. It spans resale, implementation, co-selling, and increasingly joint positioning around AI and workflow. While no single value is disclosed, the economic weight is significant. In APAC alone, IBM’s influence across these channels is likely in the range of $200–300 million annually, with the global figure considerably higher. More importantly, the downstream value through transformation and services is materially larger.

With offerings like watsonx Orchestrate, IBM is increasingly able to challenge ServiceNow in sectors such as banking, telecommunications, and the public sector. Particularly in APAC, where complexity, legacy integration, and architectural control are critical. This introduces the potential for meaningful headwinds, possibly approaching $1 billion over five years at the upper end of scenarios.

I’m not saying this should be interpreted as a direct loss. But we should see it for what it is. An ongoing contest over who owns the execution layer. To be successful IBM does not need to displace ServiceNow wholesale. It only needs to win in environments where workflow is inseparable from data, infrastructure, and legacy control.

In APAC, where ServiceNow’s revenue base is approximately $1.5 billion and growing toward a $3–4 billion opportunity over the next five years, the battleground is not just Net New ARR. It is also NRR under pressure. Not just who owns the installed base (which is the old business model), but who captures the next layer of spend within it (the new business model). IBM’s architecture-led, distributed execution model creates a very credible techncial pathway to intercept new regional spend that might otherwise default to ServiceNow.

The likely outcome is a selective diversion of high-value growth segments, particularly in industries where architectural authority remains contested. Framed this way, a $300–700 million shift over five years could be a reasonable expectation, with a $1 billion scenario representing the upper bound if IBM consistently captures complex, AI-led transformation programs. Of course, that’s just head-to-head and doesn’t factor other major players in the AI and workflow ecosystem aggressively positioning for market share.

Regardless, the strategic implication is clear. This is less about platform competition and more about who defines how work is executed in the next generation of enterprise architecture. That is exactly IBM’s point of entry. Let me explain the breakdown.

I recently spent a few days in Bangalore at IBM’s Asia Pacific analyst event, Insights 2026. They apply transformation across a set of capabilities that, in reality, operate in multiple directions at once. So it included a broad sweep across AI, data, and hybrid cloud, alongside extensive conversations with consulting teams and enterprise clients, including captive centre operations customers.

These sessions are always valuable because you get close to the thinking and hear how the company wants to be understood. But they don’t present a fully resolved picture. They don’t explicitly show how the pieces fit together. That part is left open. And that creates a familiar challenge. The more comprehensive the briefing, the harder it becomes to see the underlying shape of the real strategy.

So while IBM didn’t frame it this way, sitting there it was already starting to become clear to me that what I was hearing wasn’t just about the convergence of their AI, Hybrid and Data portfolios. It pointed to something more structural. A convergence towards the same layer of the enterprise that platforms like ServiceNow have defined.

Then, on the flight home, somewhere between Singapore and Brisbane, that picture sharpened in an unexpected way. A targeted email campaign promoting discounted SME offers across IBM’s core portfolios.

At face value, it was unremarkable. Just low-cost entry points into watsonx, data platforms, and hybrid cloud. But in the context of the previous few days, it changed the question from “what does IBM sell?” to “what are those pieces designed to become when you put them together?” Because that’s no longer a product question. It’s a platform one.

And when you look at it that way, the answer becomes clearer. An SME would typically buy a packaged application from an ISV. IBM is now selling the components to build that application. So while I’ve been critical in the past of its liberal use of the word “platform”, in 2026 I saw clear evidence that it is starting to execute in a way the PaaS market, and its enterprise consumer base, will recognise.

At enterprise scale, IBM is not easy to read cleanly. The most useful signals don’t come from how it describes itself, but from how each layer of the portfolio is now being positioned. It spans too much of the market to fit neatly into a conventional category. In my own filing structure, it effectively sits under “Vendor” and then “Mega Vendor,” because anything more precise quickly breaks down. It is not just a cloud provider, not just a software company, and not just a consulting firm, even though all three remain central to how its capabilities are delivered and realised.

So rather than trying to categorise it, the better way to understand IBM is to look at how it is organising itself. Increasingly, that comes down to three core domains that the market typically treats as separate.

AI, represented through platforms like IBM watsonx, promise not just model access but governance, auditability, and control. Data, increasingly anchored in offerings like IBM watsonx.data, which attempt to unify structured and unstructured information into something that can actually support decision-making. And hybrid cloud, underpinned by Red Hat OpenShift, which provides the execution environment across on-premise and public cloud infrastructure.

Seen together, the portfolio has, for some time, felt like a collection of adjacent bets. Coherent at a strategic level, but more of a vision than an operating model. The “old” IBM, viewed through the lens of a large enterprise, typically required translation, alignment, and a level of architectural intent that only existed in pockets.

This is why IBM has often appeared complex and fragmented. Not because the pieces didn’t logically fit, but because, without the involvement of IBM Consulting, they were rarely brought together as a unified system.

That’s the enterprise view. But what happens when you strip all of that away? The SME lens forces a different question. What would I actually use here? And when you look at IBM through that lens, the portfolio stops behaving like a set of products and starts behaving like a system.

Because while an SME might ask, “what would I actually use?”, the reality is they are still dependent on everything that sits beneath it whether that is identity, data, workflow, integration, and governance. So the platform doesn’t go away. It just becomes invisible, and unavoidable.

Increasingly, those dependencies are being organised around how work is actually executed. From a distance, the inclusion of AI in these SME offers looks like a standard market move. Discounted access to models. Credits for experimentation. A pathway into generative AI. But through the same lens, the dependency becomes obvious.

In the IBM model, AI is not intended to sit on top of work. It is designed to operate where work is already structured, observable, and governed. And that is the catch. Because creating that environment still requires significant process and data alignment. And these are areas where IBM Consulting has been deeply involved. The platform may now be visible, but it still needs to be assembled.

Without that, the models have nothing meaningful to act on. The outputs become inconsistent, the risk becomes unmanageable, and the promise collapses into novelty. So what looks like an AI entry point is actually another platform signal. AI is not something you add. It is something that emerges once work is already structured, observable, and governed. In other words, it operates at the level where work is actually executed.

The same pattern holds when you look at the data layer. At enterprise scale, the language of data fabric and lakehouse architecture suggests consolidation and opportunity. It offers a pathway to unify data and unlock value through analytics and AI. But at SME scale, it feels very different.

It exposes fragmentation, inconsistent definitions, and multiple versions of the same truth. Systems that were never designed to speak to each other are now being asked to form a coherent picture.

In that scenario, what is being offered is not just a platform, but a confrontation with reality. Data, in this context, has little value because it exists. It becomes valuable only when it can support execution and when it can inform decisions in a way that is consistent, auditable, and repeatable.

And then there is hybrid cloud, through platforms like Red Hat OpenShift. Outside of enterprise, the ability to run workloads anywhere and move between environments is often framed as optionality. But even from an SME perspective, that framing eventually breaks down.

You don’t just need hybrid cloud when your environment is already complex. Or when you are operating across multiple systems, multiple vendors, and multiple constraints. Or when control becomes more important than simplicity. You also need it through outages, geopolitical disruption, or supply chain failures like we’ve seen in recent weeks across the middle east. In that sense, hybrid cloud is not about infrastructure flexibility. It is about maintaining control over how work is executed in the presence of complexity.

Across all three layers, the pattern is the same. The value only materialises when it connects to how work is actually carried out. But then when you bring these three layers together, something shifts. AI, data, and hybrid cloud stop behaving like separate portfolios and become interdependent. All of a sudden this is not a collection of software infrastructure tools. It is an operating model.

So what does this mean in practice for the enterprise buyers and architects currently redefining their AI and platform strategies? Because once you strip it back, the market is no longer organised by products. It is organised by where work begins, where it is executed, and who controls it.

Microsoft still owns the broadest entry point for now. It sits where people interact with work. It makes AI immediate, accessible, and embedded in the tools that organisations already use. That position is not under threat in the near term. If anything, it is expanding, albeit with some opaqueness around its new AI-enabled E# licensing models.

ServiceNow has spent the last decade building something different. Not productivity, but execution. And the last two years re-establishing around being the platform where work is defined, routed, governed, and completed. Its language is increasingly consistent across workflows, data models, and systems of action. More recently, promoting the idea of a control plane for how work moves through an organisation.

What became clear in Bangalore is that IBM is now speaking a language that is uncomfortably familiar. Its framing is no longer confined to infrastructure, data, or models, but is now led by workflows, orchestration, and control towers. It is moving into observability of the execution layer and into the domain of how work itself is coordinated and governed. This is not a coincidence. It is a signal.

Because it means the market is no longer cleanly segmented into layers. It is converging around the single question of who owns the system that defines, governs, and executes work? ServiceNow were first to get that right.

In that context, IBM is no longer a deep architectural layer. It is reaching upward, attempting to connect its strengths in AI, data, and hybrid cloud into a model that can participate directly in execution. At the same time, ServiceNow is moving downward by strengthening its data foundations, expanding its AI capabilities, and positioning itself as more than just a workflow engine. Microsoft continues to expand laterally, embedding AI and automation into every surface where work begins.

So how does it stack up? I think IBM’s integrated portfolio spanning AI assistants and agents, middleware, data services, hybrid cloud, infrastructure, and its broader ecosystem, brings something genuinely distinct to the agentic workforce discussion. You can also read some of my earlier thoughts on IBM here (Agentic AI’s Narrow Door).

Right now, its strength lies in environments where complexity, regulation, and scale demand control. Where governance is not optional, and where execution must be observable and auditable across fragmented systems. As the conversation shifts from data sovereignty to AI sovereignty, that positioning becomes increasingly important.

Even more so when you consider that, according to IBM’s own recent CEO study, fewer than 16% of organisations have deployed AI at an enterprise-wide level. But the direction of travel is clear. It is no longer enough to provide the layers beneath work. Rather, every major platform is now moving toward owning the system through which work is actually carried out.

If a further proof-point was needed, IBM’s rollout of the watsonx.data Context Layer, effectively a context graph and semantic ontology layer, is another clear signal of where it is heading. This is a great move by IBM and is not just about improving data access or analytics but about defining how data relates to work.

And that moves IBM directly into territory that has historically been owned by ServiceNow. Because at its core, ServiceNow’s strength has never just been workflow. It has been the ability to model the relationships between services, systems, and processes in a way that allows work to be consistently executed.

What IBM is building through its context layer is not just a data capability. It is an alternative path to the same outcome ServiceNow has been pursuing. ServiceNow started with workflows and built a data model (CSDM) around them. It is an area I’ve long thought they have underplayed and under-promoted so it will be interesting to see how hard and visbily IBM will push Context Layer. They seem to be starting from the opposite direction by establishing the relationships between data, systems, and entities, and using that to inform how work should be understood and executed.

It is a subtle shift, but an important one. Because while literally everyone is now talking about workflows, the platform battle is shifting from “who runs workflows” to “who defines what things mean.” So it clearly spotlights that whoever orchestrates work must be able to define the ontology of the enterprise itself. That is the layer that ultimately determines how work can be executed, governed, and scaled. I’ve previously written about that here.

IBM’s approach to identity within this model also becomes critical. Whether it aligns to an existing framework or establishes its own will determine whether it converges with platforms like ServiceNow, or creates a parallel model of enterprise control.

Returning to the original arc, for most small and mid-sized organisations reading that marketing email, IBM’s SME offers would feel like overreach. Too much capability. Too much implied complexity and too far removed from immediate needs. And in many cases, that instinct will be correct. That’s why IBM Consulting features so prominently in so many IBM enterprise deals. But that is not the point.

Because what appears excessive at small scale is necessary at medium to large scale. And more importantly, it reveals the direction of travel. We are moving away from a world where organisations buy software to support tasks. Towards a world where platforms define how work is structured, governed, and executed.

So at this inflection point, the easiest way to consider IBM’s relevance in the platform market is not to start with its largest customers, but to strip the problem back to its simplest form. Because when you do, what remains is not a story about AI adoption or cloud migration. We are well past that. It is a highly trusted and capable transformation blueprint for what work will look like in the next decade.

Agentic AI works today. But for most organisations it remains in a narrow band of work. The net result is that the market is misreading the signal. Because it is focused on the destination, the level 5 or 6 maturity benchmark, and not the entry point or the path to get there. Enter Salesforce’s SMB play.

Agentic AI looks like it’s working, especially in smaller organisations. It is quick to deploy. It is easy to demonstrate. And it can deliver immediate gains in productivity. It also fits neatly into some workflows where speed matters more than consequence. It’s the kind of model I wrote about in TechnologyOne’s PLUS Moment.

And if you read that as the starting point, not the end state, the current wave of success tells you something important. It does not tell you that agentic AI is solved. But it does tell you we’re seeing the earliest stage of a much longer progression. One that will take years to unfold as organisations move from low-consequence efficiency into work that carries real consequence and accountability.

I feel like this is the part of the story the market continues to gloss over. Not just because we’re misreading the results, but because of how the story is being told. Vendors are conditioned to sell the future. The fully autonomous state. End-to-end orchestration. Agents operating confidently across the business. That’s what I refered to as Level 5 and 6 maturity in an article last year called Have You Tried Our New AI Agent?

And it’s not just a marketing choice. It’s a market expectation. Boards want market share, and category leadership and to know they are going to win. So the narrative gets pushed forward where the destination is clear and the vision is compelling. But it sits orders of magnitude ahead of where most organisations actually are. And in doing so, the middle gets lost.

We jump from aspiration to demonstration, without spending enough time on what meaningful entry points look like. Where do you actually start? What kinds of work can be trusted first?

That’s where the confusion creeps in. The harder the market pushes the future, the less clear the starting point becomes.

Early success is too often interpreted as capability (for both the customer and AI solution provider), when in reality we’re just seeing what happens when you apply autonomy to low-authority workflows. It’s not that every AI technology being pitched is mature. It’s that the client work isn’t demanding enough to expose where it fails (at scale or higher levels of workflow complexity). Now, after a few years of headline-grabbing announcements, it feels like things are starting to settle down in 2026.

In a recent briefing with Salesforce, what stood out was their emphasis on strong AI adoption in the CRM SMB segment. Even allowing for some variation between Salesforce and ABS definitions, that’s a TAM of over 2.5 million businesses in Australia.

The smaller deal sizes in this segment make it easy to dismiss, especially for enterprise-focused sales teams. But that misses the point. If agentic capabilities are landing quickly and sticking, that’s a signal, not something to write off.

What if this wasn’t just the easy version of the problem, but the honest one? What if it shows where agentic AI actually works today, and not where a keynote says it should.

In smaller organisations, most workflows sit in a low-authority band. Fewer systems. Lower consequence. Lighter governance, often implicit rather than defined. That’s the space where agents work easily. They can summarise, draft, trigger, and respond. They can take small actions without needing a deeply structured model of the organisation behind them (see Whatever-as-a-Service). Identity exists, but it doesn’t need to carry much meaning. It’s present, but it’s very thin. In that technical environment, agentic AI feels easy. But what if we stop seeing this as a weakness and start seeing it as a starting point?

With its latest SMB offerings, Salesforce is demonstrating through commercial expression, something much of the market is missing. Agentic AI is not something you install. It is something you grow into. It is a maturity curve. And one of the most important of this time. Yet vendors continue to sell the destination. Yes, it’s technically valid and an exciting place to be, but also practically out of reach for most organisations today. Largely because we are in a transitional age of computing, and once again in too much of a rush to get there.

What’s missing is simply clearer starting points. And I can’t for the life of me understand why more vendors don’t take a beat and realign around this fundamental assumption. It’s time to rebalance the rhetoric. Less about where the plane or train is going and more clarity on the airport or platform where I can step on.

Share

When it comes to AI, it’s more useful to think of SMB not as a cut-down version of the enterprise, but as the starting point of one. That matters even more today, as enterprise buying centres have become increasingly fragmented. That is why the AI platforms that will define the next operating model are the ones built to carry organisations through that journey, as their work gains complexity and consequence.

Take identity as an example. A business might begin with a simple login, minimal governance, and little or no integration. At that stage, identity doesn’t meaningfully constrain agentic capability. Because both are naturally limited to low-consequence workflows. So you can adopt a solution that will allow you to perform Level 1 or 2 AI.

Now as the organisation grows, so does the complexity of its work. More systems are added (swivel chair work begins). More customers. More transactions. More exposure. Identity starts to evolve. From simple login, to managed access, to SSO, to a fully governed identity platform. Workflow becomes more structured. Decisions begin to carry a lot more consequence. That requires AI at a Level 3 or 4 maturity, perhaps now in the form of an Agent, to remain useful, and evolve with it. Ideally without changing the underlying AI platform.

That is a pathway. From point of entry to escalating maturity.

And I think this is the quiet logic behind Salesforce’s tiered SMB model. From free to starter, to professional, to enterprise, to more advanced agentic capability, the platform and its licensing model, is not just scaling features. It is scaling the step conditions, up to a tipping point, from which AI in the form of agents, can be trusted to execute.

For big or small organisations, that journey can take years and reflects something deeper about Agentic AI. That it is not just about what the agent can do but about what the organisation is ready to let it do.

This is where the broader market narrative starts to quickly break down. Because we’ve become conditioned to look for immediate proof of value of high-maturity capabilities. Where only fast adoption and instant capability can deliver visible impact within a reporting cycle.

But that’s not how platforms like Salesforce create value. They create it over time. As organisations grow into them. As their work becomes more structured. As identity matures. As governance strengthens. As more consequential workflows move onto the platform. The value compounds. Not because the technology changes overnight, but because the conditions for using it evolve.

That kind of progression doesn’t show up cleanly in quarterly narratives. But it is exactly the kind of pattern long-term investors have always looked for. The ability to build with the customer, not just sell to them. In that sense, the slower journey is not a delay. It has always been the model.

In the early stages of that journey, the scope of what can be trusted remains narrow. Which is why most of what we are seeing today is still operating in the efficiency layer. AI can remove some friction and speed up some navigation. Maybe even reduce the effort required to move between systems. But it is still operating around the edges of work.

This doesn’t change the view that the real AI shift begins when agents move into workflows that carry consequence. At this level of maturity (5 or 6) a payment is no longer just a transaction, but financial authority. A service request is no longer just a ticket, but a commitment tied to service levels, risk, and compliance. And a system change is no longer just an update, but a controlled alteration to a live operating environment (managed behind the scenes by a service ontology).

Now the agent is no longer assisting. It is participating. And participation requires structure. This is where identity changes form. It stops being about access and becomes about authority. Who can act, under what conditions, with what level of accountability. Without that, the agent can suggest but it cannot execute. This is the boundary most organisations, nor technology vendors, especially legacy ERP vendors, have not yet crossed.

Not because they lack technology, but because they have never fully defined how work actually happens. It sits fragmented across systems, buried in process documents, or held in the heads of individuals. More mature Agentic AI exposes that immediately. It doesn’t fail because the model is weak but because there is nothing coherent for it to act within.

But nobody starts there. And this is why the SMB success stories matter right now. Not because they prove agentic AI is simple. But because they show where it starts. The real test is for both the vendor and the client is still going to be what happens as those organisations grow. Because that is where agentic AI stops being easy. And starts becoming accountable.

So the winners will not be the platforms with the simplest generative interface or the most capable agents. They will be the ones that understand where to start. The ones that can meet organisations at their point of entry and grow with them over time. The ones closest to the flow of work. The ones that can bind workflow, identity, and data into something that can actually hold responsibility, without requiring constant reinvention (or system replacement) as that work matures.

Two comments came up in an analyst call this week that immediately stuck with me.

“Customers want a neutral, independent identity platform
that can be easily deployed and support the maximum number of use cases,
particularly as they begin to introduce AI into workflows and business processes.”

“Agents are emerging as a new identity type,
and organisations now need to figure out how to govern them.”

It took me a few minutes to work out why they didn’t quite land with me. When taken in isolation both are true. But I think they also make it too easy to assume the problem begins with identity. And that’s the part worth challenging upfront, for the benefit of both customer organisations and technology providers.

The first could lead someone to assume that organisations are ready to drop AI into workflows, as if those workflows already exist in a coherent, structured form. They don’t. The second could lead someone to assume that agents are primarily a governance problem, as if their existence is what creates the need for control. They are not. In reality, I think both are downstream effects of something else entirely. Work.

Organisations do need a neutral identity platform. But not because they’ve decided identity is important. They need it because work has become fragmented across systems, channels, and now increasingly across humans and machines. The moment work starts to span boundaries, identity becomes operationally difficult. The same applies to agents.

Agents are not interesting because they are a new identity type. They are interesting because they are a new form of work execution. They take actions. They trigger processes. They make decisions, or at least simulate them. That is what forces identity into the conversation. Not their existence, but their behaviour.

If an agent never acted, it wouldn’t need an identity. It would just be software. The identity requirement emerges the moment the agent participates in workflow. This is the context that often goes missing. No work, no identity.

The identity platform market is not expanding again because identity is evolving. It is expanding because the nature of work is changing. The last time identity surged was with SaaS, when the problem was access. It was all about getting the right people into the right systems.

This is very different. AI is not increasing access. It is increasing action. More interactions, more autonomy, more delegation. Identity is being reintroduced as a problem because something now needs to govern all of that movement.

That’s why the idea of a neutral identity platform resonates and why platforms like Okta are a strong day one choice. Not because neutrality is inherently valuable, but because organisations are struggling to maintain control across an increasingly heterogeneous environment. Multiple systems, multiple vendors, multiple execution layers. Identity becomes the only thing that can sit across all of it.

But even then, it is still responding to something else. The deeper question is not how to govern agents. It is what work those agents are being asked to perform, and whether that work is actually understood, structured, and worth automating in the first place.

Because if the underlying workflows are still fragmented, manual, or poorly defined, then introducing agents does not create value. It simply accelerates inconsistency. And wrapping that in a strong identity model does not fix it. It just makes it governable. Yo end up with controlled chaos.

This is the pattern that is starting to emerge. Identity vendors are correctly identifying that the world is becoming more complex, more distributed, and more autonomous. They are positioning identity as the layer that brings order to that complexity. But the complexity itself is not coming from identity. It is coming from work that has outgrown the structures designed to support it. Which leads to a more grounded way of thinking about it.

The next phase of the market will not be defined by identity alone, but by how clearly it is connected to the work it is there to govern. The identity vendors that recognise this best, and are most articulate about anchoring their story in workflow, action, and outcomes, will find themselves riding a much larger wave. Because identity does not create the demand. Work does.

Identity scales as work scales. It becomes more critical as work becomes more distributed, more automated, and more autonomous. But it is always responding to something else. So the opportunity for identity providers is not to compete for primacy, but to align more directly with where value is actually created. To move closer to the systems and platforms where work is defined, executed, and increasingly delegated to machines. Done well, this will not diminish identity but amplify it.

Because when identity is tied to action (who or what is allowed to do something, not just access something) it becomes part of the operating model, not just the control layer around it. And that is where the market expands. Agents make this unavoidable. They are not a new identity problem, but a new form of work execution. And as that work scales, identity is pulled into it. Which is why identity and workflow cannot stand apart for long.

An identity layer without coherent workflows has nothing meaningful to control. A workflow layer without identity has no safe way to scale. They are not competing abstractions. They are interdependent as I called out in the Whatever-as-a-Service post.

The organisations that recognise this will stop treating identity and workflow as separate domains, and start treating them as two sides of the same operating model. One defines what can happen. The other defines who or what is allowed to make it happen. This is where the market is heading.

Platforms like ServiceNow and Salesforce are expanding identity capabilities because they need control over the work they orchestrate. Identity providers like Okta are moving closer to workflow because they need context to remain relevant. The centre of gravity is shifting toward the intersection. And in an agentic world, that intersection becomes the system.

Agents don’t just need identities. They need roles, permissions, and boundaries tied directly to the work they perform. That requires more than authentication. It requires a shared understanding of entities, states, and actions. That’s an operational ontology that both identity and workflow systems can interpret in the same way.

Without that, identity and workflow drift apart. With it, they reinforce each other. Which is why the likely winners will not be those who dominate one layer in isolation, but those who align both. Not simply around access or automation but around coordinated, governed action. That is where the real value sits.

Behind all of this sits a relatively well-defined group of control-plane identity providers. But the strongest will no longer be those with the best integrations. They’ll be the ones closest to the flow of work. For paid subscribers, I’ve put together a short view of where I think the major vendors sit today against this shift.

Read more

Everyone says you can’t do artificial intelligence with bad data. And at face value, the argument seems reasonable. But what is the answer then? We can’t simply keep repeating that transformation will take longer than expected without a clearer explanation of how fragmented enterprise data, with all its inconsistency and incompleteness, is supposed to be fixed before AI can safely operate.

And what about the organisations with messy data that are already beginning to see real operational value from AI platforms? Not through chatbots or document summarisation, but through automation, orchestration and decision support embedded directly into enterprise workflows. How does that make any sense?

Well, as it turns out, it is precisely this contradiction that reveals the deeper truth. The biggest barrier to AI inside most organisations has never been bad data. It is that they have never clearly described how the relationships actually operate between people, systems, approvals and the work that flows between them.

Enterprise technology has long been dominated by the simple assumption that systems require clean data. This belief emerged from the era of enterprise resource planning where systems were designed to execute deterministic transactions. If the underlying data was inconsistent, the results could not be trusted. That was fine for a generation, but the same assumption has carried forward into the AI era almost without question.

But artificial intelligence does not simply operate on tables and records. It operates on meaning. And that requires us to stop thinking about this technology in the way we have managed enterprise systems for the past thirty years.

For AI to perform real work inside an organisation, it must understand several things at the same time. It must know what objects exist in the enterprise, how those objects relate to one another, who has the authority to act on them, and how work moves between them. That’s what I mean by understanding the relationship structures of the organisation itself.

We’ve all worked for organisations that have never formally defined these relationships. They exist implicitly inside systems, processes and job descriptions, but rarely as a coherent model of how the enterprise actually functions or behaves. That model has a name. An ontology. And without that model, artificial intelligence is forced to improvise.

Ontology is a word that sounds abstract and so it is rarely used even by the companies that have great ontological solutions, and almost never in executive company. But the concept is straightforward. It is simply the structured representation of the things that exist in an organisation and the relationships between them.

A council, for example, operates around concepts such as citizens, properties, permits, assets and service requests. But the important thing is not simply that these records exist in systems (as a data model). It is how they relate to the work of the organisation.

A citizen may own a property. That property may require a permit before certain activities can occur. A permit must be assessed and approved by an officer. An inspection may later confirm that the conditions of that permit have been met.

Taken together, these relationships describe how the organisation actually operates, how decisions are made, who is responsible and how work flows across the council. Without that structure, artificial intelligence is left guessing or hallucinating. It can see the records, but it cannot understand the work.

Language models don’t fix this. Even connected to the right documents it can only summarise policies or generate reports. But what it cannot do alone is safely execute work across systems, departments and authorities. It does not know which team owns a service, which role must approve an action or how a process should unfold. Those rules do not live in the data alone. They live in the meaning of the enterprise. And meaning is the currency of AI. Said another way, AI runs on infrastructure but it operates on meaning. It’s just that most organisations have never actually modelled what their organisations mean.

So how did we get here? We can all agree that the cloud revolution dramatically expanded the number of systems inside organisations. It has been an appslosion! Sales teams adopted customer platforms, HR teams adopted workforce systems, finance departments moved to cloud ERP solutions and collaboration tools multiplied across the enterprise.

It’s a phenomenon I call “Whatever-as-a-Service”. A decades long application frat party. Connectivity improved dramatically but organisational meaning did not. It actually got worse. Each system introduced its own definition of the world. A “customer” in one application became an “account” in another and a “ratepayer” somewhere else. Integration platforms allowed data to move between these systems, but they rarely reconciled their underlying semantics.

We humans have quietly resolved these inconsistencies through experience and context, not architecture. But Artificial intelligence cannot. For AI to operate safely, the enterprise must first be represented somewhere as a coherent model of objects, relationships, authority and process. But where? This is where platforms like ServiceNow begin to change the conversation.

They have gradually assembled a structure that resembles an operating environment for enterprise work. Through frameworks such as the Common Service Data Model (CSDM) and the Configuration Management Database (CMDB), it is the role of the platform to model relationships between services, applications, infrastructure and teams. Incidents impact services. Services support business capabilities. Teams own responsibilities. Workflows define how requests are approved, escalated and resolved. What emerges is not simply a data platform, but a representation of how the organisation behaves.

You can see this clearly in some of the publicly available architecture diagrams. The ontological elements I am talking about in this article do not sit purely within a data model or the organisation’s systems of record.

Instead they appear in what ServiceNow describes as the semantic and intelligence layers of the platform. This is the connective tissue that ties enterprise data, workflows and AI together. It’s the secret sauce your systems architecture is probably missing if you want to do AI well.

That ontological representation of the business provides something more valuable than perfectly structured data. It provides operational coherence. And when relationships between services, teams and responsibilities are clearly defined, work can move predictably through the enterprise even if the underlying data describing those objects remains imperfect.

Incidents can still route to the responsible teams. Approvals can still reach authorised managers. Changes can still propagate through dependency structures. The ontology stabilises the environment. Which brings us back to the point. Perfect data may be desirable but ontology is essential.

Another critical component of enterprise ontology lies in identity systems. Platforms such as Microsoft Entra or Okta maintain a living map of organisational authority. They define who belongs to which teams, which systems individuals can access and which roles they perform. Those relationships quietly encode part of the enterprise’s operating structure.

For artificial intelligence, this authority layer is essential. An AI system cannot safely approve a payment, provision an employee account or modify a record unless it understands who is authorised to perform those actions. Governance therefore becomes structural rather than procedural. Security, identity and workflow together form the guardrails within which intelligent systems can operate.

Newer AI-native platforms are beginning to recognise this pattern as well. Systems such as Glean (in Australia, via Journ3y), construct knowledge graphs that map relationships between people, documents and projects across collaboration tools. Rather than attempting to impose a new security model, they inherit the permissions already defined in identity and collaboration platforms. If a document is accessible in its original system, it remains accessible in the AI environment. The insight is simple but powerful and this kind of leaning into the identity ontology approach underpins their growing success.

What this also reveals is that the meaning of the organisation can already exist in some places. It is simply scattered across systems, permissions and workflows. The challenge is therefore to surface those relationships. Once they are visible, the AI models themselves that feed the ontological structure become interchangeable. That’s why every big vendor is partnering with every AI model. It’s because ultimately the ontology becomes more important than the model.

The enterprise technology industry spent decades believing that clean data was the prerequisite for effective systems. It’s ok to say, structure the work first, and the data will eventually follow.

This shift carries another implication that the enterprise software industry has begun to recognise. Best-of-breed approaches to software work because humans reconcile the differences. AI cannot without a platform. Artificial intelligence operates far more effectively within environments where objects, relationships and authority are clearly defined. That environment increasingly emerges around platforms capable of modelling enterprise meaning. It’s part of the (very nuanced) argument discussing the “death of SaaS”.

Once such a platform exists, other systems begin to orbit around it. Workflows attach to it. Identity integrates with it. AI agents execute within it. Because ontology has gravity. Not AI. But AI is what captures attention. Ontology is what actually holds the system together.

This is why ServiceNow, Salesforce and Palantir are becoming strategically very very important. They are not simply applications. They are evolving to systems of meaning. And once an organisation begins to depend on a system of meaning, endlessly assembling best-of-breed tools (whatever-as-a-service) starts to lose its economic, financial, and technical appeal.

The bottom line is that we need to think differently about this. For decades we have pursued systems of record where the challenge was believed to be storing information correctly. Artificial intelligence forces a different question. It is no longer about where the data lives but whether the organisation has ever explained what the data means.

Therefore before machines can run the enterprise, someone must describe how the enterprise behaves. That description is not just a bunch of data schemas and lakes. It is an ontology. And the organisations that recognise this will discover that the biggest obstacle to AI was never bad data but understanding themselves.

That said, the answer to all this is not “buy a platform”, though I am glad that platform is now a broadly accepted conversation. It is more like “choose your entry point to platform.” That means identifying coordination failures within the business (problem statement). These coordination failures are usually the result of missing ontology.

I’ve included a simple example below. It reflects the kind of issue that commonly emerges during staff workshops and consultation when organisations are considering new systems. In one organisation we identified around thirty of these coordination problems in just a couple of days.

Let’s consider a common coordination failure like employee onboarding. In many organisations, provisioning a new employee across HR, payroll, finance, identity and IT service systems can take several days.

1. Coordination problem: Employee provisioning takes five days.

2. Desired outcome: Reduce onboarding time to two hours.

3. Why AI alone fails: AI cannot resolve cross-system discrepancies or coordinate approvals across multiple systems without understanding how those systems relate to each other.

The starting point is not the (new system or) platform. It is defining the ontology of the employee domain. That means identifying the core objects and relationships involved like employee, department, role, system access and approvals, and how they relate to one another. An employee belongs to a department. A department grants certain roles. A role determines which systems the employee should access and which manager must approve that access.

Once that structure is defined, the systems can be mapped against it. HR, payroll, finance, identity and IT service management platforms each manage part of that model, but none of them represent it completely on their own. The ontology provides the common structure that allows those systems to coordinate.

This is where platforms like ServiceNow become important.

Inside ServiceNow, those objects can be represented explicitly. An employee record may originate in the HR system, but ServiceNow can model the relationships between the employee, their department, their manager and the services they require. The platform’s data structures, including the configuration management database and related service models, allow those relationships to be expressed consistently across workflows.

Once the objects and relationships are visible, the missing capability becomes clear. Orchestrate the workflow across systems. That is the “simple” answer most execs want.

Using workflow automation and integration capabilities, ServiceNow can trigger provisioning steps across the relevant systems. HR creates the employee record. Identity systems provision accounts and access. IT service workflows allocate devices and system permissions. Finance systems configure payroll records. Approvals are routed automatically to the correct managers based on the defined relationships. So instead of integrating systems in isolation, the platform orchestrates the workflow across them.

At that point AI becomes useful. An AI agent can monitor the onboarding process, detect failures when provisioning steps break, investigate discrepancies between systems and recommend or trigger corrective actions. What previously required manual coordination across several teams can collapse into hours.

The larger point is that employee onboarding is only one example. Once organisations begin mapping coordination failures in the employee domain, a much broader pattern usually emerges.

In workshops and operational reviews across several organisations I’ve worked with, we routinely identify dozens of workflows that suffer from the same underlying problem. Work spans multiple systems, roles and approvals, but no single structure exists to coordinate them.

Examples include the creation and approval of position descriptions, recruitment workflows covering advertising, interviews, references and medical checks, employee induction processes including compliance training, leave request approvals, employee issue or case management, professional development requests and reimbursements, performance appraisal cycles, talent and skills searches, promotions and transfers, employee offboarding, and routine activities such as timesheet submission and approval.

Each of these processes touches multiple systems and involves several roles across the organisation, especially after more than a decade of whatever-as-a-service. Viewed individually they appear to be isolated workflow problems. Viewed together they reveal something more fundamental. The organisation lacks a shared model of how employee-related work flows across its systems.

This is where ontology begins to take shape. Each coordination problem exposes another part of the enterprise model that needs to be defined from the objects involved, the relationships between them, the authority required to act and the workflows that move work forward.

Over time those fragments accumulate into a coherent ontology of the employee domain. But that only works if the organisation has a platform capable of orchestrating across systems once those relationships are defined. Without that capability, the ontology remains theoretical. With it, the coordination problems begin to collapse.

That’s the power of a platform like ServiceNow. With or without clean data.

Everyone is racing toward an AI-enabled future state, but most organisations are working on the wrong problem first. The real challenge of 2026 is not model capability, agent maturity, or responsible AI frameworks. It is the far harder work of changing the ERP-centred operating model that still sits underneath almost every enterprise. AI will arrive regardless. The question is whether organisations will be structurally ready for it. And who is accountable for making them so.

For decades, ERP has been the gravitational centre of enterprise technology. Not just as a system of record, but as the implicit organiser of work, authority, and accountability. Processes were designed around its constraints. Humans filled the gaps. Control lived in people as much as in systems. That model worked until intelligence began to move into the machine.

AI does not fit neatly into an ERP-centred world. It does not tolerate implicit intent, fragmented state, or human-held orchestration. When dropped into these environments, AI does not transform them, it compensates for them. So humans remain in the loop not because judgement is required, but because the operating model cannot yet stand on its own.

That is why the real AI task in front of us is architectural, not algorithmic. To reach a future where AI can act, not just advise, organisations must first decentre ERP as the organising principle of work and reframe it as a still critical but bounded system of record within a broader platform architecture. This is not about replacing ERP. It is about relieving it of a role it was never designed to play.

The inevitable AI future state cannot be achieved by layering more intelligence on top of yesterday’s operating model. It can be achieved by doing the harder, less glamorous work of redesigning how intent, flow, and authority are expressed across the enterprise. That is the real AI challenge of 2026. So let’s get busy changing the world.

One of the quiet failures of 21st-century enterprise technology so far is that we keep using 20th-century language to describe it. “Human-in-the-loop” is the latest perfect example. It is usually presented as wisdom. A familiar sign that an organisation understands the limits of automation and prudently respects the role of its people. In reality, I think it really signals something far less noble.

When AI strategy or product selection depends on humans remaining in the loop to make the system work, the problem isn’t ethics or caution, it’s architecture. What you’ve really done is extend an ERP operating model, wrapped it in AI, and moved it onto modern infrastructure.

AI has exposed the limits of application sprawl, outsourced responsibility, and ERP-centred thinking, all relics of a 20th-century operating model that no longer holds. The irony is that the one construct we should have preserved to manage this complexity, the CIO as a true technology leader, has been steadily dismantled at the very moment it is most needed.

For most of the modern enterprise era, systems were built around transactions, not flow. Work happened because a human initiated it, pushed it forward, interpreted exceptions, and absorbed ambiguity. Technology recorded outcomes. But people carried the intent of the transaction. ERP systems formalised this worldview.

Byut they were never designed to run organisations autonomously. They were designed to support human-led execution. Roles, approvals, screens, handoffs, and controls all assumed that a person sat at the centre of the loop.

When AI is layered onto this environment, it does exactly what you would expect. It becomes expontentially smarter at the edges. It summarises, explains, recommends, and reassures better than we can. It improves interaction without changing the underlying structure. So humans stay in the loop. They approve what the system cannot approve. They escalate what the system cannot interpret. They stitch together what the architecture cannot orchestrate.

This becomes a serious problem at scale. Boards, whether public or private, exist to govern systems that must operate reliably, repeatedly, and under pressure. Not once. Not in a pilot. Not in a demo. At national or enterprise scale, with failure modes that are political, legal, financial, and human. We’ve seen this before as part of every significant 21st century change.

Rolling out a national vaccination program is not a communications exercise. It is a system-of-systems problem involving supply chains, identity, eligibility rules, appointment scheduling, exception handling, adverse event reporting, and public trust, all operating under intense scrutiny and time pressure. Boards were not asking whether the intent was ethical. They were asking whether the system could withstand volume, variation, and failure without collapsing.

The same is true of the shift to digital driver licences. Once a digital licence becomes a primary credential, it must work everywhere, all the time. Offline, across jurisdictions, under enforcement, and in edge cases the designers never anticipated. A board does not care that the user experience is elegant if the system fails during a roadside stop, a disaster response, or a court proceeding. Reliability and accountability are non-negotiable.

Or take the current nationwide KYC and identity reforms in Australia. These are not digital initiatives. They are foundational trust infrastructures. When onboarding fails, payments stall, benefits are delayed, or fraud scales faster than control, the consequences are immediate. Bank boards are not reassured by good intentions. They want to know where authority sits, how decisions are enforced, and who is accountable when the system makes, or enables, a mistake.

In all of these cases, humans are involved, but critically, not because the system would otherwise fall apart. They are involved because judgement, discretion, and oversight are genuinely required at the edges. The core system is designed to stand on its own. Human involvement enhances it; it does not prop it up. That is the standard boards apply. Which is why this matters so much in AI discussions.

When AI-enabled systems are presented to boards with the reassurance that humans are in the loop, but without clarity on whether those humans are adding judgement or simply preventing failure, boards are being asked to underwrite risk without being shown the architecture. That is not how large-scale systems are governed. Boards understand the difference between human oversight and human dependency. One is a strength. The other is a liability. But the distinction is not always made explicit in how AI is presented to them. And at scale, that distinction is everything.

At scale, boards care less about intent than about exposure. When something goes wrong, they actively look for where control actually sat and who carried the consequences. If a system cannot function without humans, accountability does not sit with the technology, it sits with the people. And boards rarely tolerate hidden accountability.

Hidden accountability is risk. Diffuse accountability is risk. Implicit accountability is risk. This is why failing technology initiatives so often become personal at board level. Failure exposes whether control ever truly existed. Boards do not fund virtue. They fund capability, control, and outcomes.

On the factory or the trading floor, responsibility has very little to do with whether a system needs human intervention to function. Architecture does. And so this brings us to where platforms fundamentally break with ERP thinking.

A real platform is not defined by UI, licensing model, or cloud credentials. It is defined by where control lives. In a platform environment like ServiceNow, control is designed to live in the architecture, not in people’s heads or inboxes. Workflow is explicit, not implicit. State is durable. Authority is delegated, not implied. Policy is externalised from process. Integration is transactional and observable. The truth only lies at a modular level.

Every serious platform converges on the same capabilities, and notably, these are platform-as-a-service constructs, not ERP ones. Explicit workflow orchestration (e.g. Servicenow’s Flow Designer). Transactional integration (e.g. IntegrationHub). A trusted model of operational reality (e.g. CMDB). Enforceable policy and security controls. Not because vendors agree, but because autonomy demands that policy and decision logic exist so rules stop being folklore and start being code. Without these foundations, AI can reason, but it cannot be trusted to act.

These are not additional products or services to be included in an ERP roadmap. They are the structural foundations on which autonomy depends. And when they are absent or immature, humans must step in to compensate. Humans become the workflow engine. Humans become the integration layer. Humans become the permission model. Humans become the exception handler.

The real outcome is that humans in the loop has never been about man-machine collaboration. It’s a cover for unpaid architectural debt. And this is why so many early conversations about agentic AI have felt underwhelming.

The agent can look and sound intelligent. It can analyse, categorise, plan, and make suggestions. But when it comes time to act, it often can’t. The ERP-centric environment it lives in doesn’t give it real authority, clear boundaries, or end-to-end accountability. So the work stops at the screen. A human has to step in and finish the job. The demo looks impressive, but the client operating model underneath hasn’t actually changed.

For much of last year this was explained away as ethical restraint, and while it is true that reality is never black and white, in many cases, that language is masking a more uncomfortable truth. The architecture (of some solutions) and many organisations simply isn’t ready yet.

When presented to customers by a technology provider early in their AI maturity curve, human-in-the-loop is not a sign of wisdom. It’s a sign of platform limitation. Only later, when the system can operate reliably on its own, as it adopts more PaaS-centric models, does keeping humans in the loop become a genuine design choice, and a source of strength.

In immature environments, humans are in the loop mostly because the system cannot be trusted. In mature environments, humans are in the loop because their judgement is genuinely valuable. Those two states look identical on a governance slide whereas they could not be more different in reality. Most of the high-profile failures of 2025 sit squarely in that gap when organisations convinced themselves they were in the second state while still operating firmly in the first.

One means humans are propping up brittle systems or solutions. The other means humans are governing autonomous ones. Which brings me back to the beginning. The entire purpose of a platform is to enable the once in a generation transition wea re living through in real time.

This is not about removing humans. It never was. It is about relocating humans to where 21st-century organisations actually need them. Not as workflow glue. Not as integration buffers. Not as permission proxies. But as stewards of intent, ethics, accountability, and outcomes.

When platforms mature, humans move out of execution and into governance. They become orchestrators. They stop making the system work and start deciding how it should behave. That is also when AI stops being dangerous. Not because it is constrained, but because it can be contained by architectural design.

The opportunity is to move beyond an ERP-centric operating model, not to abandon ERP altogether. ERP isn’t going away. But it is being moved out of the centre, because organisations are now dealing with a genuine three-body problem between ERP, PaaS, and AI. Each exerts force on the others, and none can dominate without creating instability. ERP’s role is to remain a system of record, not the system of control. The centre of gravity is shifting toward platforms that can express intent, orchestrate work, and delegate authority across the estate, with AI operating inside those boundaries.

Regardless of which industry you operate in, crossing that threshold does not start with more AI. It starts with an honest reassessment of the operating model itself and a willingness to accept that the future of ERP is as a critical component of the value chain, but not its organising principle. That is not a loss of control. It is how control is regained for the next era and it should rewrite most procurements from this year forward.

Enterprise technology buyers are being told a comforting story. Artificial intelligence, we are assured, can be bought, licensed, and governed much like the systems that came before it. Enterprise licence agreements, flexible consumption pools, and familiar commercial constructs promise to make AI feel legible and safe. Salesforce’s Agentforce Enterprise Licence Agreement (AELA) is a good example of this intent. It is not a gimmick. It is a solid and sincere attempt to meet customers where they are.

The problem is not that these models are wrong. They are right for now. But that is also precisely the issue. They are transitional. They wrap a fundamentally different economic creature in the language of a world that no longer exists. Traditional total cost of ownership (TCO) was built for software that behaves like an asset. Agentic systems behave like labour. And that distinction matters more than any pricing model.

For decades, TCO has been an exercise in containment. Organisations estimated licence costs, infrastructure, integration, and support, then spread that cost across users or transactions. Performance improvements were welcomed because they reduced run costs. Efficiency meant savings. Usage broadly tracked value, and behaviour was bounded by human attention, working hours, and organisational friction. Agentic systems break every one of those assumptions. How and why?

An agent does not wait to be used. It acts. It retries. It escalates. It triggers other systems. It improves over time and continuously operates. Cost is no longer driven by access but by behaviour. In traditional systems, better performance was efficiency driven to reduce cost. Whereas in agentic systems, the more capable an agent becomes, the more it does. So better performance often increases use. This is where familiar TCO models quietly fail.

An organisation may deploy an agent to reduce case handling time, improve resolution rates, or increase customer satisfaction. All of those outcomes can be achieved. Yet the same improvements can also drive higher system interaction, greater orchestration complexity, more monitoring, and increased downstream activity. The agent becomes productive, but not necessarily cheap.

That creates the new TCO question. Are we paying for fewer actions or for better outcomes? The difficulty is that even this framing assumes a level of comparability that rarely exists. I’m sure the model enthusiasts reading along have already quietly objected to the efficiency argument.

But I agree. Two organisations can deploy the same agentic process, on the same platform, under the same commercial model, and experience materially different economics. One may operate with clean data, minimal workarounds, and low regulatory friction. Another may require multiple exception paths, manual validations, and heavy oversight. The agent performs the same “work,” but with very different efficiency, risk, and cost profiles. That doesn’t change the argument that traditional TCO has no way to account for this because it was designed to price systems, not organisational complexity.

This is why agentic cost benchmarking remains elusive. What looks like an AI efficiency problem is as much an operating-model problem in disguise. That is a management consulting problem and the result is the ensuing economic fog.

Customers want AI. Boards expect it. Executives feel pressure to adopt it. Yet few organisations truly understand how to model its long-term cost, let alone govern it. Everyone is struggling to determine whether to buy capacity, consumption, outcomes, or something in between. The language of tokens, actions, and autonomy feels abstract and risky.

To this point vendors have only been able to respond rationally. They have to offer what sounds safe and familiar. Enterprise licence agreements. Flex pools. Commitments that resemble what procurement teams already know how to approve. These constructs are not cynical. They are necessary bridges. They allow organisations to step into agentic territory without immediately confronting the fact that the ground rules have changed. But the ground rules have changed.

In many ways, this challenge should feel familiar. It is the same problem organisations have wrestled with for decades in business process outsourcing and managed services. Cost outcomes were never determined solely by the contract rate card. They were shaped by process maturity, regulatory burden, exception volume, and the level of oversight the organisation itself required. Two customers could outsource the same process and experience radically different economics. Agentic TCO brings that same reality into software.

At this point, it is important to be precise. Not every layer of an AI-enabled platform behaves the same economically. Foundational PaaS capabilities like workflow engines, data models, and integration layers can still be governed and amortised like traditional software assets. Their cost curves are familiar, and their value can be planned. The discontinuity appears at the point where agency is introduced. Once software is empowered to act, decide, and initiate work, cost becomes behaviour-driven rather than asset-based. This is why vendors are carving out separate commercial constructs for agentic capability. It is not an admission that platform pricing is broken, but an acknowledgement that agency cannot be priced in the same way as software.

Agentic TCO is not about ownership. It is about economic governance. It shifts the focus from controlling access to controlling autonomy, from budgeting per user to budgeting per action, and from minimising cost to constraining behaviour. That shifts the dominant cost drivers from licences and infrastructure to decision loops, orchestration logic, exception handling, guardrails, and oversight. These become operating costs, not implementation artefacts, and they tend to grow with success rather than diminish over time.

Let me beat my old drum again. This is why platform architecture matters. Agentic systems do not sit neatly inside application silos. They require a platform layer that can observe, govern, throttle, and evolve behaviour across systems. This is not an ERP problem. It is a platform-as-a-service problem. PaaS becomes the economic trunk through which agentic activity flows, whether organisations acknowledge it or not.

So what we are witnessing is a market in transition. Customers are being sold AI using commercial models designed to reduce anxiety, while vendors quietly pivot toward a future where agency, not software, is the unit of value. Enterprise agreements like Salesforce’s AELA are part of that necessary bridge. They help organisations begin the journey by uncapping some of that agency. But even they will admit that they do not yet resolve the underlying economic ambiguity at free agency scale. No one has.

The bottom line is that agentic AI cannot be priced and governed like software. It must be governed the way work is. And until organisations accept that shift, total cost of ownership will remain an estimate rather than an insight. Is it still worth pursuing? Absolutely! The shift is simply this. Where traditional TCO asked what a system costs to own, agentic TCO asks what it costs to let software act on your behalf.

I think we all get that part of the discomfort to this point comes from a reluctance to talk about AI taking jobs. Framed that way, the conversation becomes politically charged and emotionally loaded. In practice, agentic AI is not taking jobs. It is taking work. The tasks and decisions that were previously performed by people. That distinction matters, because work can be delegated, reallocated, and governed in ways that jobs cannot.

Agentic AI is not difficult to price because vendors lack models, but because enterprises have not yet accepted that they are buying delegated work rather than tools. So try reframing the way you are approaching those business cases. Everything else is just a negotiation over how long we pretend those two questions are the same.

Share

The Top 10 Questions to Start Costing Agentic AI

Costing agentic AI is not difficult because the technology is new, or because vendors lack pricing models. It is difficult because organisations are trying to apply asset-based thinking to something that behaves like delegated work.

Traditional TCO models assume comparability, predictability, and efficiency gains that reduce cost over time. Agentic systems violate those assumptions. Their costs are shaped as much by organisational complexity, governance choices, and operating discipline as by software consumption itself.

The questions below are not designed to produce a perfect number. They are designed to surface where agentic AI will behave unlike traditional software, where costs will scale with success, and where economic exposure is likely to appear. Without answering them, any TCO model will be incomplete, regardless of how familiar the commercial wrapper looks.

They focus on the agentic (probablistic and variable) layer of the platform, not the underlying PaaS foundations, which can still be governed and amortised using traditional asset-based TCO models. They are based on the premises that you can’t cost what you can’t see, you can’t budget what you can’t limit, and you can’t govern delegated work without ownership.

At scale, organisations are likely to require a control layer that can observe, constrain, and govern agentic behaviour across systems. Such control mechanisms should not be viewed as a product trend, but as a structural response to the economic realities of delegated work operating at machine scale.

Read more

2026 is not the year of AI adoption. It is the year organisations start treating platforms as minimum viable operating systems for work. That reframing explains why 2026 represents a more consequential year for ServiceNow than 2025. Not because anything is accelerating, but because the platform’s role is now clear.

In 2025, AI was widely used to rationalise ServiceNow’s acquisitions, software contract evolution, and platform expansion. In reality, AI was not the objective. It was the forcing function. What mattered most was that, under that pressure, ServiceNow continued to complete the foundational capabilities required for autonomous execution. That is, the foundations required to act.

In practical terms, AI did not clarify ServiceNow’s role. Platform coherence did. The ability to translate AI potential into operational reality requires a level of platform maturity that few enterprise vendors have reached.

ServiceNow’s 2025 acquisitions and platform investments followed a consistent and deliberate logic. Capabilities such as data.world strengthened data context so decisions could be grounded in trusted information. Veza extended identity authority so actions could be taken safely and with clear permissioning. Moveworks established a natural enterprise entry point, allowing work to flow into the platform without friction. Armis expanded visibility into exposure and risk so automation could be corrected in motion rather than after the fact. Together with workflow intelligence embedded across the platform, these moves allowed ServiceNow to understand what actually happens in the enterprise, not just what process diagrams suggest should happen.

None of this was about adding features. It was about closing the gaps that required humans to stay in the loop. Human-in-the-loop is frequently presented as a safety measure, but in most environments it reflects the limits of platform maturity. Where systems lack reliable data, consistent workflow logic, clear authority, and enforceable policy, human oversight is not a choice. It is a workaround.

By the end of 2025, those gaps have been underpinned. And what has now emerged is not simply a broader platform, but something more specific. A benchmark for a minimum viable operating system for execution and governance. Whether you are talking about the NOW platform itself, or elements like Control Tower, or even lesser functional solutions, the execution and governance narrative is consistent and strong.

With that in place, this is where platform licence tiering needs to be understood differently by contemporary enterprise buyers.

For many years, tiers have been interpreted primarily as commercial packaging. Higher costs exchanged for more modules, more functionality, and a broader set of use cases. That framing made sense when the platform behaved largely as a collection of applications.

But moving forward, licence tiers will describe something far more fundamental. They will define the minimum operating baseline required for the platform to function as a coherent system.

Identity, core workflow, trusted data context, policy enforcement, and observability will no longer be optional capabilities. They will be the pre-conditions that must be in place before automation can be relied upon to safely act with consistency. Seen through this lens, higher tiers do not simply add capability. They actually expand delegated authority. Those that work in highly regulated industries know just how consequential the concept of “expanded delegated authority” is. It is everything.

In the context of the PaaS market, forget technology for a second. Expanded delegated authority widens the scope within which the platform is permitted to execute work autonomously. It allows activity to move across more organisational domains without constant human supervision. It enables the platform to act, not merely recommend.

So what organisations are really choosing at each tier is not how much software they want to license, but how much execution they are prepared to delegate. That is a very different commercial conversation, and a far more productive one, because it shifts the discussion from software cost to outsourced business value, where financial return can be more honestly assessed by the non-technical buyers that prolifierate in today’s large enterprises.

That is why ServiceNow’s playbook essentially becomes a platform benchmark. As clarity emerges, conversations change.

Sales discussions can move beyond individual use cases and start addressing operating posture. Procurement conversations can shift from SKU optimisation to entitlement boundaries. Executives can stop asking whether ServiceNow can automate and begin asking where it should be allowed to do so without oversight. It is great for service partners too. Because those are not incremental changes in messaging. They are structural changes in how the platform is understood and discussed right across the SI and BPO supply chain.

Seen through this lens, ServiceNow’s evolution reflects a decisive shift toward coherence rather than scope. In platform-as-a-service markets, there is a maturity threshold that must be crossed before a platform can function as a true enterprise control loop for work execution. Having crossed that threshold last year, ServiceNow can approach its 2026 SKO without the need for its sales organisation to improvise within abstract AI or CRM narratives. Instead, it can present a coherent operating story in which the pieces already fit together.

The fact that this interpretation was not broadly accessible a year ago reflects less a failure of perception than a matter of timing. The platform had not yet reached the level of consolidation required for its operating role to be clearly visible or practically defensible. And AI was a massive, albeit important, distraction.

What that means for 2026 is less hype because there is less ambiguity. Less fascination with what AI might do and more clarity about what the platform is ready to take responsibility for. Less experimentation for its own sake and more deliberate standardisation. That is not stagnation. It is maturity.

It is about helping the customer organisations to recognise that they are no longer licensing workflows. They are licensing some level of a minimum viable operating system for execution, and then deciding, deliberately, how much authority that system should hold.

It is worth repeating that I don’t think that AI made ServiceNow clearer. Building out the platform did. And only once the platform reached sufficient coherence did AI become usable rather than speculative.

The irony, of course, is that this clarity was achieved not by shrinking the application landscape, but by expanding the platform until consolidation could finally occur within it. That is why consolidation now re-enters the conversation in 2026, not as an aspiration, but as a practical next step for both PaaS and AI.

Last month I wrote about the convergence of three distinct platform layers (The New Digital Campus). Basically, a digital twin for context, a network for sensing, and a service platform for action. I didn’t mean it as a slogan. I meant it as a pattern that is emerging naturally wherever physical and digital systems are forced to coexist.

Every major transformation wave eventually reduces to architecture. And the same is happening here. If the last twenty years have been about digitising processes. The next ten will be about digitising environments. Those places we live, work, and move through. And in doing that, we’re actually building three simultaneous control planes that each see the world differently.

The digital twin sees space. The network sees motion. The service platform sees purpose.

Each is essential, but none can govern alone. The twin without the network is static. The network without the service layer is blind. The service layer without the twin is contextless. The art, and the next decade’s leadership challenge, lies in learning how to align them. Because context without sensing is theory. Sensing without action is noise. And action without context is chaos. Let’s look at each in turn.

Share

Imagine match day at the new Macquarie Point Stadium in Hobart, or at Brisbane’s future Olympic venue rising at Victoria Park for 2032. Whether it’s thirty thousand fans or a hundred thousand, half a dozen entry gates or twenty. At these venues, every part of the environment comes alive. Food and merchandise stalls, floodlights, elevators, big screens, turnstiles. Each one behaves like its own system, yet all of them share, and must operate within, the same physical reality.

The digital twin is the layer that gives that reality structure. It’s not just a 3D model of stands and seats. It’s the contextual fabric that tells every other system where it lives. It defines the relationship between a sensor, a gate, and the concourse it occupies. It knows that Gate 7 leads to Section D, that Section D holds 4,200 people, and that 12 percent of them are likely queuing for food at halftime, or at end of next heats.

Ten years ago, that kind of intelligence was called visualisation. It was a dashboard with geometry. Today, it’s becoming governance. Bentley, Esri, and Hexagon see it. So do the digital-engineering teams inside stadium operators and city councils. Las Vegas runs on it. The twin has evolved from static architecture into a living spatial framework that anchors decisions in reality. It’s where the geometry of the physical world meets the semantics of data.

When a sensor trips, the twin gives it meaning. When a maintenance task is triggered, the twin places it in space. When a workflow is launched, the twin defines its scope. Context becomes the control plane. It is the quiet source of truth that keeps data from floating free of the world it’s meant to describe.

But context alone can’t keep up with movement. On match or event day, a stadium isn’t static. It breathes. And that’s where the next platform comes in.

By the moment the event starts, whether it’s a match or a medal race, the digital twin understands the environment, while the network understands the activity within it. It knows the moment.

Every tap of a turnstile, every phone connecting to Wi-Fi, every surge of foot traffic from the nearest public transport hub, the network senses it first. In a modern stadium, connectivity is no longer a utility. It’s actually a nervous system. Thousands of access points, edge switches, and antennas feeding a live pulse through the environment. Extreme Networks calls it “network as experience,” and that’s not marketing hyperbole. It’s a statement of architecture.

On game day, the network becomes the bridge between movement and meaning. It knows when a stand fills unevenly and can redirect fans through alternate gates. It detects congestion at food outlets and pushes alerts to digital signage. It powers dynamic advertising boards that change based on crowd composition, location, or even sentiment. It feeds anonymised analytics back to transport operators to synchronise departures at the end of proceedings.

Every packet of data tells a small story, whether it is a path, a delay, or a choice. And together those stories form a real-time map of human behaviour. That’s why sensing has become the new competitive advantage. It’s not about signal strength anymore, but situational awareness.

And yet, awareness doesn’t equate to action. Knowing that a crowd is forming at Gate 4 doesn’t disperse it. Detecting a security anomaly doesn’t resolve it. Sensing is only valuable when the system can respond. That’s where the third layer, the service platform, comes in.

When you can observe but not intervene, clarity becomes its own kind of pressure. It means the system is fundamentally incomplete.

In a connected stadium, thousands of micro-events unfold every second. A sensor detects rising CO₂ in a corporate box. A payment terminal goes offline in a bar. A Wi-Fi access point overheats above Section F. A floodlight trips on the northern stand. Each alert is meaningful, but without coordination it’s chaos.

The service platform is where those signals become decisions. It’s the layer that translates sensing into action and where telemetry turns into a ticket, a workflow, or a dispatch. Platforms like ServiceNow are increasingly acting as the orchestration brain in these environments. They link the physics of the twin and the pulse of the network to the operational routines of human teams.

When a cooling unit fails, the network senses the drop in performance, the twin knows its location, and the service layer automatically assigns a technician complete with route optimisation, part availability, and escalation protocols if the fault affects broadcast integrity. The system doesn’t just notify someone. It mobilises the right response.

That response extends beyond maintenance. The same service logic drives the fan experience by triaging support queries, coordinating lost-and-found incidents, and dynamically updating digital signage or transport information. When a thunderstorm rolls in, the platform can trigger automated messages across screens, social channels, and the transit API all in a single orchestrated act of service drawn from dozens of sensing points and one shared context. Action is the visible edge of architecture. It’s how design becomes experience.

Let’s scale this up. A stadium is a microcosm of a city. It has transport, energy, retail, safety, waste, water, and Wi-Fi all compressed into a few square blocks and a few decisive hours. It’s a system of systems with no margin for error. If you can govern a stadium digitally, you can govern almost anything.

But in practice, few environments are governed by a single authority. The modern campus, whether a stadium, hospital, port, or recreation precinct, often sits at the intersection of public and private control. Local government owns the land, maybe even the facility. State agencies regulate safety and transport or co-locate adjacent premises or share infrastructure hubs. Private operators manage the facilities. Vendors and contractors own the data pipes, the cameras, the kiosks, the fibre, even the lights. Each layer of ownership comes with its own systems, contracts, and accountabilities.

That’s what makes the campus such a compelling modelling framework. It exposes the messy middle ground where infrastructure meets jurisdiction and where the problem isn’t just technical integration but institutional alignment. Who decides when every system has a stake? Who governs the shared space between ownership and operation? These has been one of the key challenges of Macquarie Point for over a decade.

The answer will vary by place, but the 3-platform architecture won’t. Whether public or private, the path forward still depends on the alignment of context, sensing, and action. The same logic scales outward. A streetlight isn’t that different from a floodlight. A bus interchange isn’t that different from a gate. A council operations centre isn’t that different from a control room. What changes is the number of owners and the complexity of consent.

When these three platforms align, we stop managing assets and start governing environments. Cities and campuses alike become living, responsive systems, just like organisms that can sense, think, and act with intent, even across boundaries.

So here’s the rub. It only works if the data can move between jurisdictions, stakeholders and platforms securely, predictably, and with consent. In a stadium, that means Wi-Fi telemetry owned by a network partner may feed into an incident workflow managed by a facilities contractor, which depends on spatial context from a digital twin licensed to a different entity altogether. Each stream is vital, and each is owned by someone else.

That’s why the real foundation of this architecture isn’t just technology. It’s shared data governance. That’s just fancy language for a practical framework for how data crosses boundaries without losing its lineage or trust.

In most environments, those capabilities sit within the service platform layer. It’s the part of the stack that can enforce access rules, orchestrate data flows, log decisions, and record who acted on what signal. It’s the connective layer where operations meet accountability. In that sense, the service platform isn’t just the place where things get done but the place where governance lives.

The three-platform model doesn’t magically solve the governance problem, but it does give it shape. It also reveals the complexity of where ownership must be defined, where agreements must exist, and where the friction still sits. For some organisations, it will remain a reference model that guides decisions even if full alignment remains out of reach. For others, especially those managing complex shared spaces, it offers a blueprint for building genuine interoperability between people, systems, and intent.

Because in the end, context, sensing, and action aren’t separate domains. They’re three ways of describing the same pursuit. That is, turning a world full of signals into one that can think, decide, and act together.

Most campus-scale and city-scale digital transformations have stalled, and will keep stalling, for a simple reason: they are trying to connect a landscape that was never built to be connected. For years, even the largest asset-engineering firms have tried to bridge that divide through modelling and spatial mastery, but the systems they interface with were never designed to operate as one shared experience.

The converged environment stack I’ve written about here is the pattern that finally closes that gap. It anchors the architecture, maps the ecosystem, and makes the structural gaps impossible for both organisations and their supplier ecosystems to ignore.

One of the clearest is this. Digital engineering firms are world-class in physical and spatial data, but they remain weak in the platform layer that actually orchestrates the organisation. Whereas the opposite is also true. IT-led PaaS capability alone can’t win the campus either. Spatial brilliance without service orchestration, and service orchestration without spatial truth, leaves the transformation unfinished.

Until engineering capability and platform capability converge, the outcomes leaders are seeking will continue to stall at the edge of the models they create. But there is a way.

A Bentley Systems ad slid through my Instagram feed last week (I’ve posted it later in the article). It depicts a bridge stretching across calm blue water. Clean symmetry, the promise of precision. It read, “All sensor data in one intelligent platform”. Bring your sensor data to life with iTwin IoT. It was a small thing, but it stopped me. Not because of the ad itself, but because of what it represented. It’s a resurgence in the quiet convergence of infrastructure, telecommunications, and software into something that looks less like asset management and more like urban governance.

And what struck me most was that it’s not new. In fact, part of the reason I paused was because I’ve seen this cycle before, and it feels like it’s on the rise again. It’s been more than a decade since I first sat in a conference room at the now-demolished Mirage in Las Vegas during an early Amazon Web Services event and watched the commercial birth of IoT devices into enterprise platforms.

It was one of those moments that genuinely altered the course of my career, leading me to take on the role of City Innovation Director for one of Australia’s capital cities. I spent four remarkable years helping to kick start the digitisation of the city’s physical assets. Everything from parking, lighting, energy, bridges, parks, and transport into data models that could help rethink how the city managed outcomes, not just assets.

That’s why the Bentley ad caught me. It wasn’t just the precision of the bridge. It was the memory of that same promise, resurfacing a decade later in sharper focus.

In that image I didn’t just see a bridge. I saw a campus. The kind with buildings, roads, pipes, and poles. The kind that behaves like a miniature city but runs under a single operating budget.

Airports, hospitals, ports, universities, and recreation precincts have become the new frontier for digital transformation. They are self-contained economies, each with multiple classes of assets, thousands of endpoints, and an emerging expectation that everything within their boundaries can be not just monitored or modelled, but connected and continuously available and responsive to the people and businesses who depend on them.

Back in that first wave, the conversation was dominated by connectivity itself. By LoRaWAN, Sigfox, and other low-power, low-bandwidth networks that made it possible to instrument the physical world cheaply and at scale. They opened the field but also defined its limits due to narrow pipes, patchy reach, and constrained intelligence.

That’s where the real collision is happening now. The convergence of IoT, 5G, digital twins, and network intelligence isn’t just a technical shift. It’s an architectural one. It is a battle over who defines the truth about the physical world when it becomes software.

Every major vendor now sees this layer as strategic and its time we did too.

Schneider Electric approaches it from energy and building automation, wrapping every pump, motor, and HVAC unit in an efficiency story. Philips (Signify) extends its lighting heritage into connected luminaries and adaptive control systems, where a single light pole can act as a node for sensors, cameras, or Wi-Fi. Bentley Systems, traditionally the domain of engineers and civil modellers, is pushing iTwin as a digital-twin-driven data layer that spans sensors, structures, and spatial analytics1. IDT Snap4 takes the open-data route, trying to free telemetry from proprietary formats and feed it into whatever analytical engine the owner prefers.

And then there’s ServiceNow, which most people don’t think of as an IoT company at all. Yet its CMDB quietly absorbs IoT events through API connectors, allowing real-world devices to exist as configuration items that trigger workflows, incidents, and maintenance logic. It’s not about visualisation. It’s about operationalisation. Where Bentley might model a bridge, ServiceNow wants to orchestrate its upkeep, compliance, and lifecycle events through the same platform that handles HR requests and cybersecurity incidents.

This is the point where categories start to blur. The traditional notion of a campus management system becomes less about booking rooms or scheduling maintenance and more about managing a distributed, living infrastructure. A pole might contain a light, a sensor, a camera, and a 5G antenna. Each one is technically a different asset class, often belonging to different data hierarchies, yet all share the same physical coordinates and power source.

That blurring isn’t new. It’s just harder now. In most organisations, the physical estate has always been fragmented across multiple divisions. Property owns the buildings, engineering owns the road and energy networks, operations manages the maintenance, and IT historically stayed in the background. But the rise of new technology buying centres through digital experience teams, sustainability functions, and innovation hubs has layered new complexity over the old.

The result is a genuine decision point for CIOs and digital leaders. When every asset produces data and every division wants control, who actually defines the source of truth?

The hidden player in all of this is, of course, the network. Every connected object depends on a backbone that is itself transforming. 5G and Wi-Fi 6 are no longer just telco evolutions, they are the enablers of this municipal mesh. They collapse the boundary between public and private infrastructure, between what’s owned and what’s provisioned. Suddenly, a university network looks more like a telco. Every access point, switch, and gateway becomes part of an ambient computing fabric.

That’s where companies like Extreme Networks re-enter the conversation. For years, networking felt like plumbing. It was critical but invisible. Now, as IoT architectures scale, the network has become the nervous system that determines visibility, security, and performance. CIOs who once treated it as background infrastructure are being forced to re-elevate it to a strategic discipline. The network defines the enterprise perimeter, the latency of sensor data, and ultimately the credibility of the digital twin itself.

The industry is circling back to a phrase that used to make architects groan. The single pane of glass. It is the idea that all operational data, from lighting to elevators to air quality to asset depreciation, can be viewed and managed through one unified interface.

It failed the first time (I was there), because it was tech-led and data models and protocols and governance were too fragmented. But today’s digital-twin ecosystems, combined with service orchestration platforms, might finally make it viable. The pane of glass this time isn’t actually a dashboard. It is more like an ontology where that shared language connects telemetry (tech) to context (outcomes).

So when Bentley speaks of iTwin IoT, what it really signals is the merging of civil engineering with live operational data. When ServiceNow extends the CMDB into IoT, it blurs the line between IT and facilities. When Schneider and Philips embed intelligence into their respective domains, they move from product vendors to platform participants. Each is competing to become the anchor of the digital campus, and by extension, of the digital city.

For CIOs and CTOs, this presents a new dilemma. Where to centre digital engineering gravity in a world where every system is trying to pull the enterprise into its own orbit. Which layer should become the organising centre of the organisation’s digital fabric? The twin, the network, or the service platform?

If you lead with the digital twin, the world looks like geometry and assets. If you lead with the service platform and it looks like workflows and incidents. Lead with the network and it looks like packets and policies.

Each approach is rational, but each yields a different form of governance. And really, that’s potentially just more of the same blur that will perpetuate the same overlapping lines of ownership and accountability. Only now it will be amplified by data, automation, and expectation.

The challenge isn’t to choose one.

In fact, most organisations already have versions of all three, often multiplied by department or vendor. The strategic opportunity is to rationalise the sprawl and start by anchoring around a single organising principle for the layer that best aligns with how the organisation actually governs itself.

The most advanced campuses will still weave all three together. I think the future is a twin for context, a network for sensing, and a service layer for action. But they’ll do so deliberately, with clear lines of ownership and a defined centre of gravity. I can’t wait to see the global partner models emerge in this space in the coming years.

And this is why the campus has become such a revealing unit of analysis. It’s small enough to manage but complex enough to mirror the systems of a city. It contains every challenge that municipalities face. It has multiple vendors, overlapping asset classes, fragmented data, competing operational logics, and the constant tension between centralisation and autonomy. If we can learn how to govern a campus digitally, we may have the blueprint for governing cities themselves.

What Bentley’s ad hinted at, perhaps unintentionally, is that the next wave of digital transformation won’t be about apps or analytics. It will be about alignment and getting infrastructure, information, and intent to inhabit the same architectural space.

And that’s the real frontier.

When every pole, light, and pump speaks, the question isn’t how to listen. It’s how to make them agree on what they’re saying.

When software companies take off, the headlines are usually all about altitude. It’s revenue growth, new product lines, and the size of the sky they’re claiming. But real maturity in enterprise technology isn’t about getting airborne. Execution is all about the landing. That means how well a company aligns its trajectory, coordinates the approach, and manages the turbulence of scale.

In that sense, ServiceNow is coming in to land. The numbers are strong, the engines are humming, and the company’s AI-driven transformation is sounding less like marketing and more like mastery.

Their third-quarter 2025 results confirm that the flight path is now controlled, not coasting. Revenue from subscriptions rose more than 20 percent to about $3.3 billion, future bookings topped $11 billion, and profit margins widened beyond 33 percent. The company kept an impressive 97 percent of customers and lifted its full-year forecast to more than $12.8 billion in subscriptions..

These are the numbers of a company executing with precision. Yet the real story lies beyond the balance sheet. When execution is this consistent, the more interesting question isn’t what they achieved, but why it’s working.

Think of every organisation as operating its own controlled airspace. A kind of living operational environment where departments, systems, and AI agents all fly at different speeds and altitudes. Some are climbing, some circling, some descending. They cross data corridors, pass through shared zones, and rely on coordination to avoid collision.

ServiceNow understood early that in any enterprise airspace, control is everything. And just like in real aviation, two kinds of air-traffic controllers are needed to keep things safe and efficient.

En-route controllers are needed to manage specific stretches of airspace, maintaining order and separation as aircraft travel through their assigned sectors, much like finance, HR, IT, or customer service teams manage their own domains.

Then there are tower controllers who, by contrast, manage the intersections. Things like the take-offs, landings, and hand-offs between sectors where flights converge, timing is critical, and coordination keeps everything moving safely.

The challenge for most enterprises is that when it comes to AI, while they have plenty of aircraft (applications, automations, and models), they lack unified control. There’s no tower. No controllers. Each software vendor just adds another flight to the sky, and another signal to track. But without a coordinated system, the airspace becomes noisy, siloed, and unpredictable. Unsafe. Not trusted.

That’s the problem ServiceNow’s AI Control Tower was built to solve. It acts as the enterprise’s tower and radar combined, giving organisations visibility, coordination, and, most importanlty, trust across every flight in motion, from departmental automations to cross-enterprise AI operations.

Just like in aviation, the Control Tower is not designed or meant to replace the en-route controllers. It depends on them. Both are essential to the overall system. For air traffic control to work you need aircraft in flight, en-route coordination to manage their movement across sectors, and tower control to handle the apron and runways where timing matters most.

In the enterprise sky, the en-route controllers include the system-of-record vendors like the ERPs, CRMs, HR and asset platforms that manage traffic within their own domains. Each governs its stretch of airspace, maintaining order, process, and compliance within its boundaries. But none of them can see the whole sky. That’s where ServiceNow’s Control Tower comes in.

Like aviation, it combines tower control and flight freedom, enabling domain systems to scale safely under shared governance. ServiceNow doesn’t seek to fly other company’s planes. Rather it coordinates them, providing the radar, sequencing, and cross-sector communication needed to keep every system of record moving in harmony across the enterprise.

What sets ServiceNow apart is that it didn’t just build another aircraft. It built the system that coordinates the entire sky. Its architecture is engineered for orchestration, not participation, designed to manage movement, timing, and safety across every flight path. It does this through four interlocking pillars that mirror the structure of real-world aviation management:

The first, AI Strategy, is equivalent to the flight planning function. It defines the routes, priorities, and airspace design so every AI initiative departs with purpose and stays on course with business objectives.

Secondly, AI Governance is the regulatory and safety function setting the rules of the air through compliance, auditability, and frameworks such as NIST AI RMF and the EU AI Act, ensuring trust and accountability across every flight.

Thirdly, AI Execution is the air-traffic management layer providing operational control that automates hand-offs, monitors flow, and keeps all AI systems moving safely across departments and sectors.

Lastly, AI Value is the performance and telemetry system tracking fuel, altitude, and efficiency and translating every flight’s data into measurable business outcomes in real time.

Together, these pillars make ServiceNow the airspace orchestrator, not just another aircraft. It is the platform capable of connecting, governing, and optimising every other flight in the enterprise sky, keeping traffic visible and synchronised through the Workflow Data Fabric.

After all, imagine a real airport control tower that couldn’t communicate with different airlines. The result would be chaos. The same principle applies here. Complex ecosystems thrive only when coordination and autonomy coexist under intelligent regulation.

So that means the quiet brilliance of ServiceNow’s approach lies in its focus on stability under speed. That is, governance as growth.

Its innovation isn’t a single model or algorithm. It is the governance architecture that allows many to coexist. The solution turns scattered initiatives into measurable business assets, making risks visible, aligning AI development with enterprise strategy, and letting organisations prove, not just promise, value. In aviation terms, it provides the landing path for every new flight of automation. That is critical.

Because aviation teaches us that the measure of a system’s sophistication isn’t how many planes it launches, but how safely and efficiently they land. ServiceNow’s architecture reflects that truth. Its success feels less like another climb into new airspace and more like a controlled arrival. That’s the real payoff we all experience when we travel. And that is the mark of a company that’s learned how to coordinate complexity rather than just accelerate it.

Yet even the best-equipped tower faces trade-offs. Too much control creates bottlenecks and too little invites trouble. So ServiceNow’s future depends on managing that balance by allowing partners and customers to fly their own aircraft while maintaining oversight of the whole airspace.

If the customer’s (AI CoE), and by extension the tower, insists that every signal pass through it, the system slows. But if it permits too many private channels, coherence is lost. The art lies in orchestrating both. Maintain centralised visibility without stifling decentralised freedom.

Customers and their teams will continue to choose bespoke AI tools tied to their ERP and vertical systems of record, but the Control Tower’s role is to ensure that this freedom doesn’t fracture the operational airspace and that innovation still resolves the larger challenges of trust, safety, and efficiency rather than creating new turbulence.

That symmetry between the enterprise and the tower defines the current competitive frontier in AI. The race is no longer just about building the fastest or most capable model, but about governing coexistence through the choreography of thousands of machine and human actors operating safely in the same airspace.

ServiceNow’s other advantage is its understanding that control and freedom are actually not opposites, but coordinates. Its success now depends on how well it can manage both. The partner side will be interesting.

For direct customers, the implications are immediate. Most already have dozens of AI projects flying in loose formation. They need orchestration, visibility, and safety. The Control Tower model provides that discipline, letting IT and business leaders coordinate across the enterprise to know which models are active, where data is flowing, and what outcomes are being achieved.

But just as in aviation, control brings responsibility. Stronger towers demand stronger governance. Fairness, transparency, and trust must be built into the infrastructure itself, not added after the fact.

For partners, this marks a shift. Many are used to flying solo, managing their own airspace with little interference. That model won’t hold in the 21st century. The new environment rewards those who can operate within a regulated, coordinated sky, where visibility, safety, and shared standards take precedence over individual autonomy. Some will thrive and accelerate through alignment with ServiceNow’s platform and alliances. Others may need to adjust to remain visible and viable within the broader system.

For ServiceNow, landing this strategy requires precision, and the financials suggest it’s achieving it. The company is expanding margins while accelerating adoption, embedding AI governance exactly when enterprises most need it, and doing so on a platform now central to how organisations coordinate intelligence.

In this sense, ServiceNow’s leadership is less about dominance and more about discipline. The stronger its tower becomes, the more it must enable, not control, the flights around it. True ongoing maturity lies in building a system where thousands of independent journeys can still move in harmony, each confident that the sky above them is both open and safe.

I hope ServiceNow continues to go deeper with the Control Tower concept. It’s a rich idea. Strategically brilliant. One that captures exactly what the AI era demands. But it remains under-explained. Not yet fully articulated. The potential is far greater than the current narrative suggests.

For me, what it says most profoundly, is that ServiceNow isn’t trying to teach the world how to fly. It is actually showing it how to land.

Share

We talk about AI the way people once talked about mainframes. Like it’s a kind of magic. Complex. Hidden. Best left to experts. That was true for a while, until it wasn’t. Someone eventually gave it structure. MIPS. FLOPS1. Numbers that let people compare. Numbers that made performance measurable, cost understandable, strategy defensible. A framework that challenged assumptions and gave executives a way to think about machines without mysticism.

We’re in that moment again.

But this time the fog isn’t just about technology. It’s about trust. In my earlier piece on Breaking the AI Confidence Recession, I argued that the AI challenge isn’t capability. It’s actually conviction. Too many teams are stuck. Not because they lack tools but because they lack a framework for action. AI has made this worse. Not because its potential is unclear, but because its economics are. You can’t measure ROI without knowing what you’re spending. And with AI, even that basic understanding feels out of reach.

No one can quite agree on what the cost of intelligence actually is. Or who owns it once it’s embedded across the business. Or how to hold it accountable when its value disperses across functions. This isn’t a capability gap. It’s a visibility gap. And it’s eroding the confidence that transformation depends on.

Here is a truth from which we can all embark. AI introduces a new kind of operating cost. One that’s linguistic, probabilistic, and dynamic.

Traditional FinOps disciplines were built for infrastructure like compute, storage, and bandwidth. They monitor systems that execute instructions. AI, by contrast, performs cognition. Every model interaction consumes tokens. Every inference represents a micro-decision made on your behalf. The problem is, we don’t yet have a shared way to describe that consumption.

We talk about “running” a model but the units of AI economics are buried under licensing abstractions and pricing bundles. Few leaders could say what that run actually costs, per transaction or per outcome.

This is the next frontier of FinOps. Not a financial exercise, but a leadership one. Because when you adopt AI, you’re no longer just managing infrastructure. You’re managing digital thought. Each model has a runtime signature. A distinct pattern of how it processes context, handles ambiguity, and delivers output. Understanding that signature, and what it costs to maintain, is the new responsibility of executive stewardship.

Part of the answer clicked into place at the Google Cloud Summit in Sydney earlier this year. ANZ Vice President Peter Miglorini flashed a slide showing the exponential growth of AI tokens. Tokens. Not seats, not licenses, not users.

Tokens are fast becoming the new unit of enterprise work. Yet most organisations have no framework for what that means. No shared understanding of how to measure, govern, or plan for the economic implications of tokenised intelligence. That’s the real gap in the conversation. Not how capable AI is, but how accountable it can be once cost becomes measurable.

I am not saying the goal is to audit every token. It is to reclaim confidence by making something hidden visible enough to manage. Too many teams are trying to synthesise before they’ve analysed. This just layers complexity over uncertainty.

AI’s economics will never be as neat as infrastructure metering, and they don’t need to be. What matters is clarity. The ability to compare, not by vendor claim or marketing label, but by observable behaviour. By how models actually perform, and what it costs to make them perform that way.

To do that, we need a language that normalises the chaos. In the mainframe era, MIPS and FLOPS made sense of performance. In the AI era, we need equivalents that make sense of cognition.

One such idea is the Token Resource Unit, or TRU. It is a way of expressing how much work a model performs per fragment of language. It’s not exact, and it’s not meant to be. Precision is less important than comparability. What problem is this solving? TRUs would allow leaders to reason about AI consumption in relative terms and to compare different models, platforms, or configurations using a common scale of resource behaviour.

Alongside TRU sits another idea. Tokens Attributed Per Second, or TAPS. Where TRU helps you think about cost, TAPS helps you think about speed or how efficiently intelligence is being delivered per unit of resource.

Together, they hint at a language that ties cost, performance, and value into a single continuum. They won’t make AI economics precise. They don’t have to. What they offer is the ability to think about it coherently, to turn abstraction into something we can observe, question, and benchmark over time.

This shift also reframes how we think about value. AI cost doesn’t live in procurement or capital budgets. It lives at runtime in the moment a model does the work. That’s where operating expense meets business outcome. That’s where efficiency becomes measurable and ROI becomes tangible.

The question isn’t what you paid to deploy the system, but what you pay every time it runs. And whether that cost is justified by what it delivers.

The truth is, executives don’t need another billing dashboard. They need a way to reason. A structure to ask better questions. What’s our true cost to serve per agent task? Are we paying for cognitive complexity we don’t use? Should AI cost be charged back to IT, HR, or CX? How does our runtime footprint compare to others doing similar work? These questions don’t have fixed answers. But asking them is the beginning of accountability.

AI FinOps, in the end, is not about control. It’s about comprehension. It’s about building confidence through conversation, not compliance. It’s the ability to say, with some structure, that this is what our intelligence layer consumes, this is what it delivers, and this is where we choose to draw the line.

The AI wave won’t slow down. But the fog around cost and value will only lift if we help lift it. Vendors won’t do that for us. Regulators can’t. If AI is truly the next layer of enterprise infrastructure, then we need to own how it runs, and how much that running costs.

So, AI isn’t really a black box unless we let it be. The tools and metrics are still forming, and they won’t be perfect. But that’s okay. The act of looking inside and of reasoning through what AI consumes, not just what it produces is the real step forward. The rest will follow.

Author’s note:
Somewhere during a long airport layover, I started sketching a framework to make sense of AI cost and performance. What began as a thought exercise turned into a small browser-based benchmark. It was a way to model runtime behaviour across public LLMs using nothing more than the data vendors already publish. It wasn’t a product, just an exerise to prove that it’s possible to reason through AI costs with what’s already in the open. The fog only feels impenetrable until you start mapping it. What I’m saying is, it’s possible.

Salesforce has finally stopped orbiting IT service and picked a re-entry path that plays to its strengths. The front door is Slack. The backbone is Service Cloud. The bet is that conversation-first work, guided by agents and grounded in a coherent record, will change how service is delivered across the enterprise.

The history matters. Remedyforce showed that borrowing an engine doesn’t make a platform. ServiceNow built scale by turning ITSM into the wedge that unlocked corporate services. Salesforce watched, learned, acquired Slack, and rebuilt the kernel (in one year!) from the inside. This time it is an organic build. No borrowed chassis, no Force.com detours. Just a Service Cloud product with Slack as the surface where the work actually happens.

The October 2025 launch lands with four moves. A service desk that speaks ITIL rather than trying to rename it. Employee agents that resolve the obvious where people already are. IT (nominally, Fulfiller) agents that collapse the hunt through tickets and logs into a single conversation with the right context. And a CMDB with discovery and an enterprise graph that maps dependencies not as a static diagram, but as the substrate for root cause and change analysis. The promise is fewer tickets, faster resolutions, and a paper trail that writes itself as the dialogue unfolds.

The message is Slack-first and Teams-ready, but the shift is bigger than chat. This is omnichannel by design. The ticket is no longer the beginning of the story. The conversation is. Proactive detection lights up before someone types “my VPN is broken.” Auto-resolution takes the first actions a human would have taken. When judgment is needed, the handoff isn’t a bounce or a portal detour. It’s the same thread, the same context, the same record.

There is a quiet rebuttal here to the last two years of agent hype. A fleet of point agents without a record is noise. A pristine record or KB without a surface is inertia. Salesforce wants both. Slack commands attention. Service Cloud enforces process, data, and audit. Together they aim to convert attention into action, and action into a governed outcome that other systems can trust.

This will not arrive as an ITSM monolith. How could it? Salesforce will land first in commercial and mid-market accounts, coexist where displacement would be wasteful, and grow depth quarter by quarter. Pricing follows the shape of the work. Fulfillers (IT) will be priced per user and employee agents as a subscription with consumption-based add-ons for connectors and agentic actions. The theme is simplicity. The intent, predictability. The subtext is total cost, not a race to the bottom on licenses while the integration bill climbs.

For ServiceNow, I thikn the contour of competition is clearer. The suite keeps its edge in governance, depth, and the maturity of a long-tested operating model. Salesforce will pressure the edge where people live. So the fight will not be about who can brand a portal, but about who can make the surface feel native without breaking the spine of the record.

And the sharper contest may not evem be with ServiceNow alone. By putting Slack at the surface, Salesforce moves directly into the lanes of Freshworks, Jira Service Management, and ManageEngine. These are the tools chosen by mid-market and cost-conscious buyers who see ServiceNow as too heavy and too expensive.

Slack as the service front end, paired with Salesforce’s existing footprint, makes it easier for those buyers to justify extending rather than adding a separate platform. That distinction matters.

ServiceNow remains the gravitational force in enterprise ITSM, but in India, Southeast Asia, and globally across the commercial segment, price and simplicity win the day. Buyers who will pay for SAP in ERP and Salesforce in CRM can sometimes draw the line at ServiceNow’s ITSM licenses. Freshworks and Jira thrive in that gap with “good enough” service desks. Salesforce’s re-entry sharpens the perception that there is now an alternative that feels both familiar and affordable.

The architecture question remains the only one that matters. Surfaces capture attention. Suites enforce order. Neither wins alone. The trunk that binds them is the platform. And you know my thoughts on this! Salesforce is arguing its trunk is now strong enough to carry IT service as just another domain on the same line as customer service and HR. If that holds, the gravity of the installed base will matter more than any feature list. Initally anyway.

This is where cost comes back into the picture. For years, Total Cost of Ownership was the discipline that kept technology buying honest. It was the world my generation grew up in. Subscription models changed that. They eroded the discipline, turning license fees into a proxy for value and hiding the integration and governance costs that never really went away. Every new SaaS tool without architectural discipline adds to what has become the complexity tax.

ServiceNow’s value claim has always and remains about cost not price. And I agree that it does still collapse ownership costs into one platform. Salesforce will argue that its install base and Slack surface deliver the same effect with less sticker (price) shock. Freshworks, Jira, and ManageEngine will counter with even lower prices and speed. The real choice is whether buyers want affordability at the edge, discipline at the core, or a workable blend of both.

What happens next will also depend on how cleanly SI partners can build with it. Out-of-the-box agents are a start, but enterprises will want domain packs tailored to the messy realities of their estates. Credibility won;t come from demos but from post-mortems where the agent prevented an incident rather than summarised one.

Ultimately, the risk is the same as ever. If the surface floats without the platform, this will be a novelty that, like all novelties, will fade. If the platform underneath becomes too rigid and process-heavy, Slack risks becoming just a thin veneer over the same legacy workflows. The opportunity is a single motion. To see the issue early, act in the conversation, land the outcome in the record, and repeat.

If Salesforce can do that at scale, Slack will no longer be just the place where work is discussed. It will be the place where service work is done.

Salesforce has decided that Slack is more than a collaboration tool. It is now the entry point for IT Service Management. That shift might feel abrupt, but it is best understood as a continuation of a much longer story. They have actually hovered around the ITSM market for more than a decade, sometimes experimenting at the margins, sometimes engaging directly, and now by making another serious attempt to establish a position.

Share

The first chapter came around 2010, when Salesforce partnered with BMC to create Remedyforce1. It was born in the glow of Force.com, positioned as the alternative to ServiceNow. The idea was elegant. BMC had the ITIL process maps, Salesforce had the platform, and together they could present a credible cloud service desk. For a time it worked. Remedyforce sat inside Salesforce, accessible, familiar, and pitched to CIOs as the seamless way to manage both customer and employee services. But it never broke through.

ServiceNow was already building momentum as a purpose-built ITSM platform. Remedyforce, tied to Salesforce licensing and constrained by Force.com’s data model, became a product that appealed to a subset of customers but lacked gravitational weight. By 2016 Salesforce had stopped selling it, leaving BMC to manage its decline as it pivoted Remedy.

ServiceNow, in contrast, expanded aggressively. What began as incident and change management has since become a launchpad into people, finance, procurement, and governance. But the pattern was clear. ITSM was the wedge. And it became more than a service desk. It became a system of record for how work could be orchestrated across functions. It now comfortably resides across the corporate services2 suite and explains why ServiceNow today is valued not just as a dominant IT tool but as an enterprise platform.

Salesforce never abandoned the original idea. How could it? It just regrouped. The clarity of a competitive corporate services move by ServiceNow has no doubt sparked another response. The Slack acquisition in 2021 simply gave it a new surface, one that was already embedded in the daily rhythm of work for millions of employees.

The strategy this time appears not to build another heavy ITSM suite, but to turn Slack into the surface where ITSM lives. It’s doing this by channeling its service, collaboration, and AI capabilities into Slack, positioning it as the central hub for customer and agent workflows. Incidents, requests, approvals, and knowledge retrieval are all being reimagined as conversations. That is AI speak for “not managed in separate systems”.

While other vendors are exploring the same model, for Salesforce, shifting ITSM into Slack is the defining strategic move. So instead of competing with ServiceNow on service management depth, Salesforce is competing on engagement. ServiceNow positions itself as the suite, Salesforce positions Slack as the surface. The suite governs, the surface engages. It is not yet clear which model will dominate, but the contrast is stark. This may become clearer after Dreamforce 2025.

More broadly, this move also reflects the changing nature of IT buying. The CIO is no longer the sole authority. HR directors, finance controllers, and marketing operations leads have each become a buyer of workflow and automation tools. ServiceNow’s recent market performance is in part due to a more coherent suite that extends from IT outward. Salesforce is addressing the same sprawl by going sideways. If everyone already lives in Slack, why make them step out to another portal3?

There is logic here. The power in ITSM has shifted away from owning the ticketing system to owning the place where people actually pay attention. Shadow IT blurred the lines of control, and now the real battleground is the collaboration layer. Slack is an attention engine. Salesforce is betting that by embedding ITSM into Slack, it can contest the ground where ServiceNow has simply been clearer and earlier to market.

This is where I think the historical echo is important.

Remedyforce failed not because the need was absent, but because the model was wrong for the time. Embedding ITSM in Force.com required CIOs to accept Salesforce as an operational backbone. That leap never happened. It was too early. At that time, few could grasp or commit to the kind of platform-centric architecture that is now becoming standard and will define the next two decades.

But embedding ITSM in Slack doesn’t actually require that leap anyway. Slack is already a fabric of daily collaboration. So it is not a matter of fighting adoption, but of extension. That’s a much easier battle.

The question is whether this will be enough. Suites offer discipline. Surfaces offer immediacy. ServiceNow’s advantage lies in its process depth, its mature CMDB, its ability to enforce governance across sprawling estates.

Salesforce’s advantage lies in presence. Slack is where people already are. AI can potentially accelerate the divergence. Can an agent embedded in Slack resolve a request faster than a ticket logged in a portal? Maybe, but the record of that action still needs to land somewhere. The architecture cannot be surface alone.

I have written a lot over the last 18 months that the future will not be about choosing between systems of record and modern surfaces, but about fusing the two. That’s what Hybrid Platform Architectures are. Where stability at the core meets efficiency at the edge. It means enterprises will not abandon systems of record. Nor will they ignore the efficiency of surfaces. So the real challenge is integration.

If Salesforce can fuse Slack’s immediacy with Service Cloud’s records in a way that feels seamless, it may yet carve a credible path into the “new” ITSM and corporate services suites. If it cannot, ServiceNow’s gravitational pull will continue to hold for now.

With this announcement, at least in the short term, Salesforce is betting that the surface is now more important than the suite. ServiceNow is betting that the suite will always anchor the enterprise. The immediate outcome will be decided by sales speed, execution, and visible impact at the client’s desk.

The market is about to test which of these bets carries the most weight in the long term, and that means the deeper issue is architectural. A surface like Slack can capture attention, but it cannot carry the weight of record. A suite like ServiceNow can govern process, but how will it command presence? What ties process and presence together is the platform beneath them. A platform that unifies engagement and record without forcing them into the same skin.

This is where the real competition lies. It is not really Slack versus ServiceNow. It is whether Salesforce can grow Slack into a surface that rests securely on the trunk of its broader platform architecture.

ServiceNow has already positioned its platform as both root and trunk, a system that promises to govern data, processes, and services in one line. Salesforce has historically excelled in engagement but struggled to convince the enterprise that its architecture is fit to be the backbone. Remedyforce was an early example of that struggle.

The pivot to Slack is an attempt to solve the problem by flipping the argument. They are reversing the traditional approach.

Instead of building from the core outward, they are starting at the surface where users already work and testing whether that can pull the core along. The risk is a disconnected experience if integration falls short, but the opportunity is for Slack to become the unifying layer that finally bridges systems of record with systems of engagement.

Customers are holding back now, but they will not wait forever. Once confidence returns, they’ll place their bets on vendors with stable architectures and disciplined growth. Until then, expect marketing spend to chase quick wins, even if the deals aren’t structurally sound, because in the short term, momentum matters as much as strategy.

But it didn’t.

Instead, across many publically available studies from Gartner, Deloitte, McKinsey, MuleSoft, Flexera, Salesforce, ServiceNow and many others, the evidence lined up in an unexpected way. Architectural maturity on paper looked promising. Platform maturity in practice was stalling. Instead of bending toward composability, the adoption curve was bending the wrong way, toward hardened anti-patterns that trap organisations in the tactical middle.

As tech leaders, this is the unsettling reality of 2025 we need to face. We are living in an era dominated by anti-platform patterns.

The problem isn’t simply that organisations are slow to adopt platforms. It’s that the most common adoption paths are actively entrenching fragility.

Too many enterprises normalise practices that were never designed to scale. RPA-first automation that chains spreadsheets together. Departmental platforms masquerading as enterprise backbones. Vendor suite lock-in confused for strategy. Data treated as an afterthought, reconciled after the fact instead of embedded at the start.

These patterns aren’t marginal. They dominate. Which means the modal adoption path is inverted. Instead of climbing toward composability, most organisations are reinforcing the very behaviours that anchor them in the tactical middle.

Part of the reason we are living in an anti-pattern era is cultural. We are in an age of instant gratification, where quick fixes are rewarded and long-term discipline is undervalued. Tactical automations and departmental platforms give the appearance of progress, but they don’t compound value. They satisfy immediate demand, while deferring the harder work of building trusted data, governance, and observability.

I think that is why platform maturity feels stuck. In most cases, the anti-patterns are not being corrected. They are being institutionalised. Short-term wins are hardening into long-term operating models. Instead of bending toward composability, the curve is bending in the wrong direction.

Vendors sell to departments, not enterprise architects. Integrators deliver projects, not platforms. Analyst benchmarks track adoption volumes, not governance quality. Gravity keeps pulling everything back to the wrong centre. An enterprise black hole where nothing escapes.

And in too many places, these defaults have already hardened into operating models. RPA-first, departmental platforms, suite lock-in, data last. Unless deliberately broken, they will continue to define the next decade.

Part of the trap lies in ownership. Throw a rock and you’ll hit a survey with neat data and percentages. When aggregated, about 40% of organisations say the CIO owns architecture, another 40% say the CIO owns platform strategy too. A tidy picture, as though architecture and platform move forward together from a single office.

But the neatness is an illusion.

CIOs naturally claim ownership when asked, but operational influence is far more fragmented. Departments lobby for platforms to meet their own needs. Vendors push roadmaps that shape adoption more than any architecture board. Integrators fill the gaps.

The result is a gap between nominal ownership and operational reality. Platforms are treated as CIO-owned but department-driven. That guarantees they remain tactical. Without governance in practice, with authority, budget, and teeth, platform maturity will always stall.

The anti-pattern repeats across workflows, automation, and reuse.

Most workflows are still department-specific, stitched together with minimal integration. End-to-end, event-driven orchestration appears in fewer than 10% of cases.

Integration reuse is shallow. Forty percent are single-use, another third are reusable only within a team. Managed catalogues that span departments remain rare.

Automation is equally fragile. RPA and scripts account for nearly half of all activity. Integrated platform logic is the minority, composable reusable automations rarer still.

The result is that enterprises are working hard but not compounding value. They are busy, fragmented, and tactical. The building blocks of Hybrid Platform Architecture (HYPA) are absent.

If this picture sounds bleak, it is. But it is not inevitable.

Look at GovTech Singapore. While many governments remain stuck in ERP legacies or tactical automations, Singapore has become a recognised world leader in digital government precisely because it has chosen to avoid the gravitational pull of anti-patterns.

GovTech treats platforms as shared infrastructure. They start with trusted data entities. They stitch multiple platforms together through common identity, events, and policy. They enforce governance dynamically, through code not committees. They instrument services for journey-level observability. And they fund platforms as products with long-term ownership, not projects with short-term budgets.

This is what disciplined platform adoption looks like. It is why Singapore is increasingly cited not just as a digital leader, but as a pioneer in as-a-service adoption architectures. They have shown that platform maturity is not theoretical. It is achievable if treated as operating-model infrastructure rather than software procurement.

The question is what it takes for others to follow. The answer is not even grand theory. It is six quarters of disciplined execution.

In the first two, get a clear picture of your current state. Define trusted data entities like customers, assets, cases. Publish basic policy and event standards. Establish a small platform strategy office to hold the line.

In the next two, rebuild a handful of high-value cross-functional flows as event-driven services tied to those trusted entities. Instrument them for journey-level observability. This reinforces funding flow not function.

In the final two, expand the catalogue of reusable services, enforce policies consistently through code, and convert tactical RPA into proper services. Introduce chargeback and FinOps so cost, reuse, and time-to-change are visible. This last bit is critical for Agentic.

That is the onramp to platform. The path from tactical to composable. From illusion to practice. From anti-pattern to HYPA.

Everyone talks about platforms. I talk about them a lot! The truth is most organisations are reinforcing anti-patterns that will keep them tactical for decades. But as GovTech proves, there are counterexamples. They seem to inherently understand that platform maturity is not a dream but a product of discipline, governance, and treating platforms as infrastructure.

What makes GovTech different is that it never tried to bend the laws of technology nature. It did not abandon the core physics of IT management. It never bought into the myth that the old disciplines were uncool or obsolete. Architecture principles rooted in frameworks like TOGAF. Governance and risk disciplines that echo COBIT. Service management maturity that grew out of ITIL. These foundations were not discarded. They were absorbed into a new, platform-first operating model.

Where many organisations tried to shortcut maturity, GovTech doubled down on discipline. They made tech management engineering cool again. Almost in the same way hyperscaler cloud engineers have become modern icons. In the platform era, it turns out the geeks really do inherit the earth.

That is why their trajectory looks different. While others normalise anti-patterns that fight against gravity, GovTech aligned with it. They understood that the real energy of platforms comes from operating with, not against, these laws that have served as the foundation for our modern technological environment. And crucially, they didn’t outsource that responsibility. They built and kept the capability in-house, embedding it into their operating model. That ownership, more than anything, explains why their maturity looks so different.

And it’s not only governments that can do this. Enterprises that are self-aware enough to see the anti-patterns in their own environment need to look carefully at their own capabilities as well as the types of partners they choose. The service providers who have architecture, governance, and service management in their DNA. Companies like Fujitsu, or IBM, or TCS, or DXC if it has managed to archive and hang on to what the old HPE once represented, are examples of the natural candidates to help organisations bend the curve back.

These are not flashy project vendors. They are providers who hold firm to the core physics of IT management and translate those principles into platform-first execution. For organisations trying to escape the gravitational pull of anti-patterns, these are the partners that can anchor a return to discipline and set a trajectory toward true platform maturity.

The next thirty years will not be decided by which ERP or CRM vendor wins. They will be decided by whether organisations can master interoperable platforms as their operating backbone. The anti-pattern era is real, but it is not destiny. Gravity can be broken, or better, harnessed. The curve will continue to bend the wrong way only if organisations continue to ignore the physics that hold it together.

I attended IBM Think in Singapore this year as a guest of IBM’s analyst relations program, and the setting itself reinforced the point.

Singapore has just marked sixty years of independence, yet already speaks openly of its centenary. That is the kind of horizon IBM and its clients understand. What looks like slowness from the outside is often intention. So in the context of Agentic AI, which is not a software feature or a service licence but a tectonic shift in enterprise architecture, IBM may deserve the benefit of the doubt.

IBM is not a hyperscaler. Its name does not dominate the cloud league tables. Instead it has built its identity around high performance computing and the custodianship of systems where scale, security, and stability matter more than market agility. In the heat of the cloud era this posture looked out of step, even archaic. But the emergence of Agentic AI does not and will not reward speed alone. It requires the very foundations that IBM has spent decades refining. What once seemed like a disadvantage, you can now read as foresight.

For more than a decade, they have been quietly assembling the components that agentic systems require. Then pivoted to open architectures before that became fashionable. They have invested in AI longer than almost anyone, often ahead of the curve, and sometimes, as with Watson Health, were punished for it. But in a market suddenly gripped by the language of orchestrators, supervisors, and hybrid frameworks, IBM’s methodical architecture-first philosophy begins to look less like legacy and more like inevitability.

The industry is now converging on an unavoidable consensus. Agentic systems will not be monolithic. They will be hybrid by default. There will be multiple agents, multiple models, and multiple contexts running side by side. That reality requires orchestration, governance, and observability at scale. It is less a software problem than an architectural one. And if architecture and scale problems define the playing field, then IBM has a natural advantage.

watsonx Orchestrate, launched three years ago, is not just another assistant. It routes. It supervises. It helps in planning. It runs headless, independent of interface, and it standardises across architectures rather than locking enterprises into a single front end. With Orchestrate, IBM is not positioning itself as the vendor of every agent but as the backbone that can govern them all. That is a more enduring ambition than the sprint to be first to market with yet another copilot.

To many, including myself, it is always striking how little urgency IBM shows in its go-to-market across almost every product and service line. The absence of hyperbolic energy feels intentional, yet it sits uncomfortably against the frenetic internal pace of its high-end sales culture. One no doubt feeds the other. The result is that IBM consistently undersells itself.

Even at Think Singapore, the strategy and substance were there, but the staging told another story. The venue was cramped, with little room to move. Breakout spaces were scarce, and the setting itself felt constrained, spilling into the paths of hotel guests heading to the pool, the tennis courts, or the Orchard Road shopping strip. The marketing wrapper did not match the tremendous weight of the ideas. To me that is clearly an executive decision.

When it comes to technology, the contrast is sharp. Where other Agentic AI vendors push features with the urgency of an ERP sales cycle, IBM positions itself as more measured and deliberate. What remains uncertain is whether IBM aims to lead decisively from the front or whether it intends to arrive later and impose order on a fragmented landscape. Either path would be consistent with its history.

This perspective also explains why IBM sits outside the usual competitive frames. If we accept that the orchestration space will not belong solely to Microsoft, Salesforce, Accenture, ServiceNow, or even Google Cloud, then the question becomes: who will really define it? Certainly not IBM Marketing.

Nor is IBM attempting to dominate CRM, ERP, MRP, or ITSM. Like every major vendor I’ve spoken to, or whose event I have attended in 2025, its ambition is to orchestrate across them. The difference is that, for IBM, this positioning fits naturally with its identity as an architecture-first company.

This is where the contrast between noise and reality becomes clearer. Agentic AI is attracting a tidal wave of investment and marketing spend, but adoption itself is still only a ripple. The demos are polished and the press releases constant, yet proof-of-concepts rarely convert at scale.

Enterprises remain stuck in experimentation rather than shifting operations. That gap between promise and practice may work in IBM’s favour. Lightweight frameworks and quick PoCs risk evaporating before they ever scale, while IBM’s heavier, architecture-anchored approach has the potential to land with greater mass. If adoption proves slow to start but accelerates over time, those who built for weight rather than speed will be better positioned to capture durable share.

IBM also knows the risks of building platforms that are too heavy. Lotus Notes and Domino were once technically rich and deeply integrated, but they proved too inflexible for the agile disruptions that reshaped business models in the 21st century. That history is not lost on the company.

IBM may not have deliberately engineered this moment, but its architectural DNA means it is accidentally in the right place as Agentic AI takes hold. The happenstance is what matters, and whether IBM can seize it.

Either way, the alignment is striking. Agentic is not another software licence to be sold or a SaaS module to be bolted on. It is a structural shift in enterprise architecture. To orchestrate it requires foundations that can endure, not features that can pivot.

That architectural weight is also the counter to what might be called the explosion problem. Enterprises are drowning in systems, applications, and now agents. Every function has its stack, every stack generates data, and the proliferation is accelerating. Self-discipline in this area will fail. It will take an Ozempic for applications, a metabolic reset, before the sprawl consumes itself. IBM’s approach is not just to add yet more assistants but to orchestrate the excess. Architecture ultimately helps to metabolise the system, not contribute to the bloat.

Agentic AI adoption will also not arrive evenly. The digital divide is already visible, not just between organisations but within them. Some functions will mature quickly while others will lag, and orchestration will need to span across both. The unevenness of maturity is a challenge for any vendor pushing a thin solution, but it fits IBM’s argument that architecture and orchestration are the narrow door to real scale.

There is a great line in the bible (St Luke) that functions as a useful frame for moments of real difficulty. Try your best to enter by the narrow door, because many will try and will not succeed. In the context of Agentic AI, the narrow door is architectural integrity. Few vendors are even aiming for it. Most are rushing the wide gate with “plus AI” products that add features without rethinking foundations. But scale does not come from shortcuts. Without solid architecture, they will not endure. IBM’s wager is that by moving slowly and deliberately, it, and its clients, can hold the narrow path.

So what is the endgame? A century-long perspective is useful, but markets live in five-year increments. IBM’s argument is that Agentic AI is not a race to the first billion-dollar assistant but a choreographed relay across decades of enterprise transformation. Rob Thomas frames it against global GDP.

If twenty percent of the world’s one hundred trillion dollar economy is knowledge work, and IBM can influence even ten percent of that, the opportunity is measured in hundreds of billions, if not trillions.

According to Thomas, the value curve to that elusive ROI runs from experimentation to automation, and then into multi-agent orchestration. We are at the early inflection point now.

Whether that is enough depends on whether enterprises finally reward architecture over agility. I think they should. I advocate for it every day. And IBM’s clients, like Singapore’s government agencies, may be patient, and willing to walk through the narrow door.

But markets are less forgiving. So the question is not whether IBM is right about hybrid agentic architectures. It almost certainly is. The question is whether doing it slow and doing it right will once again leave the company with superior technology and inferior market share.

On strategy, I am with IBM. Agentic AI is not a software SKU and it is not a service licence. Vendors who treat it that way will win headlines and lose the future. IBM’s execution still feels unfinished, but the architecture is right. In the end, on the path to Agentic, that is the only door worth walking through.

I used to take it personally. More than once I was passed over for senior sales positions at some of the biggest technology firms in the world. On paper, the explanation was always tidy: I hadn’t carried a quota for a decade.

In practice, the decision had less to do with capability than with a checklist approach to hiring. If you hadn’t been closing deals in the previous 18 months, you weren’t considered a contender.

Yet the irony was hard to ignore. The same companies that dismissed me for their sales teams regularly engaged me for their marketing, communications, sales enablement, and executive strategy work. I was trusted to shape the very narratives their account executives would take into the field, and to brief their leadership teams on market positioning and buyer dynamics. The gap between who they hired and who they listened to was striking.

For a while I assumed geography played its part. Being based outside the major metros can be a disadvantage in global hiring cycles. But over time it became clear that the deeper issue was the industry’s rigid view of experience. Ten years without a direct selling role was enough to disqualify me in their eyes. Yet much of what I saw, and continue to see, suggests that this obsession with uninterrupted sales tenure doesn’t produce the best results. Especially when most candidates come from the same closed pool of vendors, all selling variations of the same magic product.

This is more than just a personal frustration. It’s a structural blind spot in enterprise technology sales. One I see play out every day in buyer advocacy and frontline sales conversations. And it looks increasingly outdated in the age of AI.

Share

The enterprise tech industry has long prized tenure above all else. Job ads for senior roles rarely ask for adaptability, perspective, or an ability to navigate new categories. They ask for “10+ years of enterprise sales experience.” That phrase has become shorthand for credibility, even when the experience itself comes from running the same playbook at the same handful of vendors.

The result is a kind of recycling. Oracle hires from SAP. Salesforce hires from Oracle. Microsoft hires from Salesforce. Everyone is moving the same people around to sell slightly different variations of the same platform. It creates a talent pool that is deep in process familiarity, but often shallow in originality. These are professionals trained to sell what is already accepted, not to introduce what is still in question.

I’ve seen this up close. The best enterprise technology sales leader I ever met didn’t come from tech at all. They came from the fine arts. Their ability to frame ideas, command a room, and build trust outstripped anything a quota-carrying veteran could teach. More importantly, their approach to team development transformed an entire region’s sales culture. The acolytes who learned under them carried that influence forward for years, changing not just numbers but the way sales was practiced.

And the greatest account executive I ever worked with? They started as a retail sales assistant at Sportsgirl, with zero IT background. What they brought to the role wasn’t product familiarity. It was empathy, resilience, and an instinct for customer needs that no technical résumé could match.

These aren’t quirky exceptions. They’re reminders that the qualities that truly move markets often sit outside the narrow definitions of “experience” that hiring managers or LinkedIn AI recruitment algorithms cling to.

Selling in a mature ERP or CRM market is one thing. The product category is understood, the buyer knows what’s at stake, and the sales process is designed to remove friction. But when the category itself is shifting, as it is now, with AI moving from a buzzword to a platform, the old model looks less like discipline and more like inertia.

The question is no longer “who has carried a quota longest?” It’s “who can carry a conversation when the product is still being defined?”

That question matters most in the age of AI. No one has twenty years of AI sales experience. At best, a handful of people can point to a decade of working adjacent to machine learning or data platforms, but the idea of a career-long AI sales veteran is a fiction. The field is too new, too fluid, and too undefined.

Which means the hiring filters that worked for ERP and CRM fall apart here. A twenty–year Microsoft sales executive doesn’t automatically know how to sell an agentic platform, because there is no standard playbook to follow. The buyer isn’t looking for a familiar checklist. They’re trying to make sense of an unproven future. In that kind of market, credibility doesn’t come from longevity. It comes from the ability to frame uncertainty, to translate technical possibility into strategic clarity, and to build trust where no baseline exists.

And there’s another challenge for the veterans. Their success was built on selling into buying centres that no longer look the same. ERP and CRM were CIO- and CFO-centric motions, with clear procurement playbooks and predictable cycles. But AI doesn’t sit neatly in those lanes. Its impact cuts across HR, operations, customer experience, risk, even frontline service delivery. The buying conversation is migrating outward into parts of the enterprise where yesterday’s gurus never operated, and where their credibility is thin.

This is why the AI shift is not just about products. It’s about people. It should reset the very definition of sales experience. Those who thrived in a world of fixed categories may find themselves out of step. Those who can bridge strategy, relationships, and emerging capability may find themselves in demand, even if they never carried a quota in the “right” years.

So what actually matters when the playbook is gone? Not years in a territory, but the ability to read the room when the room itself is unsettled. Not how many quotas you’ve hit in the past, but how well you can navigate a buyer’s uncertainty today.

The most valuable skills now are relational and interpretive. The ability to build trust quickly across technical and executive audiences. The discipline to translate architectural shifts into business outcomes. The confidence to acknowledge risk while still creating momentum. And perhaps most of all, the willingness to learn in public because in AI, both the buyer and the seller are learning as they go.

This is where many “non-traditional” profiles have an edge. Strategists, advisors, solution consultants, business analysts, and those who have worked at the seams of marketing, product, and sales enablement in non-IT sectors often know how to shape a narrative, connect stakeholders, and create clarity. These aren’t necessarily the skills or domain of the quota-carrying IT veteran who’s mastered discounting and procurement cycles. They’re the skills of someone who can sell a future state that hasn’t yet been proven.

The irony is that the very qualities once seen as disqualifiers, things like time away from the field, careers built adjacent to direct selling, may be the ones most suited to leading the next era of enterprise sales.

As ERP titans pivot toward agentic, AI-first platforms, I don’t think the next generation of sales leaders will emerge from the same recycled talent pool. They will come from unexpected places: strategists, storytellers, or those who’ve led in functions adjacent to sales. People who can hold the room when the product is still foggy, who can translate uncertainty into belief, and who can shape narratives about a not-yet-defined future.

And here’s the irony. In most corners of corporate life, monocultures are seen as a liability. We celebrate diversity of thought, background, and experience in boardrooms, product teams, and marketing departments. Yet in enterprise sales, a monoculture is still treated as a virtue. The same résumés are shuffled around, the same playbooks re-run, the same assumptions reinforced. In the shift to AI and agentic platforms, sameness isn’t safe. It’s the real risk.

The leaders who will matter most won’t be carbon copies of yesterday’s quota carriers. They’ll be the ones who break the pattern, who arrive without the perfect résumé but with the ability to carry the conversation when the product, the market, and the future are all still being written.

Anyone who has worked in government knows the rhythm of transaction policy: the same services, repeated endlessly, with process refinements measured in years. The traditional remedy has been to throw people, process tweaks, and big technology projects at the problem. PaaS changes that equation. It brings the efficiencies of the “pane of glass” front-end directly in line with the back-end architecture, without forcing agencies to build monoliths or run decade-long custom development programs.

Modernising the core, application rationalisation, or database replatforming is no longer about grand $100+ million, five-year odysseys. The new normal will see projects more easily glide under or through Singapore’s $30 million “significant project” review trigger, enabling agencies to modernise faster, with procurement and architecture evolving together. I don’t think this shift will be just a cost story. It will be a redefinition of how digital transformation gets done in the public sector.

Singapore’s hiTech agencies, GovTech and IMDA, have long been the architectural conscience of the public sector. For over two decades, they’ve championed composable, reusable architecture, treating government systems as modular capabilities rather than one-off builds. This isn’t just governance. It’s active design stewardship. That philosophy is why PaaS lands so cleanly in Singapore today, setting a national baseline that agencies can extend rather than reinvent. They have also cut their teeth on SaaS, so there’s a hard won blueprint for a contemporary approach to executing as-a-service, securely and at scale.

Singapore’s whole-of-government service stack is already living proof of this philosophy. Platforms like Corppass (business digital identity), Singpass (citizen digital identity), Postman (nation-scale communications), SHIP (Smart Nation IoT architecture), and HATS (whole-of-government API testing and security) are more than just utilities. They are shared capabilities designed once, deployed everywhere, and reused across agencies.

I’ve accessed these services myself as an Australian-based contractor working on Singapore government projects, and the impact is unmistakable. The architecture doesn’t just benefit the agencies, it powers an entire, complex, and interconnected delivery ecosystem that spans borders, suppliers, and service providers.

This is exactly where ServiceNow has a strategic opening. Its modular platform components, like case management, workflow automation, integration hubs, and experience layers, are naturally aligned with Singapore’s reusable- and digital first program mindset.

But alignment isn’t enough. The opportunity here is to package these components as whole-of-government capabilities, built once, deployed centrally, and extended at speed across multiple agencies. If ServiceNow seizes that role, it doesn’t just modernise individual departments, it cements itself as the platform that defines the reusable-program standard for digital government.

That could be a strategic inflection point for the company. It’s one that I have no doubt has seen board-level friction and reluctance to go all in on its hitherto elusive platform destiny.

Then there is this.

In Singapore, architecture is never just about code, it is also about trust. As Hefen Wong, Director of Customer Systems and Experience at the Ministry of Manpower, put it: “Trust is the ultimate currency in Singapore.” If you’re a supplier and GovTech trusts you, that trust becomes currency in the Little Red Dot. Some of it measurable in contracts, some of it indirect and impossible to quantify.

What do I mean? Well, because Singapore’s public sector is underpinned by the global system integrator market, that trust doesn’t just move inside the island’s borders. It travels. It shapes the success of international providers in the region, it defines how solutions are designed, and over time, I think it nudges the entire global service provider market toward composable, PaaS-first agentic architectures by default. And a chunk of that with ServiceNow.

In this model, winning in Singapore isn’t just about delivering on island. It’s about setting the standard everywhere.

We’ve all seen the meme.

An endless row of urinals. One person standing in solitude. Another walks in and inexplicably takes the spot right next to them, breaking the unwritten rules of personal space. In the final frame, the interloper leans in and says: “Have you tried our new AI chatbot?”

It’s funny because it’s true. In enterprise technology, we’ve reached that moment.

No matter where you are, be it at a conference, in a customer meeting, or online, someone is pitching their AI. Not as a feature, but as a future. A bold promise of agentic transformation. A system that doesn’t just respond to prompts, but acts, learns, adapts, and even initiates. What they’re really describing is the top of the maturity curve: full agentic autonomy, integrated into complex workflows, spanning departments, functions, and systems.

But most organisations aren’t there. They are not even close.

To make sense of where we really are, we need to zoom out and think about the roles AI is actually playing inside the enterprise today. Not in terms of dry technical levels, but in terms of behavioral archetypes. That is, how agentic systems show up, contribute, and evolve within operational environments.

This isn’t just a metaphor. When you think about it, it’s how we already assess capability in people. Think of frameworks like SFIA, where progression is measured through increasing autonomy, complexity, and influence. Agentic systems can, and should, be viewed through the same lens. The difference is, these “digital roles” evolve fast, and organisations must be ready to architect around their growth.

Consider this maturity curve:

• Level 1: The Intern
  It waits to be told what to do. You type a prompt, it generates a response. It’s helpful, occasionally insightful, but entirely dependent on your initiative. It doesn’t know your business. It just listens, replies, and resets.

• Level 2: The Assistant
  It starts to understand the task at hand. It can reference documents, fetch status updates, and personalise answers slightly. But it’s still reactive. It doesn’t start work or close loops without being asked.

• Level 3: The Advisor
  Only now is it starting to show up inside workflows. It offers suggestions based on current context, flags likely next steps, highlights gaps. It has a seat at the table, but still needs your sign-off to act.

• Level 4: The Operator
  The AI begins to act independently on routine tasks. It follows observed patterns, initiates tasks based on known thresholds, and performs actions within bounded autonomy. Think rules with judgment. Still supervised, but operationally useful.

• Level 5: The Orchestrator
  It moves across systems, coordinates between teams, and links processes end-to-end. It behaves like a workflow manager with agency, making decisions, notifying stakeholders, and closing loops faster than traditional automation ever could.

• Level 6: The Autonomous Partner
  It sets goals, adapts to new constraints, learns from outcomes, and proactively adjusts course. This is the rare agent that doesn’t just do the work, it understands why the work matters. Few, if any, organisations are truly here, and none will arrive by accident.

  ---

Subscribe now

I think it’s a helpful frame. Because when someone pitches you “agentic AI,” what they’re really doing is pitching Level 5 or 6. The thing is, most organisations are still at Level 2 or 3. They are just trying to figure out how to manage (Level 2) Assistants and (Level 3) Advisors, not (Level 6) Partners. And that’s exactly where the real work is.

But this is also where architectural maturity matters.

To operationalise Agentic AI, organisations must first address where they actually are. This is not a deficiency; it’s the natural early phase of a longer journey. It’s where foundational work happens. Building structured workflows, cleaning up data debt, linking systems, embedding machine-readable signals into processes that were never designed to be dynamic.

Yet even while focusing on these foundational steps, architectural choices must still be made with higher maturity in mind. This doesn’t mean stalling delivery while you stand up a Centre of Excellence or blueprint every possible future state. In fact, the danger is doing exactly that.

This is about applying a core TOGAF-aligned principle: just enough, just in time.
Good architecture doesn't demand you predict the future but it does ensure you are ready for it. It scaffolds the business to evolve without locking it into imagined outcomes.

Because by the time you need AI to act autonomously across systems, functions, and boundaries it’s too late to retrofit the integration fabric, policy scaffolding, and trust frameworks that should have been laid down during the so-called “basic” levels.

The real “oops” moment won’t be that your COE wasn’t ready. It will be that your architecture wasn’t. Or worse. That there wasn’t one at all.

And as architecture matures, so too must cost modelling.

At Levels 1 to 3, AI usage feels mostly invisible. It is prompt-response tools bundled into product licenses, sporadic usage patterns, and low volumes. There’s no real cost signal and nothing to optimise.

But once you enter Levels 4 through 6, the economics of autonomy become real.
Agents aren’t just responding; they’re initiating. They’re generating, evaluating, and acting. Potentially tens of thousands of times per day. That’s when cost starts to matter. Not just to Finance, but to Architecture.

In preparation for this shift, I’ve been developing a lightweight benchmarking approach using two metrics: TRU (Token Resource Unit) and TAPS (Tokens Attributed Per Second). These are not industry gospel. Just my own working tools to help clients begin meaningful conversations about cost visibility, token efficiency, and agent value attribution.

Share

I’ll be sharing a more fulsome post on this in the coming weeks, focused on how to benchmark and anticipate the operational cost (not price) of agentic systems before they become invisible and unmanageable. Because cost, in an agentic world, is no longer just a licensing construct. It is also a function of architecture, observability, and flow.

The platforms best positioned for this journey, like ServiceNow’s NowAssist, Microsoft’s Copilot stack, and Google’s Duet AI (now evolving under Gemini), offer the ability to start small (Levels 1 and 2), embed gradually (Levels 3 and 4), and scale wisely (Levels 5 and 6). They don’t force you to leap ahead. They do allow you to build forward.

And crucially, they do so regardless of the underlying LLM instance whether that’s OpenAI, Anthropic, Mistral, Meta, Cohere, or Google itself. Because what matters isn’t which model generates the token. It’s how that token moves through your business, and what architecture governs its use.

But that same principle, meet the enterprise where it is, not just where you want it to go, should start applying to the vendors themselves. It’s probably time for a pivot. We get the vision. We understand the North Star. But now do a better job of lighting the path. Map it. Segment it. Make it real.

By all means, keep the platform-level vision and high-fidelity futurecasting for architects, strategists, and digital governance leaders who are building with 2030 in mind. But also come back to ground level. Meet the operators, the service managers, and the domain leads at Level 2, not just Level 6. Help them succeed in the present. Help them lay track, not just stare at the horizon.

Because while the men’s bathroom meme is light-hearted, the message beneath it is not. We are at risk of overwhelming teams and disappointing leaders by over-promising agentic transformation and under-delivering on operational value.
Worse, we risk turning AI into background noise. Just another system that talks a lot, but helps little.

It’s time to acknowledge the curve. Then respect the curve.

Design for the Partner. Deliver with the Assistant. Model the cost. Build the architecture. And maybe, let people finish their business in peace.