People, Process, Technology in the AI Era: Still Valid?

The ERP module I learned the most from has no AI in it. ANCoraPRO's accounts payable module replaced invoice approvals that ran on email and chat. The fix was ordinary software: an approval chain modelled per organisation level, an email at every step, and a record of every decision. Turnaround went from days to hours. The code was not the hard part. Getting the chain right was: submitted, manager, finance, approved, payment, paid. There was no CFO step, so the software had none.

Since October 2026 my job title has AI in it: I wire AI agents into the systems a company already runs. That work keeps raising the question in the title of this post. If an agent can do the work, is people, process, technology still the right way to plan change? I did not want to answer from opinion, so I read fourteen sources, from Harold Leavitt's 1965 chapter to BCG, MIT NANDA, DORA, Gartner, METR and a century-old lesson about electric motors. Here is what they say, where I land, and a question I want you to answer at the end.

Where people, process, technology came from

The framework is older than most of the software it is used to plan. Harold Leavitt's 1965 chapter on organisational change, published in James March's Handbook of Organizations, described an organisation as four variables that move together: task, structure, technology and people. Change one and the others shift, whether you planned for it or not. IT practice later compressed the four into three words, with task and structure merged into process. ^[1]

Security engineers made the idea a habit. In May 2000 Bruce Schneier wrote the line many of us still quote: security is a process, not a product. Products give some protection, he argued, but only processes that account for their weaknesses keep you safe. Read that way, the framework was never a checklist with three boxes. It is a claim that the legs are coupled, and that technology bought without the other two delivers less than its brochure promises. ^[2]

The data says people and process still decide the result

The largest surveys of AI adoption put most of the difficulty outside the model. BCG surveyed 1,000 executives in 59 countries in 2024 and found that 74% of companies had yet to show tangible value from AI. Only 4% had cutting-edge capabilities across functions. Those leaders followed what BCG calls the 10-20-70 rule: 10% of resources on algorithms, 20% on technology and data, and 70% on people and processes. The problems sat in the same proportions, with around 70% of challenges stemming from people and process issues. ^[3]

MIT's Project NANDA reached the same conclusion from a different angle. Its 2025 report, built on more than 300 public AI initiatives, interviews at 52 organisations and 153 survey responses from senior leaders, found 95% of organisations getting zero return from generative AI. The authors were explicit about the cause: the divide does not seem to be driven by model quality or regulation, but by approach. Most enterprise tools failed because of brittle workflows, a lack of contextual learning and misalignment with day-to-day operations. ^[4]

Gartner expects the same pattern with agents. In June 2025 it predicted that over 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 also estimated that only about 130 of the thousands of vendors selling agentic AI are the real thing; the rest are relabelled assistants, RPA tools and chatbots. None of those three causes is a weakness of the model. ^[5]

Electricity already ran this experiment

This is not a new problem. Edison was selling electricity as a commodity in the early 1880s, yet by 1900 less than 5% of the mechanical drive power in American factories came from electric motors. Owners who swapped a steam engine for a motor were often disappointed with the savings, because the factory was still built around one massive spinning driveshaft. ^[6]

The gains came when factories were redesigned around the new technology: small motors at each machine, a layout that followed the production line, and workers trusted with more autonomy. Tim Harford's account of the economic historian Paul David's work is blunt: you needed to change everything, the architecture and the production process, and even the way workers were recruited, trained and paid. American manufacturing productivity soared in the 1920s, once manufacturers finally worked out how to use a technology that was nearly 50 years old. ^[6]

Economists have a name for that delay. Erik Brynjolfsson, Daniel Rock and Chad Syverson call it the productivity J-curve: general purpose technologies such as AI enable and require large complementary investments in skills, processes and organisation, which official statistics barely measure. Productivity looks flat, even negative, while those investments are being made. Bolting an AI model onto an unchanged process is the steam engine swapped for a motor. ^[7]

AI amplifies the process you already have

The best evidence from software teams says it in one sentence. Google's DORA programme surveyed nearly 5,000 technology professionals for its 2025 report. 90% use AI at work and more than 80% believe it made them more productive, yet AI adoption still has a negative relationship with software delivery stability, and 30% report little or no trust in AI-generated code. DORA's conclusion: AI's primary role is as an amplifier, magnifying an organisation's existing strengths and weaknesses. ^{[8, 9]}

