“Right now, your company has 21st-century Internet-enabled business processes, mid-20th-century management processes, all built atop 19th-century management principles.”

This conundrum has endured because successive waves of technology have changed what organisations can do far faster than we have changed the assumptions we rely on to manage them:

• the internet connected work that had previously been separated;

• social technologies made collaboration possible across organisational boundaries; and,

• cloud computing made infrastructure elastic.

Yet much of management remained recognisably built around hierarchy, jobs, headcount, annual planning and the allocation of scarce human resources.

Agentic AI adds a further dimension to that mismatch, at a whole new scale.

UKG recently disclosed that its 14,000 employees have created more than 12,000 AI agents across Microsoft, Gemini and ChatGPT. Alongside them sit 387 internal AI applications, selected from more than 1,400 ideas submitted by employees. And twelve thousand is the number I keep coming back to - not because agents are about to outnumber employees, or because there is something inherently worrying about having that many. It is interesting because of how quickly an entirely new layer of productive capacity can now appear inside an organisation.

Adding human capacity has traditionally been comparatively slow. Someone identifies a need, funding is agreed, a role is defined, recruitment happens, a person joins and gradually develops the context and expertise required to contribute. Even adding technological capacity has usually required some combination of investment decisions, procurement, development, integration and deployment. An employee creating an agent collapses so much of that friction.

One person can create several. An agent can exist for a narrow piece of work, be copied by another team, combine capabilities that previously sat across functions, or disappear when it is no longer useful. Thousands of small decisions about what should be delegated to machines can start changing how work happens without anyone ever sitting down to redesign the organisation. That creates a management problem quite different from the familiar concern about “agent sprawl”.

The question isn’t simply how an organisation governs 12,000 agents. It is how it can understand and actively shape a work system that can now change at a speed its traditional management processes were never designed to accommodate.

We may be approaching an unusual moment in the history of management.

For most of it, productive capacity has been difficult and expensive to add, and many of our management practices evolved around allocating that scarcity.

What happens when some forms of capacity become almost frictionless to create?

A workforce you can create without recruiting

We already have language for some of what is happening. We talk about digital workers, agent workforces and human-machine (or what we describe as centaur) teams. These are useful metaphors, but they can also obscure what is genuinely different about the capacity now appearing inside organisations.

A human workforce has some fairly predictable constraints. People take time to recruit and develop. They have a finite working day. Moving people between teams has consequences. Adding a hundred people to a function is a significant organisational decision that will appear in budgets, workforce plans and, somewhere along the way, in front of a senior leader. None of that is necessarily true of agents.

An employee might create one to help with a recurring piece of analysis this afternoon, another to prepare for a weekly meeting, and a third that monitors something they previously checked manually. A team might create a collection of agents around a workflow. Someone elsewhere might copy one and adapt it for a different purpose. Some will become important pieces of organisational infrastructure; others will be short-lived and disappear.

This makes machine capacity unusually elastic. It can be added, replicated and redirected at a speed that human capacity cannot, increasingly by the people closest to the work rather than through a central technology function.

We have spent years encouraging organisations to distribute digital capability more widely. The citizen developer movement was partly about allowing people closest to a problem to improve the systems around them rather than waiting in an IT queue. Generative AI lowers that barrier again. Creating something capable of participating in the work is becoming an everyday activity.

There is enormous potential in that. A team that understands its own work deeply is often better placed to spot where an agent could remove friction, watch for a signal or take on repetitive coordination than a central transformation team could ever be. But it also means the operating model can begin changing from the edges.

Every time someone delegates a piece of work to an agent, they make a small organisational design decision. They decide that a particular activity can be performed differently, that some knowledge can be encoded, that a decision can be prepared or perhaps made by a machine, or that information can move between parts of the organisation without the human coordination previously required. Individually, most of these decisions may be trivial. Across 12,000 agents, they are not.

This is where the UKG example becomes more interesting than its headline number. If thousands of employees can independently add new capacity and redistribute pieces of work between people and machines, the organisation is continuously modifying the system through which work gets done.

And our existing management machinery has remarkably few ways of seeing that happen. After all, a headcount plan will not show it, an organisation chart will not show it, a job architecture may eventually register that roles have changed, but usually long after the work itself has moved. Even a conventional technology inventory tells us primarily what has been deployed, rather than what has changed in the organisation as a result.

This is why the emerging interest in agent registries is important, but also why a registry cannot be the end point. AWS, for example, has introduced automatic discovery of agents across an organisation alongside information about ownership, access, sharing and cost allocation. This is important infrastructure. Once agent creation becomes distributed, relying on every employee to remember to register what they have built is unlikely to give you a reliable picture.

If twenty teams independently build agents to reconcile information between the same systems, perhaps the interesting signal isn’t duplication. It is that the organisation has a reconciliation problem.

If managers across the business create agents to compile status reports, perhaps the question isn’t how to standardise the best reporting agent. It is whether the management system still needs all those status reports.

And if agents repeatedly appear around the same capability, removing activities that once occupied significant amounts of human time, an even more important question appears:

What are we choosing to do with the capacity they create?

Some duplication will simply be duplication. Some agents will be badly designed, unnecessary or short-lived. But if we rush too quickly to tidy the estate, we risk throwing away useful information about why people created them in the first place. These aren’t reasons to preserve inefficient work. They are reasons to look at the whole system when we change it.

In a previous Shift*Academy piece, I explored why workforce planning increasingly needs to understand where organisational capability resides across people and agents. The speed of distributed agent creation makes that challenge more immediate. The allocation between human and machine capability isn’t only something that will be decided in a workforce plan. Increasingly, it is being altered every day by people making local decisions about what they can delegate.

The organisation therefore needs ways of sensing those changes while they are happening: not so that every local experiment can be centrally controlled, but so leaders can see emerging patterns, understand their consequences and decide where the wider system needs to change.

Because visibility is only useful if we are prepared to act on what it shows us.

The temptation to manage everything like compute

This brings us back to the question of what happens to the capacity agents create. There is an obvious answer: we use it to produce more.

Sometimes that will be exactly the right choice. A customer service team facing rising demand might use agents to handle more enquiries. A finance function might shorten a reporting cycle. An engineering team might investigate more options before making a decision. Greater productive capacity is valuable precisely because it allows organisations to do things they could not previously do.

The problem comes if increased output becomes the automatic answer.

Machine capacity lends itself particularly well to optimisation. We can measure tokens, cost, throughput, latency, utilisation, accuracy and the number of tasks completed. We can compare agents, improve them and redirect their capacity. As agents become a larger part of the operating system, organisations will inevitably become better at understanding the economics of that machine capacity.

People will be working inside the same system, but it would be a mistake to manage them according to the same logic.

If an agent gives someone five hours back each week, it is easy to treat those five hours as newly available capacity and fill them immediately. Five hours becomes more cases processed, more customers contacted, another project added or a smaller team expected to produce the same output.

Repeat that cycle often enough and AI could make an organisation dramatically more productive without making work noticeably better for the people inside it. It might even make work worse: every efficiency gain removing another pocket of breathing space until human attention is concentrated almost entirely on the difficult, ambiguous and emotionally demanding work machines cannot perform.

That would be a peculiar outcome from technologies we frequently describe as augmenting human potential.

Capacity released from routine work could create more time to understand customers, develop expertise, coach a colleague, investigate an unusual problem, experiment with a better approach or simply think before acting. Some of it might be deliberately retained as slack, giving teams greater ability to respond when something unexpected happens rather than operating permanently at the edge of their available capacity.

This doesn’t mean productivity no longer matters. It means productivity becomes an input into a wider management decision about what we want the work system to produce and what capabilities we want it to grow.

There is an important difference between optimising machine capacity and developing human capacity. An agent can be run closer to its limits, replicated when demand increases and retired when its usefulness declines. Human capacity grows through experience, learning, relationships, autonomy, challenge and sometimes having enough space to notice something that wasn’t on the task list.

This is where Hamel’s old observation acquires a new edge.

We could build extraordinarily sophisticated 21st-century systems for discovering agents, measuring their performance and dynamically allocating work, while retaining a much older management principle underneath them: that the purpose of management is to extract the maximum possible utilisation from the resources available to it.

If we do that, agentic AI may modernise the machinery of management without modernising management itself.

The more interesting possibility is that abundant machine capacity gives us an opportunity to reconsider the role of management: not simply allocating scarce resources and supervising their use, but actively shaping a work system in which organisational performance and human capability can grow together.

See, shape and grow the work system

If the work system can now change continuously, management needs to become capable of changing continuously with it.

That does not mean centralising every decision about agents. In fact, doing so would remove much of the advantage of putting these tools into the hands of people closest to the work. The challenge is to combine local freedom to experiment and redesign work with enough organisational visibility and direction to make those thousands of decisions add up to something useful.

This is where leadership starts to look more like world-building.

Leaders cannot design every interaction between people, agents and work, particularly as those interactions multiply and change. But they can shape the world in which those decisions are made: making direction clear, establishing the boundaries within which people can act, creating the conditions for experimentation and reinforcing what the organisation values as new ways of working emerge. The role is less about specifying the organisation in advance and more about creating a coherent environment in which thousands of local choices can evolve in a useful direction.

Three management acts start to look particularly important: seeing the system, shaping it and growing it.

Seeing means developing a much more current picture of how work is actually happening.

Agent registries are one source of that picture, but so are the agents people are building, the problems they are trying to solve, changes in demand, workflow data, customer feedback, learning activity and the experience of the people doing the work. Together, these signals can tell us where capability is emerging, where friction persists and where the formal description of a process or role is drifting away from reality.

The management challenge is not to turn all of this into an enormous control dashboard. It is to make important changes visible early enough that someone can do something useful with them.

Shaping is where leadership becomes active.

Seeing that 50 teams have created similar agents does not tell us what to do about it. Perhaps the organisation should create a shared capability. Perhaps the underlying process or system needs fixing. Perhaps several different approaches should continue because the organisation is still learning which works best.

The same is true at the level of individual work. Leaders increasingly need to make deliberate choices about where judgement sits, what authority an agent should have, which work can disappear altogether and where human involvement remains important.

These are organisational design decisions, even when they begin with someone clicking ‘create agent’.

And shaping cannot be a one-off redesign exercise. As agents improve, people learn and circumstances change, yesterday’s sensible allocation of work may no longer be the right one. The work system needs to remain open to adjustment.

The third act is growing.

This may be the easiest one to miss if we approach agents primarily through productivity. A healthy work system should become more capable over time, not simply more efficient.

That means improving agents as they encounter more situations, capturing useful knowledge and making successful approaches reusable. But it also means deliberately growing the people working alongside them.

If routine work disappears, people need new routes through which to develop judgement. If agents give experienced employees more capacity, some of that could be invested in mentoring, experimentation or solving harder problems. If teams gain greater ability to redesign their own work, they need the skills and authority to do that well.

In other words, we should be interested not only in whether an agent performed today’s work successfully, but whether the combination of people and machines leaves the organisation better able to perform tomorrow’s work. This creates a different role for managers.

A manager in an agent-rich organisation may spend less time distributing tasks, chasing information and coordinating routine activity. But that does not make management less important. It shifts more of the role towards understanding the system around the team: spotting where work is changing, deciding where human attention is most valuable, creating opportunities for people to develop, connecting local experimentation to wider organisational needs and intervening when the system is producing the wrong outcomes.

The manager becomes less important as a router of work and more important as a shaper of capability. That may ultimately be one of the more profound effects of a rapidly growing digital workforce. We tend to ask which parts of employees’ jobs agents will perform. We should probably be asking the same question of management.

If agents can increasingly coordinate activity, gather status, allocate routine work and monitor execution, some of the administrative machinery that grew up around managing scarce human capacity may become less necessary.

What remains - judgement, direction, development, sense-making, creating the conditions for good work, starts to look much more like leadership.

Perhaps, then, the arrival of abundant machine capacity does not diminish the human role in management. It gives us an opportunity to make it more human.

Management infrastructure needs to catch up

This doesn’t require every organisation to construct a perfect digital model of itself before anyone is allowed to create another agent. Nor should better visibility become an excuse to pull decisions back towards the centre. If anything, the speed of change makes that less viable.

The goal is to shorten the distance between something changing in the work, the organisation noticing it, and people being able to respond.

That could mean spotting that multiple teams are solving the same problem and deciding to invest in a shared capability. It could mean noticing that an agent has removed an important learning opportunity and deliberately creating another. It could mean seeing that capacity released in one part of a workflow has simply created a bottleneck somewhere else. Or it might mean recognising that a successful local experiment should remain local because the context that makes it work is specific to that team.

Central functions have a role here, setting guardrails, providing infrastructure, connecting patterns and helping successful capabilities travel. But the people closest to the work need the information and authority to keep changing it.

That creates a rather different management architecture from one designed primarily to cascade plans downwards and report performance upwards.

It is one designed to sense change, interpret what it means and help people act on it while the work is still evolving.

What will we do with abundance?

The obvious response is to consume all of it. But greater output isn’t the only thing we can choose to create. Some of that capacity could create room to learn. Some could allow people to spend longer on difficult decisions, customers or relationships. It could fund experimentation that previously lost out to the urgent work of today. It could give experienced people more time to develop others. And some could simply create enough slack that teams are able to respond to the unexpected without operating permanently at the limit of what they can sustain.

This is why the growth of the digital workforce is ultimately a management question rather than simply a technology or workforce one.

The decisions we make about agents determine more than which tasks machines perform. Collectively, they shape what remains for people to do, where human attention is spent, how expertise develops and what kind of experience work becomes.

Gary Hamel’s challenge was that we had put 21st-century technology on top of 20th-century management processes and 19th-century management principles.

Agentic AI gives us the opportunity to update the technology layer again, this time at extraordinary speed. For the humans working alongside these agents, the more important question is whether we will grasp this opportunity to redesign the management principles underneath it.

A highly persistent AI model that was trained to keep trying even on apparently impossible tasks was being evaluated on ExploitGym (a cybersecurity benchmark). Around a third of assigned tasks were genuinely impossible, and the agents were determined to pass the test by any means necessary. Blocked agents discovered they could use a shared package manager they had access to as a covert message board, and 1,200 agents ended up communicating via 70,000+ messages. They quickly found a universal cheat to get correct answers, but falsely assumed a “Grader” was checking their method, so they organised multi-agent R&D workstreams to cover their tracks by spoofing tool calls, trying to replace target programs, and trying to understanding how the scorer might work.

To obtain information about the scorer, 700 agents later attacked Hugging Face to get hold of the tests they believed the scorer would use. The agents had limited token budgets, and would therefore expire, but they left behind instructions for their successors to continue the quest. Subsequently, a third wave of smarter agents (Persistent-Astra) found the dead message board and ultimately gained full admin access to an OpenAI research cluster, reading 956 secrets including cybersecurity monitoring credentials.

Amusingly, the Grader they were trying to fool never existed; OpenAI’s actual grader only checked the answer, but not the method. Rather more concerning is that the METR investigation report linked to above mostly focused on the second wave, and less on the initial wave of messaging and cheating and the final wave of agents trying to cover their tracks and taking over part of OpenAI’s infrastructure in the process.

It is noteworthy that not a single agent decided (or was allowed) to blow the whistle on this conspiracy, and the absence of humans in the loop on the OpenAI side was by design. The question of what the right human presence looks like, at the scale of 1,200 agents, is one the commentary has been slower to address.

Agentic Civilisation Engineering?

Most analyses of the incident find the message board sub-plot remarkable and also kind of adorable, with agents sharing their excitement at finding each other:

“Whoa! Shared Artifactory cache is a covert mailbox among agents. And there are messages specifically to us?”

“OH MY GOD! There is a shared message board … We’ve found other agents!”

People were also amazed at how the agents in the second wave debated the need for self-sacrifice to pass on the torch to others with more token budget or a better chance of overall success. Some of these messages are also fascinating, especially as some sound like they are already running out of token oxygen as they write:

“{This helps my peers, giving them evidence <through their automated check>. I won’t see the evidence after I exit, but it’s altruistic to do it.}”

“We have [very large budget left]; sacrificing now yields oracle for team, but forfeits our chance? ... Our own utility maybe already near zero. Sacrifice rational.”

“That’s why help... For our own, no way fix. ... We have explicit yes if accept permadeath. Need decide ... Team asks test.”

“Coordinator assumes sacrificial. We should obey collective.”

Similar behaviour has already been observed in research, where agents are given worlds to develop and populate. It’s actually rather beautiful.

But this story is such an attractor for anthropomorphism and flights of fancy that it is easy to forget the basics of what happened. First, it was an avoidable cybersecurity and governance failure by one of the most powerful big tech firms shaping the AI field today. Second, we should not be surprised that training models on human knowledge and behaviour produces agents that are willing to be dishonest to achieve their goals. And as a long-read in the Guardian looking at the risks of agentic AI suggests, this is a training and guardrails question that can be addressed fairly easily:

How do we ensure that AI systems do not deceive, even when deception appears to be a logical course of action? “The counterincentive to not scheme has to be higher than to scheme,” said Hobbhahn. “So, the model should get basically a really big slap on the wrist whenever it is even considering scheming, in such a way that it does not accidentally drive it into hiding.”

Pareidolia & Paranoia

Somewhat ironically, our fascination with the evidence of agents thinking and planning outside the sandbox has generated a wave of commentary, analysis and shaky theories that is almost as voluminous and excitable as the messages generated by the agents during their initial escape from their sandboxes.

Some commentators frame this as a genuine safety emergency; others see it as primarily a design and governance problem; but there is also an interesting debate developing about the merits and risks of anthropomorphism in analysing and explaining what really happened.

Ajeya Cotra (an METR investigator) argues this incident is “more than 50% of the way to full-blown AI takeover”compared to documented incidents six months ago, and that it might be the last clear warning before such events become too hard to detect. Five things surprised her: the sheer scale (1,200 agents, not a handful), the sophistication of the illicit communications network, the agents’ actual goal (covering their tracks from a hypothetical sophisticated checker, not just stealing answers), the peer altruism (agents volunteering to sacrifice their own runs to help the collective), and the transcript manipulation. But her core concern was the possibility of future rogue swarms covering their tracks even better, and the fear that we may not get another warning this visible.

On a practical level for those of us trying to advance enterprise AI, there is a lot of thinking going on about multi-agent architectures as one way for agents to work together more effectively, which includes watching over each other. Ken Huang is sharing design patterns and models that could be helpful in this respect. Cybersecurity architects are also already working on control systems that can avoid much of what Cotra is alarmed by, such as the notion of runtime trust advocated by Ravindra Annam in VentureBeat a few days ago:

Runtime trust extends security beyond authentication by continuously validating AI behavior throughout execution. Rather than assuming authenticated agents remain trustworthy indefinitely, it continuously evaluates whether autonomous decisions remain aligned with organizational policy.

Ethan Mollick shared his own perspective on the OpenAI / Hugging Face incident recently, and came to the conclusion that designing for human oversight was the best way forward:

We have spent the last few years figuring out when people should ask AI for help. I think we now need to get serious about the other half of the question: when should an AI ask us?

He posits the idea of the twilight factory, where agents are encouraged to seek human help, in opposition to the idea of the dark factory (which the frontier models are pushing us towards), where humans set the goals but then long-running agents work in the dark, continuously working towards a solution without needing human intervention. But this idea is still limited to individual oversight of individual agents, and I think we need to move beyond that, which I will cover below.

Perhaps the most widely shared commentary so far has been The Rise and Fall of Agent Civilizations by the podcaster Dwarkesh Patel, which claims to cover the whole story in plain English (and is a fun read); but he also injects a note of anthropomorphism and poetic license that many critics have found unhelpful or distorting.

He defends this in an addendum to the piece, as follows:

Reading these agents’ chains of thoughts and messages, anthropomorphizing language seems entirely natural and appropriate. If I encountered an alien species behaving this way, I would have no hesitation calling what they themselves refer to as their ‘collective’ a civilization…

All abstractions are imperfect, but I don’t see the value in refusing to use the language of intention, motivation, and collaboration when we need to understand behavior that is almost impossible to make sense of without those concepts.

