Are We Transforming Around the Wrong Thing?

What if the transformation is pointed at the wrong object?

Most large organisations now have an AI strategy. Many also have an AI transformation programme, an AI officer, an AI governance committee and, increasingly, a plan for AI agents. The working assumption is familiar. A new class of technology has arrived, so the institution should be rebuilt around it.

I keep coming back to a simpler question. What if we are transforming around the wrong thing?

Language models are unusually capable. That is not in dispute. The more interesting possibility is narrower technologically and larger organisationally. We may be making a category error by treating a general-purpose language capability as another enterprise-wide technology transformation, when its most useful contribution is as an interface into capability the institution already possesses.

The overlooked institution

Institutions are not empty until a model arrives.

They already contain substantial intelligence and capability in people, policy, legislation, procedures, business rules, information architecture, capability maps, data, systems of record, APIs, workflow engines, analytics, specialised models, delegations, records, professional expertise and organisational experience. Some of that is formal. Some of it is tacit. Some of it is incomplete, stale or fragmented. None of this is an argument that everything an institution needs already exists perfectly.

The more accurate observation is simpler. The institution often possesses much more capability than an ordinary worker can practically discover or assemble in the middle of a real situation.

That is the distance problem I wrote about in The Knowledge We Buried. Knowledge did not disappear. It receded into systems, configuration, tickets, vendor environments and the memories of the people who still know how work actually gets done. Workers can operate the interface without being able to reach the logic underneath it.

The current wave of AI activity can either reduce that distance or add another layer on top of it.

What language actually changed

The genuinely important shift is easy to miss because it does not look like a new institution.

Ordinary human language can now become a practical interface into heterogeneous institutional capability. A person can begin with a situation rather than with a menu. They do not first have to know which application holds the record, which policy applies, which API exists, which procedure is relevant, which expert owns the issue or which approval is required.

That is a real change. It is also a limited one.

A language model, as I am using the term here, is a general-purpose language capability. Examples include models supplied by OpenAI, Anthropic, Google, Meta, or through services such as AWS Bedrock. Useful functions may include interpreting natural-language expression, summarising, drafting, extracting information, translating, classifying, matching meaning, explaining, and converting unstructured material into a more structured representation. Those functions can help a person navigate assembled complexity.

They do not make the model the architecture.

High language utility. Low institutional authority.

The language model should generally be the least institution-specific layer, not the place in which the organisation is reconstructed.

Less doing. More thinking.

This is, first, a workforce argument.

Workers currently spend a great deal of cognitive effort finding the right system, locating the right policy, remembering where information lives, searching repositories, translating one system's terminology into another, switching applications, copying and re-keying information, reconstructing processes, finding who has authority, stitching together fragmented context, and performing routine summarisation, drafting, formatting and administrative coordination.

The barrier is also linguistic. Much of the institution's capability is reachable only through specialist languages and local dialects: SQL and other data-access knowledge, Python or similar tooling, BPM jargon, application-specific query languages, schema names that only a few people remember. The person may already know what they need. They still have to translate that need into a language the system will accept.

Those activities consume capacity. They are often not the reason the person was employed.

Deloitte's 2025 Global Human Capital Trends survey reported that respondents spent 41% of their day on work that does not contribute to the value their organisation creates [1]. That finding is broader than policy-search, system-navigation or specialist-language barriers. It should not be over-read. It does support a more modest claim: a large share of working time is already absorbed by activity that is not the work itself.

Language technology and existing automation can reduce some of that burden. The purpose is not that AI thinks so the worker does not have to. The purpose is to reduce unnecessary cognitive and administrative load so the worker has greater capacity to think.

That includes problem framing, interpretation, sensemaking, evaluating evidence, recognising exceptions, resolving ambiguity, making trade-offs, exercising empathy, solving problems, and remaining professionally responsible for accountable decisions.

