Three kinds of AI, one conversation
The public conversation about AI runs together three quite different activities.
The first is AI chat. A person asks, a model answers. It is a remarkable advance in personal productivity. It needs no enterprise data, no integration and no approval workflow. The value is real and it accrues to the individual.
The second is AI research. Models applied to protein folding, materials, mathematics and the sciences are producing results that would have taken decades. The data is largely public or purpose-built. The user is a research team. The value is immense and it accrues to the world.
The third is Workflow AI. This is the use of probabilistic intelligence upon private company and public-sector agency data, towards delivering a specific product, service, experience or benefit to a specific user, over time.
It is the kind of AI that most organisations mean when they say they want to adopt AI. It is also the kind that has proved hardest to adopt.
The definition, clause by clause
Each part of the definition carries a condition.
Probabilistic intelligence. Models reason, generate and plan. They do not do so deterministically. In a workflow that must produce a correct outcome, probabilistic intelligence has to be combined with deterministic logic, policy and evidence. The intelligence is necessary. It is not sufficient.
Private company and public-sector agency data. The data that makes Workflow AI valuable is the data an organisation already holds — in heritage systems, modern platforms, files and operational protocols. It is governed by privacy, sovereignty and policy obligations. It cannot simply be copied into another environment.
A specific product, service, experience or benefit. Workflow AI exists to do something. Approve, route, reconcile, respond, repair. The output is an action or a decision with consequences, not a suggestion.
To a specific user. Someone receives the outcome. A customer, a citizen, a case officer, an operator. Their entitlement, their context and the authority to act on their behalf are part of the workflow.
Over time. A workflow runs every day. The solution must be deployed, observed, evidenced, repaired and eventually retired. Over time also means the models, platforms and providers underneath it will change, and the workflow must survive that change.
Why the conditions are different
AI chat succeeds if the answer is useful. AI research succeeds if the result is true. Workflow AI succeeds only if the right data participated, the right policy was enforced, the right person was served, the action was permitted and there is evidence of all of it — repeatedly.
This is why the enterprise has found AI adoption harder than the demonstrations suggested. The intelligence arrived. The conditions did not change. The data still sits where it sits. The policy still applies. The heritage system still runs the business. None of that is a failure of the model. It is the nature of the work.
The industry has noticed. The investment now being made in forward-deployed engineering — teams embedded with customers to make the first deployment succeed — is an investment in Workflow AI. It correctly locates the gap in the workflow rather than in the model. The question that investment raises is what each deployment leaves behind, and that is the subject of the FDE perspective.
Where Data Mediation fits
TomorrowX developed Data Mediation for exactly these conditions, before the current generation of models existed.
Data Mediation places a fully programmable capability in the data path between the intelligence and the systems, data and actions of the workflow. It is a single Data Mediation point, independent of the model and external to the applications on either side. At that point the right data is selected, contextualised and transformed. Privacy, sovereignty, policy and human approval are enforced. Permitted actions are carried out. Evidence is retained.
Within the Composable Agentic Platform, the Programmable Data Agent executes deterministic and probabilistic intelligence in the interaction. The Editor is where the functional requirements of the workflow are programmed. The Console is where security, privacy, performance, resilience and the other non-functional requirements are selected, deployed and carried into operation. The X Store publishes what has been proven so the next team does not begin again.
Nothing is sent to TomorrowX. The solution runs inside the enterprise environment. Not SaaS.
What changes for the organisation
Workflow AI stops being a programme and becomes a capability.
The first workflow is adopted in controlled scope, with the data, policy and actions governed from the first interaction. A Proof of Capability and Value takes a week to know. What that first solution learns — its functional logic, its non-functional requirements, its operating evidence — is retained and reused. The second workflow starts from a stronger position than the first. The tenth starts from a stronger position than the second.
The organisation keeps its authority over its data and its actions. It keeps the freedom to change models, platforms and providers. It keeps the capability after the specialists leave.
What follows
Naming the category changes more than the vocabulary. Once Workflow AI is defined by the data it operates on and the outcome it delivers, the arithmetic of what AI adoption requires — in integration, in expertise and in energy — looks different from the arithmetic of the models alone. That is the subject of the next paper in this series.
Sources and further reading
From Legacy to AI — the Forbes Australia feature
Platform-led AI: from embedded expertise to repeatable capability
Data Mediation: foundational control for AI, cyber and interoperability