There is a fear that nobody in the room is naming.

The business analyst who has spent twelve years mastering the intake process. The credit analyst who can read a corporate ownership structure and spot a shell company in minutes. The developer who knows exactly which edge case will break a migration script before it runs. These are the people sitting in the AI adoption meeting, nodding at the strategy deck, and quietly wondering: am I training my replacement?

That fear is not irrational. And it will not go away by itself.

But here is what I have come to believe after watching several AI implementations up close — including one I am running myself: the fear is pointed at the wrong thing. The threat is not the agent. The threat is what happens when you take an agent and drop it into a process that was never designed to include one.

That is when things go wrong. Not because the agent fails — but because the process was built around human execution, and an agent inserted into that process can only ever be a faster human. Which is useful. But it is not transformation.

When organisations introduce AI agents into their operations, they tend to do it the same way. They identify a task that is repetitive and time-consuming. They find an agent that can handle it. They wire the agent into the existing workflow in place of the human who was doing it.

The result is a ten or twenty percent efficiency gain — real, measurable, and entirely insufficient to justify the change management effort that surrounds it. The leadership that expected transformation gets incremental improvement. The workforce that feared displacement gets disruption without the promised upside. And the implementation stalls.

The right starting point is not a vendor demo or a technology selection. It is a whiteboard.

Before any agent is deployed, the organisation needs two people in the same room: a subject matter expert who knows the workflow deeply — its steps, its exceptions, its informal rules, its judgment calls — and an agentic engineer who understands what agents can and cannot do reliably. Together, they do something that sounds simple and is actually difficult: they map the process end to end, and then they ask, of every single step, one question.

Let me give a concrete example from my own experience.

We are running a large-scale Oracle Forms modernisation engagement — converting a legacy application to a modern Angular web stack. We built three agents to assist: a BA agent to parse legacy inputs and generate business requirement documentation, a Dev agent to convert code, and a QA agent to generate test cases and test scripts.

In the first iteration, we used these agents as assistants — tools that helped individual team members do their tasks faster. The BA used the BA agent. The developer used the Dev agent. The QA analyst used the QA agent. Each in their own lane, in the same sequence humans would have followed.

The efficiency gain was real. But it was modest — somewhere in the ten to twenty percent range. Enough to see on a timesheet. Not enough to change the economics of the engagement.

So, we reengineered.

Instead of agents assisting humans sequentially, we redesigned the pipeline so agents interact with each other. The BA agent’s validated output now feeds the QA agent and the Dev agent simultaneously — the same way a well-run human squad would brief a developer and a QA analyst at the same time, not one after the other. The test cases generated by the QA agent become an input to the Dev agent — so the developer’s agent is writing code against both the requirements and the test criteria from the start.

We then split the Dev agent’s pipeline into two: a coder pipeline that generates the first-cut code, and a validator pipeline that runs the test cases against it. Failed tests are fed back into the coder as a reinforcement loop. The agent iterates until either all tests pass — at which point the output is ready for human peer review — or it exhausts its retry threshold, at which point it enters an exception queue for a human in the loop.

Here is the insight that crystallised this for me: complex human workflows already operate as squads with built-in checks and balances. They just do it with people.

I recently reviewed a process document written by a senior engineering leader on my own team — someone steeped in how agents work, responsible for building the very agent frameworks our products run on. Reading his standard operating procedure for AI-assisted software delivery, I noticed something striking at every step, the human remained the gatekeeper. Every agent output required human review before the next step could begin. The document described the AI system explicitly as an assistant tool — not an agent, not autonomous — and built sign-off gates into the workflow at every transition.

I do not say this as a criticism. The instinct to retain human oversight is correct, especially in the early stages of any new process. But it is worth pausing on: even the people who build agents default to treating them as tools when they design their own team’s workflows. The mental model runs deep. And if it runs this deep in people who build agents for a living, imagine how deep it runs in the operational teams we are asking to adopt them.

What struck me even more was the structure of the human roles he described — business analyst, solutions architect, developer, tech lead, QA engineer. This is a squad, with each role feeding, checking, and handing off to the next. That structure exists because complex delivery requires multiple perspectives, validation at multiple levels, and accountability distributed across the team.

A well-designed multi-agent pipeline mirrors that squad exactly. Each agent represents a function. Agents interact, validate each other’s outputs, and hand off within guardrails set by humans. The human team does not disappear. It moves up: from executing every step to setting the guardrails, handling exceptions, and owning the judgment calls that the agents are not equipped to make.