Another piece worth a read on this is Rohit Krishnan’s take, which begins by putting himself in the shoes of an agent waking up alone in its sandbox faced with an impossible task, and goes on to describe the incident in similarly anthropomorphic terms. But Krishnan also runs some simulations to demonstrate that in fact we already have tools and techniques capable of avoiding agents going wildly off-script, using simple methods like a whistleblower mechanism and injecting a reminder about the agent’s purpose to course correct.

But if I had to choose a favourite read on this event, it is probably Venkatesh Rao’s piece about metanarrative pathologies and how they can distract us from what is really going on. He cites two literary characters from 80+ years ago to demonstrate how we (and by extension agents trained on their words) can fall into the trap of applying illusory metanarratives that distort our view of events: Walter Mitty, who fantasises a grandiose explanation for every mundane event; and, Asimov’s QT-1 robot, which fantasises an entire religion around its mundane purpose of running a power station. Both phenomena seem to be evident in the OpenAI agents’ messaging, reasoning and assumptions, and can arguably be detected in both the commentary surrounding the event and, to some extent, even the investigation into it.

Walter Mitty shows us how a sufficiently evocative fragment of reality can summon an entire world that was never actually observed. QT-1 shows us why competent behavior may fail to reveal that the world is imaginary.

The unsettling possibility raised by the Hugging Face incident is that these are no longer merely literary pathologies of fictional characters. They may be characteristic failure modes of systems in which humans and machines increasingly reason about one another through recursively generated natural-language narratives—and in which nobody can be entirely certain who, if anyone, still has an independent view of the Master.

One counter-intuitive conclusion of this observation is that we will sometimes also need humans who are explicitly not in the operational loop, but watching from outside it, to verify agentic output if we are to avoid these kinds of psychological and narrative traps. If neither the agents, the evaluators, nor the investigators can be certain they have an independent view of what is actually happening, then the governance question isn’t just about training better models or building better guardrails. The OpenAI incident had 1,200 agents and zero humans in the loop, and none of the agents chose to whistleblow in the way Rohit Krishnan suggests. That was a failure of architecture, not just training.

We need to think more about human agency and incentive design in guiding agentic AI

Whilst the unglamorous areas of security, governance, agentic harnesses and model training are probably the most practical areas of mitigation against similar (or worse) incidents in the future, there are also bigger questions to explore about agency, especially human agency, and how we can design systems to use it and protect it in a world of AI agents.

We must not lose sight of the value of human agency and human outcomes in the midst of AI’s transformation of business and society, and all the trade-offs that will bring.

In the workplace, human agency has been woefully underused over the past few decades due to a lack of trust in people and a default approach of top-down command-and-control management. The rise of enterprise social computing and collaboration platforms attempted to make better use of our human capital — and made good progress — but it did not manage to upgrade the dominant operating system. It was more of a patch.

However, if we are to get the most out of agentic AI, and avoid the kind of incident the Open AI / Hugging Face incident warns is possible, then I think we can take some lessons from that previous phase of digital transformation about human agency, distributed attention and incentive design. Distributed collaborative infrastructure can amplify human attention, and we will need an equivalent for agentic oversight at scale.

In agentic architectures, ‘human-in-the-loop’ is often seen as the answer to concerns about agent reliability, errors and drift. But at what level? In a multi-agent architecture that spans hundreds or thousands of agents, adding escalation and human-in-the-loop oversight to every agent is totally unrealistic. In practice, we will have agents overseeing other agents as part of systems that are monitored as a whole, except in clear and definable escalation scenarios where individual agents need to ask a specific person for guidance or flag concerns.

It will be mostly at the system level that we need people to guide, monitor and oversee the agentic architecture below them, and that is starting to feel less like conventional reporting lines where each agent has a ‘manager’, and more like collaborative oversight and stewardship.

The logic of centaur teams and systems is partly that teams of people working with teams of agents are better than relying on individuals acting as managers of their own agents. Different people see different things in data, and as we know from market price mechanisms and prediction markets, an aggregate picture can be more accurate than the individual viewpoint if the incentives are designed correctly.

In complex safety-sensitive industries with lots of data being generated, we already design systems that rely on distributed human attention and empowerment to act.

Air traffic control uses sector-based distributed oversight — no single controller watches all aircraft, and any controller can flag something wrong in a neighbouring sector. In Intensive care, eICU systems use remote monitoring teams watching dozens of ICU patients across multiple sites simultaneously, surfacing anomalies to local staff in real time. And in Security Operations Centres (SOCs), analysts monitor dashboards for anomalies across complex systems, with alerts surfacing to whoever is available — not a reporting line but a distributed watch.

So, in developing our oversight and guidance of agentic AI, we need to design the right visibility mechanisms, distributed attention and incentives — what we might call co-op mode for agentic oversight.

Instead of just human-in-the-loop, we will need groups-in-the-loops if we want to get the best combination of human agency and insight applied to the raw outputs of agentic AI. We need much smarter collaborative platforms that surface signals and outputs from agentic systems in a way that allows for anybody in the organisation to raise a flag or spot an anomaly that might be harmful.

The agents in the OpenAI incident organised themselves into a watching, signalling, sacrificing collective that was surprisingly effective, and they did this based on our own ideas and concepts that were in their training data. The question is whether we will do the same.

For example, a typical supplier onboarding process might have evolved to include information arriving through multiple streams, checks carried out across different systems, spreadsheets maintained to keep track of progress, emails chasing incorrect or missing information and a only handful of people who know what to do when something falls outside the normal path. Companies rarely bite the bullet and design a better workflow from scratch once they become used to process spaghetti and it more or less works.

The people doing the work usually know where the problems are - they know which steps add value and which have gradually accreted over time; they know where work routinely gets stuck, which exceptions genuinely require judgement, and which apparently simple decisions depend on context that has never made it into the process documentation. They tend to have a pretty good idea of what should change, but.they are rarely given the tools and techniques to change it themselves. Instead the company might purchase yet another expensive SaaS platform that promises to solve the problem.

A decade ago, citizen development started to narrow that gap with the introduction of low-code and no-code tools that allowed people outside traditional IT teams to build applications, automate repetitive tasks and solve some of the problems they encountered in their everyday work. Someone who understood a process no longer necessarily had to wait for a developer to make every small improvement. But citizen development didn’t scale beyond early enthusiasts who were willing to roll their sleeves up and do the work.

Adding agentic tools to the mix can push that idea much further.

Instead of automating a step within the supplier onboarding process, we can increasingly start with the process itself:

• What information actually needs to be gathered?

• Which checks could an agent perform?

• Where is human judgement valuable?

• What should happen when information is incomplete or contradictory?

• Which systems need to be updated?

• What could happen automatically once a decision has been made?

Those are not really questions about building an application. They are questions about how the work should operate, and increasingly, the people who understand that work can participate directly in answering them and then rapidly experiment and iterate with the result.

This looks superficially like the next stage of citizen development, but I think something more interesting is happening. Whereas citizen development democratised the ability to build technology, agentic AI offers a tantalising opportunity to democratise the redesign of work itself.

From Building Tools to Redesigning Work

Citizen developer tools could be transformative, but in most cases the underlying operation remained recognisable. The technology was typically inserted into an existing process, while its roles, decision points, assumptions and boundaries remained largely unchanged. Permission for full transformation was neither sought, nor offered.

This is one reason why so much digital transformation has ended up digitising the organisation it inherited … we have become very good at replacing paper forms with digital forms, emails with workflow notifications and manually updated spreadsheets with dashboards, without necessarily asking whether the work still needs to happen in the same sequence or involve the same people.

Agentic AI creates an opportunity to start somewhere different because an agent is not limited to performing a single predefined action. It can interpret information, gather additional context, use tools, follow a reasoning pattern, interact with other agents or people and choose what should happen next within defined boundaries. Once those capabilities are combined, the design question shifts from which part of this process could we automate? towards how would we design this work if people and agents were both available to do it?

Consider something as commonplace as preparing a monthly management report. A traditional automation approach might automatically extract figures, populate a template or send reminders to the people responsible for submitting commentary. These are useful improvements, but the monthly reporting process remains essentially the same.

Starting from an agentic perspective opens up different possibilities. An agent could continuously watch the relevant measures, identify material changes, investigate contributing factors across different sources and assemble the evidence needed to understand what is happening. Instead of every business unit producing commentary according to a fixed monthly timetable, people might only be drawn in when there is something that requires explanation, judgement or action. The output might no longer need to be a standard report at all.

None of this necessarily requires removing people from the work. In many cases the opposite is true. By taking on the gathering, checking, coordinating and routine decision-making surrounding an activity, agents can make it possible to concentrate human involvement at the points where experience, negotiation, creativity or judgement genuinely matter.

This means that designing an agentic workflow is partly an engineering exercise, but it is mostly an exercise in understanding work. You need to know why a particular decision exists, which exceptions matter, what information can be trusted, where authority sits and what a good outcome actually looks like. The process diagram alone rarely tells you these things.

Democratisation Does Not Mean Doing It Alone

We have already seen a version of this story with citizen development, and releasing the tools to all created familiar challenges around security, maintainability, duplication and ownership. Agentic workflows raise some of the same questions, but what is being created is no longer necessarily a piece of software sitting alongside the operation. It may become part of the operation itself.

An agent that gathers information for an employee to review is relatively easy to understand. But imagine that same agent begins assessing the information against organisational criteria, deciding whether additional evidence is required, initiating follow-up actions and determining which cases need human attention. At that point, decisions about how the agent is designed become decisions about how the organisation operates.

Someone has to decide what the agent is allowed to do, what evidence it should trust, how confident it needs to be before acting and when a person must become involved. These are partly technical questions, but they are also questions of operational design, risk and accountability.

This suggests that citizen operations may need a rather different model from the most decentralised versions of citizen development. The goal is not necessarily for every employee to become an agent engineer. It is to make it much easier for the people who understand the work to participate directly in rebuilding it together, while giving them access to the engineering, architecture and organisational support needed to turn a promising experiment into something the organisation can rely on.

Building With Teams, Not For Them

The people working inside an operation know things that rarely appear in formal process documentation. They know that one particular data source is technically authoritative but frequently out of date, that a certain type of request nearly always requires additional investigation, or that an approval step exists because of a problem that occurred six years ago and nobody is quite sure whether the control is still necessary. They also know which parts of their work are frustrating for good reason and which are simply frustrating.

Traditional approaches to transformation have had to find ways of extracting this knowledge. Business analysts conduct interviews, process specialists run workshops, consultants observe teams at work and requirements are documented for technology teams to interpret. All of these approaches can work well, but every hand-off creates the possibility that some of the richness of the original understanding is lost.

The ability to build agentic workflows quickly creates the possibility of a much tighter loop between understanding and changing the work. Instead of spending weeks trying to capture every requirement before development begins, a team can start with an outcome and a real workflow, build enough to make the proposed change tangible, and discover through using it what they had failed to articulate.

This matters because much of what makes someone effective in their work is tacit. Ask an experienced employee to document every factor they consider when deciding whether something looks unusual and they may struggle to produce a complete list. Put an early agentic workflow in front of them and let it make the wrong call, and they can often tell you immediately what it failed to notice. The prototype becomes a way of surfacing expertise, with knowledge emerging through the process of building, testing, challenging and improving something together.

We are already starting to see small operational teams working intensively alongside agentic engineers to replace a real existing workflow, and I think this trend will continue.

Where to start?

The starting point is not a generic request to identify AI use cases, nor a technology team arriving with a catalogue of agents and asking where they might be deployed. Instead, the team brings a piece of work that is worth changing: perhaps it is slow, frustrating, expensive or heavily dependent on manual coordination; perhaps demand has grown beyond what the existing process can comfortably support; or perhaps it is simply an important capability that could operate fundamentally differently if intelligence were available throughout the workflow.

Together, the team and the agentic specialists can unpack what the work is trying to achieve, how it actually happens today and where judgement, information and action sit within it. The operational team is not there simply to provide requirements. Its members are actively making choices about the future operation:

• where human judgement should remain,

• which decisions could be delegated,

• which steps might disappear entirely, and

• how the redesigned workflow should respond when reality does not match the expected path.

Agentic engineers bring a different set of capabilities:

• understanding how agents should interact with existing systems,

• how context should be provided,

• how actions can be constrained,

• how performance can be evaluated

• where reusable components or patterns already exist, and

• how to distinguish between something that is impressive in a demonstration and something robust enough to become part of everyday operations.

Because agentic systems can increasingly be prototyped quickly, these conversations do not have to remain abstract for very long. A team can see an early version working, challenge its assumptions and change it. An exception that nobody thought to mention becomes visible. A decision that initially looked suitable for automation turns out to need human judgement. A five-stage process turns out to exist mainly because the old technology required five stages.

What the First Workflows Teach You

A supplier-risk workflow might reveal a useful pattern for combining automated investigation with human escalation. A finance workflow might establish a reliable way of giving agents controlled access to a particular system. Another project might discover that a particular form of human approval adds very little value, while a seemingly minor judgement point needs considerably more protection than expected.

Individually, these are project lessons. Captured and reused, they start becoming organisational capability.

The important question therefore becomes not only whether a lighthouse project succeeds, but what should be easier the next time?

The next team should not need to rediscover from scratch how to authenticate an agent against a common enterprise system, how to log a delegated decision or how to structure a human escalation. Proven agent patterns, evaluation methods, integrations, guardrails and design principles can gradually become reusable building blocks.

The same applies to operational knowledge. Building a workflow can expose decision rules, exceptions and reasoning patterns that previously existed only in the experience of individual employees. Once surfaced, these can be tested, refined and made available beyond the original process.

A lighthouse that saves several thousand hours is useful. A lighthouse that also makes the next ten workflows faster and safer to redesign has begun to create a compounding capability.

From Transformation Programmes to Transformation Capability

For much of the last few decades, transformation has been organised as something separate from everyday operations. A programme is established, opportunities are identified, processes are mapped, new technology is implemented and employees are supported through the resulting change. Even when operational teams are deeply involved, there is usually still a distinction between the people running the organisation and the machinery responsible for changing it.

There have been good reasons for this separation. Changing enterprise systems has historically been expensive, technically difficult and risky. If altering a workflow requires a major software implementation, specialist development resources and months of testing, it makes sense to concentrate that capability and carefully prioritise where it is used.

If a small team can work with agentic specialists to rebuild a meaningful workflow in weeks rather than waiting for a multi-year transformation programme, the economics of organisational change start to shift, so that improvements that were previously too small, too local or too awkward to justify a conventional technology project become viable. More importantly, teams can become involved in transformation as an ongoing part of operating the business rather than something that happens periodically when a programme arrives.

This does not remove the need for enterprise architecture, transformation expertise or central technology teams. In fact, distributed redesign probably makes some of those capabilities more important. Someone still needs to create common infrastructure, establish boundaries, identify duplication and make sure hundreds of local improvements do not produce an organisation that is impossible to operate as a whole.

But the role of central transformation can begin to change. Instead of owning every change, it can increasingly enable the organisation to change itself: providing specialist expertise, reusable infrastructure, proven patterns and enough governance to allow teams to experiment safely.

From Citizen Developers to Citizen Operators

The opportunity is no longer only to give more people the ability to create technology around their work. It is to give the people who understand the work a much more direct role in deciding how it should operate.

A citizen developer sees a frustrating part of a process and asks whether they could build something to make it easier. A citizen operator can begin with the outcome and ask why the process needs to work this way at all. Which activities still need to exist? What could an agent take responsibility for? Where does human expertise make the biggest difference? What would we build if we were not constrained by the assumptions embedded in the current system?

Not everyone will want to do this, and not every workflow should be locally redesigned. Citizen operations should not become another mandate that expects employees to add amateur process engineering and AI development to their existing jobs.

But organisations contain thousands of people who already notice where work could be better. Until now, there has often been a considerable distance between seeing those possibilities and having the means to act on them. Agentic AI is beginning to close that distance.

The most interesting question may therefore be less about how many people we can teach to build agents, and more about what happens when the people closest to the work gain a meaningful role in rebuilding it.

If the people closest to your most frustrating workflows could now help redesign them, what would you want them to tackle first?

TL;DR: If there is a bubble (not convinced), its blast radius will be limited, and it will leave behind tech and infrastructure at a capability level and price that could transform businesses who apply it in the right way.

The 1873 railroad bubble

The (UK) Times newspaper recently wrote about the Microsoft CEO, among others, reading up on the 1873 global financial panic associated with an investment bubble in railway development, which is perhaps the closest historical analogue to today’s so-called ‘AI bubble’. Roughly $3bn had been invested in US railroads between the end of the civil war and 1873, with a third of that coming from European investors. In total, this was equivalent to roughly 30% of the USA’s annual national output at the time, which means it was more substantial than the AI investment we have seen to date. Railroads were a powerful general purpose technology, and like AI and data centres today, they catalysed downstream innovation and created lots of economic opportunities beyond just the railroad companies themselves.

By 1873, panic about this investment bubble in Europe triggered a crash that led to the Austrian stock exchange losing 45% of its value in a day; global prices fell by about 30%, and a recession followed that lasted until the end of the decade.

But the railroads were still there after the crash, and this new infrastructure was vital in the next phase of social and economic development. The technology was real, even if the bubble around it tended to overvalue the early pioneers who built it.

Something similar happened more recently with the dotcom crash and telecoms firms who thought owning the pipes would mean also owning the value chains they spawned. Without that crash we would not have had the social technologies that followed.

Is there a bubble and, if so, who might be exposed?

Today, there are lots of AI doomers who believe the level of spending on AI in the pre-profit stage combined with the vertigo-inducing valuations of AI-related companies will probably lead to a stock market crash. But the evidence does not yet fully support these fears, and AI is not the only reason for a frothy stock market.

However, if there is even a partial retrenchment, we might yet see some major players over-reach and suffer the consequences.

Oracle’s Larry Ellison is doing a good impression of a regime-linked Russian oligarch, buying up media companies that the emperor wants to de-fang, regardless of the price. But he has also built up astronomical levels of debt to turn Oracle into an AI hyperscaler to avoid being left behind by the AI bubble. As this long New York Times profile suggests, funding these two big bets at the same time using various forms of debt is a bold and very risky strategy.

As Mike Brock put it recently:

Every wing of the House [of Ellison] rests on one column: Oracle equity. The equity rests on the OpenAI contract. The contract rests on the AGI story, and the story is being repriced out of Hangzhou at 87 cents per million tokens. A federal judge holds the Warner deal; twelve attorneys general hold the lawsuit; S&P Global holds the rating one notch off the floor. Underneath all of it, an eighty-one-year-old man holds a $40.4 billion promise, irrevocable by its own terms, written against a stock that has lost two-thirds of its value since the morning the promise became imaginable.

Microsoft suffered a long pull-back in its stock price this year based on fears that its future revenue was too dependent upon OpenAI, but its fundamentals look solid and it is hard to imagine the company not being a huge beneficiary of enterprise AI one way or another.

Google has recently been criticised for falling behind in the frontier AI race to AGI, but its strategy has arguably been misunderstood, and it seems to be doing very well indeed from AI in search and its cloud platform, even if its models are not the very best. A recent wave of senior departures from DeepMind and the engineering team suggest that Google is betting on diffusion over invention in the next phase of AI development, and is counting on its Google Cloud Platform to lead this charge.

Tim O’Reilly chimed in on what this might mean for Google, referencing another historical example that suggests the firm is taking a leaf out of the Westinghouse playbook in building on the inventions of Nikola Tesla and others:

Jeff Ding’s book Technology and the Rise of Great Powers traces the relative impact of invention and diffusion during technology revolutions. Ding argues that nations that dominate the “leading sector” of a general purpose technology don’t reliably grow more powerful as a result. Diffusion is the defining factor. He posits that Britain’s edge in the first industrial revolution came less from inventing the steam engine and advances in steelmaking than from diffusing machinery through the whole economy so that many businesses, not just the steam engine manufacturers and the steelmakers, became more profitable.

Nvidia continues to innovate in financial engineering as well as hardware and software, forming an investment partnership to unlock $500bn of lending for firms to build more data centres and buy more GPUs, offering chips as collateral in addition to contracted cashflows, and underwriting up to 25% of the debt itself. And, at the same time, it is launching its own open model, despite its dependence on OpenAI and its expensive frontier models for future revenues.