This is not a claim that humans are universally superior to computational models at every cognitive task. Efficiency in doing does not imply authority or superiority in judgement. Reducing load should expand a person's capacity for judgement and problem-solving. It should not turn them into the supervisor of an artificial worker.

The architecture we may be accidentally building

If language is treated as the institution, a particular architecture starts to assemble itself.

Institutional knowledge is copied into giant system prompts. Policies and procedures are restated as proprietary agent definitions. Context is stored in provider-specific memory. Fine-tunes and hidden prompt logic become the unofficial operating model. Existing systems are exposed as tools for an agent to call. The model is asked to orchestrate, decide, act and then explain itself.

Some of that may be locally useful. The question is what happens when it becomes the default.

Don't put the enterprise in the prompt.

A prompt should express the situation, not become the institution's operating model. The worker's expression belongs there: what is happening, what is needed, what is unusual, what outcome is being sought. Situational facts belong there. Some interface instructions may be needed so the system can understand intent and discover relevant capability.

Institutional knowledge is a different class of thing. Policies, business rules, delegations, process definitions, terminology, schemas, decision criteria and organisational instructions should normally already exist as governed institutional assets. They should be discoverable. They should not have to be pasted into the prompt each time a person asks for help.

If the worker has to teach the system the organisation every time they ask for help, have we really made the organisation intelligent to work within?

Sovereignty is not a hosting decision

DataMPowered's notion of sovereignty here is not simply hosting your own foundation model.

It is that the institution continues to own what it knows, what its rules mean, what it can do, who has authority, and how work is governed. Policies, rules, delegations, decision rights, processes, information definitions, controls, records, authority and judgement should remain governed institutional assets. They should not have to be reconstructed inside prompts, agent definitions, provider memory or model-specific orchestration.

Sovereign Operational Intelligence names that implication. Models should remain substitutable. Switching from one provider model to another should not require rebuilding the institution's operating knowledge.

This is a hypothesis about architecture, not a claim that every vendor is trying to capture the enterprise. Commercial incentives do favour architectures in which models consume more context, invoke more tools, perform more steps and occupy a more central position in enterprise work. Inference, stored context, proprietary orchestration and switching costs all pull in that direction. That does not prove those architectures are wrong. It does give institutions another reason to ask whether the complexity is necessary.

Existing enterprise architecture still matters

None of this requires inventing an entirely new "AI architecture".

Many institutions already possess business capability maps, information architecture, enterprise metamodels, data models, glossaries, process models, BPMN and DMN, application and service catalogues, API specifications, identity and access models, data catalogues, lineage, policy repositories, records classifications and enterprise architecture repositories. The problem is often that these assets are fragmented, incomplete, stale, inaccessible to ordinary workers, not semantically linked, not readily executable, or difficult to assemble around a particular situation.

That is an important caveat. The transformation, if there is one, may involve making existing institutional architecture discoverable and operational rather than constructing a parallel AI institution.

In DataMPowered terms, this is the operating sequence of Operational Intelligence: language, intent, context, existing capability, governed work, human judgement and an accountable outcome. The model is one possible execution mechanism inside that sequence. It is not the sequence.

Discoverability and malleability

Discoverability, from the worker's perspective, means being able to say: here is the situation I am dealing with. The person should not already need to know the map of the institution in order to get help from it. Language allows work to begin from intent rather than navigation. That is one of the genuinely important properties introduced by modern language models.

Discoverability is not enough.

Traditional automation commonly assumes a predefined process, a predefined sequence and predetermined branches. Real institutional work does not always behave that way. The pathway may need to emerge from the particular situation, current context, evidence, requirements, authority, available capabilities, constraints, previous outcomes and unresolved uncertainty.

This is not an argument that AI should invent options. The pathway emerges from what becomes possible when the relevant institutional capabilities are assembled around the situation. The capability may already exist. What was missing was the ability to discover it from intent and assemble it differently when the situation demanded it.

Why should automation occur inside the language model?

