Chapter 7
Your Colleague is a Robot
The Utopia of the Agentic Enterprise, Part II. The Agents Who Take Your Job
My first job was an apprenticeship at a telco, in an office above a high-security data centre. My manager had an idea: rent out servers by the hour. This was before AWS and Azure dominated the market, when the standard terms were a 12-month commitment and the hardware was bought only after the deal was signed. He sat me in a corner with a few old PCs and let me play with virtual machines. At the time, this was the bleeding edge of technology. We got it working, at least for the demos. But commercially it made no sense to anyone else in the building. The telco’s business was effectively fixed income, and revenue secured for an hour looked like a step backward.
The project never reached the market. The conclusion was that customers wanted cheaper server contracts, and the way to make contracts cheaper was longer commitments: a pricing problem, solved with a pricing response. That the market might want capacity on demand, with no commitment, wasn’t so much rejected as never seriously considered. The economics pointed one way, the institution’s understanding of its own business pointed the other, and the institution won, for a while.
The Agile revolution was getting popular around the same time. A growing number of successful software companies could do things faster and cheaper. The cost of change was falling, and the organisations that adapted outran the ones that kept trying to plan change away. That was a problem for everyone else, because customers started demanding cheaper products with shorter change cycles. So, predictably, the incumbents responded the only way they knew. The board decided the organisation needed to become agile. No one knew what that meant, so they hired consultants to explain it to them. The consultants, of course, were there to give advice.
Taken seriously, agile would have meant trimming middle management, the same people who’d been put in charge of making the company agile. Nobody volunteered to fire themselves. After all, they had kids in school and mortgages to pay. So they found a version of agile that left the org chart alone. Monthly management meetings were relabelled sprints. The minimum viable product became an excuse to squeeze an unfinished product out within budget, when the principles would have led you to define “viable” more carefully. The language was adopted and the substance stayed where it was.
Rebranding something that already exists as “AI-powered” is much easier than changing what’s underneath. And from inside the building, a shift in the economics of the business looks like an adoption problem, so it gets an adoption push. When the push stalls, it stalls at a particular level and for a particular kind of reason, and it helps to know both before anyone prescribes a fix.
Tool, Workflow, Operating Model
Like all new technology, the leadership teams meet AI through board pressure and vendor demonstrations. The information is incomplete and optimistic, filtered by those who benefit from adoption, starting with the people selling it. The board releases a budget, and the organisation reaches for the only playbook it has: deploy, train, measure adoption. Possibly hire a consultant to help. Which works fine as long as a new tool comes in and the work stays the same.
Factories did the same with electricity. From the mid-1890s to the 1920s, American factories electrified by adding electric motors to their old shafts and belts, and kept the steam engines in place as spare capacity. Electric power didn’t lift productivity in manufacturing until the early 1920s, four decades after the first central power station opened. The gains came once factories were built for it, with a motor on each machine and a single storey laid out around the flow of materials. The economic historian Paul David found that the motors on the machines accounted for about half the speed-up in manufacturing productivity growth in the 1920s.1
Tool adoption is the easiest level. Individuals learn to use the AI tools, and most of what goes wrong can be fixed with onboarding. Organisations like to concentrate here because the metrics are visible, and a number that goes up is easy to report to the board. A CTO can do all of it without asking anyone.
Workflow redesign is harder. Here teams change how work moves between people and AI, which means deciding what to delegate and who checks the result. Once two functions have to agree on an AI-assisted handoff, someone above both has to get them into a room and arbitrate. Anyone who has watched two departments agree on a shared process knows the negotiation takes months, especially if it changes how budget and bonuses are allocated. If it succeeds, the credit is spread across everyone who attended the meetings. If it fails, the sponsor owns it.
Operating model change is the hardest. Now the organisation restructures roles and incentives, and that needs HR and the C-Suite behind it, ideally at the same time. Every decision about headcount or pay has a constituency that will resist it.
So plenty of organisations stay on the first level and call it transformation, which can go on for a long time, because the numbers keep going up and nobody has to renegotiate anything.
In early 2026, the Financial Times reported that Accenture had informed associate directors and senior managers that “regular adoption” of its AI tools would be a requirement for promotion to leadership positions.2 An internal email, seen by the FT, stated that “use of our key tools will be a visible input to talent discussions.” By then the company had reskilled 550,000 of its 780,000 employees on generative AI fundamentals, and its CEO had told investors that staff who couldn’t reskill would be “exited.” Which you would think is motivation enough. And yet the senior staff still weren’t using the tools enough, so the login dashboard was tied to the promotion cycle.
Obviously, the policy measures logins. It says nothing about what anyone produced with the tools after logging in, which is presumably the part the clients pay for.
And Accenture is a firm companies hire to guide their own AI transformation. If it has to track logins to get its own senior people to use the tools, the clients paying it to drive adoption could reasonably ask what it will achieve for them. Then again, a login dashboard is a deliverable, and deliverables can be billed.
Organisational sociology described this kind of policy long before anyone wrote it. In 1977 John Meyer and Brian Rowan argued that much of an organisation’s formal structure exists to signal legitimacy to outsiders rather than to coordinate work, and that the organisation protects itself by decoupling the two: the structure is displayed, the work carries on regardless, and nobody inspects the gap too closely.3 Six years later Paul DiMaggio and Walter Powell added why a whole industry ends up with the same structure.4 Under uncertainty, organisations copy the ones that look successful, and the consultants and business schools carry the template from one to the next, for a fee. An AI adoption mandate is that mechanism running in real time. The board wants the company to look like the companies in the keynote, and a login dashboard is the quickest way to produce the look.
The push stalls roughly where the CIO’s and CTO’s authority ends. They can authorise tool adoption alone. Workflow redesign needs teams with different bosses and different incentives to agree, and operating model change means restructuring pay and authority across the organisation, which is politically expensive and uncertain in outcome.
Uncertain in outcome because the technology is changing faster than anyone can learn it. The rational thing, then, is to buy licences and run training, which can be undone, and put off whatever can’t be. A licence can be cancelled at the next renewal. A reorganisation can only be undone by another reorganisation, and nobody wants to sponsor that one.
Every function involved has a fix ready, and finds a problem to match. The technology team sees a technology problem, and the change managers, trained in psychology and communication, see a psychological one. But when things don’t add up, follow the money.
Money takes more forms than the project budget itself. Headcount is money, and so is a grade. Milton Friedman, the free-market economist, pointed out that nobody spends somebody else’s money as carefully as their own.5 Inside a company it’s all somebody else’s money, so everyone involved spends it rationally, given their own targets and constraints. The executive sponsor gains visibility and credit, and probably a slide in the next investor presentation if things succeed. But he also has an incentive to set up a steering committee for plausible deniability in case it doesn’t work out. Nobody wants their name on a burning platform. When middle managers lose people, the structure that justifies their grade goes with them. Sometimes the team stays and picks up work it would rather not do, on a budget that doesn’t cover it. If nothing gives the people who lose a share of the gains, holding back is the rational response. It needs no bias to explain it, and in meetings it comes out as “what happens to my team?”
So in the end the organisation deploys technology, because technology can be bought and run within one team’s authority. When adoption plateaus it must be the people and their resistance to change. When the people push back with perfectly good reasons the deployment never addressed, leadership buys adoption enforcement, of which there is plenty on offer, and calls it change management. Meanwhile the technology team and the change managers compete for the same budget, each holding half a diagnosis.
What’s new is giving agents autonomy, and it works much like giving it to middle managers. A manager with autonomy gets a goal and a budget and decides the steps, and nobody above can check every one of them. When the board wanted the company to become agile, it gave middle management the goal and no reason to want it, and they found a version that left the org chart alone. A department handed agents faces the same choice. If whatever the agents save comes out of its budget next year, the rational response is a version of agents that leaves the department as it is. A share of the savings gives it a reason to make them work.
The agents need what a good manager is given, the task and what the task is for. The task is the easy part to write down, and it’s what the prompts and evals are built around. The purpose is what a manager falls back on when a case comes up that nobody wrote down, and an agent without one finds its own.
Graeber collected his evidence from confessions. People wrote to him about their own jobs, and he had to take their word for which parts were pointless. An agent’s job is written down, in its instructions and the list of systems it’s allowed to touch, and everything it produces is logged. So the question he put to jobs can be put to an agent with evidence, and the answer costs nobody their mortgage.
The log is easiest to read by sorting what the agent produces by who consumes it.
| The output goes to | Graeber’s type |
|---|---|
| a superior, as reassurance | flunky |
| the other side’s agent | goon |
| a defect somewhere else, to cover it | duct taper |
| a file, as evidence | box ticker |
| a colleague, who now has a task | taskmaster |
| someone it changes something for | real work |
The sort has a trap, and an advertising man described it. Rory Sutherland calls it the doorman fallacy: define a hotel doorman’s job as opening the door, and an automatic door can replace him. But opening the door was only the notional part of the job. The doorman also kept out people who had no business inside and recognised the regulars, and having him there let the hotel charge more for a room.6 Graeber, writing a year earlier, gave doormen as the most obvious flunkies there are, doing for the very rich what an intercom has done for everyone else since the 1950s.7 Both had a point, about different doormen. The residents’ sense of their own importance was a flunky’s output. The guests paying more for a room were getting something they wanted.
An agent built from a job description gets the door. Whatever the person in the role did for consumers nobody listed stops when the agent takes over, and the agent’s log can’t show it, because the log only records what the agent does. So the sort needs a second list, of who used the work before it was handed over. Where the two lists differ, someone has stopped getting something.
Checklist
- Who has to say yes for this to move? Tool adoption, workflow redesign and operating-model change need different authority. Does your sponsor hold it?
- Are you counting logins and licences and calling it transformation?
- Who gains and who loses if AI is adopted at scale, and is there a credible way for the people who lose to share in the gains?
- Does the intervention fit the diagnosis? Training can’t overcome a rational economic reason to resist.
- For each agent you run, who consumes what it produces? And who used that work before the agent took it over?