In the age of AI, the bottleneck is shifting from writing code to specifying what we actually want.

Most of us in technology have seen some version of the famous project swing cartoon.

Illustration from ProjectCartoon.com

The customer explains one thing. The project leader understands something slightly different. The analyst designs something else. The programmer builds another interpretation. Operations installs something different again. And at the end, what the customer actually needed was remarkably simple.

We used to laugh at this because it captured one of the oldest problems in software development – what someone meant and what eventually got built were often very different things.

For decades, software engineering has focused heavily on one question – how do we build software better? For years, we tried to solve that problem with better requirements, Agile, user stories, acceptance criteria, prototypes, architecture reviews and tighter collaboration. Better languages. Better frameworks. Better architectures. Better development tools. Better testing. Better DevOps. And yet the fundamental problem never disappeared. Intent gets lost in translation.

Now add AI.

AI changes the economics of misunderstanding

Give an experienced developer an ambiguous requirement and they will usually stop and ask questions.

What exactly do you mean? What happens in this scenario? Which system is the source of truth? Who is allowed to do this? What does “done” mean?

Give an AI coding agent permission to execute against the same ambiguous requirement, and unless the workflow forces clarification, something interesting can happen – it may simply build it – Quickly – Beautifully – And potentially incorrectly.

That changes the problem. When software took weeks to build, ambiguity created rework. When AI can generate an API, write tests, refactor code, create documentation and prepare deployment artifacts in hours – or sometimes minutes – the act of producing code becomes less of the constraint. Ambiguity can now scale at machine speed. The act of producing code starts becoming less of the constraint. A different constraint becomes visible – did we clearly specify what we wanted in the first place?

The New Programming Language May Be Specification

We spend enormous energy discussing prompt engineering. But as AI takes on more execution, I think another discipline becomes equally important – specification engineering – the ability to turn business intent into clear, contextual and testable instructions for humans and AI.

Not bigger requirements documents. Not bringing waterfall back.  Quite the opposite – A good specification is a clear expression of intent with enough context for execution. It should allow a human – or an AI agent – to understand.

• What are we trying to accomplish?
• Why does it matter?
• What are the constraints?
• What systems and data are involved?
• What decisions have already been made?
• What remains open?
• What does “done” actually mean?

That changes the role of the backlog. A Jira story shouldn’t simply be a ticket waiting for someone to code. It becomes an expression of intent. And creating that expression of intent isn’t the responsibility of one role. Product owners bring the business outcome and priorities. Business analysts and domain experts translate needs, rules and exceptions. Architects and engineers surface technical constraints and dependencies. Security, data, QA and operations contribute the questions that make the specification complete.

Consider a simple Jira story

Suppose the story says – build an API to retrieve policy information. AI can certainly generate an API from that. But should it? There are dozens of unanswered questions. Which policy information? For which user? Who can call the API? What is the source of truth? What happens if there are multiple matches? What fields are restricted? What should happen when the policy system is unavailable?What are the latency expectations? What should be logged? What should the error response look like? What constitutes success?

Those aren’t really coding questions. They’re specification questions.

Experienced engineers have always filled these gaps through conversations, assumptions, institutional knowledge and judgment. AI doesn’t eliminate those gaps. It exposes them. And sometimes it does something potentially more dangerous – It confidently fills them in for us. An LLM is exceptionally good at filling gaps. Unfortunately, the answer it invents may not be the answer your business intended.

The quality of the answer starts with the quality of the question

Now imagine giving an AI engineering agent a vague Jira story. It can generate code.

Now give the same agent – a clear requirement + acceptance criteria + API standards + architecture patterns + data models + security requirements + existing code + examples of similar implementations.

The difference in output can be enormous. And this is an important distinction. The model didn’t necessarily become smarter. The context became better. That may be one of the most important lessons in AI-led software engineering. The answer isn’t necessarily to keep searching for a smarter model. Sometimes the answer is to give the model better intent, better context, better constraints and better evidence of what “good” looks like.

The bottleneck is moving

For decades, much of software engineering productivity focused on – how quickly can we turn requirements into code? AI is rapidly compressing that part of the lifecycle. The emerging constraint may instead become -how clearly can we turn business intent into something executable? That changes the engineering lifecycle. Traditionally, we might think of it as – Requirement – Developer – Code. Increasingly, it looks more like – Intent – Specification – Context – AI Execution – Human Judgement – Evidence. Each part matters.

• Intent – What business outcome are we actually trying to achieve?
• Specification – What precisely should happen?
• Context – what does the AI need to know about our architecture, systems, standards, data and constraints?
• AI Execution – use AI to perform and accelerate more of the analysis, design, coding, testing and documentation, within defined engineering controls.
• Human Judgment – review critical decisions, resolve ambiguity and exceptions, make trade-offs and validate that the outcome matches intent.
• Evidence – can we demonstrate that what was built satisfies the requirement and behaves correctly?

The better the specification and context, the less the AI has to guess. And as AI gets faster at execution, the quality of everything upstream becomes more important, not less.

Asking the right question becomes an engineering skill

There is another implication that we find particularly interesting. Engineers have traditionally been valued partly for knowing how to produce the answer. Increasingly, some of the highest-value engineers may be those who know –  which questions must be answered before anything should be built? Take our simple requirement – build an API to retrieve policy information.

