Did It Do It For You?

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 risk looking, in five years, like the ERP investments of the 1990s: expensive, ubiquitous, and structurally hard to tell apart from the manual processes they claimed to replace.

This paper is about that distinction: why it matters more than almost any other question in the current AI deployment conversation, what the human-factors and management literatures that study automation actually say about it, and what it means to build software that answers it correctly.

The output looks the same either way. Only the switch underneath says which one actually happened.

1. What Kind of Claim This Is

This paper is making a narrower, more specific claim than the manifesto framing above might suggest, and it is worth stating precisely before making it.

What it argues from. A conceptual distinction borrowed and sharpened from an existing taxonomy in human-factors research — the difference between automating an action and automating the decision that triggers the action.¹ A documented historical pattern from enterprise-software adoption in the 1990s, where two independent sources (one a widely cited productivity-paradox paper, one a Harvard Business Review account of enterprise-system rollouts) describe organisations digitising an existing process rather than redesigning it.²³ A named failure mode from management research — organisations defaulting to "augmentation" over "automation" even where automation is technically available — that was published independently of this paper and of Flux.⁴ Two product cases, PBOMaster and ProcureBee, described from the inside, by the company that built them.

What it does not argue from. It does not argue from a controlled study measuring how often AI deployments in the wild turn out to be "assisted" versus "complete" — no such study is cited because none was found that operationalises the distinction this way. It does not argue that PBOMaster and ProcureBee are a representative sample of enterprise AI deployment; they are illustrations, from one company's product line, of what the complete side of the distinction looks like in practice.

What it does not claim. It does not claim human involvement is never valuable — §8 states directly, using the automation literature itself, that a human nominally supervising individual transactions is a well-documented failure mode in its own right, which cuts against treating "a human is in the loop" as self-evidently the safer design. It does not claim the binary test is easy to apply in practice — many real deployments are mixtures, and §8 takes that objection seriously rather than asserting the test resolves cleanly in every case.

What would refute it. Given in full in §11. The sharpest version: if large-sample evidence shows AI deployments classified as "complete" by this paper's own test perform no better — on cost, error rate, or throughput — than deployments classified as "assisted," the distinction this paper treats as categorical would be shown to be a difference that does not actually matter, and the paper's central claim would need withdrawing, not softening.

2. 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, on its face, a matter of degree. It is intended as a categorical difference that determines whether an organisation is building compounding advantage from AI or building a faster version of the same institutional structure it already has — though §8 takes seriously the objection that many real deployments sit uncomfortably between the two categories rather than cleanly inside one.

3. 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 plausibly produce measurable productivity gains — though measuring that at the level of whole organisations, rather than individual tasks, is exactly the kind of claim this paper is not in a position to make.

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.

This failure mode now has a name in the management literature, independent of the language this paper uses for it. A 2021 paper in the Academy of Management Review, synthesising the organisational-AI literature, distinguishes an "automation" logic — AI replacing human tasks — from an "augmentation" logic — AI and humans working interdependently — and argues organisations systematically favour augmentation even where the underlying technology would support automation, because augmentation preserves existing roles, routines, and accountability structures that a genuine automation redesign would disrupt.⁴ That is this paper's "AI as a better pen," stated as an organisational-behaviour finding rather than an essayistic observation. The 2021 paper is about organisational AI adoption broadly, not about any product of Flux's, and not Africa-specific; it is cited here because it independently names the pattern this paper is built around, not because it tests this paper's own cases.

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.

4. 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 many deployments delivered process digitisation.

The productivity-paradox literature from that period is directly on point, and it is worth being precise about what it actually found rather than what is now folklore about it. Erik Brynjolfsson's 1993 survey of the economics research on information technology and productivity found that, through the end of the 1980s, the aggregate statistical relationship between IT investment and measured productivity growth was weak or absent at the level most studies could detect — not because computers did not help individual tasks, but because the gains were, in his account, offset by mismeasurement, by lags between investment and payoff, and by redistribution rather than net creation of value within firms.² That paper does not say IT investment was wasted; it says the simple story — spend on computers, get proportional productivity growth — did not hold, and offers several candidate explanations rather than a single confirmed one. It is cited here for that narrower, more careful claim, not for a stronger one.