BCG's 2025 survey of 10,600 workers in 11 countries found the people side stalling. Only 51% of frontline employees are regular AI users, a figure that has stagnated, and just 25% say their leaders give enough guidance on AI. Workers who received five or more hours of training were significantly more likely to become regular users. The companies BCG saw unlocking value were the ones going beyond deployment to reshape entire workflows. ^[10]

I saw the amplifier at small scale when I ran an unattended Claude Code agent on my own servers. Most failures I logged were harness bugs, not model mistakes: the process around the model, not the model. The details, with the published research beside them, are in my post on AI agent harness engineering.

People: from doing the work to judging it

The people leg changes most visibly. In February 2024 Klarna announced that its AI assistant had handled 2.3 million conversations in its first month, two thirds of its customer service chats, and was doing the equivalent work of 700 full-time agents. Customers resolved their errands in under 2 minutes instead of 11. ^[11]

By May 2025 its chief executive, Sebastian Siemiatkowski, told Bloomberg that cost had been too predominant an evaluation factor, and that what you end up having is lower quality. Klarna started hiring people again so that, in his words, there will always be a human if you want. The technology worked. What the plan underweighted was the people leg: who judges quality, and who the customer reaches when the bot is wrong. ^[12]

Even the people using AI misjudge it. In METR's 2025 randomised trial, 16 experienced open-source developers took 19% longer on real tasks when they were allowed AI tools, yet believed afterwards that AI had sped them up by 20%. METR's February 2026 update says developers are likely sped up more by today's tools, but found the effect hard to measure, partly because more developers now refuse to work without AI at all. The lesson for the people leg is not that AI is slow. It is that a feeling is a bad metric, and someone has to own the measurement. ^{[13, 14]}

Process: the leg AI turned into code

The biggest change is to process. Before AI, a process document was written for people, and people filled its gaps with judgement and a quick question to a colleague. An agent does not ask the colleague. A process an agent can run has to name its trigger, its steps, its decision points, the data each step reads, what done means and who owns the exceptions. If the steps live only in someone's head, there is nothing for the agent to follow, and you are automating guesswork.

This is the shape I would write down before handing any process to an agent. The steps are the real approval chain from the ANCoraPRO project; the other fields are a template to fill in for your own process.

# Process card: written so a person or an agent can run it.
# Steps: the real ANCoraPRO accounts payable chain. Everything else: a template.
process: ap-invoice-approval
trigger: supplier invoice received
steps:                  # only what the company actually does; no CFO step
  - submitted
  - manager
  - finance
  - approved
  - payment
  - paid
decisions:              # every fork, and where a rejection goes
  manager: approve | reject -> ?
  finance: approve | reject -> ?
reads: [invoice, purchase_order, vendor]   # the data each step needs
done_when: paid, with every approver and timestamp recorded
exceptions_owner: ?     # a named person; an agent escalates, never guesses
human_checkpoint: finance   # the step where judgement stays with a person

Look at the last two lines. A process written for an agent has to say where the agent stops and a person decides. That line is where the process leg meets the people leg, and leaving it out is how quality drops quietly, the way it did for Klarna.

Technology: the cheapest leg, chosen last

Technology is still a leg, but it is now the cheapest and fastest-changing one. Models get better and cheaper every few months, and Gartner's agent-washing estimate is a reminder that much of what is sold as new is relabelled. MIT NANDA also found that external partnerships saw twice the success rate of internal builds, which suggests that building the model layer yourself is rarely where the value is. ^{[5, 4]}

So I treat technology as the last decision, not the first, and as one I expect to remake. Choose it after the process is written, keep the process independent of any single model, and make switching cheap. If your process only works with one vendor's model, the process has quietly become part of the technology leg, and it will age at the technology's speed.

My verdict: still valid, as a sequence

People, process, technology is still valid in the AI era. The evidence above does not weaken it; it is the strongest case for it in decades. What has changed is what each leg means.

The order matters as much as the legs. Start with the people who own the outcome, write the process down until an agent could follow it, then choose the technology. Worked in that order, the framework is not a relic. It is the checklist most stalled AI projects skipped.

The framework survived steam, electricity, computers and the web because it was never about one technology. AI does not break it. It raises the price of ignoring it, because an agent will run a broken process faster and more confidently than any person ever did.

Related reading

• AI agent harness engineering: what research and real runs show
• ERP process mapping: the requirements work that saves projects
• AI pair programming and the junior developer skill gap