A recent OpenAI working paper on enterprise ChatGPT adoption analyzed more than 17 million messages across more than 1,500 organizations. Buried on page 35, past the usage-growth charts and the discussion of the "frontier gap," is a small table worth paying attention to.
| Metric measured | Correlation with revenue per employee |
|---|---|
| Messages sent per employee | Not statistically significant |
| Output tokens per employee | Not statistically significant |
There is an important qualification to what this table tells us. Revenue per employee was measured before ChatGPT adoption, so the study does not establish whether subsequent AI usage increased or decreased productivity. Nor does it show that AI usage has no economic value.
But it raises a question I think is more important: why are we measuring AI adoption through AI activity in the first place?
Messages sent. Tokens consumed. Users activated. Agents deployed. Workflows automated. These are useful measures of technology adoption. They are not business outcomes.
If the objective of enterprise AI is measurable improvement in business performance, then the architecture should begin with the business outcome we intend to change — and work backwards from there. That sounds obvious. But I watched the industry miss essentially the same opportunity during the previous wave of enterprise AI, and I think we are at risk of repeating it.
We have seen this before
The original promise of AIOps and observability was bigger than better monitoring. As machine learning became applicable to operational telemetry, the opportunity was to connect technology behavior to the availability and performance of the business processes technology supported.
If an order-to-cash process was repeatedly disrupted, for example, the objective wasn't simply to detect the infrastructure or application problem faster. The real outcome was improved availability and performance of order to cash. Technology telemetry was the intelligence required to achieve it.
Machine learning gave us new ways to recognize abnormal behavior, correlate signals and identify conditions that preceded failure. The business process gave those signals meaning.
I worked directly on this problem during that period. Using APAMA as the core event-processing engine, we built a layered, anomaly-detection-based approach to what I called incident avoidance. Instead of starting with every alert generated by the environment, we started with identified, repetitive, high-severity incidents and worked backwards:
- What business process was being affected?
- What metric patterns preceded the failure?
- Could multiple metric streams be layered together?
- Could anomalies be identified within the business process itself, in real time?
- Could automated root-cause identification enrich a pre-incident "situation" before the actual failure occurred?
The objective wasn't simply to detect the incident earlier. It was this: resolve the situation, and the incident never happens.
Later, I ran proof-of-concept demonstrations against real Severity-1 use cases across many of the major observability platforms available at the time. Technically, the concept worked — across platforms and across organizations. Commercially and operationally, it never scaled the way I expected.
A decade later, that experience looks increasingly important.
What actually scaled?
A 2026 survey of senior IT decision-makers with observability budget authority put a number on how far AIOps maturity has actually progressed.
| Maturity level | Share of organizations |
|---|---|
| Full operational maturity — AI fully leveraged across IT operations | 4% |
| Using AI to automate root-cause analysis and remediation | 12% |
| Using AIOps primarily for anomaly detection and incident response | 13% |
| Still piloting or experimenting | 49% |
| Not adopted AI or machine learning in IT operations at all | 22% |
But the more interesting question isn't simply how much AIOps was adopted. It is what we learned to measure once it was adopted.
Look at the metrics that dominate observability and AIOps success stories:
- MTTR reduced
- Alerts correlated
- False positives eliminated
- Root-cause analysis accelerated
- SLA compliance improved
These are all valuable operational improvements. But compare them with the outcome that originally mattered: did the availability and performance of the business process improve? Or more specifically, how many business-impacting incidents never occurred?
That metric remains remarkably difficult to find in published AIOps case studies. Somewhere along the journey, the center of gravity shifted. The technology was capable of supporting a business outcome. But implementation increasingly optimized the technology operation itself.
Detection became better. Response became faster. Operational KPIs improved. Avoidance did not become the dominant operating model.
Why? I don't think the missing ingredient was another generation of technology. I think the missing ingredient was intent.
What if the intent had been explicit?
Imagine that the transformation had begun with a statement like this:
"Improve the availability, performance and throughput of the order-to-cash process, measured through agreed business KPIs."
That changes the architecture. Now the objective isn't "implement observability." It isn't "deploy AIOps." It isn't even "reduce MTTR." Those become capabilities or intermediate measures. The governing intent is the performance of order to cash. Every technology decision can now be evaluated against it:
- If repetitive application or infrastructure conditions are causing the business process to fail, identify and avoid those conditions.
- If an operational event carries no meaningful business impact, stop generating work around it.
- If a known condition can be remediated without human intervention, automate it.
- If human judgment is required, provide the person with the context necessary to make the decision quickly.
And then return to the original question: did the business KPI move?
Had that intent remained the architectural anchor, I believe incident avoidance would have had a much stronger foundation for scaling. Because avoidance would no longer have been an interesting AIOps capability. It would have been a design requirement derived from a measurable business outcome.
That distinction matters enormously now, because we are entering the same decision point again.
The second wave: GenAI and agentic AI
Generative AI and agentic AI are dramatically more capable than the machine-learning systems of a decade ago. Large language models can reason across enterprise knowledge, interpret context, generate and modify code, interact with systems and increasingly execute multi-step workflows. Agents can plan, invoke tools, make decisions and complete work that previously required people to move between multiple systems.
The opportunity is enormous. And once again, the promise is measurable business outcomes:
- Higher productivity
- Lower operating cost
- Faster cycle times
- Better customer experience
- Greater throughput
In other words: peak business performance. But look at what we increasingly measure:
- Copilot adoption
- Users activated
- Agents deployed
- Tokens consumed
- Tasks completed
- Workflows automated
- Developer productivity
Once again, we risk allowing the measures of the technology to replace the measures of the business. The technology has changed enormously. The question organizations are asking has changed much less.
A decade ago, we asked: how can machine learning help us detect and respond to operational problems more intelligently? Today we ask: how can GenAI and agents execute existing work more intelligently?
Both are legitimate questions. But neither should be the first question. The first question should be: what measurable business outcome are we trying to change?
That is the role of Intent Architecture.
The missing layer: Intent Architecture
I define Intent Architecture as starting with a measurable business outcome, making that outcome the governing intent for the transformation, and using it to determine what should be eliminated, what should be automated and where human intelligence should be assisted or enriched.
The distinction from capability architecture is important. Capability Architecture asks: what can this technology do? Intent Architecture asks: what measurable business outcome are we trying to change — and what must we eliminate, automate or assist to change it?
Without that layer, powerful technology naturally attaches itself to the operating model that already exists:
- We automate the queue.
- We summarize the ticket.
- We generate the resolution.
- We build an agent to execute the workflow.
- We help the employee complete the task faster.
All of those can produce value. But none asks whether the queue, ticket, workflow or task should exist in its current form. That is where the architecture needs to begin.
Intent → Eliminate → Automate → Assist
Once the business intent is explicit, the design sequence becomes much clearer.
1. Define the measurable intent
Start with the business outcome, not the technology initiative. The distinction is critical — one names a technology initiative, the other names an outcome:
| Instead of | Define the outcome |
|---|---|
| Deploy AI across order management. | Reduce order-to-cash cycle time while improving availability, throughput and customer experience. |
| Deploy AIOps. | Reduce business disruption caused by repetitive technology failures. |
| Introduce an AI service-desk agent. | Reduce employee productivity lost to technology-related interruptions. |
And importantly, define the KPIs before designing the AI solution. If the business outcome isn't measurable before the transformation begins, it becomes very easy to substitute adoption metrics for outcome metrics later.
2. Eliminate
Once the intent is defined, ask what work is preventing that outcome and whether some of it needs to exist at all.
I have seen remarkably simple examples. An order stuck inside a highly capable order-management platform because the person who created it wasn't permitted to delete a single line item. The user couldn't correct it. A ticket had to be raised. It entered a queue. Someone eventually performed an action the original user could have completed immediately. The delay could last a day or two.
There was no technology problem. There wasn't even an automation problem. The fix wasn't a new AI capability. It was a permissions decision nobody had made.
If the intent is improving order-to-cash performance, that ticket isn't something to automate. It is something to eliminate. The same principle applies across enterprise operations:
- Unnecessary approvals
- Preventable incidents
- Avoidable access requests
- Duplicate reconciliation
- Known-error tickets
- Manual handoffs created by outdated controls
Before asking AI to perform any of that work faster, ask whether the work should continue to exist.
3. Automate what legitimately remains
Not all work can or should disappear. Once unnecessary demand has been removed, automate the repetitive work that legitimately remains. This is where GenAI and agentic AI become extraordinarily powerful.
But notice how different the economics now become. Instead of applying agents, inference, integration, orchestration, governance and exception handling to 100% of an inherited workflow, we apply them to the residual workload that actually deserves to exist.
That matters because AI isn't free. Every automated workflow carries infrastructure, inference, integration, monitoring, governance and exception-management costs. Automating work that could have been eliminated can create enormous AI activity without changing the underlying economics of the business process. More AI activity is not inherently more AI value.
4. Assist where judgment creates value
Some work remains because human judgment genuinely matters. That is where AI should enrich rather than merely replace:
- Bring together the context
- Surface relevant history
- Identify patterns
- Recommend actions
- Remove information-gathering work
Let the person focus on judgment, decisions and genuine exceptions. And importantly, treat those human interventions as intelligence:
- Why did the agent escalate?
- What wasn't understood?
- What judgment was necessary?
- Was the exception genuinely exceptional?
- Can the next occurrence be automated?
- Does the exception reveal another category of work that can be eliminated?
That produces a continuous improvement loop.
↻ every exception cycles back into Intent, sharpening what gets eliminated next
And through every cycle, measure against the business KPI that established the intent in the first place.
This is the connection the OpenAI data makes interesting
This brings us back to the table on page 35. Messages sent and tokens generated are useful indicators of AI activity. Revenue per employee is a business-performance measure. There is no reason to assume one automatically translates into the other.
Something has to connect capability to outcome. That something is the architecture of the operating model around the technology. Recent enterprise research makes the problem visible.
- Deloitte's 2026 State of AI in the Enterprise research found that 37% of organizations were still applying AI largely at the surface, with little or no change to underlying processes. Another 30% were redesigning key processes around AI, while only about a third — 34% — reported deeper transformation involving new products, services, core processes or business models. Only 21% reported having a mature governance model for autonomous AI agents.
- IBM's research exposes an equally interesting contradiction. More than three-quarters of executives said most AI investment had focused on improving existing processes rather than developing net-new capabilities. At the same time, 78% of C-suite executives said achieving maximum benefit from agentic AI requires a new operating model.
In other words, enterprises increasingly recognize that the operating model must change. But much of the investment is still going toward making the existing model more capable. Intent Architecture provides the bridge.
The same architecture applies across the enterprise
Consider software engineering. A coding agent can repeatedly fix a class of defect. But if those defects originate from an upstream schema, contract or architectural problem, the intent shouldn't be to make the agent increasingly efficient at fixing them. Eliminate the source.
Consider code review. A copilot can generate comments every time a developer violates the same rule. But if the condition can be prevented through policy, linting or an architectural control, don't build a more intelligent review process around recurring unnecessary work. Eliminate it.
Consider employee support. An AI agent can become extraordinarily efficient at resolving password, access and configuration requests. But if users can safely self-serve those actions, don't celebrate the number of tickets the agent resolved. Ask why the ticket existed.
And consider IT operations. An AIOps platform can become extraordinarily good at predicting, diagnosing and remediating incidents. But if the same underlying condition continually generates those incidents, the ultimate measure isn't how quickly AI resolved them. It is whether they stopped occurring.
Different technologies. Different workflows. The same architecture.
Procurement cannot buy intent it was never given
This also explains a persistent problem with outsourced services. Many managed-services contracts still operate through FTE, time-and-materials, ticket-volume or other input-oriented commercial models.
It is easy to blame the service provider. A vendor paid to process work has an obvious economic tension when asked to eliminate the work generating that revenue. But that is only half the problem.
Procurement typically receives something to source after the operating model has already been defined: FTE requirements, ticket volumes, response-time SLAs, service categories, unit-cost targets. These are measurable, benchmarkable and auditable. But procurement cannot independently decide that 40% of those tickets should never exist. That decision belongs upstream with the owner of the business process.
If the process owner hasn't defined the intended business outcome and identified what demand should disappear, procurement cannot reasonably construct a contract around eliminating it. So procurement buys capacity to process the demand. The provider optimizes delivery. AI is introduced to improve productivity. And everyone may perform exactly as they were incentivized to perform. Yet the unnecessary work survives.
Intent was never handed to procurement to contract against. This is why outcome-based contracting begins before the RFP. It begins with Intent Architecture.
Two waves, the same missing architecture
Looking back, I increasingly see the first wave of AI in operations and today's GenAI/agentic-AI wave as variations of the same architectural challenge.
In the classic AI and machine-learning era, we had the ability to use intelligence to improve the availability and performance of technology-enabled business processes. But what scaled most visibly was detection and response, not the avoidance that could have compounded into a business KPI.
Now GenAI and agentic AI give us vastly greater capability. We risk scaling the first pattern again, at a much larger scale, instead of the second.
The technology waves are different. The missing layer is the same: intent.
The question I'd put to CIOs
The question isn't whether enterprises should adopt AI. They already are. Nor is it whether generative AI and autonomous agents will become more capable. They will.
The question is what sits above that capability. Before deciding which model to deploy, which copilot to license, which agent to build or which workflow to automate, ask: what measurable business outcome are we trying to change?
Then make that outcome the intent around which the architecture is designed. What can be eliminated? What should be automated? Where should people be assisted? What should the system learn from the remaining exceptions? And ultimately: did the business KPI move?
A decade ago, we had machine-learning technology capable of helping us avoid incidents and improve the availability and performance of business processes. What scaled more successfully was detection and response. Today, we have dramatically more powerful intelligence available to us. We shouldn't repeat the same architectural mistake at a much larger scale.
Capability Architecture asks what AI can do. Intent Architecture defines the measurable business outcome and determines how AI — through elimination, automation and assistance — should achieve it. If we want AI adoption to scale into measurable business outcomes rather than simply measurable AI activity, that intent needs to come first.
Key Takeaways
- OpenAI's own enterprise ChatGPT research found no statistically significant correlation between messages or tokens per employee and revenue per employee — activity metrics aren't outcome metrics, and adoption doesn't automatically translate into business performance.
- AIOps taught the same lesson a decade earlier: machine-learning capability scaled into faster detection and response, while the outcome it could have delivered — incident avoidance tied to a business KPI — never became the dominant operating model.
- Intent Architecture starts with a measurable business outcome as the governing intent, then works through a design sequence — Eliminate, Automate, Assist — with every human exception feeding back into what gets eliminated next.
- Deloitte's and IBM's 2026 research shows the same gap playing out today: most AI investment still optimizes existing processes, even as large majorities of executives say agentic AI requires a genuinely new operating model.
- Procurement cannot eliminate demand it was never told to eliminate. Outcome-based contracting — and outsourced-services reform generally — has to begin with Intent Architecture, upstream of the RFP.
Sources & Further Reading
- OpenAI — How Organizations Use AI: Evidence from ChatGPT. Enterprise ChatGPT research covering more than 1,500 organizations and more than 17 million messages, examining enterprise adoption, usage intensity and organizational characteristics.
- LogicMonitor — 2026 Observability & AI Outlook for IT Leaders. Research on AI and observability maturity, including adoption of anomaly detection, automated root-cause analysis, remediation and broader AI-enabled operations.
- Deloitte — The State of AI in the Enterprise 2026: The Untapped Edge. Research based on 3,235 business and IT leaders across 24 countries examining surface-level AI adoption, process redesign, deeper business transformation and agentic-AI governance.
- IBM Institute for Business Value — Agentic AI's Strategic Ascent. Research examining the shift from incremental AI improvements to new operating models and the C-suite view that realizing agentic AI's full potential requires operating-model transformation.