Institutions already automate through application logic, APIs, workflow engines, rules engines, event systems, RPA, databases, schedulers, specialised models and transaction systems. Where a deterministic capability already exists, use it. Where a rule can be established, establish it. Where a system can execute something reliably, invoke it. Where specialist computation is required, use the appropriate capability. Use a language model where language or probabilistic interpretation genuinely adds value.

Do not generate what can be discovered. Do not infer what can be established. Do not simulate what can be executed.

Use models where interpretation, synthesis, perception, prediction or genuinely probabilistic reasoning is required.

That is not a ban on automation. It is a question about where automation should live. If the capability already has a home, there is no obvious reason to migrate it into a probabilistic language layer so that it can be redescribed as AI.

Did this work require an artificial actor?

The market language is now heavily agent-oriented: AI agents, agentic AI, digital workers, AI coworkers, autonomous workflows.

I am using ordinary meanings. An agent acts for another or acts toward an outcome. Agentic implies some capacity or freedom to act independently and make choices. There are situations in which autonomous software can provide real value. I am not arguing that it never can.

The question is whether this piece of institutional work required an artificial actor in the first place.

OpenAI's enterprise guidance describes agents as systems that independently accomplish tasks on a user's behalf, using a language model to manage workflow execution and tools to act on external systems [2]. More recently, OpenAI has positioned workspace agents as a way for teams to turn repeatable work into shared agents that can be delegated across tools, with approvals for sensitive steps [3]. That is useful evidence of how the market is framing the technology. It is not independent proof that the architecture is the right one for institutional work.

Salesforce, from inside the same market, is explicit that not every enterprise workflow can rely entirely on probabilistic model reasoning. Authentication, permissions, sequencing and security-sensitive execution often require deterministic guarantees [4]. That acknowledgement matters. It suggests that even vendor architectures are having to reintroduce the surrounding institution: data, permissions, systems and controls.

If we deliberately construct the AI as an actor, we then need AI identity, AI permissions, AI delegation, AI monitoring, AI decision boundaries, AI accountability structures and AI kill switches. Some of those controls are necessary if we choose that architecture. Australian and partner-agency cyber guidance on agentic AI services is largely about that choice. It treats identity, least privilege, tool access, monitoring, reversibility and human accountability as essential once agents are given authority to act [5].

The prior question is still available. Did the business problem require that architecture, or did we create an artificial actor and then create a governance problem around it?

I do not think that question has a universal answer. It is worth asking before the architecture is treated as inevitable.

Gartner has predicted that more than 40% of agentic AI projects will be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls. It has also used the term "agent washing" for the rebranding of assistants, chatbots and RPA as agentic AI without substantial agentic capability [6]. That is an analyst forecast, not a measurement of failure that has already occurred. It is still a useful warning against transforming around a label.

Workers are not a parallel workforce

When DataMPowered talks about Workers in ifCEM, the term does not mean artificial employees.

Workers are bounded capabilities. A Worker may execute through deterministic logic, an existing institutional system, an API, an approved tool chain, specialised computation, or a language model where that is appropriate. They are not autonomous AI agents. They should not be anthropomorphised.

ifCEM does not create a parallel workforce of artificial actors. It is one way of making institutional capability usable around a real piece of work. That is an implementation consequence of the thinking in this article. It is not proof that the thesis is correct, and it is not a claim that the approach has been proven at enterprise scale.

The important product distinction is the same as the architectural one. Do not invent a new actor if the need was to make an existing capability reachable. That is the same instinct as not boiling the ocean.

An abstraction bubble, not a market prediction

I am not making a financial-market prediction.

The more useful idea may be an abstraction bubble. Perhaps the bubble is not the technology. Perhaps it is the conceptual territory we have assigned to it.

Retrieval becomes "AI knowledge". API invocation becomes "AI action". Workflows become "agent orchestration". Business rules become "AI reasoning". Deterministic automation becomes "AI agency". Institutional capabilities become "agent tools". Decision support becomes "AI decision-making". Human accountability becomes "human in the loop".