Thomas Davenport's 1998 account in Harvard Business Review, written from direct experience advising companies on enterprise-system rollouts, makes a complementary and more process-specific argument: an enterprise system "imposes its own logic on a company's strategy, organization, and culture," and companies that treat the system's technical imperatives as the only ones that matter — rather than reconciling the system with the business needs it was meant to serve — produce deployments that are disruptive without being transformative.³ Davenport's account is a practitioner argument, not a controlled study, and it is cited as such: a documented, specific, named-author account of the same pattern, not a statistical finding.

The shared diagnosis across both pieces, read carefully rather than summarised from memory, is narrower than "ERP failed." It is that the technology's availability did not by itself force the process-redesign question, and in enough cases organisations answered a different, easier question instead — "how do we do what we already do inside this new system?" rather than "what should we be doing, and how should a system be built to do it?" AI is at risk of running the same play, for the same reason: the process-elimination question is optional unless something forces it, and most organisations, given the option, do not ask it.

5. What the Automation Research Actually Says

The binary test is grounded here in literature that has studied exactly this distinction for longer than AI has existed, because the test risks sounding like a rhetorical device if it is not tied to something more rigorous.

Human-factors research on automation has, since at least 2000, used a taxonomy that separates automation by stage and by level. The stage question is which part of a task is automated: information acquisition, information analysis, decision selection, or action implementation. The level question is how much of that stage is handed to the machine, from fully manual to fully autonomous.¹ A system that automates information acquisition and analysis but leaves decision selection and action implementation to a human is, on this taxonomy, assisting a human decision. A system that automates decision selection and action implementation is doing something categorically different — not more of the same assistance, but a different stage of the task altogether. This paper's "AI-assisted" and "AI-complete" map directly onto that distinction: assisted work automates acquisition and analysis; complete work automates decision and action as well, with the human's role moved up to setting the policy that governs the automated decision.

This matters because it means the binary test is not this paper's own invention dressed up as a framework. It is an application, to AI deployment specifically, of a distinction that has been load-bearing in aviation, process control, and medical-device design for over two decades, in domains where getting the distinction wrong has had measured, sometimes fatal, consequences. The taxonomy itself does not say which stage of automation is better in general — it is explicitly a design tool for choosing the right level for a given task, not an argument that full automation always wins. This paper's claim is narrower than the taxonomy itself licenses: that for the specific category of task described in §6 — high-volume, rule-specifiable, low-judgment — moving further along that taxonomy toward full automation is usually the right design choice, not that it always is.

6. 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 a fee in the tens of thousands of Kenyan 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 the changes are correct — but a human is not processing each clause. The AI did it. What a language model finds when it reads a constitution goes into what this specific checking task does and does not require from the model.

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 dozens of expense requests per month is no longer approving expense requests one at a time. 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 — for this category of task. §8 takes up directly which categories of task this does not extend to.

7. 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 if 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, the honest empirical question is not whether a human is present, but whether the human's presence is actually producing the vigilance accountability is supposed to buy. §8's second objection, drawing on the same automation literature as §5, argues this often is not true even on its own terms.

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 accountability was supposed to prevent. Encoding the policy and enforcing it automatically produces more consistent compliance, not less, for this specific category of decision.

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. Whether that is in fact better accountability than the approval chain it replaces is an empirical claim this paper is making, not a definitional one — and §8 names the strongest reason to doubt it.

8. Objections I take seriously

