The question every executive is asking about AI, "will agents replace this job?", has a false premise baked into its grammar. It treats the job as the thing that gets automated. It isn't. The unit of automation is the task, and a job is a bundle of heterogeneous tasks that happen to be sold together under one title. Hold that distinction and the replace-or-not debate dissolves into three sharper questions: which tasks in the bundle are automatable, what the surviving tasks are worth once the automatable ones cost almost nothing, and whether the survivors re-bundle into a larger role or a smaller one.
This is not a semantic dodge. It is the framework labor economists have used for twenty years, and it predicts the actual pattern of who wins and who compresses far better than the binary everyone defaults to.
A job is a portfolio, not an atom
The task-based view comes from Autor, Levy, and Murnane's 2003 work on what computers actually did to the labor market. Their move was to stop asking whether a machine could do a job and ask whether it could do a task, and to notice that a computer substitutes for tasks reducible to explicit rules while it complements tasks that aren't. A payroll job in 1980 was arithmetic plus exception-handling plus talking to the guy in shipping about why his hours were wrong. Software ate the arithmetic. It could not touch the conversation. So the job didn't vanish; it recomposed around the parts the software couldn't reach.
Large language models did not overturn this framework. They moved the frontier. The tasks now falling to the automatable side aren't just codifiable-by-rules; they're pattern-dense but ambiguous: drafting a memo, summarizing a deposition, ranking a differential diagnosis, writing the first version of a function, reconciling two messy spreadsheets. That's a genuinely new class of automatable task, but the underlying logic is identical. Agents take tasks, and the question that matters is what happens to the rest of the bundle when they do.
Here is the part people miss because it runs against intuition. Automating one task in a bundle usually raises the marginal value of the tasks it cannot do. When tasks are complements in producing output, making one of them cheap makes the others the bottleneck, and the bottleneck is where value concentrates. Cut the cost of the automatable half of a role to near zero and you have not deleted half the role. You have made the other half the whole game.
The ATM already ran this experiment
The cleanest real-world proof is the automated teller machine, documented most carefully by James Bessen. The naive 1975 prediction was obvious: machines that dispense cash will replace the humans who dispense cash. ATMs went from essentially none to hundreds of thousands across the US over the following decades. Teller employment should have collapsed.
It didn't. The number of bank tellers roughly grew across the era of ATM saturation. Two things happened, and both are pure task logic. First, the ATM automated one task, cash handling, which was a large share of a teller's hours but never the whole job. What remained was account problems, cross-selling, judgment calls on suspicious activity, the human face of the branch. Those tasks became the teller's actual value. Second, and this is the piece the compression story always forgets, cheaper branch operation meant banks opened more branches, and more branches meant more tellers, now doing re-bundled relationship work rather than counting twenties.
The teller job was unbundled by the machine and re-bundled by the market. Same title, different task basket, more of them. That is the outcome the "will it replace the job" question cannot even represent, because the question assumes the basket is fixed.
The arithmetic that kills the naive headcount cut
Take a role that is ten roughly equal tasks, each about ten percent of the week. An agent can now do four of them at a ninety percent cost reduction. The board-deck version says: forty percent of the job is automated, cut headcount forty percent. That number is almost always wrong, and you can see why on one page.
The four automated tasks free up roughly forty percent of a person's time. That time doesn't evaporate. It reallocates to the six surviving tasks: the judgment calls, the client relationships, the accountability. Those six were the constraint on how much output the role could produce, and now there's more capacity flowing into them. Output per person rises. Whether you end up with fewer people depends entirely on a variable that has nothing to do with the AI: the demand elasticity for the role's output.
If demand for what the role produces is elastic, so cheaper output pulls in disproportionately more of it, the role expands, exactly like bank branches. If demand is inelastic, a fixed pie, then higher output per person means the same total work needs fewer people, and the role compresses hard. The predictor of job outcomes is therefore not automatability alone. It is automatability times output-demand elasticity. A role can be eighty percent automatable and still grow if its output is elastic enough, and a role can be thirty percent automatable and shrink if its pie is fixed. The single-variable panic, "AI can do most of this, so most of these people go," is arithmetic done with one of the two numbers missing.
This also tells you which jobs get crushed with no cushion: the ones that are essentially a single automatable task wearing a job title. A role that is only first-draft copy, or only lead qualification from a script, or only transcription has no residual bundle to re-concentrate value into. There is nothing left to become the bottleneck. Those compress fast and don't come back. The bundle was thin, and the machine took the whole thing.
Where the human premium goes
When the automatable tasks fall away, the value doesn't spread evenly across what's left. It piles up in the specific tasks agents are structurally worst at. Four of them do most of the work.
Judgment under ambiguity. Agents are strongest where the problem is well-posed and weakest where the hard part is deciding what the problem even is. As a physician I can watch this line precisely. A model will out-rank me on a clean differential from a tidy vignette. It has nothing useful to say when a patient's story fits no vignette and the real skill is knowing which of seven plausible things to chase first, with incomplete information and a consequence attached to being wrong.
Accountability. Someone has to own the outcome, and an agent cannot. It has no license to lose, no capital at risk, no name that suffers when the call is bad. That is not a temporary capability gap; it is structural, and I've argued the full version of it in Your AI Agent Has No Skin in the Game. The task of being liable, of standing behind a decision when it costs something, stays human because accountability requires a party that can actually be made to bear the loss.
Problem specification. The scarce skill in an agent-heavy workflow is turning a vague, underspecified situation into a crisply posed problem the agent can execute against. That translation, from "something's off with churn this quarter" to a precise, decomposed, checkable specification, is the task that gets more valuable as execution gets cheaper, which is the argument in Problem Specification Is the Skill That Outlasts Prompt Engineering. When execution is free, specification is the whole job.
Relationship and trust. Some tasks are valuable precisely because a person did them. Building Kommerce in trust-scarce markets, where cash-on-delivery exists because buyers won't prepay strangers, made this concrete for me: the reason a customer accepts the package is often a human relationship the agent literally cannot occupy. Trust is a task where the identity of the doer is part of the output.
These four are not random survivors. They are the tasks whose value rises as the surrounding tasks get automated. Complements, not leftovers.
Audit the basket, not the title
The method follows directly, and it works on your own role and on your org chart the same way.
Stop reasoning about job titles. Write down what a role actually did last week as a list of discrete tasks. For each task, assign one of three tags: automatable now, automatable soon, human-premium. Do it honestly. The temptation is to over-protect your own tasks and over-automate everyone else's, and both errors are expensive. Then sum the hours by tag. That gives you the shape of the role, which is the thing the org chart hides.
Now you can act instead of wait. For the automatable-now tasks, hand them over and reclaim the hours. For automatable-soon, don't build your next two years of identity around them. For the human-premium bucket, reallocate deliberately toward it; the four categories above are where your hours should be migrating. Run the same audit on a team and you'll see which roles are thin single-task bundles that will compress and which are thick heterogeneous bundles that will reshape, and you can staff, hire, and reorganize against the real distribution rather than the titles.
The org chart will eventually be rewritten to match the new task baskets. It always is; the teller's job description in 2010 was not the one from 1975. The only question is whether it gets rewritten for you or by you. The people who win the agent transition are not the ones whose tasks happened to be safe. They are the ones who audited their basket early, dropped the automatable weight without sentiment, and re-bundled their remaining hours around judgment, accountability, specification, and trust before anyone told them to.
Waiting to find out whether "your job" survives is the wrong posture, because your job was never the unit. Your tasks are. Go count them.