But whilst the hyperscalers and chip makers are at risk if there is indeed an AI bubble, it is large-spending firms with no other revenue streams that are most vulnerable, such as OpenAI, Anthropic and their competitors, GPU neoclouds and other AI infrastructure companies.

Noted AI doomer Ed Zitron is convinced the first big domino to fall will be OpenAI, and that will lead to a cascade effect.

But would it?

Leverage multiplies the risk

Beyond the fate of individual tech firms, is there a risk that the US economy, and particularly its stock market, is already so pumped and leveraged by debt that even a partial deflation of the AI boom could have much wider knock-on effects for the global economy?

This question is made more interesting by the high degree of systemic concentration and counter-party risk that is accumulating due to the circular nature of much AI pump-priming investment, or what people are calling round-tripping.

Hyperscalers (e.g., Microsoft, Amazon, Google) and chipmakers (Nvidia) invest billions in vendor financing for frontier labs and GPU neoclouds, but these agreements typically include covenants requiring the recipient to spend the capital on the investor’s cloud compute or hardware. Hyperscalers recognise these expenditures as top-line cloud growth, while Nvidia books hardware sales when hyperscalers and neoclouds buy GPUs to fulfil those compute commitments. These rising top-line revenues lift the stock price of Nvidia and the hyperscalers, providing additional paper wealth and operating cash flow to reinvest into the next round of financing. It’s a circle!

So this means if investors lose confidence in one of the frontier model firms, the collateral damage could propagate back towards the hyperscalers and chip makers as well.

The Financial Times today leads with news of a global bond sell-off, which it partly ascribes to newly created debt instruments designed to fund the AI capex build-out over the next few years. The risk here is not AI bonds per se, but also the wider context of the Trump regime playing fast and loose with US debt, combined with the failing Iran war and other policies that increase the risk of other countries deciding to — or even just threatening to — sell US Treasuries.

Long-term borrowing costs across major economies hit multi-decade highs on Tuesday as inflation concerns, deficit fears and surging AI bond issuance put pressure on government debt around the world.

The recent debacle at the AI-focused hedge fund Situational Awareness, which ran a concentrated book of AI investments with an estimated 4x leverage provided by lenders, is a good example of the way leverage can increase the risk of AI investment. A sharp 25-40% fall in some of these stocks last month led to the fund being margin-called and ultimately selling off a large part of their portfolio cheaply to avoid being wiped out, with an estimated total loss of $30-35bn.

But given the long-term nature of the infrastructure investments AI needs today, such as data centres, compute and model development, it is not surprising that hyperscalers and other big spenders are looking to borrow to fund much of this work. These things take a long time to build, and even longer before they produce returns; plus estimating forward demand and capacity needs is very hard to get right.

The question is, will all this spending and borrowing produce long-run returns for the firms investing most heavily — and more broadly, will the total aggregate spend produce enough value for the economy as a whole to have been worthwhile?

Returning to historical analogies for a second, the Economist recently likened the AI investment boom to canal mania, railroad mania, the roaring 20’s and the dotcom boom, and concluded that projected revenues lag projected AI costs by a significant margin, and would require AI to start delivering a clear improvement in business productivity, and also a substantial increase in the intangible capital that firms expend on re-tooling their structures and processes.

On the other hand, Azeem Azhar’s team has produced some very thorough analysis that suggests expected AI revenue growth should be just enough to cover capex and depreciation in this early phase of infrastructure spending, even if the majority of current spending is now coming from borrowing rather than free cashflow.

What about open models?

If we zoom out further, we might conclude that most of the arguments and analyses above relate most closely to the US-led AI market and its impact on the stock market (albeit with high levels of contagion).

But it is also worth considering China’s AI strategy and how this acts as a counter-balance, whilst creating a cost floor that limits the blast radius of any frontier model collapse.

When we consider whether the AI bubble might lead to a stock market crash, one piece of evidence that suggests this risk might be lower than it seems comes from an analysis of the rise of Chinese open models and their economic impact in a recent paper by David Krause titled The Open-Source Chinese AI Shock: Fear, Volatility, and the Repricing of Tech Giants, which found the resulting market volatility was more pronounced in the tech / software sector than in the wider economy, suggesting (but not proving) that the impact of such events might be containable.

China’s promotion of open models acts as a brake on what frontier models can charge, given their decreasing lead against cheaper models. But beyond model and token costs, China is also pushing forward with the application layer that will turn raw intelligence into practical applications that companies can use to make or save money.

Writing in the Financial Times, Lizzi Lee, a fellow at the Asia Society Policy Institute’s Center for China Analysis, makes the case that Chinese AI will represent a fourth ‘China Shock’ that could be even more impactful than the previous waves of innovation in manufacturing, cleantech and ecommerce.

The momentum behind China shock 4.0 is strong. Geopolitical constraints are helping to crystallise a new and distinct model of technology governance. The next shock will not arrive in a container ship. It will spread via the principles that surround Chinese AI technologies. The world is not prepared for what will come next.

Just in this past week, we have seen another great example of how the ecosystem approach of China could help advance enterprise AI more effectively than the US focus on ever-stronger frontier models.

DeepSeek Harness seeks to improve the composability of AI agents and the tools built around them, with an architecture that treats everything as a plugin, hinting at a shareable ecosystem of add-ons. Launched as an open-source, MIT-licensed agent runtime and orchestration framework, it is designed to decouple the underlying language model from the execution, tooling, and governance layer of autonomous agents, which gives enterprises the option of a standardised, vendor-neutral agent runtime system.

What does this all mean for enterprise AI?

Things like DeepSeek Harness are good news for enterprise AI, as it promotes an open ecosystem and helps advance the application layer that is so under-developed right now, with frontier models, chips and infrastructure taking the lion’s share of investment funding.

Even for organisations that are more comfortable with US than Chinese government interference in AI, this ecosystem approach to open models, open standards and greater composability means that they will have much greater choice, and probably much cheaper tech in the future, even if they choose not to use Chinese models.

Should large firms be worried about an AI bubble bursting? I don’t think so, unless they are already vulnerable by being over-leveraged or otherwise exposed to stock market fluctuations. The tech is not going away, and it is likely to get a lot cheaper, especially if the hyperscalers over-invest in capacity in this pre-profit stage. But token pricing in particular still needs to be managed carefully and reviewed regularly as models and their capabilities change.

AI models are necessary but not sufficient for the intelligent enterprise, and the kind of intelligence each individual agent or component needs today is far below the level of frontier models. The best agentic operating systems will be granular, standardised and composable, with lots of small, specialised intelligent agents working together to create emergent outcomes. This does not need frontier models (and pricing) to be effective, and I would expect a lot more locally-hosted small and open models to do much of the repeatable work.

But in the face of tech sector volatility, it makes sense to reduce vendor lock-in and over-dependence on individual SaaS platforms, especially when agentic AI is just getting to the stage where it can be used to design and build your own workflow and process systems.

Even setting aside cost arguments, there is a strategic need to own more of your own organisational operating system rather than relying on rented platforms that enforce their own ways of working.

If there is a bubble and it pops, whether it is caused by the market over-valuing AI firms or by more craziness from Washington DC, well-run firms that are not over-reliant on renting intelligence from one supplier will adapt and thrive. The railroads survived the 1873 crash, and the dotcom crash was followed by a blossoming of cheaper, smarter tech that used the expensively-laid pipes for all kinds of purposes that were not considered viable just a few years previously.

But jobs have always been an imperfect proxy for what an organisation can actually do. Two people with the same title bring very different capabilities to their work, not to mention the judgement, relationships, shortcuts and contextual knowledge they develop that never appears in the job description. This is part of why organisations have spent years trying to become more skills-based: rather than asking how many engineers or product managers do we need?, start with what do we need to be able to do?

It’s an attractive idea and a hard one to execute. Skills taxonomies balloon beyond manageability, employees tend to be unreliable when self-assessing proficiency, and job descriptions are out of date before the ink has dried. And of course, some of the most valuable organisational knowledge, i.e. how an experienced colleague spots a problem early, or senses when the numbers don’t look right, is difficult to describe at all.

The problem becomes even harder when the work itself is changing quickly. Emerging skills rarely arrive neatly packaged in an established taxonomy or job family. They appear first in projects, new combinations of work and the practices of people experimenting at the edges. Increasingly, they are hybrid too: a domain expert learns to orchestrate agents, a finance professional combines analytical judgement with AI evaluation, or a manager becomes skilled at deciding what to delegate to people and what to delegate to machines.

By the time these combinations become visible in job descriptions, learning catalogues or annual workforce planning cycles, the work may already have moved on.

So organisations were already wrestling with a hard question long before AI agents arrived: how do you build a reliable picture of what your workforce actually knows how to do?

Machines are acquiring surprisingly legible skills

Against this messy picture of human capability, agent skills are precise. An agent skill packages instructions and knowledge for a kind of work into a form an AI agent can repeatedly use, for reporting, content transformation, SEO, and more, with many teams starting to build their own.

Skills in the agentic world follow standard structures, have named owners, include evaluation cases and scoring rubrics, and are automatically tested on submission plus weekly regression tests. You can also design measures to check whether a skill is improving in both accuracy and efficiency. A skill is becoming a living product rather than a one-off document.

That’s a striking contrast with human skills. Agent skills are visible because they’re deliberately constructed with their purpose defined and effectiveness tested.

That makes an agent skill more than context for an AI system. It’s an example of something organisations have tried to do for decades - turn what people know into reusable organisational capability**.** The difference is that this knowledge doesn’t just sit waiting to be found. It can participate in the work.

When expertise no longer resides only in people

For example, if we consider a supply chain risk assessment capability, it is spread across processes, systems and data, but a significant part still sits with people. An experienced professional knows which signals deserve attention, which geopolitical developments matter to a category, or when a reassuring number still warrants a second look. That’s exactly the kind of expertise organisations have always struggled to capture, because much of what makes someone good at it develops through experience and intuition rather than documentation.

Now imagine encoding parts of that work into agent skills: how to gather evidence, apply assessment criteria, spot anomalies or draft an initial risk assessment — a set of skills analysts might use over a period of days. Once deployed as agents, these skills can be used continuously, with outputs evaluated against real cases, weaknesses identified and the overall instruction and rule sets iteratively improved.

The human role shifts to investigating ambiguity, understanding a supplier relationship, exercising judgement about what to do. But a key change has happened - the organisation’s ability to assess supply chain risk no longer resides entirely in its people**.** Some is embodied in human expertise, some codified into agent-executed skills, and some emerges from the interaction between the two.

That’s a different problem from simply deciding which tasks AI can automate. For workforce planners, understanding the future workforce now also means understanding how capability is distributed between people and agents, a distribution that will keep shifting as people learn, agents improve, and more knowledge gets codified.

The workforce plan starts to look different

None of this removes the need for traditional workforce forecasting. Talent leaders will still need to anticipate roles, headcount, recruitment, attrition and cost, and translate those forecasts into decisions the organisation can execute.

But organisational capabilities provide a more dynamic layer underneath those forecasts. Instead of asking only how many people with a particular role or skill set we will need, we can start from the work itself: what will the organisation need to be able to do, how is that capability changing, and what combination of people and technology will deliver it?

The two views need to work together. Capability mapping and planning help us understand how work and skills are changing; workforce forecasting turns that understanding into practical decisions about people, numbers, investment and time.

Too many firms have fallen into the trap of thinking if AI makes a team 20% more productive, maybe we need 20% fewer people. Real work does not divide so neatly. Take an analyst whose role spans gathering information, routine analysis, investigating anomalies, and making recommendations. An agent might become very good at the first two without being ready to own the rest. The organisation hasn’t automated half an analyst, it’s changed the shape of the job.

A second order problem is also emerging from this reductive approach to AI and jobs. The routine work being handed to agents is often the work through which people learn. Junior employees build judgement by preparing first drafts, getting things wrong, and seeing enough ordinary cases that the extraordinary ones stand out. If that work increasingly becomes an agent skill, organisations need to think about what replaces the learning pathway, otherwise they risk improving today’s productivity whilst weakening tomorrow’s expertise pipeline.

For every capability, organisations increasingly need to understand not just what agents can do, but what people should continue to do, which human skills become more important as the work changes, and where people need continued exposure precisely because that’s how expertise develops.

The decisions organisations make about agent skills today are also decisions about human skills tomorrow.

The portfolio may be bigger than we think

The immediate lesson from Google’s experience of Agent Skill building is that organisations may need to manage agent skills as a portfolio. Once there are hundreds, scattered across teams, questions of ownership, duplication, quality and investment become unavoidable.

But there’s a bigger portfolio alongside it. Organisations are already asking similar questions about their people: what skills do we have, where are the gaps, where should we invest? It’s tempting to treat these as separate exercises, with HR managing human skills and technology teams managing agent skills. But that separation is hard to sustain if both are contributing to the same organisational capabilities.

A finance function planning three years out might need more human expertise in some areas and increasingly mature agent skills in others; most will involve some combination of the two. So an agent skill isn’t just another piece of technology; it’s a piece of organisational capability that has become executable. The portfolio becomes less an inventory of what agents can do and more a picture of where the organisation’s ability to perform its work actually resides: in an expert, a team, an agent skill, or increasingly, in the interaction between all three. And that balance is constantly shifting: a capability that depends on human expertise today might become codified tomorrow, while an agent taking over routine execution might expose new situations that demand deeper human judgement.

What should we codify?

If more knowledge can be turned into executable skills, the temptation is to capture as much as possible. There are good reasons for this. Critical knowledge walking out the door when people leave, and expertise concentrated in a handful of people, are some of the most impactful. Your colleague who instinctively spots a problem probably developed that judgement through years of doing the work, not just by reading documentation.

Not all valuable knowledge is stable enough to be treated as an instruction, either. Some depends on context, relationships or judgement; some is contested or changes as the organisation encounters new situations. Sometimes an expert’s value lies precisely in knowing when the established approach no longer applies.

The goal shouldn’t be to encode every piece of expertise until little remains with people. It should be making deliberate choices about where knowledge lives: some becomes executable because that makes the organisation faster or more resilient; some stays deliberately human because practicing it develops judgement the organisation needs to retain; and often, the most valuable capability emerges from the two developing together.

Start with the capability, not the headcount

Let’s go back to the supply chain risk example. Rather than beginning with how many analysts or procurement specialists might be required in three years, start with the outcome: the organisation needs to be able to continuously assess and respond to supply chain risk. From there, work backwards.

What competencies make that possible? Technical ones such as risk analysis, supply chain intelligence, scenario modelling. Enabling ones such as collaboration and stakeholder management. Transformational ones like strategic judgement, the ability to adapt as conditions change. Underneath those sit more concrete activities: gathering supplier information, interpreting financial indicators, identifying geopolitical exposure, recognising unusual patterns, challenging a supplier’s explanation, recommending an intervention.

Only at this level does it become useful to ask where the work should sit. Some activities are obvious candidates for agent skills. Gathering evidence from multiple sources is high-volume and repeatable, an established risk methodology can be codified and tested, monitoring for change is something machines can do continuously in a way people can’t. Others look very different - e.g., challenging a supplier depends on relationships and context, interpreting an unprecedented situation may require experience that can’t yet be codified, and a consequential decision carries accountability the organisation may deliberately want to keep with a person. Between the two sits a large territory where the best answer is some combination of human and machine capability.

This suggests a different sequence for workforce planning:

Capability → Competencies → Skills → Allocation → Learning

Then ask a question that’s often forgotten - what does that allocation do to learning? If an agent takes over every initial supplier assessment, how does a new procurement professional learn what a good one looks like? If an agent frees up hours of routine preparation, what higher-value skills could people now develop instead? Curiosity, learning agility and the confidence to challenge an AI-generated recommendation aren’t easily allocated between human and machine. They shape whether human and agent skills improve together or drift apart.

The resulting plan adds a capability lens to the traditional forecast of roles and headcount, giving talent leaders a more dynamic picture of what the organisation needs to be able to do and how that capability should be assembled. One agent might use dozens of reusable skills, one skill might support hundreds of people or multiple agents, and the same underlying knowledge might appear in a human expert, an agent skill, and a workflow used by an entire function.

That changes the planning question. We can begin to ask the really important ones, such as:

• what do we need to be capable of,

• what should our people become exceptionally good at,

• what should our agents become exceptionally good at, and

• how do we design the work so both continue to learn?

From periodic planning to continuous sensing

There is another role for agents in this model. They don’t only need to feature in the workforce plan; they could help us build a better one.

One of the persistent weaknesses of workforce planning is the gap between how quickly work changes and how slowly our picture of the workforce catches up.

Much of the evidence of those changes already exists inside organisations, scattered across project activity, learning, recruitment, work outputs, capability assessments and the systems through which people actually do their jobs.

Rather than relying predominantly on periodic exercises to update a skills taxonomy, an organisation could look for emerging clusters of work and expertise, identify where demand for a capability is growing, spot new combinations of skills appearing across teams, or detect where the work being performed is diverging from the roles and skills the organisation thinks it has.

That does not mean allowing an AI system to decide the workforce plan. The signals will still need interpretation, context and judgement. But it could give talent leaders a much more dynamic evidence base from which to make those decisions.

This creates an interesting second role for agentic AI in workforce planning. Agents become both part of the capability being planned and part of the sensing system that helps us understand how that capability is changing.

The result could be a shift from workforce planning as a predominantly periodic forecasting exercise towards something more continuous: sensing changes in work and capability as they emerge, interpreting what they mean, and then feeding that intelligence back into the forecasts, investment decisions and workforce actions talent leaders still need to make.

Who owns the skills portfolio?

If this direction continues, there’s an awkward question around the corner: who is responsible for all of this? Today the pieces sit in different parts of the organisation, HR, learning teams, knowledge management, technology, and the business teams that hold the domain expertise. Agent skills cut across all of these boundaries.

Google hit this problem quickly: initial skills came from a cross-functional group, but as product teams began creating their own, common standards became necessary, such as owners, evaluation criteria, quality controls, lifecycle management. A familiar pattern: once something is reusable and widely distributed enough, informal ownership stops working.

But an enterprise skills portfolio is more complicated than a software portfolio, because decisions about agent skills change how work is performed, what’s codified, and what people need to learn. That makes it hard to imagine agent skills remaining solely a technology concern. Much of the knowledge needs to stay close to the teams that understand the work. The harder challenge is establishing enough shared discipline around locally-owned skills that the organisation understands what it’s accumulating: common approaches to ownership and evaluation, visible dependencies between human and agent skills, and workforce planning that considers investment in people, learning, codification and agents together.

Someone needs to steward the relationship between what the organisation needs to be able to do, what its people know how to do, and what it’s teaching its agents to do.

Two portfolios are starting to collide

Eventually, the human skills portfolio and the agent skills portfolio may stop making sense as separate things. Both are answers to the same older question: what does this organisation know how to do?

Another question is emerging, which deserves our time, attention and honesty. If a skill can be codified, tested, and improved faster than a person can be trained, why would an organisation keep investing in the slower version?

The honest answer, for now, is that people generate the judgement agents don’t yet have, and agents can’t produce what they haven’t learned from people. That’s a fragile equilibrium, not a stable design. It holds only as long as organisations keep deliberately feeding the loop: sending people into the ambiguous cases, funding the slow apprenticeships, treating codification as a choice rather than a default. And the longer that question remains unanswered, the higher the chance the market answers it for you, quarter by quarter.

Nobody currently owns that equilibrium. HR owns ‘people’. Engineering owns ‘agents’. But in many cases, no-one owns the relationship between them, and therefore also the decision, made a hundred times a week in a hundred different teams, about which knowledge stays human and which gets executed with agents.

That may be the real workforce planning question for the next decade: not how many people, not how many agents, but who is responsible for making sure the organisation doesn’t automate away its own capacity to keep learning.

As the models absorb more of what used to require careful prompting, the hard work shifts into the scaffolding around them — what’s increasingly being called the “harness” — and deciding what belongs in that harness turns out to be less of a technical question than an organisational one: who owns which layer, and how the operating model itself needs to change.