"A human nominally 'in the loop' for routine decisions is a documented poor supervisor — which means AI-assisted work may already share AI-complete work's accountability problem, rather than solving it." This is the sharpest complication to §7's argument, and it comes from the same literature §5 used to ground the binary test in the first place. A 2010 review of three decades of automation research found that human operators monitoring an automated system for the rare case where it fails systematically exhibit "complacency" — reduced vigilance that increases with the automation's reliability — and "automation bias," a tendency to trust an automated recommendation over contradicting evidence from other sources, even among trained professionals in domains like aviation and clinical decision support.⁵ Applied here: a manager who nominally reviews forty expense requests a month, most of which are unremarkable, is a documented candidate for exactly this failure mode — not because the manager is careless, but because sustained vigilance over a mostly-compliant stream degrades reliably, a finding that holds across operators and domains, not merely weak individuals. If that is right, "a human is in the loop" was never the reliable accountability mechanism §7's objection assumes it to be, for the specific category of high-volume, low-variance decision this paper is about. This does not vindicate AI-complete workflows automatically — a badly specified automated policy fails silently and completely, which is its own different risk — but it means the comparison in §7 is not "human vigilance versus no vigilance." It is "human vigilance that degrades predictably versus a different, equally real, failure mode in the policy design." This paper does not have evidence comparing the two failure rates directly, and that comparison is exactly what §11 registers as the standard that would settle this empirically rather than by contested argument.

"Flux has a commercial interest in this conclusion." Flux builds PBOMaster and ProcureBee, the two products used to illustrate AI-complete work in §6, and sells software built on the premise that eliminating a process is more valuable than accelerating it — which is close to this paper's own thesis. This is a real conflict, not a rhetorical one to acknowledge and move past. The honest mitigation is narrow: §5's grounding in Parasuraman, Sheridan and Wickens's taxonomy and §3 and §4's grounding in Raisch and Krakowski, Brynjolfsson, and Davenport are all independent of Flux and of each other, and none of them was written to support this paper's argument. They establish that the distinction this paper draws, and the pattern of organisations avoiding it, are real phenomena studied elsewhere. They do not establish that PBOMaster and ProcureBee are good or representative instances of AI-complete design — that claim rests on this paper's own description of its own products, by the company that built them, and should be read with that limitation in view.

"The binary test oversimplifies; most real deployments are mixtures, not clean instances of either category." This is fair. ProcureBee still has a human reviewing exceptions; PBOMaster still has a human confirming the final output before it is filed. Calling these "AI-complete" is a claim about where the individual-transaction decision sits, not a claim that no human touches the process anywhere. A sharper version of this paper's test would ask, for each discrete decision inside a workflow, whether that specific decision requires a human — rather than asking the question once for the whole workflow. §6's cases pass that sharper test for the transaction-level decision specifically; this paper has not applied it rigorously across a wider set of deployments, and doing so for deployments outside Flux's own products is exactly the kind of test that could falsify the claim that this distinction is usually easy to apply, which §7 asserts more confidently than this paragraph now does.

"The ERP parallel may be read as stronger evidence than the sources actually support." Brynjolfsson's 1993 paper is a survey identifying competing explanations for a measurement puzzle, not a confirmed finding that 1990s enterprise software failed to transform the organisations that bought it; Davenport's account is a single practitioner's argument, however well-informed. Treating either as settled proof that the 1990s wave "failed" would overclaim what they say. §4 above is written to reflect that qualification, named again here because the temptation to flatten a careful source into a punchier claim is a real one.

9. 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, on this paper's argument, a large fraction 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 share 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. This paper has not measured that share for any organisation outside Flux's own case studies, and §10 registers that absence rather than assuming a number.

The tasks that do require a human are, by the same argument, 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, on this paper's own terms, a vision of AI replacing work wholesale. It is a narrower claim: that AI should eliminate the work that humans were doing only because no one had yet built the software to do it properly, and that the people freed from that work are not thereby redundant — they become available for work that actually required them all along, a claim this paper does not independently verify but states as the premise its own product decisions are built on.