A product owner asks what business outcome we’re trying to achieve and for whom. A business analyst asks about the workflow, rules, exceptions and acceptance criteria. An architect looks at it and asks about system boundaries and integration patterns. A security engineer asks who should be allowed to call it and what they should be allowed to see. A data engineer asks where truth resides and how data should be interpreted.A QA engineer asks how we’ll know the API behaves correctly across positive, negative and edge cases. An operations engineer asks what happens when a dependency fails at 2 a.m. A domain expert sees the business exception nobody else noticed. No single role owns all the right questions. The quality of the specification emerges from bringing these perspectives together.

AI can help answer many of those questions. But first, somebody has to know – that the question matters. That is engineering judgment. And judgment may become more valuable – not less – as execution becomes automated.

This doesn’t make humans less important

As AI takes on more execution, more human value moves upstream—and toward the points in the lifecycle where judgment matters most. From writing every line of code toward – defining intent, providing context, challenging assumptions, making trade-offs, setting constraints, recognizing exceptions, validating outcomes.

The scarce skill may no longer simply be – can you build it? It will increasingly become – can you define precisely what should be built – and recognize whether what was built is right? AI may make implementation dramatically faster. It doesn’t remove accountability for the outcome.

The next generation of SDLC may start before the code

This is something we have been thinking about as we develop AcxWorks, our approach to AI-led software delivery. The interesting opportunity isn’t simply putting a coding assistant in front of every developer. The opportunity is bigger. Start with the backlog. Understand the intent. Identify what is missing. Ask the questions that need to be answered. Bring in the relevant enterprise context – Architecture, API standards, Security patterns,  Data models, Existing code, Similar implementations, Testing standards, Business rules, Acceptance criteria.

Then let AI progressively help across the lifecycle – Plan – Design – Build – Test – Deploy – Operate.

• At Plan, AI can analyze the backlog, identify missing information, dependencies and risks.
• At Design, it can propose API contracts, architecture, integration patterns and technical approaches using enterprise standards and existing patterns.
• At Build, it can generate and modify code using the approved design and repository context.
• At Test, it can derive test scenarios from the original requirement and acceptance criteria—not merely test the code it generated.
• At Deploy, it can assist with reviews, release evidence, documentation and readiness while deterministic CI/CD controls what ships.
• And at Operate, production telemetry, incidents and behavior can become context for the next iteration.

The lifecycle becomes a continuous loop rather than a one-way path to production.

AI-led execution. Human governance.

This is an important distinction. AI-led engineering doesn’t mean – AI builds software and humans watch.

It means AI can take on substantially more of the execution while people retain responsibility for the decisions that require context, judgment and accountability. The engineer’s role changes from doing every step manually to guiding, constraining, reviewing and validating an increasingly capable execution layer.

That is why the starting point isn’t code. It’s clarity. Because when AI can build faster than ever, ambiguity gets expensive faster too.

Perhaps the old swing cartoon has never been more relevant

For years, the cartoon was funny because it showed how easily a simple customer need could become distorted as it moved through an organization. AI doesn’t automatically solve that problem. In some ways, it raises the stakes. We may finally have technology capable of turning ideas into working software dramatically faster than before. That’s extraordinary. But before celebrating how quickly AI can build the swing, perhaps we need to become much better at answering a more fundamental question:

What kind of swing did the customer actually want?

The future of software development isn’t just about writing better code. It’s about expressing better intent. And perhaps one of the most valuable engineering skills in the age of AI won’t be knowing all the answers. It will be knowing the right questions to ask.

AI can build faster. The question is – can we specify better?

Illustrations generated using ChatGPT (OpenAI)

Most insurers don’t need a model that knows insurance. They need a model that knows their insurance.

The same is true for banks, healthcare organizations. manufacturers…

Every enterprise has products, business rules, operating procedures, terminology, and decades of institutional knowledge that make it different from every other organization in its industry.

A general-purpose AI model understands the industry. It doesn’t understand your enterprise.

That distinction will become increasingly important as AI moves from experimentation into business-critical operations.

You are paying twice.

The cost of enterprise AI is usually measured in tokens. But that’s only half the story. You are paying twice.

Paying Twice

First, in tokens –

• Every claim summarized.
• Every underwriting submission reviewed.
• Every document extracted.
• Every API call.

Metered per interaction, repriced on someone else’s schedule. Everyone understands that cost.

Second, in compounding – and this one never reaches the invoice.

Reputable providers commit contractually not to train on enterprise data, and that commitment is worth having. But it doesn’t change the underlying arithmetic – nothing accumulates on your side.

Every correction your adjusters make, every prompt your team refines, every evaluation you run to prove an output is safe – all of it improves this quarter and leaves nothing behind. Year three looks like year one, minus the spend. And because every carrier is renting from the same handful of providers, whatever capability you gain, your competitors gain on identical terms. Differentiation that comes from a shared model isn’t differentiation. Meanwhile the things that actually separate you stay outside the model entirely –

• Your products
• Your underwriting philosophy
• Your claims handling practices
• Your policy forms
• Your operating procedures
• Your engineering standards
• Your enterprise terminology

A general-purpose model knows insurance. It doesn’t know your insurance – and no amount of prompting permanently teaches it, because nothing you teach it persists past the context window.

