Did It Do It For You?

A Manifesto for Workflow-Native AI

There is a question that most organisations deploying AI have not yet thought to ask. It is not a technical question. It is not about the quality of the models, the size of the training data, or the sophistication of the prompts. It is this: when the task was finished, did the AI do it, or did it help a person do it?

These are not the same thing. The difference between them is the difference between a transformation and an upgrade. And the inability to distinguish between them — the tendency to call any deployment that involves AI a step toward transformation — is producing a generation of AI investments that will look, in five years, like the ERP investments of the 1990s: expensive, ubiquitous, and structurally indistinguishable from the manual processes they claimed to replace.

This essay is about that distinction, about why it matters more than almost any other question in the current AI deployment conversation, and about what it means to build software that answers it correctly.

The Test

The test is binary. When the task is complete, was there a human in the loop?

Not a human who could have been in the loop. Not a human who reviewed the output after the fact. A human who did the work — who read the document, made the judgment, drafted the text, reviewed the transaction, approved the decision. A human whose presence in the process was constitutive of the process getting done.

If the answer is yes, you have AI-assisted work. The human is faster. The human may be better. The human is still the agent. The AI is the tool.

If the answer is no — if the task was identified, executed, and completed by software, and the human's role was to define the policy and review the exceptions rather than to process the individual instances — then you have AI-complete work. The human is out of the loop. Not because the human was removed from a process they designed. Because a process was designed that does not require a human.

Did it do it for you? This is the test. AI-assisted is not AI-complete. The distinction is not a matter of degree. It is a categorical difference that determines whether your organisation is building compounding advantage from AI or building a faster version of the same institutional structure it already has.

The Failure Mode Has a Name

Most enterprise AI deployment today is producing AI-assisted work and calling it transformation.

Better search. Faster drafts. Smarter autocomplete. Summarisation tools that condense the document the human was going to read into a paragraph the human can skim. These are genuine improvements. They make knowledge workers faster. In aggregate, they probably produce measurable productivity gains.

They do not change the structure of the work. The human is still in the loop. The process is the same process. The AI is a better interface on top of a workflow that was never interrogated. The question "should a human be doing this?" was never asked.

The name for this failure mode is: AI as a better pen.

A better pen does not change the fact that a hand is holding it. Organisations that mistake a faster pen for a different hand are optimising the surface of processes that should be questioned, and generating productivity metrics that measure the improvement without capturing the opportunity cost: the work that could have been eliminated entirely if the process had been designed from first principles rather than inherited from the pre-AI world.

The Historical Parallel

This has happened before. The enterprise software wave of the 1990s — ERP systems, document management platforms, workflow automation tools — promised process transformation and in most deployments delivered process digitisation.

The accounting departments that adopted large ERP systems in the late 1990s did not shrink. They grew. The number of people processing financial transactions did not fall; the number of people managing the system that processed financial transactions increased. The process complexity did not decrease; it increased, because a manual process that everyone understood was replaced by a software process that required specialist knowledge to operate and maintain.

The problem was not that the software was bad. The problem was that organisations asked "how can we do what we already do inside this software?" rather than "what should we be doing, and how should we design a system to do it?" They digitised the ledger. They did not ask why the ledger existed. The result was more expensive accounting with a computer attached.¹

AI is at risk of running the same play. The organisations that deploy AI most extensively without asking the process-elimination question will find themselves, in five years, with the most sophisticated and most expensive versions of the same processes they have today. The metrics will be better — tasks per hour, error rates, response times. The structure will be unchanged. And the organisations that did ask the process-elimination question will be operating in a structurally different way, with a cost base and a throughput that is not merely better but categorically different.

What AI-Complete Looks Like in Practice

I want to be specific, because the distinction between AI-assisted and AI-complete is easy to state abstractly and harder to see clearly in practice.

Consider Kenya's civil society compliance sector. An organisation that needs to register under the PBO Act has a constitution. That constitution may or may not satisfy the Act's requirements. The traditional path to determining whether it does — and fixing it if it does not — is to hire a lawyer, pay sixty to two hundred thousand shillings, wait several weeks, and receive a revised document. The lawyer is in the loop. The lawyer is the agent. The process requires a lawyer.

