Most companies responding to AI are doing headcount arithmetic: which roles shrink, which get frozen, which get combined. That's the wrong unit of analysis, and it produces the wrong plan. The research is consistent on this point — automation doesn't consume jobs whole, it consumes tasks within jobs. Get the unit of analysis right, and the redesign question changes from "who do we cut" to "which tasks in this organization no longer need a human, and what do we build around the ones that still do."
Why task-level, not role-level
The task-based framework from labor economists Autor, Levy, and Murnane — later extended by Acemoglu and Restrepo — treats every job as a bundle of tasks, some automatable, some not, and the bundle shifts over time as some tasks are displaced and new ones are created. Applied at the level of a single organization, this reframes the transformation question entirely: instead of asking "is the analyst role still needed," you ask "which of the fifteen things this role currently does are now commodity, and does the remaining bundle still add up to a coherent job."
A 2025 study gives a genuinely usable version of this exercise at scale. Researchers built what they call the Human Agency Scale, auditing 844 tasks across 104 occupations using input from 1,500 workers and 52 AI experts. Roughly 46% of tasks fell into what they termed an "automation green-light" zone — safe to hand over cleanly. The rest split between tasks needing continued human involvement and tasks where the right degree of AI involvement is still genuinely unclear. That's not a headcount number. It's a map you can actually run against your own workflows: task by task, not role by role, with an honest "we don't know yet" category instead of pretending the whole thing is solved.
The three layers, in practice
Once you've mapped tasks rather than roles, the org tends to reorganize into three layers, each with a distinct job to do.
Judgment and accountability is the thinnest layer and the one that doesn't shrink. These are the people who decide what "good" means for a given piece of work, own the outcome when it's wrong, and make the calls that require context the AI doesn't have — the client relationship history, the political sensitivity of a decision, the exception to the rule that the rule-maker didn't anticipate. This layer doesn't do more tasks after a transition. It does fewer, higher-stakes ones.
Orchestration is the layer most companies underbuild, because it doesn't show up naturally — it has to be designed. These are the people who route work between human and AI capability, sanity-check AI output before it reaches a customer or a decision-maker, and notice when the AI is confidently wrong in a way a less experienced person would miss. This is a real skill, not a placeholder job, and it maps closely to what Brynjolfsson, Li, and Raymond found in their customer-support study: the AI tool worked by transmitting the patterns of the best performers to everyone else. Someone still has to decide when to override the pattern.
Execution is the layer that shrinks, and it shrinks specifically where tasks fall in the "green-light" zone — genuinely commodity work, well-specified enough that a machine does it as well or better. It doesn't disappear entirely, because plenty of execution work still needs a human for reasons of cost, regulation, or simply because the task isn't well-specified enough yet.
A concrete (hypothetical) walk-through
Picture a 40-person customer support team — deliberately the same kind of organization as the Brynjolfsson study, because it's the best-documented case we have. Before AI, the team is flat: 35 agents, 4 senior agents who informally mentor, one manager. Task-mapping this team honestly might produce something like this:
- Green-light (execution, largely automatable): answering well-documented product questions, drafting first-pass responses to routine complaints, summarizing a chat thread for handoff.
- Orchestration: reviewing AI-drafted responses before they go out on anything involving refunds, churn risk, or an angry customer; noticing when the AI's suggested resolution technically answers the question but misses what the customer actually needs; training new agents on when not to trust the tool.
- Judgment and accountability: deciding what your company's actual policy is on edge cases the AI has no precedent for; owning the relationship with a handful of high-value accounts; setting the standard the orchestration layer checks against.
The redesign isn't "cut 20 agents." It's: some portion of the 35 agents move into a formalized orchestration role — likely including some of the 4 informal mentors, whose tacit knowledge of "what good looks like" is exactly what the role needs — with real training and a real title, not just an expectation bolted onto their existing job. A smaller number stay in pure execution, handling the volume the green-light tasks don't fully absorb (edge cases, non-English queries, whatever your automation coverage doesn't reach yet). The manager's job shifts from scheduling and quality-spot-checks to something closer to the judgment layer: deciding what "good" means when the orchestration layer escalates a genuinely new situation.
Done well, this is a smaller team that handles more volume with better outcomes — which is roughly what the underlying research found at the individual level, just organized deliberately instead of happening as an accident of who happened to adopt the tool fastest.
Getting there with the workforce you already have
Three things transfer from the pre-AI literature on capability transitions, and they show up directly in the example above. First, task-mapping has to happen with the people who do the task, not to them from above — the Human Agency Scale study's own methodology, surveying workers alongside AI experts, is the right model precisely because the informal mentors in the example know things about the work that no org chart captures. Second, the orchestration layer has to be deliberately built, not assumed — it's built from people already doing the work, which means a real development path and a new title, not a memo redefining someone's job overnight. Third, the pace problem outlined by Teece's dynamic-capabilities work matters more than getting the initial design right: this org chart will be wrong again in a year as the green-light zone expands, so the actual capability worth building is the muscle to redraw it, not the redrawn version itself.
Where in your own org would task-level mapping tell you something your current org chart is hiding?
If you're working through what this looks like for your team, I coach leaders through exactly this kind of transition — or start with my book on self-coaching.
Sources:
- Autor, D., Levy, F., & Murnane, R. (2003). "The Skill Content of Recent Technological Change." QJE; Acemoglu, D. & Restrepo, P. — task-based automation framework.
- Shao et al. (2025). "Human Agency Scale" / WORKBank study — 844 tasks, 104 occupations, 1,500 workers, 52 AI experts. arXiv preprint, not yet peer-reviewed.
- Brynjolfsson, E., Li, D., & Raymond, L. (2023, rev. 2025). "Generative AI at Work." QJE, 140(2).
- Teece, D., Pisano, G., & Shuen, A. (1997). "Dynamic Capabilities and Strategic Management." Strategic Management Journal.
Want to explore this further?
Start with a free 30-minute discovery session — no commitment required.
Book a Discovery Call