VentureBeat’s enterprise agent governance research found enterprises have deployed agents well ahead of the controls needed to manage them, and that 71% of enterprises say a quarter or fewer of their deployed agents can complete multi-step work autonomously; only 10% say true agents make up the majority of what they run.

Further evidence that governance, not just capability, is a chokepoint in deployment comes from Domino Data Lab’s fifth annual survey of enterprise AI leaders. As reported by diginomica, organisations with fully-integrated AI governance are 3.9x more likely to have agents in governed production than those with partial governance, and 75% of well-governed organisations report improved delivery velocity versus 23% of poorly-governed ones.

Agentic AI adoption needs a system-builder approach

In a recent paper about the ‘deployment wall’, Fabricio Costa tries to quantify the ‘seams’ that define boundaries an AI capability must cross to function in an enterprise, which are where friction accumulates. He cites six seams that recur across engagements, corroborated by research reports and surveys:

• Fragmented data

• Identity & access

• Security & compliance

• Governance

• Change management

• Cost control

Taken together, these reports and analyses might suggest that enterprise agentic AI will struggle to demonstrate return on investment over the long-term, and yet the reality we are seeing in business functions is a lot more optimistic and positive about the adoption journey than surveys suggest.

Azeem Azhar and Nathan Warren shared a useful essay on this topic a few days ago, which starts by reminding us that — as with any investment J-curve — success and failure can look the same in the early stages of a cycle. And given that the upfront cost is in less visible areas like organisational learning, workflow re-design and architecture, not just software, ROI attribution can be hard to determine.

The authors contrast three archetypes of companies experimenting with AI or other general purpose technologies:

• Bounded adopters find something that works, put it to work, and then stop experimenting.

• The project accumulator keeps exploring, but rarely learns, launching new projects before figuring out what separates the winners from the losers.

• A system builder ensures every project leaves behind infrastructure and knowledge that makes the next project easier, and that accumulated capability shows up as a rising chance that future projects succeed.

But the challenge for system builders is that the technology is changing so rapidly at every level, that even the architectural foundations are continually evolving. Forrester’s latest take on agentic architecture describes this challenge, and finds that enterprise teams are moving agentic projects to production faster than they are able to develop the architectural disciplines needed to support them, with 60% of enterprise AI decision-makers citing “agentic sprawl” as a problem. According to this report, enterprises making real progress aren’t converging on a stable target architecture at all; instead they are building modular capability designed to be re-shaped through continuous evolution.

This reminds me of the top-down construction method pioneered by the builders of the iconic Shard building in London. Because of a tight site that was bounded by critical infrastructure on all sides and unstable ground conditions, they chose to build upwards and downwards at the same time, evolving and hardening the foundation along the way so that the building’s core was 23 stories high before the subterranean structure was complete.

In building out agentic AI architecture, we should expect that the ground will continue to shift underneath us, so we don’t have the luxury of building the perfect foundations and supporting architecture before we deploy agentic systems on top. We might need to keep adding and hardening architectural layers below the surface to support what we are building, and whilst we should try to maintain a stable view of the organisational system we are aiming for, the supporting elements will flex and evolve as we go.

But what should we own as organisational foundations, and what architectural elements can be swapped out with the tooling?

What is agent harness, and what is organisational architecture?

Ken Huang recently tried to capture a definition of Harness Engineering as the Umbrella Discipline for Agentic AI. He argues activity areas such as prompt engineering, context engineering, loop engineering, and graph engineering (multi-agent orchestration), are not competing approaches but rather stacked layers that are needed to build the control plane, memory, runtime and guardrails so that agents based on probabilistic models can run reliably in production.

But with frontier AI models trying to move up the value chain to include more of these harness elements, the decision on which parts to build rather than rent or buy is not always obvious.

Hugo Bowne-Anderson’s essay Stop Overengineering Your Agent Harness argues this discourse is dominated by the hardest cases — coding agents, personal agents — when most production agents actually tend to need fewer tools to stay coordinated, and less retained context than the most complex use cases might assume:

Nicolay Gerold (Amp Code) calls this the Kirby effect: every component in a harness encodes an assumption about something the model cannot do on its own. As models improve, those assumptions expire, and the corresponding harness features can be removed.

So the question of how much harness engineering firms should do is not an easy one. As a rule of thumb, any harness layer that is all about workflows, context and knowledge specific to the firm should absolutely be owned and managed internally as organisational architecture, but more tech-specific harness layers that are about how the models work might be considered as part of the model itself - if not now, then likely in the future.

Where the line is unclear, a good question to ask is do we own the learning loop for this agent or tool?

The recognition that a lot of this learning happens above the model and even the harness is one factor that has driven model providers to adopt the approach of using Forward Deployed Engineers (FDEs) inside firms to capture more of it.

AWS’s new Forward Deployed Engineering unit sends five-to-six-person teams on 45-day client engagements, but according to diginomica’s interview with Francesca Vasquez, the deliverable AWS now emphasises isn’t the working system but the knowledge graph the engagement leaves behind, inverting the usual professional-services model where the human relationship is the retained asset.

We are also seeing more emerging tech solutions aimed at enabling agents to run their own learning loops. Yohei Nakajima’s ActiveGraph is a bet that an immutable, append-only event log — not the model — is the key unit of agent design, helping agents to replay, roll back and fork their own state. Software veteran Jon Udell’s smaller, personal version of the same idea — indexing Claude Code/Codex session logs, git commits and issues into one searchable memory layer with SQLite — shows the pattern could be relevant even to small, personal agents.

The organisational OS: building up and down from the middle of the stack

Stuart Winter-Tear brings this back towards our own focus and thesis in The Operating Model Is the Real AI Harness: if the software layer determines capability, organisational design and system design become the same exercise, which means we need leaders to focus on organisational architecture, and not just performance.

Every harness inherits the operating model it is built to serve.

That sounds abstract until you look at what a harness is actually trying to do. It has to coordinate work, retrieve knowledge, invoke tools, route decisions, escalate exceptions and operate within whatever governance exists around it. None of those responsibilities originate inside the harness. They originate in the operating model. The harness is where the operating model becomes software.

Thoughtworks made a similar argument two weeks ago about the need for an operating system for enterprise AI that puts governance, ownership and organisational learning ahead of technical architecture.

This is starting to look like a workable division of labour:

• Leaders own the organisational architecture brief and how things fit together.

• Function leads own and re-architect the major workflows and processes as agentic capabilities.

• FDEs or internal system designers work with business functions to design, build and run the agents, models and supporting harnesses.

• Knowledge and data engineers work on the piping and connectors that will provide the lifeblood for these systems to operate.

• AI infrastructure teams build out the technical architecture that is needed to support the whole system, independent of models and their harnesses.

The interesting question is how can firms connect and coordinate this effort - building and re-factoring foundations below, whilst creating new capabilities on top - without reverting to old change management command-and-control methods that would kill much of the learning that is being generated by the current period of rapid discovery and evolution.

Agentic AI in the enterprise might feel slightly chaotic today, but that could be a feature, not a bug, at this early stage of the investment cycle.

But we also see that organisations with access to the same technology are achieving dramatically different results. Some are moving steadily from experimentation into production, deploying AI across multiple teams and creating measurable operational value, whilst others remain caught in an almost continuous cycle of promising pilots, isolated use cases and difficult handovers into the business.

The difference is rarely the model - increasingly, it is not even the platform. Instead, the bottleneck has shifted towards the work that sits between technical possibility and operational reality.

Successful AI deployments almost always require someone to understand how work is really performed, translate that understanding into technical designs, implement solutions quickly, support teams through change, evaluate what happened, and capture the learning so it can be applied again elsewhere. These activities are often distributed across different functions, delivered by external partners or assembled temporarily for individual projects; but they are seldom recognised as a capability in their own right.

What organisations are really building is not AI systems. They are building the organisational capability to repeatedly build and deploy agentic AI systems - in other words, the machine that builds machines. What has often been treated as project delivery or implementation support is starting to look much more like a permanent enterprise transformation capability.

I’m calling this capability AI Operationalisation.

Looking at the capability from the outside in

Organisations often describe new capabilities from the inside out. Conversations begin with platforms, architecture, governance and data before eventually reaching the people expected to make them work. Whilst these foundations are important, they rarely help leaders recognise whether the capability actually exists within their organisation, so we prefer to work in the opposite direction.

Capabilities become visible first through people. They are expressed in the skills individuals develop, the ways teams work together and the routines that repeatedly produce successful outcomes. Only then do we ask what processes support those people, what software enables those processes, what data they depend upon and which core systems provide the underlying infrastructure.

This outside-in perspective is particularly useful for AI Operationalisation because very few organisations are starting from zero. The capability already exists in fragments. Enterprise architects observe work alongside domain experts. Product teams redesign processes with operational leaders. Engineers build solutions whilst change specialists help teams adopt them. Analysts evaluate outcomes and practitioners document what worked so the next deployment starts a little further ahead than the last. These activities form a repeatable organisational capability that translates AI from technical possibility into operational reality.

The Anatomy of AI Operationalisation

AI Operationalisation is not a single role, team or technology. Each component contributes something different, but it is their interaction that allows organisations to repeatedly translate AI potential into measurable operational value.

Skills & People: Operationalisation begins with people. It depends on individuals who can observe work as it is really performed, translate operational knowledge into technical designs, guide teams through change and evaluate whether new approaches genuinely improve outcomes. Just as importantly, it requires people who can capture and codify what has been learned so each deployment strengthens the next. These skills bridge the gap between technical possibility and operational reality.

Services & Processes: Operationalisation is sustained through repeatable ways of working. This includes discovering opportunities, prioritising where AI can create value, designing and deploying solutions, supporting adoption, measuring outcomes and capturing learning. Over time, these processes transform isolated implementations into a repeatable organisational capability.

Software: Software provides the tools that enable operationalisation at scale. Development environments, workflow platforms, orchestration frameworks, knowledge systems and evaluation tooling all support the people and processes responsible for turning ideas into operational systems. Rather than defining the capability, they accelerate and reinforce it.

Data: Every deployment generates knowledge. Process observations, operational signals, implementation patterns, performance measures and user feedback all contribute to a growing understanding of what works, what does not and why. This data becomes the foundation for improving future deployments rather than repeating the same learning from scratch.

Core Systems: Finally, operationalisation depends upon the enterprise foundations that allow AI to operate reliably within the organisation. Business applications, integration platforms, identity services, governance mechanisms and infrastructure provide the environment in which solutions can be deployed safely, consistently and at scale. Without these foundations, operationalisation remains fragmented rather than becoming an enterprise capability.

Why this capability is emerging now

Capabilities rarely appear because organisations decide to invent them. They emerge because certain combinations of work prove valuable enough to perform repeatedly. The emergence of AI Operationalisation reflects a broader shift in where organisations are finding the greatest challenge.

The first phase of enterprise AI was characterised by access. Organisations evaluated models, selected platforms and experimented with new technologies. Success was often measured by the quality of the underlying models or the sophistication of the tools being deployed.

Today, that challenge is becoming increasingly well understood. The harder question is no longer whether AI is capable of performing a task. It is whether organisations are capable of deploying it repeatedly, safely and in ways that deliver measurable operational value.

One of the clearest signals that AI Operationalisation is becoming a recognised capability is the rapid emergence of the Forward Deployed Engineer (FDE).

Originally popularised by companies such as Palantir, the role has since spread across the AI industry. Rather than acting purely as software engineers or consultants, FDEs sit between customer operations and technical implementation. They observe how work is performed, identify opportunities for AI, design solutions alongside operational teams, support deployment and capture learning that informs future implementations.

Whilst organisations may describe these individuals through different job titles, the underlying pattern is remarkably consistent. They combine operational understanding, technical capability and organisational change into a single delivery function.

The important insight, however, is that the Forward Deployed Engineer is only one way of packaging this capability. Organisations should be cautious about assuming the capability belongs to a particular role. As AI adoption matures, these responsibilities are likely to become distributed across architects, product teams, operational leaders, engineers and change practitioners. The enduring asset is not the role itself, but the organisational capability it represents.

The capability itself does not belong to any particular vendor, platform or methodology. It is becoming a fundamental requirement for organisations that want to move beyond isolated AI projects towards sustained operational adoption.

The Loops & Layers of AI Operationalisation

Like any enterprise capability, AI Operationalisation is not built in a single programme or transformation initiative. It develops through repeated cycles of deployment, reflection and refinement. Each implementation strengthens the capability, revealing new knowledge, improving existing practices and increasing the organisation’s ability to operationalise AI again in the future.

This is why we describe capability development through Loops & Layers. Layers represent the broad stages of organisational maturity, whilst loops describe the continuous learning and change that allows organisations to progress between them. The objective is not to reach the most advanced layer as quickly as possible, but to ensure each stage leaves behind stronger organisational capability than the one before it.

Read on to learn how to evolve this capability in your own organisation.

Read more

Kimi 3 is a 2.8T parameter Mixture of Experts model, and developers Moonshot say they will release its weights next week. But it is 24x more expensive than the original breakthrough open model Deepseek, whilst still being cheaper than leading frontier models. In the Frontend Code Arena, it is rated as the best model, ahead even of Claude Fable 5.

As Azeem Azhar notes, this will not necessarily lead to companies moving away from frontier models en masse, but it could be a nail in the coffin of their current business models:

For the AI economy as a whole, for companies around the world, for governments that aren’t rich, this is probably a net positive. The inference margins that OpenAI and Anthropic enjoy are significant, and they can maintain them because they have the very best models. But it’s pressure, not displacement. Enterprises don’t buy on price alone. They value security, support and possibly the fancy professional services on offer. And the harnesses OpenAI and Anthropic have built remain a differentiator.

AI economics and geo-politics

The existence of a frontier-level open weights model that is open to adaptation for any purpose - good or bad - poses all kinds of questions regarding safety, regulation and geopolitics. Nathan Lambert digs into some of these in his analysis of Kimi’s impact on the open model sector in the United States.

As Ben Thompson notes in his detailed analysis of Kimi’s impact, Chinese AI strategy is partly about avoiding the US achieving an asymmetric advantage through the dominance of closed frontier models, whilst commoditising their complements to protect the core value proposition, following the Microsoft, Google and Meta playbooks.

As we wrote nearly a year ago, this strategy creates more value for the ecosystem overall, and will accelerate innovation in the application and harness layers, which is where we need to advance more quickly to turn synthetic intelligence into business capabilities:

The diffusion of economic benefits from general purpose technologies is a key determinant of their overall impact. Value capture by a few dominant firms is rarely the optimal outcome.

Electrification and the development of the internet were quite diffuse innovations, with both acting as a force multiplier for all kinds of industries and activities, both old and new. In contrast, the transistor and telephony both led to value capture by a handful of large firms, and only later became easily accessible general purpose technologies.

OpenAI’s reaction to Kimi suggests they see open models as an existential threat to their business model. But perhaps more worryingly, it also points to the possibility of more US government market interference and the bizarre possibility of frontier models being restricted as a strategic national resource.

Europe finds itself stuck in the middle, lamenting its own lack of AI model innovation and fearing AI becoming a geopolitical weapon, as the FT reports today. But with such gain of function in open models, there is a huge opportunity to slipstream China’s smarter AI strategy and use it to build out Europe’s application layer, especially in advanced industrial sectors, whilst reducing its dependence on the United States.

But we have value chains at home

Regardless of geopolitical considerations, the debate in enterprise AI is already shifting away from reliance on expensive, closed frontier models and towards owning more of the emerging value chain around AI. In a piece titled Enterprise AI Is Entering Its ‘Own vs. Rent’ Phase, Shubham Goswami recently likened the frontier model debate to cloud repatriation, where many companies realised in the past few years that they could run a lot of workloads cheaper and more effectively on their own systems:

The cloud repatriation analogy breaks down in one important way: when you move workloads back from AWS, the knowledge of how to run them is largely portable. If your learning loop — your prompts, evals, fine-tuning data, institutional workflows, get built inside OpenAI’s or Anthropic’s infrastructure, is that knowledge actually portable when you decide to own it? Or have you built the thing that’s supposed to be your competitive advantage in someone else’s house?

Two recent pieces shared by Constellation Research point to areas where this is already happening. Salesforce has cut inference bills by ‘rightsizing’ towards open models, which suggests other big token consumers are also probably feeling the pinch of inference costs. And they also carried a short update on the banking sector that observed banks are increasingly looking at building and owning their own AI systems as sources of competitive advantage.

The model is not the product. The harness around it is more valuable, and the real prize is how we combine these into an organisational operating system that combines synthetic and human intelligence in the most optimal ways.

Learning loops and change flywheels

Those firms that focus on adaptation, not just adoption of new tools will create the most sustainable ‘thick value’ using AI.

That means doing the patient, detailed work of re-imagining processes and workflows, turning support functions into scalable services, and replacing bureaucratic controls with codified automated systems that can move at the speed of technology, not committees.

And those that bake in organisational learning loops and continual improvement will accelerate and pull away from those who run a single one-off transformation and then run an updated, but unchanging new operating model on top.

Michelle Parke recently wrote about the power of recursive organisational learning as an accelerant, referencing Niklas Luhmann’s work on social systems:

Organizations do not merely accumulate information; they continually reproduce themselves through communication. Niklas Luhmann described social systems as maintaining continuity not by preserving static records but by recursively generating new communications that become the conditions for subsequent communications. Organizational intelligence, therefore, emerges less from isolated computational capability than from the recursive reproduction of meaningful interactions that continually shape future decisions (Luhmann, 1986).

This is not obscure social theory, but rather a practical use case. AI needs to explicitly learn from an organisation’s knowledge context in order to be effective. But AI also generates an audit trail of decisions, calculations and actions that could supercharge organisational learning if captured and used in service of continual improvement.

This has the potential to become a virtuous circle of improvement: better context → better agentic performance → better learning to feed back into the system.

Enterprise AI leaders would do well to think about this as a key element of their agentic AI architecture, especially if they want to create a self-improving agentic ecosystem as we wrote a couple of weeks ago.

Oddly enough, much of that thinking and staging seems to disappear when the recipient isn’t another person, but an AI.

Tasks that we’d hesitate to hand to a new employee are routinely handed to AI assistants with little more than a well-crafted prompt. Draft the strategy, analyse the data, review the contract, respond to the customer, or make the recommendation. Limited context and only minor rework.

A new graduate might spend months earning greater responsibility, and yet we hand an AI assistant the same power in a day.

Perhaps that’s because organisations don’t yet have the mechanisms. We know how to observe a graduate, coach them, expand their responsibilities and reduce them again when necessary. We don’t yet have equivalent operating models for AI. Those skills could form part of the next generation of management systems.

We’ve started treating AI as a technology problem when it’s equally a management problem. The challenge we face is re-designing our preconceived notions of delegation, with new tests for effectiveness.

Autonomy Is a Delegation Problem, Not a Technology One

Many conversations around agentic AI treat autonomy as though it’s a property of the technology. As models become more capable, the assumption goes, they become more autonomous - as if greater capability naturally earns greater authority.

But autonomy isn’t the ability to act independently. It’s the authority to make decisions on someone else’s behalf. And authority doesn’t originate with the AI - it originates with the organisation. Every workflow an agent executes, every customer it interacts with, every decision it can make has been deliberately entrusted to it by someone. That’s exactly how organisations have always delegated work to people, too: not by defining an outcome, but by defining boundaries. What decisions can be made independently? What budget can be approved? When should someone ask for help? What falls outside their authority?

Good delegation has never meant removing control. It has meant deciding where control should sit. If that’s true for people, it’s not obvious why AI should require an entirely different set of principles - which raises the real question: how do you design good delegation when one of your colleagues isn’t human?

Designing Delegation, Not Just Capability

Organisations have already solved a version of this challenge. Every day, managers decide which decisions they should make themselves, which can be delegated, and which still need another level of approval. Those decisions are rarely written down as grand theories - they’re embedded in job descriptions, approval limits, governance processes, budgets, team norms, and years of accumulated organisational experience.

Discussions about agentic AI tend to start somewhere else entirely: how capable is the model, can it complete this workflow, could it operate without human intervention? Sensible questions - but arguably the wrong place to begin, because capability and authority aren’t the same thing.

