Chapter 2
What is a Job and how does the Robot take it from you?
The Utopia of the Agentic Enterprise, Part I. The Jobs the Agents Are Here to Take
The office of the future will have only two employees, a manager and an AI agent. The manager will be there to sign off the agent’s work. The agent will be there to keep the manager from touching it.
At the software companies that adopted AI early, meetings changed well before any job title did. By now an AI agent joins the calls and takes the notes, sometimes in place of someone who didn’t. The summary and the action list reach everyone before the call has even ended. So the people who used to attend only to find out what was decided now just read the summary, and some of them send their agent instead.
A product manager at one of these companies runs the same weekly planning meeting they ran two years ago. Some of the people on the call are there, and some have sent a bot. The summary is accurate, and everything in it was said, word by word. But it leaves out the awkward pause before the platform team agreed to the date. The people actually on the call knew what that pause meant: the date would slip.
Their title and pay grade haven’t changed. “Product Manager” is a title and a box on the org chart, and like most titles it says very little about what the person does all day.
Task, Workflow, Role, Job
The title covers tasks, workflows, a role, and a job, and they move at different speeds.
A task is bounded: write up a ticket, or check a design doc against the security checklist. A task has a done state and a way to check it. Tasks are what AI systems do competently right now.
A workflow is tasks in sequence with state. A feature runs from design doc to release. Workflows are mostly about handoffs: what state the work is in when the next team picks it up.
A role is a bundle of tasks and workflows plus the judgment that binds them: knowing which team’s dates to believe, or when to stop a release. Nobody designed the bundle. It grew over decades, because coordinating work across people is complicated.
A job is a role plus accountability and status. It’s what HR’s salary band tracks, and what the person answers for when something goes wrong. Jobs move slowest, and tasks are always changing.
So far, AI operates on tasks, and now and then on workflows. Which is why watching job titles tells you almost nothing about what it is doing to work.
What the tools actually removed from the product manager’s week was the evening before planning. Reading the specs and the customer-call notes, and somewhere along the way working out that two teams had promised the same customer different dates.
Nobody would have listed that evening as a deliverable, and nobody logged it on a timesheet. But it was how the manager built the picture they took into the meeting. The summaries they get now are accurate and complete, but reading them doesn’t build that picture. So these days the customer finds the clash before the planning meeting does.
Losing that evening is what the agent changed in the product manager’s job, and the org chart recorded nothing. An agent changes the job it is put into, and the change comes in several kinds. Before any AI system goes live, somebody should be able to say which kind it will make, and to whom.
Enrichment. The time a tool takes off a task becomes work the same person can decide. They find the problem, and they are allowed to fix it. That needs work the organisation values. Where the measure counts volume, the hours fill straight back up.
Intensification. The system clears the cases it can classify and passes on the rest, so one person gets more hard cases than before. The ordinary cases, which were how they learned to recognise the hard one, no longer reach them.
Expansion. Drafts cost nothing, so the same person puts out far more of them. Whatever still needs their sign-off grows at the same rate, and their hours don’t.
Fragmentation. Work one person owned from end to end is split across systems that each produce a correct part. The person keeps the responsibility and sees one part of it, so when the customer disputes the whole, nobody can explain it.
Deskilling. The method moves into the model. Review takes minutes instead of hours, and the practice that made the review worth having stops.
Emergence. The tool creates work nobody had before. Checking a draft turns out to be harder than writing it was, and someone has to keep the templates the system drafts from up to date. Neither was in the business case, which was about saving time.
Elimination. Too little coherent responsibility remains to hold a job together. Which says something about the old cost structure, and nothing about the people who did the work.
One rollout can make several of these changes at once, enrichment for the people who take over the hard cases and deskilling for the ones left reviewing the system’s recommendations, all under the same job title.
There is an older way to score the same list. In 1976 Richard Hackman and Greg Oldham, working from studies of job redesign in the previous decade, found that five properties of a job predicted whether the person doing it would care about it: how many skills it used, whether it produced a whole identifiable piece of work, whether it mattered to someone, how much say the person had in how it was done, and whether they found out how it turned out.1 Every change above except enrichment removes at least one. Fragmentation takes the whole piece of work, and the review queue takes the feedback, since approving a dozen drafts doesn’t tell you which of them went wrong later. The model is 50 years old, which you’d think is long enough to make it into a business case template.
That does not keep the trailblazers of the industry from announcing AI they hired robots to run their companies now.
In 2025 Salesforce’s chief executive, Marc Benioff, said on a podcast that AI agents now handled half the company’s customer conversations, and that he had cut support from 9,000 people to about 5,000, “because I need less heads.”2 The quieter way to replace a job starts with a project, and the first thing it needs is a description of the work, so somebody has to write it down. The obvious choice is whoever does the job now. They write the instructions an agent can follow, the agent is tried on past cases, and they mark the result. If the output matches what they would have produced, the match rate goes into the headcount case, which makes the person being replaced the examiner as well.
Each step leaves something out. A product manager can list the reading of specs and the summarising of calls. The evening of reading before the planning meeting isn’t on the list, because nobody ever called it work. And the past cases the agent is tested on include every report that was produced and never read, so a high match rate shows the copy is faithful and says nothing about whether the work was needed.
The person doing the job also knows which parts are pointless. Much of Bullshit Jobs rests on accounts people sent Graeber about their own jobs. They knew perfectly well which parts of their work were pointless and kept quiet about it in the office, because saying so there amounted to a resignation letter. Listing which reports get read and which approvals are theatre would mean admitting years of waste, in a steering committee quite possibly chaired by the people who commissioned them. So the instructions keep them.
Offshoring went the same way. It began with knowledge transfer, where the in-house team wrote down what it did so the vendor could do it, and whatever got written down became the specification. The reports nobody read went into the contract with the rest, and the saving was measured against a process nobody had questioned. An agent briefed the same way inherits the same specification, at a cost per report too small for anyone to question individually. But each of them requires hours from some maintenance team at the software integrator tasked with automating them well into the future.
Plenty of jobs get replaced without a project at all. A tool takes over one task, then another, and the title and pay band stay where they were, since those are the slowest things to change. Somebody leaves, the position isn’t refilled, and the remaining team spreads the work among them. Nobody decided the job should go, so nobody can be asked why.
Others go without anyone being asked to describe anything. Companies have long handed whole departments to a service provider, HR among them, and the provider’s service is now software with hardly any employees doing the work. Payroll and employee questions run on a platform. The company buys a contract and a licence, and what runs is the vendor’s idea of the HR job. Nobody wrote the department’s work down, so nobody got to say which parts shouldn’t exist.
It is the textile story again. Machines moved the work from many hands in a trade to a few hands tending a frame somebody else owned, and the Luddites broke those frames. HR’s version moves the work out of the company altogether, so the machine isn’t even the company’s own.
Some jobs go in a reorganisation, where the boundary between teams is redrawn so that what the agent does becomes a whole job, or two teams merge because one of them no longer needs people. There is no automation project to point at, and the people drawing the new chart are the ones with something to keep.
However it happens, the work nobody wrote down doesn’t transfer. The approval keeps being produced, and when someone eventually asks whether it is still needed, nobody left knows.
Checklist
- Take any role AI might change. What sits at each layer: tasks, workflows, the role, the job? Which layer would a change actually move?
- Which kinds of change could it produce, and for whom: enrichment, intensification, expansion, fragmentation, deskilling, emergence, elimination? Expect more than one under the same title.
- If output goes up, does the capacity to answer for it go up too?
- How is the replacement actually happening: written down and piloted, a task at a time, bought as a service, or a reorganisation?
- What does the role do that nobody has written down?
- Which parts of the written-down job would nobody miss, and who is allowed to say so?
- Who marks the pilot, and against what? A match with past output rewards copying the reports nobody reads.
- If the work leaves the company, who is left to ask whether a step is still needed?