The organization that trains on those same interactions ends year three holding something: weights that encode how its people actually work, an evaluation suite calibrated to its own standards, and a pipeline that turns next year’s work into next year’s improvement.

That is the real second cost of renting. Not that someone takes your knowledge – that you never get to keep it. And every enterprise reaches the same realization eventually .. the closer AI gets to business-critical work, the more enterprise-specific knowledge matters.

What is a Sovereign Model?

Sovereign Model

The term “sovereign AI” is used in different ways. For the purpose of this article, a sovereign model isn’t simply an AI model running on-premises. It is an enterprise model built on an open-weight foundation model, then adapted, governed, and continuously evolved by the enterprise. That means –

• You choose the open-weight foundation model.
• The enterprise owns the model, adapters, and enterprise knowledge it builds.
• Your data remains under your control.
• It runs inside infrastructure you choose.
• It continues to operate regardless of any individual AI vendor.

Sovereignty isn’t about isolation. It’s about ownership. A simple test captures the idea. If your AI vendor disappeared tomorrow, what would your enterprise still own?

Frontier Models and Sovereign Models are complementary.

This isn’t an argument against frontier models. Quite the opposite. Frontier models continue to redefine what’s possible. They are exceptional for:

• Research
• Coding assistance
• General reasoning
• Knowledge discovery
• Creative work

Every enterprise should use them where they create value. But not every enterprise capability should depend entirely on models whose weights, pricing, roadmap, and availability are controlled elsewhere. General intelligence is becoming increasingly accessible. Enterprise knowledge never will.

Enterprise AI is evolving into four layers.

Rather than thinking about “one model,” enterprises will increasingly think in layers.

Layer 1 – Open-weight Foundation Model

Start with an open-weight foundation such as Qwen, Llama, Mistral, Gemma, or another approved model. The objective is not to build a model from scratch. It is to start with one your enterprise can own and deploy.

One point of precision, you own the weights you train. You inherit the licence of the base model you started from, and those licences are not uniform – some are permissive, others carry attribution, usage or scale conditions that flow through to derivatives. Choosing a base model is a legal decision as much as a technical one, and it belongs at the start of a project rather than the end.

Layer 2 – Industry Foundation Model

Teach the language of the industry. Insurance / Banking / Healthcare / Manufacturing.

This layer captures the concepts every organization in that industry shares.

Layer 3 – Company Foundation Model

This is where competitive advantage lives.

• Your products.
• Your forms.
• Your terminology.
• Your underwriting rules.
• Your claims philosophy.
• Your operating procedures.
• Your engineering standards.

This is the layer that differentiates one carrier from another.

Sovereignty means being deliberate about what belongs inside the weights and what belongs around them. Two questions decide it.

How fast does it change? Your terminology, your house voice, your claims philosophy, your engineering conventions and the way your organization reasons about risk move on a scale of years. Train them. They should shape how the model thinks by default, which is something no amount of context-stuffing achieves. Your endorsement library, rate tables, form versions and desk procedures move on a scale of weeks. Train those and you’ve built something that is confidently wrong by next quarter.

Does it need to be provable? Some knowledge stays outside the weights even when it’s stable, because the answer has to cite a source. When an agent tells an insured what their policy covers, a regulator wants the form referenced, not a model recalling it. Retrieval isn’t only about freshness – it’s about producing an audit trail.

Train the judgment. Wire in the facts. A sovereign model isn’t one large artifact – it’s a stable trained core, surrounded by machinery that keeps it current and accountable.

Layer 4 – Business Agents (insurance example below)

Insurance examples –

• Underwriting — clearance, appetite screening, submission triage
• Policy operations — endorsements, form comparison, renewal review
• Claims — FNOL intake, coverage checks, file summarization

This is where enterprise specifics arrive at runtime. Agents retrieve the current form, read the live claim record, call the systems of record, and carry context across a transaction. The layers below supply vocabulary and judgment; this layer supplies today’s facts.

That inheritance is what separates an agent from a demo. An agent running on general-purpose intelligence begins every task as a stranger to your business, and spends its context being briefed. One built on the layers below starts already knowing how your organization reasons – and spends its context on the work.

The model isn’t the product.

The enterprise capability is. The objective isn’t to own AI for the sake of ownership. The objective is to own the intelligence that powers the business capabilities your enterprise depends on.

Most enterprises don’t own their policy administration, claims or billing platforms. They license them – and a decade of cloud migration moved them further from ownership, not closer. That was a reasonable trade. A system executes a process, and processes are largely common across an industry; there was never much advantage in owning the code that issues a policy.

A model is a different kind of thing. It doesn’t execute your process, it reproduces your judgment – how your underwriters read a submission, how your adjusters weigh a file, what your organization has learned to treat as normal. That judgment isn’t available from any vendor, because no vendor has it. It was built inside your own walls over decades, and it is now, for the first time, expressible as an asset.

Building sovereign models requires more than technology.

Owning a sovereign model is not simply downloading an open-weight model and fine-tuning it. It requires –

• identifying and preparing the right enterprise data
• building industry and company training datasets
• establishing evaluation benchmarks
• implementing governance and guardrails
• deploying models into enterprise infrastructure
• continuously retraining and monitoring them as the business evolves

In other words, building sovereign models requires a repeatable engineering capability – not just another AI project.