PBOMaster's constitution analyser does not assist a lawyer to do this work. It does the work. An organisation uploads its constitution. The system checks it against the Act's requirements, identifies the specific gaps, and generates the language changes required to close them. The organisation reviews the output — a human is in the loop at the policy level, confirming that the changes are correct — but a human is not processing each clause. The AI did it.

This is the distinction in practice. Not: the AI helped a lawyer work faster. The AI replaced the need for a lawyer in this specific, well-defined task.

Consider corporate procurement. ProcureBee is built around the same distinction applied to a different domain. The traditional procurement workflow — expense request, manager approval, finance review, card issuance or reimbursement, reconciliation, audit — involves multiple humans making individual decisions about individual transactions. Each approval is a human act. The process exists because, in the absence of software that could enforce spending policy automatically, human judgment at each stage was the only available quality control mechanism.

ProcureBee encodes the spending policy and executes it. The employee states what they need. The system assesses the request against the policy, issues a virtual card with the appropriate spending limit and merchant category restrictions, processes the transaction, and reconciles it automatically. The manager is not in the loop for each transaction. The manager set the policy. The software executes it continuously.

The manager who was approving forty expense requests per month is no longer approving expense requests. Not because the requests are fewer. Because the process was redesigned so that individual approval is not the mechanism. The process that required a human no longer requires one, because a better-specified process was built in its place.

Did it do it for you? Yes. That is the standard.

The Accountability Objection

I want to address the objection I encounter most often when I make this argument, because it is serious and deserves a serious answer.

The objection is: human involvement is accountability. When a human approves a transaction, signs a document, reviews a compliance output, there is a named person responsible for the quality of that decision. When software does it, accountability diffuses — who is responsible when the AI gets it wrong?

This objection has force for the hard cases. When the decision involves genuine judgment — the kind that depends on context, relationship, and experience that cannot be specified in advance — human accountability is not merely a regulatory requirement. It is a substantive input to the quality of the decision.

But the objection is applied far too broadly. It is used to justify human involvement in processes where the decisions are not matters of judgment — where the policy is clear, the rules are specified, and the human is not adding interpretation but executing a process that software could execute more consistently and more cheaply. In these cases, human involvement does not produce accountability. It produces a bottleneck, and occasionally a point of failure that a well-specified automated system would not have.

The expense approval process in most organisations is not a judgment process. The policy is known. The rules are clear. The manager's role is to check the request against rules that could be encoded. When a manager approves an expense that violates policy because they did not check carefully, that is not accountability — it is the failure mode that accountability was supposed to prevent. Encoding the policy and enforcing it automatically produces more consistent compliance, not less.

Accountability in AI-complete workflows is structural: it lives in the policy design, the system configuration, and the exception-handling processes for the cases that fall outside the specified parameters. This is better accountability than the approval chain it replaces, because it is systematic rather than dependent on individual vigilance.

What Flux Is Building Toward

The essays in this series — about PBOMaster, about ProcureBee, about the civil society compliance sector, about the procurement workflow — are instances of a single argument. Software that is designed, from first principles, to eliminate the human from the loop for the tasks that do not require a human, and to support the human in the tasks that do.

The tasks that do not require a human are the majority of what most organisations' workflows contain. Constitution checking. Expense approval. Data aggregation. Compliance reporting. Document routing. Reminder generation. These are not marginal tasks — they constitute a substantial fraction of the administrative load that slows institutions down and consumes the capacity of people who should be focused on the judgment-intensive work that genuinely requires them.

The tasks that do require a human are the minority: the decisions that turn on context and relationship, the exceptions that fall outside any specification, the oversight functions that governance rightly demands of named individuals. Software should make humans available for these tasks by eliminating the ones that do not require them.

This is not a vision of AI replacing work. It is a vision of AI eliminating the wrong work — the work that humans were doing only because no one had yet built the software to do it properly. The people freed from that work are not redundant. They are available for the work that actually required them all along.

The Question That Follows From This Argument

For every process your organisation runs: did the software do it, or did it help a person do it?

If it helped a person do it, the relevant question is not "how much did AI improve this process?" The relevant question is "should this process require a person?"

In many cases, the answer is no. The process exists because, in the pre-AI world, a person was the only available implementation. It was not designed because human judgment was needed. It was designed because human labour was the cheapest available mechanism. That is no longer true. The software now exists. The question is whether you are asking the right question about what to build with it.

Did it do it for you?