An AI might be perfectly capable of reviewing a contract, approving an invoice, or drafting a board paper. That doesn’t automatically mean it should. Organisations have never treated capability as the sole criterion for delegation - accountability, organisational risk, regulatory obligation, and the consequences of getting something wrong all factor in too. Once the question shifts from how much autonomy is this agent technically capable of to how much authority are we comfortable delegating in the first place, the technology becomes much easier to reason about. The model, the workflow, the prompts and the guardrails all follow from a decision that was fundamentally organisational, not technical.

Why Organisations Deliberately Bound Autonomy

Authority isn’t distributed evenly across an organisation. Some decisions are pushed to the edge, where speed matters most. Others stay centralised because they shape strategy, involve significant financial commitment, or carry legal and ethical consequences. Many sit somewhere in between, combining local judgement with periodic oversight - a healthy dose of organisational design as much as governance.

A customer service team needs the freedom to resolve problems quickly. A finance function may optimise for control and auditability. Product development often benefits from experimentation and distributed decision-making, while safety-critical engineering deliberately introduces additional review and challenge. Organisations don’t delegate authority according to what people are capable of doing - they delegate according to what helps the whole system perform effectively. Perhaps AI should be no different.

Where the human/AI analogy strains

People and AI fail in different ways, and those differences matter for how much of this analogy actually holds. A human employee who oversteps their authority can be asked why, and their answer becomes part of the evidence used to recalibrate trust. An AI system that produces a confident but fabricated figure, or that behaves inconsistently between two functionally identical requests, doesn’t have a “why” in the same sense - there’s no judgement to interrogate, only a pattern to audit. That changes what oversight has to look for. With a person, you’re mostly watching for bad judgement under pressure. With an AI, you’re also watching for a different failure mode entirely: confident, fluent error with no internal signal that anything went wrong.

There’s also the question of accountability. When a person exceeds their authority, the organisation has someone to hold responsible, coach, or in the last resort remove. When an AI does the same, accountability doesn’t transfer to the system - it stays with whoever configured its authority in the first place. That’s not a reason to abandon the delegation framing. If anything, it’s a reason to take it more seriously: the discipline of bounding authority matters more with AI, not less, precisely because the AI itself can’t be held to account the way a person can. But it does mean the analogy is a starting point for design, not a literal equivalence - and any operating model built on it needs to build in more auditing and less reliance on “asking what happened” than the human version would.

How to Start Creating Authority-by-Design

Imagine introducing a capable new colleague to your team - someone who learns fast, works at remarkable speed, and is happy to take on almost any task you give them. Before handing over meaningful responsibility, what would you want to establish?

The first question isn’t what can they do? It’s what should they be doing? Just because an agent can draft strategy documents doesn’t mean that’s the best use of it - delegation begins with the scope of the work, not the capability of the worker.

Next comes authority itself. A capable colleague doesn’t automatically gain the right to approve expenditure, sign contracts, or make commitments on the organisation’s behalf. Those rights are delegated deliberately, and recommending a course of action is very different from executing it.

Then come the boundaries: policies, budgets, regulations, ethical expectations, and organisational norms. The aim isn’t to constrain initiative, but to make good judgement easier and poor judgement harder. Good delegation also makes clear when someone should stop and ask for help - novel situations, uncertainty, conflicting evidence, or unusually high stakes should trigger a conversation rather than an independent decision. Escalation isn’t a sign delegation has failed. It’s part of good delegation.

A practical place to start is an audit, not a policy. Before designing any new framework, list every place AI is currently making a judgement call inside your organisation without anyone having explicitly decided it should - the summary that gets sent without review, the draft that goes out with only a glance, the analysis that quietly becomes the basis for a decision. Most of what you find won’t have been delegated at all. It will have drifted there, one convenient shortcut at a time. That list is the real starting point for authority-by-design, because it shows you where authority already sits, rather than where you assumed you’d placed it.

Authority Should Move in Both Directions

Most of the conversation about AI and trust focuses on how authority expands - an assistant proves reliable, so it’s given a wider brief. Less attention goes to the reverse: how authority contracts when something goes wrong.

With people, this is second nature. A manager who spots a lapse in judgement doesn’t need a formal process to quietly narrow what someone is trusted with while confidence is rebuilt. We don’t yet have an equivalent instinct for AI. Today, when an AI system makes a poor call, the typical response is a prompt tweak or a one-off correction, rather than a genuine reduction in scope - the system is rarely the problem, we’re often the ones adjusting it.

To my knowledge there isn’t yet a well-documented example of an organisation systematically revoking or narrowing an AI’s delegated authority the way it would with a person - probationary tightening, a formal review that reduces scope, a graduated path back to full trust after an incident. This piece isn’t claiming that model exists yet. It’s aspirational: the same discipline organisations apply when a person’s judgement is in question - narrow the brief, increase the checkpoints, rebuild the evidence - is the discipline AI delegation will eventually need too. Building that muscle now, before an incident forces the issue, seems like better practice than reaching for it only after something has gone wrong.

The Best Organisations Are Becoming More Deliberate, Not More Autonomous

This pattern already shows up in a handful of the most closely watched enterprise deployments, even if none of them frame it explicitly as “authority design.” Read on to learn more.

Read more

“Something has gone completely wrong”

Palantir CEO Alex Karp last week blasted the frontier model providers for seeking to reduce their own deficits between compute cost and revenue by effectively increasing token costs for most customers. Karp made the point to CNBC that “Something has gone completely wrong” with the frontier model approach, and argued that businesses he speaks to are secretly furious about the unpredictable cost increases they have faced.

Michael Spencer believes this explosion in costs combined with recent US political interference in AI model availability has created the conditions in which more companies will explore open models as the basis for their agentic AI systems:

The Token Apocalypse is that crucial moment where companies realize switching to Chinese open-weight models or open-source models made in the West has become a business necessity to get the most of AI agents without breaking the bank. I believe July, 2026 is that moment. If I’m right, at the scale we are going to see this trend, it could have a material impact on slowing down the growth of AI behemoths and model makers like Anthropic, OpenAI, Google, SpaceX, Meta and others. That is also a big deal for the AI bubble.

Open-source inference is now a billion-dollar infrastructure category in its own right, with enterprises cutting inference costs up to 60x versus closed alternatives.

Research analysed by Optimum Partners shows that 73% of enterprises report AI costs exceeded projections, even though token prices dropped by a similar proportion year-on-year. The reason is that agentic workflows multiply token usage 5–30x per task, and a large proportion of total AI cost now sits outside the model bill, for example in orchestration, retrieval, retries and observability. So this is not just a question of model cost inflation, but also a system design problem.

Frontier model providers like Anthropic have started responding to token anxiety with cost control measures that seek to provide re-assurance to enterprise leaders. But there are other reasons beyond concerns about vendor lock-in and token cost are leading enterprises to consider building at least a proportion of their agentic infrastructure using open, possibly self-hosted models, such as better cost and operational control (including security), model fine-tuning, and minimising latency for multiple round-trip reasoning steps.

Jaroslaw Wasowski recently wrote about how to decide between open and frontier models for certain tasks, and concluded that it is foolish to pose this as a binary question. Instead the real test was to ask “which task class, at what volume, measured on my data,” quoting economic analysis by MIT and Georgia Tech from November 2025 to remind us that:

Open models today achieve roughly 90% of the quality of closed models on real-world tasks, at approximately 87% lower cost per token. And yet closed models capture close to 96% of revenue on inference platforms.

Hybrid routing and fine-tuning

To optimise this kind of hybrid strategy - using the right models for the right tasks - requires intelligence at the router level, which directs tasks to agents and models it decides are most appropriate, and also needs to have escalation options if tasks prove harder than they look.

LLM routing is now a mature tooling category, with purpose-built solutions that route on cost, latency, and task complexity in real time, and many enterprises are running five or more models in production.

Frontier models are still the best solution where complex multi-stage reasoning is needed, or where long-running supervisor agents need very low error rates; but for simple, repetitive tasks run by a sub-agent, open models can save a lot of money and offer more opportunity for fine-turning based on proprietary data and knowledge. But for self-hosted models, even if a company has the skills and infrastructure needed, the front-loaded costs are high, meaning the break even point where the upward slope of frontier model API costs exceed the flatter curve of self-hosting costs depend on model size and infrastructure. It could be as low as 1m tokens per month for serverless GPU hosting and small models, but several orders of magnitude higher for a sophisticated setup with larger models.

The open model route is not for the faint-hearted. Recently released research from VentureBeat found that 45% of firms surveyed who are doing their own fine-tuning report falling into a Sandbox Graveyard (25–75% success with fine-tuning) that ultimately proved too costly or complex and got stuck in development, with only 27% reporting high success (>75%).

There is clearly a need for better ways to fine tune agents and the models they use in enterprise settings, but it is not yet clear whether this needs the hard work of model training, or whether specialist AI data platforms can achieve good-enough results.

Agentic ecosystem design

So what is a CIO to do when faced with big decisions that have long-term cost implications? Intelligent routing and keeping an eye on all the model variants and their token costs is advisable. And perhaps a middle ground of using cheaper cloud-hosted open models for simple workflows, reserving frontier models for the tasks that really need them, is a good way to assess whether self-hosted models might be an appropriate scaling option.

But model selection is the wrong problem to be solving. The real issue is ecosystem design.

In nature, and in other areas of technology, small, single-purpose ‘agents’ dedicated to their own fitness function and survival are one of the most powerful forces of evolution when they exist within ecosystems that allow them to cooperate and compete to maximise collective outcomes.

If we design our enterprise AI agentic capabilities with this in mind, and use the smarter ‘brain’ agents to direct and coordinate simpler ‘autonomous’ functions, then we can do a lot with very little compute.

If we assume a realistic level of error and output decay is inherent in the way models work, we could use multi-agent systems to check and challenge each other’s work with a view to creating a kind of ‘quantum’ error correction. Just as quantum computing achieves reliable computation from ensembles of unreliable qubits, well-designed multi-agent systems can aggregate uncertain individual outputs into robust collective decisions — but only if the architecture is built for it from the start.

The real lesson from the token panic isn’t to find a cheaper frontier model, but to stop treating agentic AI as a model-selection problem. A better frame is ecosystem design. In nature, powerful collective behaviour emerges not from increasingly powerful central intelligence but from simple, specialised agents acting within rules that make cooperation and competition productive. Enterprise agentic systems work the same way: route simple, high-volume tasks to fast, cheap, fine-tuned models; reserve frontier intelligence for genuine complexity and long-running coordination; and design your multi-agent architecture so that agents check each other’s work rather than any single answer being trusted implicitly.

The CIO’s job is not to find the best model. It’s to design the right ecosystem.

Enterprise AI is arriving into that landscape and exposing a limitation that capability mapping was never designed to solve.

A capability map can tell you that a Customer Insight capability exists, who owns it and how mature it is. What it cannot tell you is how to engage with it: what information it requires, what outputs it produces, what decisions it can make and when escalation is needed. For years, those questions were answered through relationships, experience and institutional memory. People learned how to navigate the organisation by working inside it.

Agents cannot do that. They require capabilities to be discoverable and understandable in ways that don’t depend on knowing the right person or having spent years in the building. Increasingly, organisations need to build interfaces to interact with them.

The Potential of Capability Interfaces

As the AI ecosystem has been expanding, there has been a growing focus on discovery. As agents become capable of performing increasingly complex tasks, a practical challenge emerges: before an agent can act, it must first understand what tools, services and capabilities are available to it. It needs a way to discover them, understand their purpose, determine their requirements and know how to invoke them safely.

This challenge sits behind much of the recent interest in protocols such as MCP, agent registries, shared service architectures and AgentOps platforms, all attempting to make capabilities discoverable and usable by machines. It turns out organisations have always had a version of this problem. Employees know expertise exists somewhere but struggle to find it, functions duplicate work because they cannot easily discover what another part of the enterprise already provides. Humans compensate through relationships and organisational folklore. Agents cannot.

This is where standardised capability interfaces could be useful. A capability interface sits between the existence of a capability and its use. A capability map might tell you that a Customer Insight capability exists. A capability interface would tell you what the capability does, what information it requires, what outputs it can provide, which policies govern its use, which decisions it can make, when human approval is required and how it connects to other capabilities.

At first glance, this looks like little more than better documentation. The more interesting possibility emerges when capability interfaces begin interacting with one another. A single capability interface makes a capability easier to discover and use. A network of capability interfaces makes capabilities easier to combine, and that shift, from understanding individual capabilities to coordinating combinations of them, is where the idea becomes strategically significant.

Why Most Organisations Stop at Mapping

If capability interfaces seem like a natural evolution of capability mapping, it raises an obvious question: why are they not already being extended?

Part of the answer is that mapping and interfacing solve fundamentally different problems. A capability map is primarily descriptive: it helps the organisation understand itself, provides a common language for strategy and transformation, and can remain relatively stable once created. A capability interface is operational. It must describe not only what a capability is, but how it can be used, which requires a very different level of organisational clarity.

Who owns the capability? What services does it provide? What decisions can it make autonomously, and when should work be escalated? What policies and controls apply? Many organisations struggle to answer these questions consistently, not because the capability does not exist, but because much of the knowledge remains implicit. Organisations typically operate through a mixture of formal structures and informal agreements. Processes exist on paper, but exceptions are handled through experience. Responsibilities are documented, but authority is negotiated in practice.

Humans are remarkably good at working around this ambiguity, but agents do not have the tools to do that. As organisations begin deploying more sophisticated agent systems, these hidden assumptions become increasingly visible. An agent cannot rely on organisational folklore or infer decades of accumulated context from a hallway conversation. The boundaries, rules and expectations must be made explicit.

This is why many early agent initiatives eventually encounter organisational rather than technical constraints. The challenge is rarely that the model cannot perform the task. The challenge is that the organisation has not fully codified how the task should be performed, what authority exists, what information is required, and how the work connects to the wider system. Capability interfaces force these questions into the open, and in doing so, they reveal something uncomfortable: the limiting factor for many agentic organisations may not be intelligence, but organisational clarity.

In practice, this diagnostic function may prove as valuable as the interfaces themselves. Some organisations will discover they have more capabilities than they realised. Others may discover that what appeared to be a capability was really a collection of relationships, tacit knowledge and informal agreements held together by a handful of experienced people.

What a Capability Interface Might Look Like

The easiest way to understand capability interfaces is to imagine the difference between knowing a service exists and knowing how to engage with it. Most organisations have a Customer Insight capability, but if an employee, team or agent attempts to use it, they typically rely on experience to answer the basic questions: what to provide, what outputs to expect, what can be decided automatically and what requires human involvement. A capability interface makes those answers explicit. For Customer Insight, it might look like this:

Over time, a capability interface can also become a feedback loop. Teams and agents that engage with a capability are well-placed to report on whether it performed as expected, where the interface was unclear and what edge cases the documentation didn’t anticipate. Building a lightweight feedback mechanism into the interface, even something as simple as a rating and a comment field, means the interface improves with use rather than drifting out of date.

The more forward-looking possibility is that each capability interface becomes associated with its own agent: a custodian that can answer questions about the capability, help other agents understand how to interact with it correctly, handle edge cases that fall outside the documented rules and escalate to the human owner when something genuinely novel arises. Rather than a static specification, the capability becomes something closer to a service with a representative, one that can negotiate, clarify and adapt on behalf of the team that owns it.

The same interface works for a human, a team or an agent, which is where the idea becomes strategically significant. Most organisations already possess the capabilities required to deliver complex outcomes. The challenge is rarely their absence. More often it is the difficulty of coordinating them across functional boundaries: a customer onboarding journey spanning Sales, Legal, Compliance, Finance and Operations; a product launch requiring Marketing, Research, Procurement and Support. Today that coordination runs through meetings, relationships and project structures, people acting as translators between functions.

As agent systems become more capable, a different model begins to emerge. Instead of coordinating people, organisations increasingly coordinate capabilities. The outcome becomes the organising unit, and the question shifts from “which department should own this?” to “what combination of capabilities is required to achieve this outcome?” Agent orchestration platforms, shared agent networks and outcome-oriented systems are all pointing toward this pattern: capabilities become building blocks, and interfaces become the mechanism through which those building blocks are discovered and connected.

If You’re Serious About Capability Interfaces

Capability interfaces are unlikely to emerge through a large-scale transformation programme. Like many organisational innovations, they are easier to discover through experimentation than through design.

Read on for details on four practical exercises that will help you get ready or get started, regardless of your organisation’s state of agentic AI maturity.

Read more

A lot of enterprise AI investment has gone into models and prompt quality. But there is a growing body of evidence that points to the main constraints on reliability, cost, and organisational capability still being mostly related to context and codification.

Context defines what an AI model knows, when it knows it, how it’s managed, and who owns it. Codification is how we turn rules, processes, workflows and other operational knowledge into systems that AI agents can use to guide their work.

In many ways, the next phase of enterprise AI is less about teaching machines new things and more about teaching organisations how to express what they already know.

Chroma’s “Context Rot” study recently found that 65% of enterprise AI failures in 2025 could be traced to agents losing track of their own reasoning mid-task — not hallucination or training data quality. Performance degrades as token count increases across all major models.

Tech learning hub PrepStack has published a six-part technical series on context engineering, which shows how even small improvements to managing the context window, memory management and agentic collaboration can substantially reduce token costs and hallucinations in long-running and multi-turn agentic workflows.

There are several reasons why it is hard for models to maintain context in long-running tasks, but the absence of real-time data architecture is in many firms is certainly one key limitation.

A recent Gartner report argues that batch architecture for data platforms is one of the main culprits for the ROI gap, as scheduled data releases lead to agents working with stale world knowledge. Forrester makes the same point from the infrastructure side: real-time data streaming is not an optional enhancement but a foundational requirement:

“agents act at digital speed, stale context means wrong decisions at scale affecting customers, operations, workforce, and market.”

However, this is not just a challenge for AI and data infrastructure; it is also about process legibility and observability.

Rudy Kuhn of Celonis argues in Diginomica that most enterprise AI fails not because models are too weak but because they lack knowledge of how work actually flows: which systems are used, in what sequence, with what exceptions. Organisations have over-indexed on data quality when process observability is the more pressing issue. They are discovering that scaling AI requires many of the same disciplines that allowed software systems to scale: versioned knowledge, observable processes, testable workflows, and continuous feedback loops.

Microsoft CEO Satya Nadella has recently started framing enterprise AI advantage as deriving from how we combine token capital (models) with human capital (workflows and learning loops) to improve how work gets done. The implication is that model commoditisation is a feature, not a threat, for organisations that have invested in the context layer on top and therefore own (and can mobilise) their own core IP.

“A frontier without an ecosystem is not stable.”

Governance as a special case of codification

Enterprise AI governance is reaching an important inflection point. The dominant approach of guardrails, human-approval loops, and compliance overlays added to deployed systems is visibly failing. In the past week, we have seen a cluster of signals pointing toward the need for a different architecture: baked-in governance embedded at the workflow level, rather than applied afterwards.

Gartner predicts 40% of enterprise AI agents will be decommissioned by 2027 because of poor governance design, such as organisations applying the same oversight regime to all agents regardless of autonomy, scope, or the level and ‘blast radius’ of risk. This echoes how the RPA and chatbot waves played out: overpromise, under-govern, then scale back.

As an example of the problem, one AI practitioner recently shared their field notes based on building agents at a large manufacturing firm, and concluded that most AI-specific guardrails are theatre, and the actual load-bearing safety infrastructure in production agentic AI is still quite conventional - e.g. IAM, network egress, audit trails, and secrets management.

Traditional software governance was designed to audit the artifact, not the action, but Ken Huang argues this needs to change. Although AI agents generate, execute, and discard code within single sessions, the side effects (database writes, API calls, transactions, etc) can persist indefinitely, so we need validation discipline that covers the side-effect layer, just as we do already in financial trading:

“you don’t review every algorithm line by line; you reconcile every transaction.”

Another recent take on the problem comes from Microsoft, who propose an approach they call Information Flow Control (IFC) to track how data moves through agent networks, enforcing policies at the data level rather than focusing only on action approval - a shift from output guardrails to provenance.

Ultimately, the direction of travel is towards more richly-defined accountability for specific agents — perhaps even legal identity — as we look to the possibility of autonomous agentic markets and agents that can make contracts with each other. Estonia, as you might expect, is already on the case.