What this costs.

Sovereignty isn’t free, and an argument that pretends otherwise deserves suspicion. A model you own sits at a fixed capability level while frontier models improve past it. You take on the evaluation burden, the retraining cadence, the drift monitoring and the safety work a frontier vendor would otherwise absorb.

So the case isn’t “own everything.” For open-ended reasoning at the edge of what’s possible, renting is the right answer and likely always will be. Ownership earns its keep on the workloads that run constantly, touch your most sensitive data, depend on vocabulary only you use, and separate you from the carrier across the street. That is precisely where renting compounds against you.

Why we created SovereignWorks.

This is the thinking behind SovereignWorks.

SovereignWorks – The Sovereign Model Factory

SovereignWorks is not simply another AI platform or another hosted model. It is a Sovereign Model Factory – a combination of technology, people, and proven engineering processes that helps enterprises build, deploy, govern, and continuously evolve models they own.

SovereignWorks brings together three things – an industry foundation model, starting with insurance – already trained on the language of the industry, a pipeline that turns enterprise data into training sets and evaluation benchmarks, and a deployment and governance layer that runs inside the enterprise’s own environment. Organizations can leverage SovereignWorks to build sovereign models that remain under their control, evolve with their business, and operate within their own chosen environment.

The objective isn’t simply to deploy another AI solution. It is to help enterprises establish the capability to build models that become long-term strategic assets.

We spent twenty years learning that renting software was fine. It was — for systems. Models are where that logic breaks, because a model reflects the part of the business you could never have bought in the first place. The next decade of enterprise architecture will be less about owning the systems that run the business and more about owning the intelligence that reflects it. Frontier models will continue to play an essential role. But the business capabilities that differentiate an enterprise deserve something more – a model that understands its business, reflects its knowledge, and evolves with it.

Illustrations generated using ChatGPT (OpenAI)

Over the past four decades, enterprise technology has gone through several major architectural shifts. We moved from monolithic applications to TP monitors, object-oriented programming, component architectures, SOA, microservices, APIs, cloud-native platforms, and now AI agents.

Each wave promised the same outcome – more modular, reusable, and composable business capabilities that enable greater automation. The technology itself was rarely the reason these initiatives succeeded or failed.

The organizations that were successful didn’t simply adopt the latest technology. They invested the effort to identify the right business abstractions – the procedures, functions, services, APIs, and reusable capabilities that represented how work should actually be performed. Those abstractions allowed technology to evolve while the business capabilities remained stable.

AI agents represent the next evolution in that journey. The abstraction has always been the business capability; only the implementation has changed. An AI agent is not the abstraction – it is simply another way of executing that capability.

From functions to objects, from services to APIs, and now to AI agents, the implementation has continued to evolve. The business capability remains the constant.

Which brings us to the questions I hear every week – Which LLM should we use? Which agent framework should we choose? How should we engineer the prompts?

Those are all important engineering decisions. But they aren’t the only design decisions that matter. If we focus only on models, prompts, and frameworks without taking the time to defining the business capability we want the agent to perform, we will simply create another generation of technical debt – this time powered by AI.

Before choosing a model or framework, every enterprise AI agent needs three things: Context, Authority, and Tools.

A capable model does not create capable enterprise agent

A capable model does not automatically create a capable agent. For an AI agent to perform meaningful work inside an enterprise, it needs three things:

1. Context – Without context, the agent does not understand the situation.
2. Authority – Without authority, it cannot act.
3. Tools – Without tools, it cannot complete the work.

1.  Context: What does the agent need to understand?

An agent needs more than a prompt.

It needs the information required to interpret the situation, make an appropriate decision, and understand the consequences of that decision. Depending on the task, context may include –

• The customer’s history and current request
• The state of a transaction or case
• Relevant policies and operating procedures
• Product and service information
• Previous decisions and communications
• Business rules and regulatory requirements
• Exceptions, dependencies, and deadlines
• The objective the agent is expected to achieve

Consider a claims agent asked to evaluate the next action on a claim. A prompt may tell it to “review the claim and recommend the next step.” But the agent cannot do that reliably without understanding the policy, coverage, claim history, supporting documents, prior communications, jurisdiction, and applicable business rules.

The model may be intelligent, but intelligence without context becomes inference. And in an enterprise process, unsupported inference creates risk. The challenge is not simply giving the agent more information. Too much irrelevant information can be as problematic as too little.

The agent needs the right context, at the right time, for the specific decision it is making.

2. Authority: What is the agent allowed to do?

Understanding the work does not mean the agent should be allowed to perform every action associated with it.

Authority defines the agent’s decision rights and boundaries.

Can the agent – Read customer information? Update a record? Approve a transaction? Issue a payment? Communicate directly with a customer? Override a business rule? Escalate an exception? Delegate work to another agent or employee?

These permissions should not be treated as a single yes-or-no decision.

Authority should be specific to the task, the level of risk, and the confidence of the decision.

For example, an agent may be allowed to approve refunds below a defined amount when all policy conditions are satisfied. A higher-value refund may require human approval. A transaction with missing information or conflicting signals may need to be escalated automatically.

Authority also requires accountability.

Every meaningful action should have a clear record –

• What did the agent decide?
• What evidence did it use?
• Which policy or rule supported the decision?
• What action did it take?
• When did it escalate to a person?
• Who is accountable for the outcome?