10. Limitations, and what this paper does not claim

No controlled or large-sample comparison between AI-assisted and AI-complete deployments is cited, because none was found that operationalises this paper's specific distinction.

It does not claim PBOMaster and ProcureBee are a representative sample of enterprise AI; §8 states plainly they are illustrations from one company's own product line, selected because they are the clearest cases this paper's authors can describe from the inside.

It does not claim a human "in the loop" is always the inferior design; §8's first objection complicates this paper's own accountability argument rather than resolving it, and the paper does not have evidence settling which failure mode — degraded human vigilance or a badly specified automated policy — is worse in general, only that both are real.

It does not claim the binary test is simple to apply to every real deployment; most sit somewhere between the two categories, and this paper's own cases are chosen partly because they are closer to the clean end of that spectrum than most deployments will be.

It does not claim the 1990s enterprise-software wave was a uniform failure; §4's sources describe a measurement puzzle and a practitioner's diagnosis, not a verdict, and §8 names the risk of overclaiming them directly.

And it does not claim to have measured the size of the administrative-task population this paper's closing argument gestures at; that is asserted, not measured, and Appendix B registers it as open.

11. What would falsify this

Stated as commitments, in decreasing order of how much damage each would do to this paper's claims.

Large-sample evidence shows AI deployments classified by this paper's own test as "AI-complete" perform no better — on cost, error rate, throughput, or compliance outcome — than deployments classified as "AI-assisted," once matched on task type and organisation size. That would show the categorical distinction this paper treats as the whole point does not actually track a real difference in outcomes, and the paper's central claim would need withdrawing, not softening.

A rigorous comparison finds degraded human vigilance in nominally-supervised routine decisions (§8, first objection) produces fewer costly errors than a badly specified automated policy covering the same decision space. That would invert this paper's accountability argument in §7 and require treating "keep the human nominally in the loop" as the safer default for exactly the category of decision this paper argues should be automated.

PBOMaster's or ProcureBee's own deployment data, examined rather than described, shows the "policy-level" human review this paper treats as sufficient oversight is in practice a rubber stamp indistinguishable from the complacency pattern §8 warns applies to human-in-the-loop review generally. That would mean this paper's own products have simply moved the complacency problem one level up rather than solved it, undercutting §6's cases as clean illustrations.

A systematic review of post-2020 enterprise AI deployments finds organisations asking the process-elimination question (§3's "right question") at a rate indistinguishable from organisations that do not, once resourcing and sector are controlled for — i.e., that the Raisch and Krakowski augmentation-preference finding, real as it is in the literature this paper cites, does not actually predict which organisations under-invest in redesign. That would weaken, though not fully collapse, §3's explanation for why the failure mode is so common.

Appendix A — Evidence table

Appendix B — Citation register

CITATION-NEEDED — comparative outcome data, AI-complete vs. AI-assisted. Appendix A row 7. No study was found measuring outcomes specifically along this paper's own binary distinction; §11 names it as the sharpest available falsification test.

CITATION-NEEDED — comparative failure rate, human complacency vs. automated-policy error. Appendix A row 8. §8's first objection and §11's second falsification condition both depend on this comparison, which no cited source makes directly.

CITATION-NEEDED — share of administrative workload that is task-eliminable. Appendix A row 9. §9's closing claim that eliminable tasks are "a large fraction" of institutional workload is asserted from the authors' own product experience, not measured, and is not extended further than that in this paper.

Not used, and why: a widely repeated account of FoxMeyer Drug's 1996 bankruptcy following a troubled SAP R/3 implementation was considered for §4 as a second historical illustration. Multiple secondary summaries (case-study abstracts, business-press retrospectives) describe it consistently, but the primary source (Judy Scott, "The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP?," AMCIS 1999 Proceedings, paper 80) returned an access error on every fetch attempt during this paper's research. Secondary agreement is not a substitute for reading the primary text, so it is not cited here.