Not every use of those terms is incorrect. Shorthand becomes a category error when it obscures where capability, authority and accountability actually reside. We may be reinventing enterprise architecture as an AI stack. I want to test that claim rather than simply proclaim it.

The Australian Government's policy for responsible use of AI in government is explicit that AI policy should complement and strengthen existing frameworks rather than duplicate them [7]. That is a governance statement, not a product architecture. It still points in the same direction. The durable object of governance is consequential institutional work, not the mere fact that a language model participated.

Don't boil the ocean

I have made this argument before. In Don't Boil the Ocean [8], the point was that each generation of enterprise technology solved one problem while asking the organisation to reshape itself around a new stack. AI should not become another vendor-led transformation of that kind. The Lesson After the Bitter Lesson took the same warning further: if we treat AI as just another technology programme, we risk adding another layer of distance from the knowledge that already governs work.

The alternative to an "AI transformation" programme is not doing nothing. It is starting smaller and closer to work.

Bring one real piece of work. Then ask:

1. What is the person trying to accomplish?
2. What creates unnecessary cognitive or administrative burden?
3. What does the institution already know?
4. What capabilities already exist?
5. What is difficult to discover?
6. What can already be executed deterministically?
7. What needs to be assembled differently for this situation?
8. Where does language assistance help?
9. Where does cognition genuinely help?
10. Where is human judgement required?
11. What evidence should survive?

Then measure what changed.

Do not begin with: where can we deploy agents?

Govern the work. Assure the mechanism.

Different mechanisms should receive assurance appropriate to their risks. The language interface may require assurance for misinterpretation, hallucination, injection, inappropriate disclosure, robustness and provider or model changes.

Authority remains institutional. Access remains institutional. Rules remain institutional. Execution remains governed. Accountability remains with people and institutions. Judgement remains distinct.

Judgement is not every human action. It is required where the correct outcome cannot simply be mechanically established from rules and evidence. A language model may make evidence easier to understand, surface conflicts, summarise, present relevant context, expose uncertainty and help a person navigate complexity. It should not automatically become the holder of institutional judgement.

Judgement Governance™ is the discipline for that distinction. The principle is straightforward: AI interprets where useful. The institution establishes. Capabilities act. Humans judge.

Govern the work. Assure the mechanism.

That is preferable to presenting AI governance as a separate parallel institutional universe.

Make the organisation easier to think within

The most important contribution of the language model may not be that it can become another worker. It may be that it can make the institution dramatically easier for its existing workers to think and act within.

Don't transform the organisation around AI. Use language technology to make the organisation itself more intelligent to work within.

References

[1] S. Harrington, C. Commisso, K. Moss, W. D. Eggers, T. Alstein, and J. Duda, “When work gets in the way of work: Reclaiming organizational capacity,” Deloitte Insights, 2025 Global Human Capital Trends. https://www.deloitte.com/us/en/insights/topics/talent/human-capital-trends/2025/reclaiming-organizational-capacity.html

[2] OpenAI, “A practical guide to building agents.” https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

[3] OpenAI, “Introducing workspace agents in ChatGPT.” https://openai.com/index/introducing-workspace-agents-in-chatgpt/

[4] Salesforce, “Achieving Reliable Agent Behavior.” https://www.salesforce.com/agentforce/levels-of-determinism/

[5] Australian Signals Directorate’s Australian Cyber Security Centre, with CISA, NSA, Cyber Centre, NCSC-NZ and NCSC-UK, “Careful adoption of agentic AI services.” https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services

[6] Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027,” 25 June 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

[7] Digital Transformation Agency, “Policy for the responsible use of AI in government – Version 2.0.” https://www.digital.gov.au/ai/ai-in-government-policy

[8] D. Pothuhera, “Don't Boil the Ocean,” LinkedIn, June 2026. https://www.linkedin.com/posts/dakshan-pothuhera_businesstransformation-artificialintelligence-ugcPost-7469281156803252224-Aheu/