An enterprise agent should not have unlimited freedom. It should have bounded authority that is proportional to the risk of the action.

3. Tools: How will the agent perform the work?

An agent cannot complete enterprise work by generating text alone.

It needs tools that allow it to interact with the systems where work happens. Those tools may allow the agent to –

• Retrieve customer or transaction data
• Search enterprise knowledge
• Initiate workflows
• Send approved communications
• Schedule follow-up activities
• Escalate work to an employee …

The quality of an agent depends partly on the quality of these tools. If a tool is unreliable, poorly defined, or exposes more capability than necessary, the agent becomes unreliable as well. Each tool should have a clear purpose, structured inputs and outputs, appropriate access controls, and predictable failure behavior.

The agent also needs to know when not to use a tool.

It should understand which actions are reversible, which create financial or customer consequences, and which require confirmation or human approval.

Giving an agent access to a system is not the same as designing a safe way for it to use that system.

All three must work together

Context, authority, and tools are not independent design decisions. They must align around the work the agent is expected to perform. An agent may have the context to identify that a payment should be issued, but not the authority to approve it. It may have the authority to update a customer record, but not the tools required to access the system. It may have both authority and tools, but insufficient context to know whether the action is appropriate.

In each case, the agent fails – not because the model is incapable, but because the operating environment is incomplete. A useful way to think about agent readiness is – Context determines what the agent understands. Authority determines what the agent may decide and do. Tools determine what the agent can execute.

The model provides reasoning across all three. But the enterprise must design the conditions in which that reasoning operates.

Start with the work, not the agent

Before creating an AI agent, organizations should understand the process in which it will operate.

• What outcome is the process trying to achieve?
• Which decisions are deterministic?
• Which require judgment?
• What information is needed for each decision?
• Which actions can be delegated safely?
• Where must accountability remain with a person?
• Which systems are required to complete the work?

Only then can the organization define the agent’s context, authority, and tools. The most important question is not – Which model should power this agent? It is – What must this agent understand, what should it be allowed to do, and what capabilities does it need to complete the work safely?

One lesson we have learned

As we have evolved KognitiveWorks from an intelligent document processing platform into an enterprise agentic platform, one lesson has become clear – building enterprise agents is not primarily about selecting the best LLM. Most of the engineering effort goes into assembling the right context, defining authority boundaries, and exposing enterprise capabilities through secure APIs and MCP-enabled integrations. The model provides the reasoning. The enterprise provides the operating environment. That’s why enterprise AI is ultimately an engineering problem – not simply a model selection problem.

Enterprise AI won’t be won by organizations with the smartest models. It will be won by organizations that build the best business capabilities. Prompts will change. Models will improve. Agent frameworks will evolve. But every enterprise AI agent will still need three things – the context to understand, the authority to act, and the tools to execute. Which of these is the biggest constraint in your organization today?

Why process intelligence – not technology alone – reveals where transformation should begin.

Organizations spend millions trying to improve processes.

• They automate them.
• They digitize them.
• They apply AI to them.

And still, most of it doesn’t stick. BCG’s research across more than 850 companies found that only 30–35% of digital transformations meet their goals – and the shortfall is rarely the technology.

Why? Because most organizations are optimizing the wrong version of the process. In my experience, every enterprise process has at least four versions.

4 Versions

1. The documented process.

The SOPs, operating procedures, and process maps that describe how work is supposed to happen.

2. The process people describe.

Ask five experienced employees how a process works and you’ll often get five different answers. None are intentionally wrong — they reflect how work has evolved, and the workarounds people quietly build to get things done. This isn’t a new phenomenon: researcher Steven Alter’s “Theory of Workarounds” found that workarounds are a predictable, rational response to a system that no longer fits the work — not a discipline problem.

3. The process the systems reveal.

Application logs, transaction histories, work queues, audit trails, emails, exception reports, and performance data often tell a different story. They show how work actually gets done—not how people think it gets done or how the documentation says it should happen.

This is where many organizations stop. They compare what the process was supposed to be with what actually happened. But there is another, more important question.

Why does the process exist in the first place?

4. The reason the process exists in the first place.

This is usually buried somewhere in organizational history. Perhaps twenty years ago, an underwriting process required three manual reviews because the policy administration system couldn’t automatically score risk. Perhaps a claims process required multiple approvals because information wasn’t available electronically. Perhaps customer service representatives had to manually gather information from several systems because those systems couldn’t communicate with one another.

Legacy constraints

Yesterday’s constraints, today’s process

Those constraints were real … at that time… Today, many of those technical limitations no longer exist. Modern platforms, APIs, intelligent automation, and Agentic AI can solve problems that previously required extensive human effort.

Yet the process remains almost unchanged. Not because it is still the best way to work – but because nobody has revisited the original assumption behind it.

That is why process discovery is only the beginning. Real transformation comes from process intelligence.

Process Intelligence

From process discovery to process intelligence

Process intelligence begins by reconciling multiple sources of truthIt requires reconciling multiple sources of truth.

• Standard operating procedures
• SME interviews
• Process maps
• Application and system logs
• Event and transaction data
• Audit trails
• Exception reports
• Work queues
• Email interactions
• Performance and operational metrics

