The Work Moved
The easiest mistake is to talk about jobs when the real movement begins inside tasks.
AI-native work moves inside tasks before the org chart changes. The first redesign job is to map which layers of the workflow the machine can handle and which layers still need human judgment.
The easiest mistake is to talk about jobs when the real movement begins inside tasks.
A job title is a container. It holds routines, exceptions, decisions, relationships, tools, obligations, and tacit knowledge.
"Account executive" contains prospect research, prioritization, outreach, discovery, negotiation, forecasting, internal coordination, legal navigation, and judgment about when to walk away. "Software engineer" contains problem framing, design, coding, debugging, review, incident response, operational thinking, and maintenance.
"Support agent" contains diagnosis, empathy, policy interpretation, account context, response drafting, escalation, and learning from repeated issues. "Product manager" contains customer understanding, prioritization, writing, tradeoff negotiation, coordination, and decision-making.
AI does not enter the job container evenly. It enters at task seams.
It drafts a reply. It summarizes a call. It writes a test. It classifies an issue. It suggests a next step. It generates an analysis. It rewrites a paragraph. It identifies a likely root cause. It produces a first version of the artifact humans used to produce manually.
That is why job-level claims are usually too broad. "AI will replace support agents" is too crude. "AI can perform parts of ticket triage, answer drafting, intent classification, knowledge retrieval, resolution verification, and coaching" is more useful. It lets an operator ask which task changed, what context the machine needs, what human judgment remains, and what workflow should exist around the new task boundary.
The task-based view of work is not new. Labor economists have studied for decades how technology changes the demand for different task categories rather than simply eliminating or preserving entire jobs. Autor, Levy, and Murnane's work on the skill content of technological change drew attention to how computerization affected routine tasks differently from non-routine tasks (paper PDF). Brynjolfsson, Mitchell, and Rock later argued that machine learning's workforce implications are best analyzed task by task, because ML systems are suited to some prediction and classification tasks but not to whole occupations in any simple way (AEA paper).
Generative AI changes the task map again because it reaches into language, code, design, and analysis work that many organizations treated as protected by ambiguity. But the task-level principle still holds. AI-native organizations do not ask which jobs get AI. They ask which tasks move, which human responsibilities intensify, and which workflow boundaries must be redrawn.
If the distinction still feels slippery, the definitional anchor is AI-Native means the machine does the job. This chapter applies that thesis one level down: not to the whole organization yet, but to the task layers where work actually moves.
Key Takeaways
- AI-native work moves at the task level first; job titles lag behind the workflow.
- The six-layer workflow map separates intent, context, production, verification, decision, and consequence.
- Machine production lowers some internal prices while making verification, specification, and accountability more visible.
- Leaders should redesign judgment gates before they claim workforce transformation.
The work was never one thing
Every workflow can be decomposed into six functional layers:
- Intent: what should be accomplished.
- Context: what must be known to do it well.
- Production: the artifact or action produced.
- Verification: how the artifact or action is checked.
- Decision: whether the result is accepted, rejected, escalated, or shipped.
- Consequence: who owns what happens after the decision.
Before AI, many workflows hid these layers inside one person's labor. A senior support agent received a ticket, understood the customer's frustration, remembered the refund policy, recognized that this customer had an enterprise contract, wrote the response, decided whether the policy exception was acceptable, sent the reply, and owned the follow-up. A product manager heard customer feedback, recognized a pattern, wrote a requirement, negotiated scope with engineering, made prioritization calls, and absorbed the consequences. A senior engineer took a bug report, inferred the system failure, designed the fix, wrote the patch, judged the tests, and carried operational responsibility.
Because one person performed multiple layers, the organization did not always need to name them. AI forces the naming.
Once a machine produces the response, patch, memo, or recommendation, the surrounding human responsibilities become explicit. Who set the intent? Who supplied the context? Who verifies the output? Who decides acceptance? Who owns consequence?
This is the AI-Native Workflow Map.
| Workflow layer | Question | Machine role | Human role | Failure if ignored |
|---|---|---|---|---|
| Intent | What are we trying to accomplish? | Can draft goals from examples, detect patterns, suggest objectives | Define the outcome, tradeoff, customer promise, and priority | The machine optimizes the wrong target |
| Context | What matters in this situation? | Can retrieve, summarize, classify, and connect known information | Identify missing context, tacit constraints, politics, edge cases, and customer reality | Output is fluent but situationally wrong |
| Production | What artifact or action is created? | Can draft, code, route, summarize, transform, recommend | Design production boundaries and generation constraints | Artifact volume rises without value |
| Verification | How do we know it is acceptable? | Can run tests, checks, evals, comparisons, policy screens | Define acceptance criteria and inspect ambiguous failures | Review queues explode or bad work passes |
| Decision | Should this be used, shipped, sent, escalated, or blocked? | Can recommend decisions under rules | Exercise judgment where stakes, ambiguity, or accountability require it | Approval becomes rubber-stamping |
| Consequence | Who owns the result? | Can log actions, trace inputs, support audit, learn from feedback | Accept responsibility, repair harm, update process | Nobody owns machine-shaped failures |
The important point is that AI does not simply "do the work." It changes the distribution of labor across layers. The machine may become primary at production. It may assist at context retrieval. It may recommend at decision time. It may support verification with automated checks.
But the workflow still needs a responsible architecture across all six layers.
That is the same bottleneck shift described in the first-draft factory. Cheap production helps only when acceptance, risk, and consequence have a place to go.
The machine changes the price of different work
Work has internal prices even when nobody writes them on an invoice. The price is time, attention, skill, coordination, risk, and opportunity cost. AI changes those prices unevenly.
Drafting a routine customer email becomes cheaper. Writing a generic job description becomes cheaper. Producing a first-pass SQL query becomes cheaper. Summarizing a meeting becomes cheaper.
Creating a skeleton test file becomes cheaper. Generating campaign variants becomes cheaper. Creating a rough analysis memo becomes cheaper.
But other prices rise or become more visible. It becomes more expensive to determine whether the draft is appropriate for this customer. It becomes more expensive to verify that a generated SQL query preserves business logic.
It becomes more expensive to review large quantities of plausible code. It becomes more important to specify what a campaign is not allowed to say. It becomes more important to know which meeting summary omitted the disagreement that mattered.
This is the economics behind the subtitle of the book: the machine took the work and left us the judgment. More precisely, the machine took some production work and exposed the judgment work that production had previously hidden.
The Turing Trap, as Erik Brynjolfsson describes it, is the tendency to pursue AI that imitates and substitutes for human labor rather than augmenting human capabilities in ways that expand opportunity (Stanford Digital Economy Lab, arXiv). The AI-native stance is not identical to pure augmentation because it accepts that machines will perform material parts of tasks. But it shares the deeper warning: if leaders think only in substitution terms, they will automate the visible labor and neglect the design of human advantage around the system.
AI-native work should not be a race to remove people from workflows. It should be a disciplined relocation of people to the points where their judgment changes outcomes.
Four modes of AI in work
The word "AI-native" is often used loosely. This book uses four modes to make it precise.
AI-assisted work preserves the human as primary producer. The model helps with drafting, summarizing, searching, editing, or suggesting. A lawyer uses AI to produce a first pass but personally authors the position. An engineer uses code completion but owns the implementation end to end. This mode is useful and common. It is not yet AI-native.
AI-automated tasks let the machine complete a bounded task under clear rules. A system classifies inbound support tickets, extracts invoice fields, routes leads, summarizes calls, or generates release notes. The task can often be evaluated independently. Automation may sit inside an otherwise human-led workflow.
AI-native workflows redesign the flow around machine production and human judgment gates. The machine is expected to produce material work. Humans define intent, set constraints, review exceptions, accept outputs, and improve the system. Evaluation, logging, escalation, and accountability are built into the workflow rather than added after the pilot.
This is where evals that predict production become operational rather than academic. Verification has to be designed into the workflow before the machine starts producing at scale.
AI-native organizations redesign roles, measurement, governance, incentives, and operating cadence around AI-native workflows. They stop treating AI as a side tool and start managing judgment quality as a first-class operating metric.
A company can be advanced in one workflow and immature in another. A support operation might be AI-native while legal review remains AI-assisted. An engineering organization might use AI coding tools heavily but not yet be AI-native because acceptance tests, architecture constraints, and review systems were not redesigned. A marketing team might generate thousands of assets but remain AI-added because approval, brand risk, and customer response loops are unchanged.
This distinction matters because it prevents false maturity claims.
The human role compression map
When a task moves, the human role does not vanish uniformly. It compresses in some places, moves in others, and intensifies in a few. Leaders need to see the difference.
| Human responsibility | What happens under AI-native redesign | Example |
|---|---|---|
| Routine drafting | Shrinks | First-pass emails, summaries, boilerplate code, support replies |
| Mechanical transformation | Shrinks sharply | Reformatting, extracting fields, converting notes into templates |
| Context assembly | Moves upward | Humans define which context sources matter and when retrieval is insufficient |
| Specification | Intensifies | Product, engineering, legal, and operations teams must state intent and constraints clearly |
| Review | Changes shape | Humans review fewer raw artifacts and more exceptions, samples, eval failures, and high-risk outputs |
| Decision rights | Intensify | Someone must decide what the machine may do without approval |
| Relationship work | Becomes more selective | Humans intervene when trust, empathy, negotiation, or ambiguity dominate |
| Learning and coaching | Moves from individual correction to system improvement | Mistakes become eval updates, policy changes, prompt/spec revisions, and knowledge-base fixes |
| Accountability | Does not shrink | Legal, customer, operational, and leadership responsibility remains human/organizational |
The map is a warning against lazy workforce planning. A leader who sees only the shrinking responsibilities will over-automate. A leader who sees only the intensifying responsibilities will miss real efficiency gains.
AI-native design requires both: let machines handle the production work they can handle, and strengthen the human responsibilities that become more consequential.
Why the work moved before the org chart did
Organizations lag behind task changes because org charts are slower than workflows. A team may keep the same titles while the real work underneath changes dramatically. The support agent becomes a resolution judge. The SDR becomes an account-context editor. The engineer becomes a spec writer and code reviewer for machine-authored changes. The product manager becomes an acceptance-criteria designer. The manager becomes a decision-quality operator.
This lag creates confusion. People still have the same job title, but their work feels different. Junior employees may wonder how to learn when the machine drafts the artifacts they used to practice on. Senior employees may feel buried in review. Managers may see more output but less clarity. Executives may ask why headcount did not drop after AI tools were purchased. Customers may notice faster responses but not better outcomes.
The confusion is not a failure of individuals. It is a sign that the work moved faster than the organization's operating model.
An AI-native leader has to make the movement explicit. Which tasks are now machine-first? Which tasks remain human-first? Which outputs require acceptance? Which acceptance points can be automated? Which cases must escalate? Which skills are now more valuable? Which old metrics should be retired? Which new failure modes must be monitored?
These questions belong in operating reviews, not innovation theater.
A practical decomposition exercise
Take one workflow you own and decompose it across the six layers. Do not start with tool selection. Start with the work.
| Layer | Current human activity | Candidate machine activity | Human judgment that remains | Evidence needed before trust |
|---|---|---|---|---|
| Intent | ||||
| Context | ||||
| Production | ||||
| Verification | ||||
| Decision | ||||
| Consequence |
A completed version for support might show that the machine can classify intent, retrieve policy, draft a reply, and propose resolution, but humans still need to define when a refund exception is allowed, when an enterprise customer requires account-owner review, and how unresolved tickets update the knowledge base. A completed version for engineering might show that the machine can draft a patch and tests, but humans need to define the architectural constraint, review the security implication, and own deployment risk. A completed version for sales might show that the machine can research accounts and draft outreach, but humans need to judge timing, relationship context, and strategic fit.
This exercise often reveals that the organization's first AI idea targets the easiest production task, not the highest-impact workflow redesign. That is fine for experimentation. It is not enough for transformation.
The work moved. Now the operating model has to catch up. The Judgment Stack names the human decision layers that remain load-bearing after that shift.