Where does AI investment actually earn a return once agents carry the production work?

Most enterprises have completed the initial, simpler phase. Licenses are purchased, AI tools are in use, and many report increased speed. However, when asked what tangible results the company has achieved, the room falls silent.

The honest answer is that faster people and a faster company are not the same thing.

Individual productivity has increased in most organisations that have bought these tools. Very little of it has reached the numbers a board looks at, and the reason is that the process the work travels through has not changed. The same teams hand work to each other in the same order, the same approvals happen at the same points, and the work waits in the same queues it always did. People are doing their part faster. Their part was rarely the constraint.

We have come to call the first state AI enabled: everyone has a tool, and every step is somewhat quicker. The second, AI native, means the process itself has been redesigned around the agents, with fewer handoffs and teams organised around decisions. Most organisations are AI enabled and are planning their next round of investment as though they were already AI native. That gap is the expensive part, and it is worth being precise about what closes it.

Every competitor you have can buy the same models on the same commercial terms, usually within the same quarter. Whatever advantage sits in the tool itself is available to everyone, at the same price, more or less immediately.

So if the budget goes on licences and nothing else, you have funded the part of this that is hardest to differentiate on. What the licence actually buys you is faster iteration for people who already have good judgment. A team can now work through ten versions of an idea in the time it used to take to build one, which is genuinely valuable, but only because someone still has to decide which of the ten is right. What used to be one decision at the end of a week is now ten decisions in the same week, and each one still needs a person who can tell the difference.

That points the budget at three things. The people who decide what is worth building. The people who can tell whether finished-looking work is actually correct. And the job of building your own standards and past decisions into somewhere the agents can read them, because an agent with no company context will only give you a generic answer.

Over the course of running our own AI transformation projects this way, five changes recurred, and they mattered in a particular order. Without them, the speed stays with the individual. The path below runs from how most companies operate today to operating as an AI native company, with the five changes in the order they work best.

1. Start with experimentation and the team brain. People upskill through hands-on practice. Writing an instruction that an agent can actually complete is a skill. It is learned by doing: describing a piece of work precisely enough, with the right context and a clear definition of what finished looks like. So provide the tools early, along with sandboxes, labs, and hackathons where people can use them outside production, and set clear expectations about what is for experimentation and what is for production work. That is the first guardrail. Inside it, teams can find the best process and push the boundaries of reducing handoffs without putting client work at risk. While they experiment, add context by building what our team ended up calling the team brain. This is a single place where the decisions a team has made are written down and kept up to date, in a form both people and agents can read: the locked business requirements, the architecture choices, the standards and the reasons behind them. Without it, individual gains stay individual. A project lead can use agents to produce an excellent set of business requirements, but if that document sits on their own drive, no downstream coding agent can read it. Multiply that by a thousand employees, and you have a thousand private improvements and no organisational one.

2. Optimise processes for people and agents, and formalise specialist skills. Parts of your current process exist to prevent wasted effort, which made sense when producing a first version of anything was slow and expensive. Rounds of specification and sign-off before anyone builds are the clearest example. If a first version now takes an afternoon, making those steps faster keeps them in place, and keeps the wait they create. The useful question is which of them you would not design today. This is also where specialist roles need to share their skills. Specialists build their checks, standards and know-how into agent skills and formalise them, so their judgment is available to the whole team, not only to the work that crosses their desk. One person spending a week building a skill that ten colleagues use daily is worth far more than ten individual pieces of work, because the first compounds and the second does not.

3. Reduce handoffs. Most delivery processes were built around specialists, so a piece of work passes through several pairs of hands before it is finished. Each pass means waiting for the next person to be free, a conversation to bring them up to speed, and some loss of detail along the way. With the team brain and specialist skills in place, others can use them to carry work across a boundary that used to require someone else, so a necessary handoff becomes optional. Removing it is where the company-level gain lies, and someone has to decide to do so, because the tools do not do it on their own.

4. Provide tools and guardrails for production work. Experimenting in a sandbox is not the same as shipping to a client. Before scaling to production, build compliance and quality into the guardrails and bake specialist reviews into production reviews, so checks happen as part of the work rather than in a queue at the end. People also need to know which decisions they can make with an agent’s output and which need a named person to sign off. Without clear boundaries, teams either escalate everything, creating queues and losing the speed advantage, or escalate nothing, allowing unchecked work to reach the client.

5. Formalise into smaller AI-native teams. Only once the steps above are working is it time to change the structure. Teams can then become smaller and organised around decisions rather than handoffs, because the context, skills and checks that used to need more people now live in the system.

Of the five changes, only one involves buying something new. The other four are organisation design, process design, training and governance. None of them will appear in a software usage report.

That matters because usage reports are what most organisations have. Licences issued, active users, sessions per week. Those numbers can look healthy even when nothing has changed in how the work actually flows, and they can look flat even as a team quietly rebuilds a process and takes a week out of a delivery cycle.

If the proposal in front of you is mostly more software, it probably solves a problem you have already solved. More tools do not change how delivery works on their own. The test is the one delivery teams already use: is the work on time, on target and meeting the requirements? Beyond a usage report, three signals show whether the change is taking hold underneath.

• How long does work wait between steps, compared with a year ago?

• How much work gets accepted without a senior person rewriting it?

• How many of your people have changed how they work, beyond holding a licence?

We rebuilt our own delivery teams to find out which of these changes mattered and in what order. The full findings, including the migration path from AI enabled to AI native and how to run the change in your own organisation, are in one place. Read what we learned from rebuilding our own teams: Reorganise Your Team in the Agentic Era