Process mining tells you what happened. Process intelligence asks why it started – and whether that reason still holds. Only when these perspectives are combined can you answer the questions that matter. The path is straightforward, even if the work is not – establish how the process is documented – compare it with how people describe it and what the systems reveal; investigate where those versions disagree – and then challenge the assumptions behind each step before deciding its future.

The decisions that matter

Only when these perspectives are combined can organizations answer the questions that matter.

• Which steps are still creating value?
• Which controls exist only because of technology limitations that no longer exist?
• Which activities should remain human decisions?
• Which should become deterministic automation?
• Which are now candidates for autonomous AI agents?

The most valuable AI opportunities rarely begin with asking – “Where can we use AI?” They begin with asking – “Why does this process exist, and does that reason still hold true?”

AI doesn’t discover transformation opportunities – Process intelligence does. And once you understand the real process – not just the documented one – you can redesign work for today’s technology instead of yesterday’s constraints.

How this connects to our work

This is exactly the gap StratWorks – our AI-informed strategy sprint at Acxhange – is built to close. Over four weeks we Perceive (collect your SOPs, SME interviews, and system data), Reason (Gen AI triangulates all three to surface where they disagree), Act (classify every process step as Agentic, Deterministic, or in need of Redesign — validated by your SMEs, iterated until it converges), and Advise (deliver a Process Intelligence Heat Map and a prioritized roadmap you can act on).

What’s a process at your company still running on an assumption from a system nobody uses anymore? I would love to hear examples in the comments.

Illustrations generated using ChatGPT (OpenAI).

Over the past year, we have had many conversations with executives about artificial intelligence. Interestingly, very few begin with the work. Most begin with the technology. “We need (Agentic) AI.” Only then do the questions follow.

• “Where can we use it?”
• “Which processes should become autonomous?”
• “What can we automate?”

In many organizations, the decision to adopt AI has already been made before anyone has determined whether AI is actually the right solution. That’s understandable. AI has captured the imagination of every industry. But starting with the technology instead of the work often leads organizations to automate processes that should first be simplified, redesigned, or solved with deterministic software.

The better question isn’t – “Where can we use AI?” – it is – “What is the best way to perform this work?” Because AI not the only option. For every task inside an enterprise, there are three fundamentally different execution engines –

• Humans
• Deterministic software
• Artificial intelligence

The challenge isn’t choosing AI. The challenge is choosing the right engine – where exactly you use which engine.

We Have Been Here Before

For decades, enterprise technology focused on automating deterministic work. If a rule could be written, software could execute it – Calculate a premium, Post a payment, Validate a policy number, Reconcile a ledger etc.

Deterministic software excels when the answer must be exactly right every single time. Humans handled everything else – Judgment, Negotiation, Language, Ambiguity, Exceptions etc.

Now AI introduces a third capability. Machines that can reason through messy, unstructured information. That changes the equation.

AI Is Different

Unlike traditional software, AI isn’t deterministic. Ask the same question twice and you may receive slightly different answers. That makes many executives uncomfortable. It shouldn’t. Because many business activities don’t require perfect answers. They require useful ones – drafting emails, summarizing documents, classifying submissions, research, generating code – these are probabilistic tasks. “Usually right” is often enough because a human reviews the outcome. The mistake organizations make is trying to force AI into deterministic problems – pricing, tax calculations, payments, identity, access control, compliance decisions – these still belong to deterministic systems.

The Three Engines of Enterprise Work

3 Engines

Enterprise work as three execution engines.

Humans

• Best at – Judgment, Ethics, Relationships, Accountability, Novel situations
• Weaknesses – Slow, Expensive, Difficult to scale

Deterministic Software

• Best at – Rules, Mathematics, Repeatability, Compliance, High-volume processing
• Weaknesses – No context, No reasoning, Brittle when requirements change

AI

• Best at – Language, Pattern recognition, Classification, Summarization, Recommendations
• Weaknesses – Probabilistic, Can hallucinate, Requires grounding and guardrails

The objective isn’t replacing one with another. It’s routing every task to the least expensive execution engine that satisfies the required level of reliability. That’s a very different way of thinking about enterprise AI.

Some people call this the same idea by a different name: tokens, CPU, and humans. Three ways to get anything done, each with its own cost and reliability profile. The label doesn’t matter. The routing does. The objective isn’t replacing one with another. It’s routing every task to the least expensive execution engine that satisfies the required level of reliability. That’s a very different way of thinking about enterprise AI.

3 Ways

Most Processes Need All Three

Take an insurance submission.

1. AI reads brokers emails
2. AI classifies documents.
3. AI extracts and summarizes information from unstructured submissions.
4. Deterministic software validates required data, checks completeness, and performs appetite and pre-underwriting rules.
5. A human underwriter evaluates the risk, applies judgment, and makes the final underwriting decision.

It’s intelligent orchestration – combining AI, deterministic software, and human judgment to optimize the end-to-end workflow.

Where AI Actually Fits Today

Zoom out across a typical enterprise and the same pattern holds, function by function.