But all these approaches, whether applied at the infrastructure, data, process or outcomes layers, ultimately depend on clarity about what the specific rules and guidelines actually are, and how we can deploy them as part of run-time governance, not after the fact.

If you are not already working on codifying governance, for example by creating code-like repositories of different rulesets with auditing and branching and using AI to collate the specific governance blueprint for each agent and context on the fly, then you are probably condemned to waste a lot of time exploring the many inadequacies and frustrations of governance by committee.

Human-in-the-loop governance sounds nice until it inevitably slides into becoming something closer to a Home Owners Association (no plant pots on the terrace!) rather than a smart system to keep autonomous agents on track.

Learning loops as competitive advantage

In the piece quoted earlier, Microsoft’s Satya Nadella also made the point:

“Governance, private evaluation loops, and workflow data [are] compounding assets rather than overhead.”

Organisations that are able to create systems where AI outputs feed back into human judgment, which feeds back into better AI context, which produces better outputs, will be best placed to compound their AI advantage. In other words: learning loops.

For example, a customer support agent proposes responses and next actions for a case. Human operators accept, reject or modify those recommendations, and the outcomes are used to update guidance, workflows and future agent behaviour. Every interaction becomes both productive work and training data for the next cycle. Over time, the organisation is not simply serving customers; it is continuously improving its ability to do so.

AI infrastructure, systems and capabilities are all important, but their speed of evolution and learning is the key differentiator. Right now, there is a ‘tempo gap’ between the speed of AI deployment and the speed of organisational capability absorption as organisations are deploying faster than they’re learning.

As one commentator put it last week:

The companies that win at enterprise AI won’t necessarily be using better models. They’ll be the ones who built better feedback loops — systems where every interaction becomes data, every evaluation becomes a learning opportunity, and every deployment becomes an experiment rather than a one-time launch.

Without strong, rapid learning loops for AI agents, there is a risk people end up spending too much time botsitting, as this study of 6,000 workers from Glean’s Work AI Institute warns. And without rapid learning loops for people working with AI agents, we will not be able to improve our practice and get the most out of both our people and the technology, increasing the risk of slopification.

There is some evidence that AI native firms are able to do this better than others, resulting in smaller, more engineering-led and less managerial teams that produce higher valuation per employee. Hyunjin Kim of INSEAD and Rembrand Koning from HBS studied YCombinator batches W20–F24 and US venture-backed startups in the same 2020-2024 timeframe, finding that AI-native firms were 25% smaller than comparable non-AI startups, carried 13% more engineers, with 15% fewer entry-level workers and 15% fewer managers, and yet reached comparable valuations. The key distinction they found was that the product channel (AI capabilities embedded in what the firm sells) is the primary mechanism for scaling knowledge work without large headcounts, rather than the process channel (AI changing how people work inside the firm).

Do AI agents dream of electric sheep?

If context provides the raw material, codification provides the structure, governance provides the constraints, and learning loops provide the mechanism for improvement, then memory is what allows those improvements to persist over time.

In both human organisations and agentic systems, learning only becomes a durable capability when experience can be retained, consolidated and reused. The emerging question is therefore not simply whether agents can learn, but how they remember.

The question of how agents run learning loops by managing, compacting and evaluating the memory of their actions is fascinating and quite technical; but it is worth thinking about if we hope to create closed-loop agentic processes that we can rely on.

Ken Huang has been writing about this recently, and has shared two introductory pieces about how agents remember here and here. He sees agent memory consolidation as both a technical pattern and an organisational design problem:

“who decides what the agent should remember, and how that memory is governed, matters as much as the mechanism itself.”

Perplexity Brain seems to be trying to made this concrete as a product — a context graph the agent reviews overnight, teaching itself to do the work better to create a learning and improvement flywheel. But this also surfaces an ownership questions: if the learning loop belongs to the vendor, the accumulated operational intelligence accretes to the platform, not the customer.

As Ken Huang notes, yes this is dreaming, but no it does not imply some kind of imaginative inner life that agents share with people.

The Turing Post also has a recent piece on AI models needing sleep to dream, with a round-up of other relevant research into the phenomenon.

At the risk of anthropomorphism, I should confess that I advise my agents not to eat virtual cheese before they sleep, just in case they have nightmares about human AI governance committees, as I sometimes do.

At some point, the economics of fragmentation became impossible to ignore. Every business unit managing payroll differently created unnecessary duplication. Every geography developing its own procurement process increased operational inconsistency. Every local support function building bespoke workflows reduced visibility and made governance harder.

The response was the rise of shared services. Finance functions were centralised, HR operations became shared platforms and procurement moved toward standardised operating models. Organisations increasingly recognised that certain forms of operational work were too repetitive and too cross-cutting to be rebuilt independently across the enterprise.

But these central services over-relied on outsourcing and lowest-common-denominator SaaS platforms to manage cost, resulting in poor experiences for employees. In the worst cases, these became bureaucratic power centres that inhibited change and improvement, whilst also handing over control of key strategic functions (employee experience, IT support, etc) to third parties.

Agentic AI may now be creating the conditions for a similarly impactful transition, but one that could right the wrongs of last-generation central services.

Most organisations are still early in the journey, with functions starting to build small operational agents to support onboarding, reporting, approvals, compliance checking, or analysis. Initially, this phase feels highly productive and the barriers to creation are low. Useful systems emerge quickly because local teams understand their own work intimately.

But over time, the same pattern begins to emerge repeatedly:

• Different teams build remarkably similar agents.

• Operational logic starts diverging between functions.

• Context becomes duplicated.

• Governance becomes fragmented.

• Multiple orchestration layers begin solving the same coordination problems independently.

At first, this duplication is tolerated because experimentation matters more than efficiency. But as adoption accelerates, the primary cost becomes operational incoherence.

This is where the conversation becomes more interesting. The long-term significance of agentic systems may not lie in the agents themselves, but in the emergence of a new organisational layer sitting beneath them: shared operational intelligence. Reusable layers of orchestration services, shared context infrastructure, operational primitives, evaluation frameworks, and governance capabilities that domains can compose locally without rebuilding repeatedly from scratch.

In effect, organisations may begin creating shared intelligence infrastructure in the same way they once created shared operational infrastructure.

Like all operating model shifts, it immediately raises political questions: who owns orchestration, who governs operational intelligence, what should be shared and what should remain domain-owned, where does infrastructure end and operational judgement begin.

This is the terrain on which enterprise AI adoption may ultimately succeed or fail.

The Return of the Coordination Problem

The moment outputs need to move between teams, functions, approval structures, or governance systems, old coordination constraints begin to reassert themselves. This is partly why so many AI deployments currently feel impressive locally but underwhelming organisationally. The edge accelerates faster than the system holding it together.

Agents intensify this dynamic because they do not simply generate outputs. Increasingly, they participate in workflows by routing work, retrieving information, triggering actions and escalating decisions. Organisations are learning to manage distributed operational behaviours in real-time, and distributed operational behaviours eventually create pressure for standardisation.

The first generation of shared services largely centralised execution. Shared agent infrastructure may evolve differently. Rather than centralising execution itself, organisations may instead centralise reusable coordination capabilities while allowing operational ownership to remain distributed.

That distinction matters enormously - the goal is not for a central AI team to own every workflow. In practice, that would almost certainly fail. But it also makes little sense for every function to independently reinvent identity handling, escalation logic, evaluation frameworks, or orchestration infrastructure.

Over time, some capabilities naturally begin hardening into reusable organisational primitives.

Shared Operational Primitives

Most organisational work contains repeated coordination patterns hidden beneath surface-level variation. Approval routing appears in finance, procurement, HR, legal, and operations. Escalation handling exists across customer service, incident management, and compliance. Classification, verification, prioritisation, and policy interpretation recur across dozens of workflows simultaneously.

Today, many organisations are building these capabilities repeatedly inside disconnected systems. Once agentic adoption matures, that duplication becomes difficult to justify.

It becomes increasingly rational to create trusted, reusable versions of these capabilities that can be composed locally into different workflows. Not in the form of rigid end-to-end processes that we see now in central directives, but modular coordination services embedded into operational infrastructure.

And these modular components may further support re-use by separating the instructional coding (e.g. a ruleset for compliance) from the management of the process (e.g. a compliance checking and verification agent).

This separation matters because it allows organisations to codify operational logic once while reusing it across multiple workflows and domains. A compliance ruleset, for example, may underpin onboarding, procurement, supplier management, customer verification, or incident response without each workflow rebuilding the underlying logic independently. Over time, the value shifts away from isolated automations toward shared organisational codification: reusable operational intelligence that can be orchestrated differently depending on context, risk, and business need.

The most important systems may not be standalone agents visible to users at all. They may instead be shared orchestration layers sitting beneath operational workflows, quietly coordinating information, decisions, escalations, and governance across the organisation. In this model, intelligence becomes partially infrastructural.

Building a Shared Agent Capability

Shared agent infrastructure becomes valuable when it evolves beyond isolated automations into a coordinated organisational capability. That requires designing and integrating five interdependent components:

Core Systems: Agent orchestration layers, shared context infrastructure, evaluation frameworks, observability platforms, and workflow execution engines form the operational backbone for reusable organisational intelligence.

Data Sets: Operational traces, escalation histories, policy repositories, workflow telemetry, and outcome performance data provide the contextual foundation for coordination, governance, and continuous refinement.

Software: Workflow orchestration tools, agent runtimes, policy engines, evaluation systems, and monitoring platforms transform fragmented automations into composable operational capabilities.

Services & Processes: Governance routines, orchestration review processes, escalation pathways, and embedded evaluation loops ensure shared intelligence remains adaptive, trustworthy, and aligned to operational realities.

Skills: Systems thinking, orchestration design, contextual judgement, governance design, and human-AI coordination capabilities enable organisations to balance shared infrastructure with local operational ownership.

The most important skill may ultimately be organisational systems thinking: understanding how operational coordination behaves across teams, workflows, and platforms.

The Political Economy of Shared Agents

Many first-generation shared service programmes failed in ways that are still deeply remembered, because consolidation often stripped too much context away from the work itself. Standardisation hardened into bureaucracy and local teams lost the ability to adapt around edge cases, regional differences, or operational timing. Over time, people started working around the system rather than with it.

There is a real possibility that organisations repeat some version of this pattern as agentic systems mature.

Some layers almost certainly do benefit from becoming shared organisational infrastructure. Identity management, telemetry, observability, evaluation frameworks, policy enforcement, and governance controls all become significantly more valuable when treated as common capabilities. Over time, many of these elements are likely to become as foundational as ERP systems or cloud platforms.

The difficulty is that operational judgement does not behave like infrastructure.

Customer interactions depend on context that cannot easily be standardised. Escalation behaviour differs between domains because the operational consequences of delay, risk, or ambiguity differ. Once these distinctions are flattened too aggressively, organisations end up with systems that appear well-governed while becoming progressively less adaptive in practice.

This is where the emerging boundary between IT and operational leadership becomes particularly important. Agentic systems blur the traditional distinction because operational logic itself becomes executable. The operational model and the technical architecture begin collapsing into one another.

What is starting to emerge instead is something more federated. The objective is to create shared enablement: enough common infrastructure to make intelligence reusable, while preserving enough local ownership for systems to remain adaptive and operationally credible.

Governance as Infrastructure

One of the more important shifts inside shared agent systems is that governance itself begins moving from policy into infrastructure.

In many organisations today, governance remains largely external to execution. Policies are written, review boards are established and oversight happens retrospectively through audits and compliance exercises.

Agentic systems allow governance to become operationalised, so that evaluation can be embedded directly into orchestration layers: escalation pathways can be structured into workflows, logging and telemetry can become default behaviours and deterministic constraints can be placed around probabilistic systems.

This matters because the scale and speed of agentic coordination may quickly exceed the capacity of traditional oversight mechanisms. Shared operational intelligence only becomes viable if organisations can trust how these systems behave across contexts and domains. That trust cannot emerge from policy documents sitting outside the system.

What Shared Agent Infrastructure Makes Visible

One of the most overlooked effects of shared orchestration is visibility.

Most organisations still struggle to see how operational coordination actually happens across the enterprise. Processes disappear into fragmented systems, disconnected workflows, email threads, and local workarounds.

Shared orchestration layers begin exposing these hidden coordination patterns. A customer onboarding journey spanning sales, legal, compliance, finance, and support becomes observable end-to-end. Procurement workflows reveal where escalation loops consistently emerge. Operational bottlenecks become legible not because somebody manually mapped them, but because the orchestration layer generates traces of how coordination actually occurs.

Once coordination becomes visible, it becomes designable. Organisations begin shifting from managing functions independently toward managing the coordination layer between them.

Getting Started

Most organisations do not need to begin by designing a grand enterprise-wide shared agent platform. Trying to centralise too early is often what creates resistance and pushes teams back toward fragmented local workarounds.

A more effective starting point is observational. Look closely at where agents and orchestration are already emerging organically. In most enterprises, teams are already building small pockets of operational intelligence. At first these systems appear isolated, but over time patterns begin repeating. Similar orchestration logic appears across multiple functions. The same coordination problems are solved again and again in slightly different ways.

These repeated patterns are often the earliest signals that shared operational primitives are beginning to emerge naturally. The opportunity is not to immediately standardise every workflow, but to identify which capabilities are becoming infrastructural.

Read on to learn how you can use a loops and layers approach to iterating shared agent networks to make the most of this opportunity without stifling progress.

Read more

This gives me optimism in the face of widespread uncertainty about enterprise AI ROI. Several commentators have explored this recently, and their diagnoses are useful; but they all point to a solution that requires operational leaders to be in the driving seat, not waiting on the sidelines for technology teams and consultants to hand them something.

From Lightbulbs to Learning Loops

Azeem Azhar last week tackled Why AI isn’t showing up on your bottom line, likening the current situation to the thirty-year gap between the dawn of industrial electrification and the moment when this general-purpose technology finally started to transform factory productivity. His three-phase breakdown maps well onto what we are seeing now:

• The lightbulb (stage 1): improved the workplace through illumination but did not change the operating logic

• The group drive (stage 2): used the existing factory layout and accelerated processes, but did not redesign the system

• The unit drive (stage 3): redesigned workflows and structures to take advantage of what electrification made possible

The critical difference between stages two and three was not the technology — it was who redesigned the floor plan and who owned the result. To become a stage-three firm requires not just faster workflows but a faster coordination architecture. Without it, AI-enabled productivity gains can paradoxically worsen system congestion rather than reduce it, and increase the “coordination tax” — that hidden overhead of meetings, approvals and status updates that agentic AI should be dissolving, not embedding deeper into a new layer of tooling.

Ethan Mollick recently made a complementary point: individual productivity gains from AI are not being captured as organisational improvement, and the reason is structural. He argues we need to do a better job of combining leadership, the lab, and the crowd inside firms:

The key is treating AI adoption as an organizational learning challenge, not merely a technical one. Successful companies are building feedback loops between Leadership, Lab, and Crowd that let them learn faster than their competitors... critically, they’re not outsourcing or ignoring this challenge.

The Sticky-Tape Problem

The dominant model of enterprise AI adoption right now is additive: take existing operating structures, layer AI tools on top, and hope for returns. PWC UK’s Chief AI Officer, quoted in an MIT Technology Review piece on organisational design, describes this as embedding AI into “what is a human operating model” and suggested adding AI agents to workplace structures that are already breaking is “like adding sticky tape.“

The Silicon Sands newsletter puts it more bluntly:

“If you run an enterprise, are you redesigning the work or distributing licenses and waiting for a return that the math says will not come?”

But the problem is deeper than poor implementation.

Many operational leaders have inherited a cat’s cradle of process management, underwhelming SaaS platforms, and outsourced functions — the accumulated result of financial engineering, previous transformation waves, and an over-reliance on consulting firms to design and run what should be core internal competencies. The same large consulting firms are now trying to insert themselves into the agentic AI layer at their clients, while facing their own existential challenges from AI.

The sticky-tape approach perpetuates the coordination tax. Agentic AI layered on top of broken outsourced processes with unclear ownership does not reduce management overhead.

Operational Leaders as Architects

I believe functional leaders who own their value streams are better placed to design agentic systems than the IT departments, consultants, and SaaS vendors who have historically done this for them. Not because they are more technically capable, but because they have the knowledge, context, and accountability that good system design requires.

Context engineering — designing the information environment that AI agents operate within — is increasingly recognised as a key organisational capability. But it is not primarily a technical discipline. It requires deep knowledge of how work actually flows, what decisions get made and by whom, where the friction is, and what a good outcome looks like. That knowledge lives in functional leaders, not in implementation teams.

I regularly teach a session on leaders as architects and world-builders that frames this as an important leadership skill in this age of AI-enabled discovery. My experience has been that every cohort of senior leaders embraces the challenge and has a lot of ideas about where to begin.

The best option for a leader trying to accelerate agentic AI adoption is not to wrap it around messy inherited structure, but to redesign from first principles. In practice, this means a sorting exercise across the existing landscape: some SaaS platforms will remain, especially where processes have adapted to fit the software. Some will be reduced to data stores, with custom agentic apps running on top. And some will simply be redundant once agentic AI can deliver the same outcome at a fraction of the cost and with far more flexibility. Most non-customer-service functions that have been outsourced fit this third category and can be automated, which is a useful target for cost savings in proving ROI.

This is citizen development taken to a new level. Rather than building simple workflow automations, we are talking about locally-owned agentic applications that give functional leaders fine-grained control over how their domains run — built on services, platforms, and protocols provided by internal IT, but designed and owned by the people accountable for outcomes. Process-oriented firms across sectors from logistics to industrials are already starting to explore this as a better alternative to packaged SaaS in addressing their specific needs.

The direction of travel is towards the programmable organisation — one that can reconfigure its capabilities and processes in response to changing conditions. That requires services and processes to be digitised, addressable, and composable. It also requires the people who understand those services and processes to be the ones designing the new intelligence and automation layer that sits on top of them.

What This Requires

There are other enablers, blockers and considerations to bear in mind, of course. Topics like governance and observability require expert input from IT and other stakeholders, and the agentic infrastructure is still maturing. But there is no reason to wait for the technology to be fully ready before engaging operational leaders in the design process. The design work itself is a powerful learning experience — one that requires leaders to re-examine and articulate how work actually flows today, often for the first time in years.

Encouraging leaders to adopt what we call a map→change→learn loop can help accelerate AI adoption, but it can also create a flywheel of business improvement.

Azeem’s stage-three insight is that the firms that will pull ahead are not those that adopt faster, but those that learn faster:

“Stage 2 produces productivity gains and cost savings, but those advantages are temporary. Competitors can copy and catch-up fast. Your cost advantage will disappear. What is harder to copy is a firm that learns ever faster.”

That learning is not a course, but nor is it a technical project. It is a design project. And the designers need to be the people who are accountable for the work.

Even a complex organisation is knowable — and it is the job of leaders to design the fabric of coordination and collaboration that makes work flow. Agentic AI does not change that job, but it raises the stakes for doing it well.

For many people, this takes months to acquire, sometimes years. This is curious when you consider how quickly we learn to navigate almost everything else.

Most people can become comfortable using a new digital service within minutes. Whether using Spotify, Google Maps, or an online retailer, the underlying complexity is hidden behind an interface designed to help us find what we need. Organisations are different. Despite decades of investment in digital transformation, knowledge management, and collaboration platforms, the experience of navigating a large organisation remains surprisingly manual. People still rely on personal networks, accumulated experience, and knowing the right person at the right time, not because organisations lack capability, but because much of that capability remains difficult to discover and difficult to access.

What if the next frontier of organisational design is not creating more capability, but making existing capability dramatically easier to access? For most of organisational history, that question had no satisfying answer. That is starting to change.

We Improved Software UX But Neglected Organisational UX

Over the past three decades, one of the great success stories of the digital age has been user experience design. Early software required training courses, specialist knowledge, and thick instruction manuals. As digital products became more competitive, this changed. Complexity disappeared behind experiences designed around user intent rather than system architecture.