• Sales and marketing – AI drafts outreach, summarizes calls, and does lead research. A person still owns the relationship. That’s assist, not autonomy.
• Back office and operations – document processing, data entry, pre-underwriting, call-center support. This is where AI does the most work, with a human still in the loop, and where the ROI is actually proven.
• Claims – AI triages intake, routes files, flags fraud signals. A person still makes the call.
• Finance – AI drafts narrative reporting and variance commentary. A person still signs off.
• Legal – AI drafts first-pass contract review and research. A lawyer still reviews.
• IT – AI generates code, tests, and documentation, and triages incidents. An engineer still owns what ships.

Same lens, applied everywhere – how much of the task can AI carry, and how much review does it actually need.

The Receipts

This isn’t just theory. The research backs it up, and it cuts both ways. The promise is real.

• Support agents using AI saw a 14% productivity gain, and 34% for novices (Brynjolfsson, Li & Raymond, QJE 2025).
• Developers using AI completed 26% more pull requests (Cui et al., 2025).
• Across writing, coding, and support tasks, teams saw 15 to 50% less time on task, with the biggest gains going to the least experienced people.

The reality is humbling. About 95% of enterprise GenAI pilots show no measurable P&L impact (MIT NANDA, State of AI in Business 2025). The barrier isn’t the technology, the budget, or the talent. It’s workflow integration, what researchers call the “learning gap.” More than half of AI budgets chase sales and marketing use cases, while the biggest ROI sits in the back office.

Both things are true at once. AI works remarkably well in narrow, well-scoped, human-reviewed settings. It quietly fails when organizations bolt it onto workflows nobody redesigned.

Why So Many AI Pilots Stall

The industry spends enormous energy discussing models – GPT, Claude, Gemini, Llama etc. That’s interesting. But it’s rarely the problem. Most failed AI initiatives didn’t fail because the model wasn’t good enough. They failed because nobody asked – is this an AI problem? Is this a software problem? Is this a process problem?

Why AI Pilots Stall

Sometimes the correct answer is – None of the above. The process itself should be redesigned before anyone automates it.

Patterns That Work

The organizations getting real value keep reusing the same handful of design patterns.

• Human-in-the-loop – AI drafts, a person reviews and approves before anything ships or commits.
• Retrieval and grounding – feed the model your own trusted data and cite sources, not just what it learned in training.
• Narrow scope – one job, clear inputs and outputs. Small, scoped tasks beat open-ended autonomy.
• Deterministic guardrails – wrap the probabilistic core in hard rules, validation, and limits.

Skip these, and even a good model turns into a stalled pilot.

Where Teams Get Burned

Whether observed in client conversations, industry research, or public case studies, these patterns appear again and again.

• Unbounded autonomy – add approval gates, and limit scope, tools, and permissions.
• No ground truth – define success metrics and a review baseline before launch.
• Hallucination on high-stakes paths – ground answers in trusted data, and keep a human on the final call.
• Pilots that never scale – integrate into the real workflow, and buy proven tools rather than DIY everything.
• Chasing the wrong ROI – target back-office automation first, where the returns are already proven.

A Better Starting Point

Before building an AI agent, every organization should ask six questions.

1. Does the task tolerate a “usually right” answer, or must it be provably correct?
2. Does someone review the outcome, or are errors cheap and reversible?
3. Does the AI have access to sufficient business context and information to produce useful results?
4. Could deterministic software solve this more cheaply and more reliably?
5. Should the process itself be redesigned first before we automate it?
6. If it works in a pilot, can it actually integrate into the real workflow at scale?

Those six questions eliminate enormous amounts of wasted investment.

From AI First Thinking to Work First Thinking

Successful AI adoption doesn’t begin by identifying where AI can be used. It begins by understanding the work. One that recognizes AI as one execution engine, not “the” execution engine. The future enterprise won’t ask – “Where can we use AI?”

It will ask – “For every piece of work, what is the best combination of humans, deterministic software, and AI?”

The organizations that answer that question well won’t simply deploy more AI. They will build better businesses.

Where Acxhange Comes In

Most organizations have already decided they need AI. What they haven’t done is reconcile what’s actually true about their own processes.

Every organization has three versions of every process: what the SOP says, what people say they do, and what the system and transaction data actually show. Those three rarely agree. And there’s a fourth, often-overlooked problem: many processes were built around the limits of legacy technology, constraints that may no longer exist. Sometimes the process itself is the workaround.

At Acxhange, we have developed StratWorks, a consulting framework designed to close that gap. Instead of starting with technology, we start with the work itself, reconciling documented processes, employee knowledge, and system data to understand how work actually gets done. From there, we classify every process step as Agentic, Deterministic, or Redesign, so you invest where AI creates real business value rather than simply following the latest trend.

If your organization has already decided it needs AI and is still working out what for, we would welcome the opportunity to compare notes. The goal isn’t to build more AI. It’s to build better ways of getting work done.

Illustration generated using ChatGPT

You have seen this movie before – if you have been in enterprise technology long enough, this pattern will feel familiar. Twenty-five years ago, critical business processes (often) lived in Microsoft Access databases, Excel spreadsheets, or applications running under someone’s desk. Individual teams built solutions to solve immediate business problems, and many of them were remarkably effective. Over time, however, those isolated solutions became difficult to secure, impossible to inventory, and risky to maintain. Organizations responded by introducing enterprise architecture, application portfolios, governance, and standardized platforms. Today, AI agents are following a similar trajectory. Employees can build powerful agents on their desktops in hours, connecting them to corporate data, APIs, and business processes. Individually, these agents may deliver significant value. Collectively, without visibility and governance, they risk becoming the next generation of shadow IT.

That experience fundamentally changed how enterprises governed technology. For years, enterprise governance focused on systems, applications, APIs, and data. Organizations built inventories of applications and databases, documented APIs, classified sensitive data, implemented identity and access management, and established cybersecurity controls. These practices became standard because every enterprise eventually needed to answer a simple set of questions.

• What is running inside our organization?
• What business purpose does it serve?
• Who owns and is accountable for it?

Artificial Intelligence is introducing an entirely new class of enterprise assets – Not models –   Not prompts – Agents. And sooner than many organizations expect, auditors, regulators, security teams, and executive leadership will begin asking a new question. “Show me every AI agent currently operating in your enterprise, what it has access to, what decisions it makes, and who is accountable for it.”

The Rise of Enterprise Agents

Unlike traditional software, AI agents are no longer passive tools waiting for user input. Modern agents can:

• Access enterprise applications
• Retrieve information from multiple systems
• Execute workflows
• Generate recommendations
• Invoke APIs
• Communicate with other agents
• Trigger business actions
• Learn from prior interactions
• In many organizations, dozens – or eventually hundreds – of agents will operate simultaneously across business functions. Each with different permissions, responsibilities, and business impact.

Governance Is Becoming the Real Challenge

Today’s AI conversation focuses heavily on model selection and prompt engineering. Those are important. But they are not the long-term governance problem. The governance challenge is operational. Imagine being asked following questions.

• Which agents currently exist?
• Which business processes do they participate in?
• Which systems can they access?
• Which APIs can they invoke?
• Which decisions require human approval?
• Which version of the prompt is running?
• Which model is each agent using?
• Which data sources ground its responses?
• Which regulations apply?
• Who owns the agent?
• When was it last evaluated?

Many organizations cannot answer those questions today – not because they lack technology, but because they lack governance.

AI Agents Will Become Enterprise Assets

Just as APIs became managed enterprise assets, AI agents will require lifecycle management. Organizations will need to maintain an inventory that captures below information.

• Agent identity and ownership
• Business purpose
• Model(s) used
• Prompt versions
• Tools and APIs available
• Connected enterprise systems
• Data access permissions
• Human approval requirements
• Risk classification
• Performance metrics
• Operational status
• Audit history

Without this visibility, enterprises will struggle to manage operational risk, security, compliance, and change.

Regulation Is Already Moving in This Direction

While today’s regulations may not explicitly require an “AI agent inventory,” the direction is clear. Frameworks such as the NIST AI Risk Management Framework, ISO/IEC 42001, and the EU AI Act emphasize governance, accountability, transparency, lifecycle management, and human oversight. Internal audit teams and regulators are increasingly focused on understanding how AI systems are deployed, monitored, and controlled. As organizations transition from isolated AI models to autonomous agents capable of executing work, those governance expectations will naturally extend to the agents themselves. The question is no longer whether organizations should govern AI. The question is how they will govern hundreds of autonomous AI workers operating across the enterprise.

AgentOps Is the New DevOps

Organizations invested heavily over the past decade in DevOps, CloudOps, DataOps, and MLOps. The next operational discipline is emerging: AgentOps. AgentOps extends beyond model monitoring to encompass the operational management of autonomous agents throughout their lifecycle – from deployment and configuration to monitoring, evaluation, governance, and retirement. It provides the visibility required to answer fundamental operational questions like below.

• Is the agent performing as expected?
• Is it using approved tools?
• Is it following business policy?
• Has its behavior changed?
• Can we explain its decisions?
• Can we audit every action it performed?

Without AgentOps, organizations risk creating an environment where AI agents multiply faster than governance can keep pace.

Preparing Today Prevents Tomorrow’s Audit Findings

Most organizations are still experimenting with AI. That is exactly why governance should begin now. Establishing standards before hundreds of agents exist is dramatically easier than retrofitting governance later. Forward-looking organizations are already thinking beyond individual AI use cases and asking broader architectural questions.

• How should agents be designed?
• How are they approved?
• How are they monitored?
• How do they integrate with enterprise systems?
• How do we measure value?
• How do we ensure accountability?

The enterprises that answer those questions today will be significantly better positioned as AI adoption accelerates.

From AI Experiments to Governed Agentic Enterprises

At Acxhange, we believe the challenge isn’t simply building AI agents – it’s building an enterprise that can trust, govern, and scale them. That’s why we have invested in frameworks, engineering practices, and platforms that help organizations move from isolated AI experiments to enterprise-wide, governed agent ecosystems. Our StratWorks consulting framework helps organizations identify where agents create value, while our Agentic Engineering practice designs and builds enterprise-grade autonomous systems. Together with KognitiveWorks, our enterprise agentic platform, we help organizations move from isolated AI pilots to governed, scalable, and production-ready agent ecosystems. Because the future isn’t simply about building AI agents. It’s about knowing every agent that is running, understanding what it is doing, and proving that it is operating responsibly.

If you are beginning to think about questions like “How many AI agents do we already have?”, “Who owns them?”, “How do we govern them?”, or “What should our enterprise architecture look like?”, we would welcome the opportunity to compare notes. These are conversations every enterprise will soon be having, and we will be happy to share what we are seeing across the industry.