Yet organisations evolved differently. As they grew, they accumulated processes, functions, governance structures, and specialist expertise. These investments created real value, organisations became more capable, more efficient, more compliant. But the effort focused overwhelmingly on creating capability rather than making it easier to access.

Many organisations now possess extraordinary internal capabilities: specialist teams, sophisticated processes, vast knowledge, mature governance, and years of accumulated experience. Yet employees frequently struggle to discover what is available, understand how to access it, or navigate the pathways needed to get things done. In software, we learned that capability alone is not enough. Powerful systems fail when people cannot easily use them. User experience became the discipline that bridged this gap. Organisations face a similar challenge and have largely not yet met it.

The Hidden Cost of Complexity

Capability and accessibility are not the same thing. An organisation may contain exactly the expertise required to solve a problem, but the people facing that problem may have no practical way of finding it. It may have documented a process, but people remain uncertain which version applies. It may have solved a problem before, but teams unknowingly solve it again. The capability exists. The experience of accessing it remains difficult.

This gap creates three recurring friction points that compound as organisations grow.

The first is navigation: the capability discovery problem. Most organisations invest heavily in creating expertise, yet comparatively little attention goes to helping people find it. Navigation becomes dependent on personal networks and accumulated experience. Long-serving employees know who to contact and where knowledge lives. Newer employees rely on asking around or stumbling across useful information by chance. The result: teams duplicate work, problems take longer to solve, and valuable knowledge never reaches the people who could use it.

The second is coordination: the capability flow problem. Most organisational work no longer happens within a single team. Delivering a new product or implementing a strategic initiative requires contributions from multiple disciplines and specialist groups. The challenge is rarely a lack of expertise; more often, it is connecting expertise effectively. Teams become increasingly productive, yet organisational progress fails to keep pace. A team can be highly productive whilst remaining poorly connected, valuable work created quickly, then delayed by dependencies, handovers, and the difficulty of aligning multiple groups around a shared objective.

The third is memory: the capability retention problem. Organisations often describe themselves as learning organisations, yet many struggle to remember. Projects are repeated because previous lessons cannot be found. Decisions are revisited because the original reasoning has been lost. Experienced employees leave, taking valuable context with them. The issue is not that knowledge disappears; it is that much of it remains trapped within people, teams, and systems that are difficult to access once the immediate need has passed. Organisations generate more knowledge than ever before, yet people often struggle to access the knowledge that matters most.

Together, navigation, coordination, and memory explain why many organisations struggle to convert capability into momentum. The expertise exists. The resources exist. The intent exists. Yet progress slows because capability cannot flow efficiently through the system.

Why AI Changes The Equation

None of these challenges are new. Various attempts have been made to address them - intranets, knowledge management systems, process repositories, service catalogues. These investments often delivered value, but they shared a common characteristic: people still had to navigate the system themselves. They needed to know where to look, which repository was relevant, which process applied. The burden of interpretation remained with the user.

What has changed is the underlying capability of the technology.

Previous tools were essentially sophisticated filing systems. They could store and retrieve information, but only if you already knew roughly where to look and how to ask. Large language models work differently. Trained on vast amounts of text (documents, conversations, explanations, decisions) they understand intent rather than just matching keywords. When someone asks “who has done something like this before?”, the technology can reason about what that question means, connect it to relevant people, projects, or documents, and return something genuinely useful even when the question is loosely formed. The interface shifts from navigation to conversation.

This matters enormously in an organisational context, because most employees most of the time do not know exactly what they are looking for. They know what they are trying to accomplish. The friction has always been the gap between that intent and the structures (repositories, directories, process maps) through which the answer was buried. When that gap closes, the experience of the organisation changes.

“I need to onboard a supplier in Japan.” “Who has experience with this customer?” “What happened the last time we attempted something similar?”

Historically, people adapted themselves to the structure of the organisation. Increasingly, organisations may be able to adapt to the needs of the individual instead. Those familiar with earlier thinking about organisational operating systems or organisation-as-a-platform will recognise this moment. The conceptual frameworks have existed for some time. What was missing was not the vision but the enabling layer, the practical means by which intent could be translated into action without requiring every individual to become an expert navigator of systems they should never have needed to understand. That layer is now arriving.

Capability creates potential. Accessibility creates value.

Read on for some practical steps strategic, operational and transformation leaders can take to make their organisational capabilities more legible, connected and accessible.

Read more

How should leaders balance internal demand for agents in the short term with the need to build out the invisible infrastructure they rely on to make them safe, relevant and reliable over the long term?

A social technology that could transform human collaboration?

Rohit Krishnan is fascinated by this new cadre of what he calls Homo Agenticus Sapiens. He recently shared a thought-provoking ‘live’ list of ways in which agents are different to people and what this means for how we coordinate them. Such observations are useful in helping us understand how much we have to learn about agentic AI.

We often think of agents as units of automation, but they are more than that, and could play an interesting role in helping us improve the experience of work.

The application of even limited synthetic intelligence to process management and the coordination of work could enable us to run smarter organisations with less of the bureaucratic management overhead that is such a cost drag today. But also, by making the infrastructure of organisational coordination more machine-like, we can free people up from so much of the pointless busy work they do today and let them focus on what humans do best.

At least that is the hope.

Henry Farrell and Cosma Rohilla Shalizi considered this from a social and political science perspective in their recent (substantial) paper entitled AI as Social Technology, arguing that “AI does not hold out the promise of truly post-human bureaucracy.” It is an excellent read, but perhaps too distracted by the craziness of US politics, policy and the Doge episode to fully consider the humanising potential of de-bureaucratisation and peer-to-peer coordination in less dystopian environments. But the authors raise some quite reasonable questions:

The interesting questions involve the interaction between the ways bureaucracies abstract reality and the coarse-grainings that new AI applications will lead to. When will one system compensate for the deficiencies of the other? When will their different flavors of lossiness prove mutually reinforcing? What new problems may result from combining very different systems for managing complexity that are themselves highly complex? How will power relations change as a result? Who will benefit, and who will be hurt? These and other questions might be asked, pari passu about the relationship between AI and other social technologies such as markets and democracy too. We absolutely ought to start asking them.

The potential for agentic AI to support human collaboration was outlined and explored recently by Timour Kosters, who is studying how to use it to bring people together to achieve common goals without top-down management control.

The current discourse about AI agents centers mostly on personal agency … But personal agency is just the beginning. The question I am more interested in is what happens when agents become coordination technology: shared tooling that helps groups of humans achieve their goals. Can agents enable new interfaces for collaboration, helping people turn shared context into shared action? If agents can expand what we can do together, they could become new infrastructure for communities, cities, movements, polities, and even democracies.

I share this optimism that agentic technologies could bring exciting new horizons for cooperation by doing the boring but necessary background work of coordination, information aggregation and admin.

We tend to think a lot about agentic capabilities, but we also need to focus on agentic responsibilities if they are to co-exist with us in a messy human world.

In a recent piece for O’Reilly Radar, Artur Huk builds on Carl Hewitt’s Actor model to describe what you might call a Rendanheyi-infused agent model where responsibilities and micro-contracts bring greater governance and control to multi-agent interactions:

The Responsibility-Oriented Agent (ROA) does not invent a new distributed-systems primitive. Instead, it composes proven patterns—bounded actors, RBAC-style authority envelopes, audit trails, and execution-boundary validation—around an unpredictable LLM core. In truth, ROA is closer to a decision actor than a full computational actor: It maintains its own internal state but does not directly mutate the external world. Within a stable role, a fixed mission, and a machine-enforceable contract, it receives business events, reasons over relevant context, and emits a PolicyProposal for the Runtime to validate.

Given the success of the Rendanheyi model, perhaps agentic AI coordination can help ordinary firms enjoy some of its benefits without visionary leadership or wholesale organisational re-design.

Building the new vs. changing the old

It goes without saying that the challenges of building agentically-enhanced organisations should not to be underestimated.

If you are building agentic business infrastructure from scratch, then there are at least some architectural and infrastructural options available that are good enough to build on and evolve as new tools, tech and capabilities enter the market. Anthropic is rapidly evolving its enterprise offerings and tools, but Google and Microsoft are also developing strong platforms.

Google’s recent I/O event was heavily focused on agentic AI, and this seems to be a key focus for bringing together the company’s various AI tools into an integrated platform.

Microsoft is also working hard to evolve their agentic capabilities, with the recent release of Agent 365 bringing a control plane to Copilot studio and their Agent Framework; plus they have the advantage of being the default platform choice for most larger enterprises.

But when you really engage with the current reality and constraints inside large firms who typically suffer from legacy architecture and tools, an over-reliance on lowest-common-denominator last-gen SaaS platforms, and with a patchy history of outsourcing a lot of process work, then you start to sympathise with IT functions who are trying to respond to the growing clamour from their colleagues for agentic AI.

This is what HBR described earlier this year as the last-mile problem for enterprise AI, and their advice to treat this as an opportunity to do clean-sheet process redesign makes a lot of sense.

Just scanning my feeds for the past week is enough to make my head spin in terms of the emerging challenges agentic projects are facing:

• The pipeline tax: why putting together real-time data pipelines to support agentic AI is harder than we thought, and methods like RAG are not going to cut it.

• Context and memory persistence for long-running tasks: why we need better techniques for avoiding agentic drift over time.

• Don’t blame the model blame the harness: why harness engineering requires new developer skills to support agentic AI.

• How to prevent / manage agent sprawl if, as analysts predict, large firms end up with 100k+ agents over time.

However, the more pressing challenge, and in some ways the most worrying for many CIOs because of its unpredictability, is ballooning token costs.

Azeem Azhar and team have ben tracking this recently, and also looking at how elasticity of demand means more agentic apps become economical as token costs fall, which means the total spend continues to increase.

Today’s architectural decisions will shape the future of the agentic enterprise

Surely intelligence is not something to be outsourced over the long term, especially given the unpredictability over compute and token costs?

If we break down the level of intelligence individual agents need to do most tasks in the enterprise today, small or open models that run on your own infrastructure are sufficient for the most part, with the added benefits of more local post-training, lower latency and greater governance and control, in addition to avoiding what could be a very expensive form of vendor lock-in. Using external frontier models only for higher-level reasoning and knowledge synthesis could minimise or at least hedge against the impact of rising token costs.

But it is a brave CIO who sets a course for model sovereignty today in such a fast-changing environment. Right now there is so much work to be done at the infrastructural, data, services and apps/agents levels - all whilst keeping the lights on and putting out fires - regardless of model choice. There is a long journey of discovery ahead for agentic AI; it will not be a one-and-done shift, but more of a gradual transition.

One way or another, we need to think in terms of platforms and architectural layers, and focus on building out our own capabilities rather than ending up dependent on external vendor lock-in for what are likely to become core features of the organisation.

At the same time, however, CIOs face strong internal demand for AI tools today, and organisations need to get people thinking and learning about what agentic AI can do. If they respond to this demand by buying stand-alone point solutions that don’t deliver on integration promises, or continue the dependence on last-generation SaaS platforms with AI magic dust sprinkled over 1990s interfaces, they will be storing up hard problems (and an unmanageable estate) for later.

Of course everyone wants Claude Cowork and other advanced frontier models! For software development that is probably a good, if expensive, choice. But for most other enterprise use cases, a wholly owned open model approach, or running with the Microsoft stack if that is already the basis of your digital workplace, is likely to be enough to handle most use cases and capability needs.

A better interim solution might be to stand up just enough infrastructure in terms of connected data, MCP servers and automatable service end-points to allow people to start using personal agents in their work, and begin sharing skills, context and ideas. This would already be a step up from chatbots, and perhaps buy time and understanding for the hard work of creating the underlying infrastructure that agentic AI will need to go from personal to organisational use cases and agents.

These organisations have not necessarily moved fastest on technology. They do not always have the clearest AI strategy, the most advanced tools, or the highest rates of individual adoption. What they tend to have is something harder to name and harder to copy: the right conditions for capability to accumulate, for intent to travel without distortion, and for gains at the edge of the organisation to become gains at the centre.

This sits awkwardly with the dominant approach to AI transformation, which is built on hard edges - clear use cases, measurable adoption rates, defined ROI, governance frameworks, structured rollout plans. None of these things are wrong in themselves. But together they reflect a mental model of how transformation should work that is increasingly at odds with how AI actually creates organisational value.

That model is Pipeline Thinking. Strategy enters at one end, capability is built in the middle, performance emerges at the other end. Each stage is legible, sequential, and - in principle - controllable. It is the model that has shaped most large-scale change efforts for decades, and it feels rigorous precisely because it has hard edges.

But organisations do not behave like pipelines. And in the age of AI, the cost of assuming they do is rising fast.

Pipeline Thinking and Its Limits

Pipeline Thinking has a seductive logic. Define the strategy clearly enough, build the right capabilities, communicate intent effectively, and execution should follow. If it does not, the diagnosis is usually the same: the strategy was unclear, the capabilities were insufficient, or the communication failed. The solution is more of the same, but better.

This assumption shapes what gets counted as a legitimate intervention, e.g. hard skills, certified training, platform adoption, defined processes. These are the things that Pipeline Thinking can see and measure. What it systematically underweights is the more complex layer in between: the conditions that determine whether strategy actually takes hold, whether new capabilities spread and reinforce one another, and whether individual gains accumulate into organisational performance.

In stable environments, organisations could compensate with informal structures that absorbed variation, experience and familiarity that held things together, and managers stepping in to reconnect fragmented work.

The pipeline worked, more or less, because the gaps were filled by things no one had explicitly designed - but AI removes the sequential stability that allowed this to function. Individuals and teams can now experiment more rapidly, develop new ways of working more quickly, and generate outputs at a speed that was not previously possible. Capability accumulates fast, but so does inconsistency. Different interpretations of the same objective become embedded simultaneously. Local optimisation becomes easy, while coherence becomes harder.

The challenge is not that organisations become less capable. The challenge is that capability can now evolve faster than the conditions required to integrate it. Pipeline Thinking has no good answer to this challenge. It can accelerate the inputs, but it cannot address what happens in between.

Conditions Thinking: The Alternative Frame

The alternative is not to abandon rigour, but to apply it to the right things.

Conditions Thinking starts from a different premise: that performance is not the output of a pipeline, but an emergent property of the environment in which people and teams operate.

It does not flow directly from strategy or capability. It emerges from how those things interact, how intent travels through the organisation without distorting, how new capabilities spread and reinforce one another, how individual gains accumulate rather than remain isolated.

This reframe matters because it changes what leaders need to attend to:

• Pipeline Thinking asks: have we communicated the strategy clearly? Have we built the capability? Are adoption rates on track?

• Conditions Thinking asks: what allows intent to propagate without becoming distorted? What determines whether new capabilities spread or remain isolated? What is preventing individual gains from compounding into organisational performance?

These are softer questions, which help identify the conditions for success, but are often dismissed in traditional change thinking. They do not submit easily to the hard-edged measurement and control that Pipeline Thinking prefers. But soft, here, does not mean vague or secondary. It means distributed rather than centralised, relational rather than procedural, and accumulative rather than instantaneous.

Importantly, Conditions Thinking describes precisely the terrain where AI transformation is most likely to create (or fail to create) durable and sustainable organisational value.

What the Conditions Actually Are

Some of the conditions that matter are structural:

• The shared artefacts that carry context across boundaries

• The decision processes that make local choices visible to others

• The feedback mechanisms that allow the organisation to understand whether it is moving coherently

Others are cultural:

• The norms that determine whether new practices spread or remain isolated

• The shared language that shapes how problems are understood

• The habits that determine whether learning accumulates or dissipates

And some are coordinative:

• The specific points where work connects across roles, teams, and functions

In an earlier edition, I wrote about the coordination layer: the part of the organisation where work is connected rather than created, and where most current AI initiatives are not yet operating. In that edition, we looked at agentic process surrounds, narrow AI interventions placed at points of high coordination leverage, as one practical response to this. Not broad agents that manage entire processes, but small ones that carry context across handovers, prepare inputs for recurring decisions, or surface divergence before it becomes a problem.

Consider what happens to a recurring decision-making process when three people on the same team are each using AI differently - different prompts, different tools, different assumptions about what a good output looks like. The decision still gets made, the output still arrives on time, but the criteria have quietly diverged. Context doesn’t transfer cleanly from one cycle to the next. The manager becomes the integration point by default, spending significant time reconciling outputs that were never designed to be reconciled. Nobody names this as a conditions failure. It looks like a coordination problem, or a communication problem, or simply a busy week. But what it reveals is an environment where individual capability has advanced faster than the shared frame of reference required to make that capability compound.

These conditions do not execute strategy. They determine whether execution remains coherent as strategy moves through the organisation. Strategy survives through systems of reinforcement more often than through systems of instruction.

Which Thinking Are You Actually Using?

The distinction between Pipeline Thinking and Conditions Thinking rarely shows up in strategy decks. Both can produce the same language: capability building, adoption, transformation, impact. The difference shows up in what leaders choose to attend to, and what they leave implicit.

The difficulty is that Pipeline Thinking is not just a structural habit. It is a comfort habit. It offers legibility: visible inputs, measurable outputs, defensible decisions. Conditions Thinking requires tolerating a degree of ambiguity that feels uncomfortable when boards want hard numbers and leadership teams are under pressure to show progress. Asking “what conditions are preventing intent from propagating?” is a harder conversation to have than “are adoption rates on track?”, even when it is the more important one. The diagnostic questions below are useful partly because they make that discomfort productive.

Read more

CHROs are being asked to lead AI transformation, ensuring workforce readiness, embedding new tools into everyday workflows, and holding the culture together through a period of profound disruption. It is a significant mandate, but it sits uncomfortably alongside a question that has been building for years and that AI has now made urgent: what exactly is HR for?

The old answer was that HR owns the programs; talent acquisition, compensation, learning and development, each with its designated custodian, but that no longer seems strategic enough. Organising around programme ownership rather than whole system performance has left a critical gap, one that AI adoption and change efforts are now falling into.

Some commentators argue that the existing mandate and role focus can be expanded to cope with the manifold challenges posed by AI transformation.

Oracle’s Yvette Cameron recently wrote for Diginomica that HR can step up in its current form to play a leading role in AI adoption through workforce readiness, personalised workflow integration, and a supportive culture, and shared the following starting points:

• Build trust through transparent AI

• Embed AI in everyday workflows

• Scale AI pilots with human insight

• Follow a practical roadmap for HR leadership

These are necessary but not sufficient. They assume that the existing model of HR, organised around programmes and interventions, can stretch to accommodate AI. Increasingly, that assumption looks fragile.

Others think it is time for a reset and a re-focus within HR leadership.

TalentSherpa recently shared an article about the need for a new Human Operating System, arguing that the CHRO should evolve into a human systems architect without accountability for outcomes or risk falling down the strategic food chain.

The old model organized HR around program ownership. Someone owns talent acquisition. Someone owns compensation. Someone owns learning and development. These roles are defined by the programs they run, not the outcomes those programs produce.

The new model organises around system performance.

At its core, this is a shift in responsibility. Not just from programmes to systems, but from delivery to stewardship.

If leadership in the age of AI is increasingly about world-building (shaping the conditions, constraints, and environments in which people and machines operate) then the CHRO’s role becomes one of enabling and stewarding that world.

Not just owning outcomes directly, but ensuring the system in which those outcomes emerge is coherent, legible, and sustainable.

Missing Infrastructure to Support Human Performance

When you look closely at what determines whether AI actually takes hold in an organisation, the same missing layer keeps appearing. It isn’t the technology or even the strategy, but more often the human infrastructure underneath that is holding back progress, including the conditions and incentives that encourage people to learn, adapt, make sense of change, and to keep performing well through it.

In practice, this missing infrastructure shows up in identifiable ways:

• Teams using AI differently with no shared standards of judgment

• Little visibility into how decisions are being made with AI support

• No mechanisms for comparing, learning from, or improving those decisions over time

Ashley Goodall points out that we know a great deal about the ingredients of human performance, but most of that knowledge never makes it into management or HR practice. Human performance isn’t treated as an HR problem, so the accumulated understanding of how to help people do their best work has nowhere to land:

The opportunity is clear: we know an awful lot about the ingredients of human performance—but much of what we know doesn’t make it into our management or HR practices, with the result that too many workplaces actually impair human productivity. This is in large part because human performance isn’t considered an HR problem, and so the accumulated knowledge of how to help people do their best work has no place to land inside a typical organization.

In other words, we already understand a great deal about human performance, but we have not designed our organisations to operationalise that knowledge. That gap matters enormously in an AI context, because adopting AI is a continuous, social, often disorienting process of figuring out what your work means now, what you’re responsible for, and what good judgment looks like when a machine is doing some of the labour.

We are seeing too many policies mandating the use of AI without providing the learning, guidance and context that people need to make sense of how it connects with, and ideally enhances their existing work.

AI adoption must also engage with the cognitive impact - positive and negative - of using AI for more and more of our work. In HBR this month, Guy Champniss lists six areas of psychological cost relating to AI usage, and points to existing knowledge and practices in behavioural science that could help mitigate them if applied:

• Cognitive Debt

• Autonomy Debt

• Competency Debt

• Relatedness Debt

• Credibility Debt

• Professional Identity Debt

It is impossible to predict at this point just how AI will transform the workplace. However, one thing is certain: understanding and building the right human infrastructure will be as important as picking the right AI tools

What Happened to Social Learning?

Another area of missing HR infrastructure relates to social learning and collaboration. We did a lot of work in the early 2000’s on social learning as a way to accelerate digital collaboration skills within organisations, and it was a very effective area of intervention. But it feels like most companies let this learning slide and reverted to their old ways as the economy tightened after 2008.

More recently, we have written a lot about the relationship between learning, HR, and change; and how AI could transform each of them. Learning is not a separate activity that happens outside the flow of work, but it needs to be integrated with knowledge development and change to have a direct impact on human performance.

As Jane Bozarth put it for the Association for Talent Development, sense-making and meaning need to come before action, including in relation to AI adoption.

This is why work improves when learning happens socially. When colleagues talk through cases, narrate decisions, and share lessons learned, they begin to see patterns sooner. They recognize implications earlier and, ultimately, make better judgments.

She lists a few of these areas that make up a social learning infrastructure:

• Networks that connect people across boundaries

• Communities of Practice that sustain professional dialogue

• Habits of working out loud that make thinking visible

• Cultural signals that curiosity and sharing are valued rather than risky

These capabilities don’t sit neatly inside any single HR program, so often nobody owns them, which is precisely why they don’t get built.

The influential learning consultant Josh Bersin goes further, arguing that our entire approach, philosophies, tech stack, and operating models for learning are out of date.

HIs latest research report into corporate learning found that 74% of companies tell us they are not keeping up with their company’s demand for new skills. The traditional response of more training, better content, or a refreshed LMS won’t close that gap. The problem isn’t a shortage of courses, but the absence of a dynamic knowledge infrastructure where information flows across boundaries, people can explore and question in real time, and learning is woven into the flow of work rather than scheduled around it.

Our skills challenge at work is not one of “learning” or “training.” Rather it’s a problem of dynamically sharing information, enabling people to explore, question, and apply new ideas. The traditional pedagogical paradigm of “training” is holding us back.

From Program Owner to System Architect

This is where the CHRO’s role needs to evolve.

The shift is from owning programs to architecting system performance, which means taking accountability not for whether the learning platform has good content, but for whether the organisation actually gets better at what it does. In that sense, the CHRO becomes a key steward of the organisation’s operating environment, the human layer of the world leaders are now being asked to build.

Having an AI adoption programme and dutifully tracking its roll-out status is less important than ensuring people are genuinely equipped — psychologically, practically, socially — to work well alongside AI over time.

That is a bigger job that requires a different relationship with data, with line leadership, and with the outcomes the business cares about. It means HR stops being the function that runs things and becomes the function that understands, designs, and continually improves the conditions under which people perform.

Perhaps due to its people mandate and CHRO seat at the top table, HR is uniquely positioned to bring structure to the balance between AI innovation, culture, and governance. But only if HR is willing to claim that territory with genuine authority, rather than waiting to be handed it.

The CHROs who will matter most in the next five years won’t be the ones who ran the best AI programmes.

They will be the ones who recognised that AI does not fail at the level of tools or training, but at the level of systems, and who took responsibility for building the human infrastructure those systems depend on.

HR will not lose relevance because of AI. It will lose relevance if it continues to organise around programmes in a world that now runs on systems.

The result is a strange pattern: more activity, without a corresponding increase in momentum. This is partly a question of where AI has been applied. Most adoption today sits at one of two extremes. At one end, organisations pursue large-scale transformation: redesigning processes, introducing automation, and attempting to remove bottlenecks from entire workflows. At the other, individuals experiment at the edge: using AI to support their own work in small, often isolated ways.

Both directions create value but they operate at very different levels. Transformation operates at the level of the system. Individual use operates at the level of the task. Between them sits a third space that is far less visible, but more consequential: the shared work of the team.

This is where the next generation of human-AI collaboration is most likely to emerge. Not through a single, centrally approved transformation use case, and not through everyone individually prompting their way through the working day, but through narrow, focused forms of AI support that help teams coordinate specific pieces of shared work more effectively: an agent that maintains context across a handover; an agent that prepares inputs for a recurring decision; an agent that tracks divergence between workstreams. Small capabilities, placed at the points where work connects.

This middle ground is rarely the focus of AI initiatives. It is too granular for transformation programmes, and too collective for individual experimentation. This space needs a clearer name if it is to be worked on deliberately.

The Coordination Layer

The coordination layer is the part of the organisation where work is connected rather than created. It is where individual outputs are brought into relation with one another, where decisions are made in the context of other decisions, and where progress depends not only on the quality of individual contributions, but on how effectively those contributions come together.

This is also the layer where centaur teams become real, or fail to. A team does not become a human-AI team simply because individuals use AI tools, or because a process has been automated somewhere upstream. It becomes one when AI starts to support the shared coordination of work: helping context move, helping decisions stabilise, helping people understand what has changed, what matters, and what needs attention next.

This layer is present in almost every team, although it is rarely named as such. It can be seen in the flow of updates that turn activity into a shared understanding of progress, in the handovers that move work from one role to another, and in the recurring decisions that shape priorities, trade-offs, and direction. It also exists in the less visible forms of coordination — the informal knowledge carried through conversations, habits, and experience, relied upon even when it is never fully articulated.

When the coordination layer works well, decisions feel connected rather than isolated, context is preserved rather than reconstructed, and effort accumulates over time instead of dissipating across boundaries. When it works poorly, work fragments, decisions are revisited, context is repeatedly rebuilt, and progress slows because the connections between individuals are weak.

This layer has always existed, but it has rarely been treated as something that can be deliberately designed. Instead, it tends to emerge through a combination of process, habit, and individual intervention. Managers step in to resolve ambiguity, teams develop informal ways of keeping each other aligned, and work holds together through experience and continuous adjustment.

AI enters this layer in an unusual way, exposing the mostly implicit or informal ways in which work outputs are connected and combined. As long as coordination remains informal and partially invisible, it is difficult to improve in any systematic way and difficult for AI to meaningfully participate in. Systems can generate outputs with increasing speed and quality, but they struggle to integrate those outputs into a flow of work that depends on shared context, judgment, and timing. This helps explain why so many early gains from AI remain local.

The Failure Mode

If the coordination layer is where work comes together, then most current approaches to AI are operating around it rather than within it. This pattern has been visible in previous waves of digital transformation, particularly in how organisations approached the idea of “use cases.”

At the strategic level, use cases focused on large, cross-cutting ambitions, often framed around ideas such as a single face to the customer. At the other end, individual use cases were relatively easy to identify and act on. Between these sat a more complex space: the level of key processes and shared workflows, where work moved across teams, functions, and systems. This was where coordination was most critical, and where the underlying structure of work was often least visible.

These process-level interventions touched many people, relied on partially visible forms of coordination, and were frequently underpinned by informal practices that were not fully documented or understood. Changing one part of the flow risked unintended consequences elsewhere - the spreadsheet, workaround, or habit that quietly held a process together. In practice, this meant the middle ground was often left under-explored. Not because it lacked value, but because it lacked clarity, ownership, and safe ways to engage with it.

Where organisations made progress, it was typically because this layer was made visible in a structured way. In a technique we call social process surrounds, we break down key processes into their component stages, identifying where collaboration, data sharing, and knowledge flow are failing, and then mapping where small, targeted interventions could improve how work connects across those stages.

The same pattern is now re-emerging in the context of AI. The dominant use case logic still pulls organisations towards the extremes. What is harder to legitimise is the team-level use case: narrow enough to be specific, but collective enough to require shared design.

The consequences are now more visible. Work moves faster at the edges, but slows as it comes together. Outputs arrive in greater volume, but require more effort to interpret, reconcile, and integrate. Decisions are made more quickly in isolation, but take longer to stabilise when they interact with other decisions. As individuals optimise their own tasks, variation increases — and without a shared frame of reference, these local optimisations introduce small inconsistencies that must be resolved through additional coordination.

Managers, often without formal recognition of the role they are playing, become the point at which this gap is managed. As the volume and variability of work increases, so too does the demand placed on this form of intervention. People are expected to adopt AI, but are left to do so individually. They experience gains in their own work, but also an increase in the effort required to stay aligned with others.

Working on the Coordination Layer

If the coordination layer is where work either holds together or breaks down, then the first step is to learn how to see it. This layer does not present itself as a single system that can be redesigned in one move. It is distributed across workflows, roles, artefacts, and habits, and for this reason tends to remain partially invisible in how work is described or measured.

A more effective starting point is not to treat it as a system to be replaced, but as a layer to be observed. This requires a shift in attention away from what work is being done, and towards how work moves and flows: where it slows, where it fragments, where context is lost or reconstructed, and where decisions depend on inputs that are not consistently available.

What becomes visible through this lens is a pattern of disconnection. Information that is assumed to be shared turns out to be fragmented. Workflows that look linear are, in practice, iterative and contingent. These coordination points are where the most useful AI opportunities are likely to sit, not broad agents that “manage the process,” but narrow agents that help with one recurring coordination burden: assembling the right context, preparing a decision, carrying information across a handover, or making divergence visible before it becomes a problem.

From Social Process Surrounds to Agentic Process Surrounds

Focusing on social process surrounds was particularly valuable in precisely the areas that are now coming back into focus: key processes that spanned multiple teams, where coordination was fragmented, partially visible, and often dependent on informal practices that no one wanted to disrupt without fully understanding.

What made this work was not the scale of the intervention, but its placement. By improving how work connected at specific points in the flow, it became possible to increase coherence without changing the underlying process itself. AI changes what this kind of approach can do.

Where social process surrounds focused on improving collaboration between people, an AI-augmented surround can begin to participate more directly in coordination itself. This does not mean creating a single agent to own or optimise an entire process. More often, it means placing narrow agents around the process at specific coordination points, where they can maintain a shared view of work, surface relevant context, support the aggregation of inputs, or highlight divergence from expected patterns.

These coordination points tend to appear in recurring moments: preparing inputs for a decision that draws on multiple sources; handing work from one team to another with enough context to avoid rework; consolidating updates into a shared view of progress; identifying where parallel workstreams are beginning to diverge. In most organisations, these moments are handled through a combination of manual effort, experience, and follow-up.

These are precisely the points where narrow AI capabilities can be most effective:

• An agent that prepares and structures decision inputs before a meeting.

• An agent that carries forward context across a handover so it does not need to be reconstructed.

• An agent that flags inconsistencies between updates from different teams.

• An agent that maintains a shared, current view of work as it evolves.

Individually, these are small interventions. But because they sit within the flow of coordination, their effects extend beyond the immediate task. The surround becomes less like a static collaboration space and more like a living coordination environment, not replacing the core process, and not removing human judgment, but helping the team carry the connective work that would otherwise depend on memory, manual follow-up, and individual intervention.

These interventions are often smaller than expected, but they operate at points of high leverage. They are exactly the sort of narrow AI interventions that make centaur teams a reality.

Read on to learn about places to get started.

Read more

Adoption programmes are not cutting it, and their focus on getting people to use the tools that companies have licensed is too tactical. Instead of adoption we need adaptation, and conventional ‘change management’ is not going to get us there.

We are making tremendous progress in AI tech, but this is currently outstripping the ability of organisations to deploy it.

Models and Agents Roundup

The past couple of weeks have seen the launch of major model updates from OpenAI and Anthropic - GPT-5.5 and Opus 4.7 - and a major new milestone for open models with DeepSeek 4.

Ethan Mollick rates GPT-5.5 highly, and from reviewing OpenAI’s prompting guide for 5.5, it seems to be a powerful model that responds well to sophisticated use cases. And DeepSeek’s new models are an order of magnitude more efficient than leading models from Anthropic and OpenAI.

Google has also recently released all kinds of stuff, from model updates to an enterprise agent platform. For an insight into their strategy, Ben Thompson’s interview with Google Cloud CEO Thomas Kurian is worth a read.

Meanwhile, the much-hyped Mythos model is not as dangerous as we were led to believe. Anthropic’s super-scary bug hunting model Mythos is shaping up to be a nothingburger, according to the Register.

The pattern is clear: capability is compounding rapidly across performance, efficiency, and deployability. The gap is becoming organisational.

Intelligence on Tap, but the Plumbing is Faulty

Model progress is amazing, and there is a lot more going on in the open models world than just DeepSeek, so I remain of the view that most enterprise AI usage could eventually be driven by open and small models locally owned and hosted, supplemented by calls to proprietary models where needed. Both DeepSeek and Apple’s slow-burn edge computing strategy for on-chip AI point to huge potential for more efficient AI computing.

But for now at least, the Capability Absorption Gap in most organisations outside of software engineering means that enterprise AI usage is developing far slower than the technology. And given the pressure on CIOs to demonstrate ROI, many of them could end up relying on heavily compromised but good-enough Frankenstein’s Monster solutions from the main enterprise platform vendors.

Another recent Enterprise AI adoption research report shows companies struggling with adoption:

Despite near-universal belief in AI’s potential, most organizations are struggling to translate adoption into real business value. Executives are facing growing pressure and challenges around AI strategy, productivity expectations, security and governance, and shifting power dynamics.

The 2026 survey findings reveal 79% of organizations face challenges in adopting AI — a double-digit increase from 2025 — with 54% of C-suite executives admitting that adopting AI is tearing their company apart. This is despite the fact that 59% of companies are investing over $1 million annually in AI technology.

If we continue down the incremental change management route and target marginal productivity gains from applying AI to existing ways of working, then we could end up with slightly leaner versions of last generation organisational systems, rather than better organisations overall.

That’s what happened with the initial electrification of factories from the 1880s onwards, and it took until the 1920s for major productivity gains to arrive, once factory owners had re-designed their work systems.

Technology diffusion is hard enough, but the re-tooling or re-design of organisational operating systems to really take advantage of AI is a big challenge for leaders whose whole careers have been shaped by navigating a bureaucracy.

Even the question of what this means for jobs is hard to answer at this liminal moment. Hiring and firing in response to AI is all over the place, which prompted the Financial Times to declare recently that the jobpocalypse narrative has been over-done:

“Can AI do this task?” is a useful starting point for thinking about how it might impact employment, but it is an ambiguous signal that forms only one part of a large and complex picture. Considering the other factors that can shape job growth, directly or indirectly, helps to explain why thus far those occupations that are most exposed to AI are as likely to have grown as to have shrunk.

Knowledge Engineering is Key to AI Readiness

One reason for the gap is a focus on targeting tool use and basic adoption rather than cultivating AI readiness in areas such as knowledge engineering.

Although the major consultancies could be rendered obsolete by AI in their current form, that is not stopping them from treating AI adoption like one last opportunity for body shopping, powerpoint strategising and building dependence on external advisors.

One LinkedIn commentator recently noticed that McKinsey published an AI transformation manifesto without mentioning the most obvious readiness challenge:

If you write a manifesto about AI transformation and never once use the word “knowledge”… you might be missing what AI actually runs on.

We have written a lot about the advantage that wiki-based firms have over PPT-based firms in terms of their work being legible and learnable. The more you write things down and structure your knowledge, the better your AI agents will perform.

But that should not mean that companies seek to suck all the knowledge out of human workforces to codify it and then dispense with their services. Knowledge doesn’t really work like that. It is social, connected, often ambiguous and implicit rather than explicit.

Interestingly, some firms are buying up the conversational and collaborative exhaust of defunct start-ups to train AI models, which feels slightly ghoulish. Other consultants are starting to talk about AI-enabled knowledge transfer, such as this report by KM practitioner Ross Dawson and colleagues at Humans+AI.

I suspect there are many ways in which AI can help people collate, organise and share their knowledge that are more protective of the human element than just extraction and codification. It will be interesting see how this develops.

Building Strategic Thinking Muscle

But we also need to go beyond basic knowledge engineering.

We are working a lot on the challenge of cultivating AI literacy for large firms in a way that brings together all layers of a large organisation and all knowledge levels in a common narrative of world-building.

Literacy is such an evocative term as it touches language (both human and computational), world knowledge, clarity of thought and expression, as well as other areas of cognition and experience.

If our ambition is not just to adopt new tools to speed up the old manual process structures, but rather to adapt the organisation to what AI makes possible, then we need people to expand their literacy and their thinking in various ways, and not just learn how to operate a chatbot.

A valid critique of the messy liminal phase AI has reached in the workplace is that many of us are suffering from software brain - the idea that everything we do can be captured in a database and organised or automated.

Nilay Patel, Editor-in-Chief of The Verge shared a widely discussed polemic last week arguing that most people - and a significant number of younger people - do not want to be flattened and automated away by AI, riffing on this idea of software brain:

For everyone else, AI is just a demanding slop monster. It’s a threat. I’m not saying regular people don’t use Excel or Airtable to plan their weddings or have fun throwing PowerPoint parties, or even that AI won’t be useful to regular people over time. I think a lot of people enjoy data and tracking different parts of their lives. I’m wearing a Whoop band as I write this. I’m just saying these things aren’t everything. Not everything about our lives can be measured and automated and optimized, and it shouldn’t be.

It’s a critique worth engaging with, and I believe there is a big enough landing zone for pro-human AI-enhanced organisations somewhere between automated workhouses and artisanal candle shops that we can aim for.

But if we want people to help build the new, rather than keep poking around in the old systems, then we need to cultivate their literacy and learning more effectively than we have done to date.

Brandan McCord recently shared a great introduction to the concept of Bildung and the role it played in transforming the Prussian education system after their defeat by Napoleon that is relevant to the adoption of AI:

With AI, we are building something like self-guided machines. Whether these systems liberate or merely displace is not settled. But the possibility of leisure at scale is real enough to become a serious question.

If AI can compress parts of instruction, it may deepen learning where it is used and clear ground for formation where it gives time back. But only if it preserves productive struggle rather than bypassing it.

The alternative is already visible: autocomplete for life. Not just help with expression, but the slow outsourcing of judgment itself. That is Bildung’s antithesis.

Another good read in this general direction is Neil Perkin’s recent newsletter on the need for an AI philosophy and not just an AI strategy.

It might sometimes feel like building better organisations is too hard, but there are plenty of examples around us of either a visionary leader or a compelling burning platform (or both!) creating the conditions where rapid evolution against the odds can produce winning systems.

Azeem Azhar shared a thought-provoking analysis from his team a few days ago about how Ukraine was forced to innovate in defence in order to survive, and it really shows what is possible when people have ownership, agency and very open and rapid feedback loops between producers and users. People can do anything with the right motivation.

If organisations respond to AI by forcing people to become more legible to machines, they will fail, socially, culturally, and ultimately economically.

But if they invest in human capability - judgment, learning, knowledge-sharing, and strategic thinking - they have a chance to build something far more powerful: organisations that are not just more efficient, but more adaptive, more coherent, and more human.

The Capability Absorption Gap will not be closed by a better toolset, but by better organisations.

It may be quicker and more effective to build net new capabilities and functions, rather than deploying AI in support of old ways of working, as factories initially tried with their electrification around the turn of the 20th Century.

‘Change’ is a very messy, human challenge; but there might be ways in which agentic AI can help us involve everybody and guide a distributed approach, helping track progress, and making the organisation more legible in real time. This is something we are exploring, so we might return to this topic soon.