The Workflow Becomes the Unit

A customer request enters the enterprise and moves through systems, decisions, teams and controls before an outcome is produced.

A product idea moves through research, design, engineering, testing, security and release.

An invoice moves through receipt, validation, matching, approval, payment and reconciliation.

A production incident moves through detection, diagnosis, remediation, validation and review.

The organization sees departments. The work crosses them.

This distinction becomes critical once machines can participate in execution.

If AI is introduced through the organizational structure, the enterprise asks which employees need copilots, which functions need agents and which applications need AI features.

If AI is introduced through the workflow, a different set of questions appears.

• What outcome is this workflow producing?
• What work is required to produce it?
• Which steps require human judgment?
• Which steps can be executed by machines?
• Which decisions can be delegated?
• Where does information move?
• Where does the workflow wait?
• Where does it fail?
• Where does human intervention create value?
• Where is human intervention only compensating for the limitations of the existing system?
• And what should the workflow look like if it were designed now?

That is the shift.

In an AI Native Operating Model, the workflow becomes the primary unit of design.

The conventional organization makes work difficult to see.

Executives see functions.

1. 01Finance.
2. 02Technology.
3. 03Operations.
4. 04Sales.
5. 05Marketing.
6. 06Human resources.
7. 07Legal.
8. 08Procurement.

Inside those functions are teams.

Inside the teams are roles.

Inside the roles are jobs.

Inside the jobs are tasks.

But outcomes rarely fit inside that hierarchy.

Consider a customer dispute.

The customer does not experience the organizational chart.

The customer experiences an outcome.

Behind that outcome may sit a sequence involving a contact center, customer data, transaction history, policy interpretation, fraud controls, financial authority, payment systems and exception management.

No single application contains the work.

No single employee performs the work.

No single function owns every part of the work.

The workflow exists across the enterprise.

Traditional organizations manage this fragmentation through coordination.

1. People send messages.
2. →Meetings transfer context.
3. →Managers resolve ambiguity.
4. →Employees move information between systems.
5. →Queues hold work until another person becomes available.
6. →Approval structures compensate for uncertainty.
7. →Specialists intervene when the process encounters an exception.

Much of what enterprises call work is therefore not the production of the outcome itself.

It is the coordination required to make a fragmented operating system produce the outcome.

AI changes this because machine intelligence can participate across the sequence.

But only if the enterprise can see the sequence first.

Much of the first generation of enterprise AI focused on tasks.

1. Summarize this document.
2. →Draft this email.
3. →Generate this code.
4. →Analyze this spreadsheet.
5. →Prepare this presentation.
6. →Find this information.

These are useful applications.

They are also incomplete units of transformation.

A task is usually one fragment of a larger chain.

Making the fragment faster does not mean the chain becomes faster.

If AI reduces a thirty minute activity to three minutes but the output then waits two days for review, the workflow has not improved by the same factor.

If a model generates a document instantly but three organizational layers still approve it, the execution constraint has moved.

If an agent identifies the correct action but lacks permission to take it, the workflow still waits for a human.

If one step becomes automated while the surrounding systems remain disconnected, people may spend the released time moving information between the automated and nonautomated parts of the process.

Local productivity can therefore coexist with systemic inefficiency.

This is one reason productivity measures alone are insufficient for evaluating AI transformation.

The enterprise can accumulate thousands of faster tasks without reconstructing how an outcome is produced.

The job is also the wrong unit.

A job bundles many kinds of work because human labor has historically been the unit through which capability enters the enterprise.

One role may contain analysis, judgment, administration, coordination, communication, approval, documentation, exception handling and relationship management.

Those activities do not have the same requirements.

1. Some depend on experience.
2. →Some depend on context.
3. →Some depend on trust.
4. →Some depend on judgment.
5. →Some are procedural.
6. →Some are computational.
7. →Some exist because systems do not communicate.
8. →Some exist because information has to be gathered before a decision can be made.
9. →Some exist because an organization has chosen to place a control at that point in the process.

AI exposes these differences.

The question is no longer whether AI can perform a job.

That framing is too coarse.

The useful question is what forms of cognition, execution, authority and human contribution exist inside the workflow in which that job participates.

Microsoft's 2026 Work Trend Index captures part of this movement. Its research describes advanced AI users shifting their attention from the tasks that define their jobs toward the outcomes they can drive. Microsoft classifies its most advanced group, Frontier Professionals, in part through their use of agents for complex or multistep work and their routine redesign of workflows around what AI can augment or automate.

That is an important distinction.

The job remains an employment construct.

The workflow becomes an execution construct.

AI Native design begins with execution.

Enterprise technology creates another distortion.

Organizations often see work through applications because applications are where digital activity becomes visible.

1. Customer relationship management.
2. →Enterprise resource planning.
3. →Human capital management.
4. →Service management.
5. →Collaboration.
6. →Data platforms.
7. →Engineering systems.

Each system owns part of the process.

The workflow does not care.

A customer resolution may require information from five systems.

A procurement decision may require seven.

An employee onboarding process may cross identity, human resources, payroll, security, facilities and management systems.

Historically, people have often been the integration layer.

1. They read information in one system.
2. →Interpret it.
3. →Enter information into another.
4. →Ask someone for missing context.
5. →Wait for approval.
6. →Return to the system.
7. →Continue the process.

Agentic systems create the possibility of moving execution across those boundaries.

That changes the role of the application.

Applications remain systems of record, transaction, policy and specialized capability.

But the workflow can increasingly sit above them.

The execution layer can gather context, invoke tools, coordinate specialized agents, request human judgment and continue once that judgment has been supplied.

The architecture begins to orient around the flow of work rather than the boundaries of software products.

The market is beginning to show this transition.

OpenAI's 2026 enterprise research describes AI use moving from assistance toward execution. Its data shows a widening difference between typical enterprise users and the firms with the deepest AI usage. Frontier firms are making greater use of capabilities that connect AI to company context, tools and repeatable workflows.

Anthropic has observed a related change in how its systems are used.

Its June 2026 Economic Index notes that a year earlier much Claude usage took the form of conversation between a person and an assistant. The growth of products such as Claude Code and Cowork has shifted more usage toward long running agentic tasks.

Microsoft reports that active agents in its ecosystem increased fifteenfold year over year and eighteenfold among large enterprises.

More important for operating model design, its research found that advanced AI users were more likely to rethink workflows, identify opportunities for augmentation and automation, and participate in repeatable AI enabled practices.

Yet the same Microsoft research exposes the gap.

Only a minority of respondents reported that agent workflows, human handoffs and quality standards were documented and repeatable across teams, functions or the wider organization.

The machines are entering execution faster than enterprises are redesigning the system around them.

Once the workflow becomes visible, AI Native design becomes more precise.

A workflow is not a list of tasks.

It is an execution system.

At minimum, it contains several distinct elements.

01

Outcome

What must the workflow produce?

The answer cannot be "complete the process."

The outcome must describe the result that matters.

Resolve the customer dispute.

Restore the production service.

Approve a qualified supplier.

Close the financial period.

Release compliant software.

The outcome provides the reason the workflow exists.

02

Inputs

What information, events, requests or conditions initiate the work?

Inputs may arrive from people, systems, sensors, transactions, external events or other workflows.

03

Execution

What actions must occur to produce the outcome?

Some actions involve information retrieval.

Some involve analysis.

Some change systems.

Some create artifacts.

Some communicate.

Some invoke other workflows.

04

Decisions

Where does the workflow choose between possible actions?

A decision is different from an execution step because it determines what happens next.

Decisions carry consequences.

That makes them candidates for explicit authority design.

05

Authority

Who or what is permitted to make each decision and execute each consequential action?

Capability does not create authority.

Authority must be assigned.

06

Controls

What constraints must the workflow respect?

Policy.

Security.

Financial thresholds.

Regulation.

Quality standards.

Risk limits.

Ethical boundaries.

07

Handoffs

Where does responsibility move between humans, agents, systems or organizational units?

Handoffs are important because they often introduce delay, context loss and failure.

08

Exceptions

What happens when the workflow encounters a condition outside the expected path?

Exceptions reveal where judgment, escalation or redesign is required.

09

State

What does the workflow need to remember as execution progresses?

Long running work cannot depend on each participant reconstructing context from the beginning.

10

Measurement

How does the enterprise know whether the workflow produced the intended outcome?

Time matters.

Cost matters.

Quality matters.

Failure matters.

Human intervention matters.

Machine consumption matters.

The workflow has to expose all of them.

The workflow is not static.

Execution produces evidence about the operating model.

That evidence should change the operating model.

Once the workflow is the unit, the question of automation changes.

The objective is not to identify the maximum number of steps that a machine can perform.

That produces automation for its own sake.

The objective is to design the best execution system for the outcome.

Some work belongs with machines because machines can execute it faster, at greater scale or with greater consistency.

Some belongs with humans because the work requires judgment, accountability, empathy, negotiation, contextual understanding or the ability to reason about consequences that cannot be reduced to the available information.

Some work belongs in mixed execution.

1. 01An agent may gather the evidence.
2. 02A human may make the decision.
3. 03The agent may execute the decision.
4. 04Another system may validate the result.
5. 05A human may enter only when confidence falls below a threshold.

The correct allocation is therefore not human or machine. It is architectural.

The workflow determines where each form of capability belongs.

This also means allocation can change.

A task that requires human execution today may move into machine execution as model capability improves.

A decision delegated to an agent may return to mandatory human review if failure patterns appear.

A workflow may use a more capable model only for a narrow class of exceptions because the economics do not justify using it everywhere.

The operating model becomes dynamic.

Traditional enterprises contain enormous numbers of handoffs.

1. Team to team.
2. →System to system.
3. →Manager to employee.
4. →Employee to manager.
5. →Function to function.
6. →Vendor to enterprise.
7. →Human to application.
8. →Application back to human.

Each handoff has a cost.

1. Time.
2. →Context.
3. →Attention.
4. →Coordination.
5. →Risk.

The cost is often invisible because it is distributed across the organization.

AI Native design makes the handoff explicit.

Some handoffs should remain.

A consequential decision may require human approval.

A customer interaction may benefit from human empathy.

A regulatory process may mandate a particular accountable actor.

Other handoffs exist only because the existing operating system cannot continue execution.

1. A person reads an email and enters the contents into an application.
2. →A manager receives a report and forwards it to another team.
3. →An analyst downloads information from one system and uploads it into another.
4. →An employee checks whether a condition has been met and then triggers the next process.

These are not necessarily human contributions.

They are architectural seams.

Agents can remove some of them.

But removing a handoff does not mean removing control.

The better design is often to separate control from manual movement.

The system can continue execution while retaining explicit approval, policy and intervention points where they matter.

The normal path tells only part of the story.

The exception path often reveals how the enterprise actually works.

1. What happens when the data is incomplete?
2. →When the customer request falls outside policy?
3. →When two systems disagree?
4. →When an agent lacks confidence?
5. →When the financial consequence exceeds its authority?
6. →When a model produces an unexpected result?
7. →When the workflow encounters something nobody anticipated?

Traditional automation often works well until an exception occurs.

Then the work returns to people.

This is not necessarily failure.

Human intervention can be part of the architecture.

The problem appears when the exception path has not been designed.

An AI Native workflow needs explicit conditions for escalation.

It needs to know when machine execution should stop.

It needs to know who receives the work.

It needs to preserve context when the handoff occurs.

It needs to capture what happened.

And it needs to determine whether the exception was unusual or evidence that the workflow itself needs to change.

This is where human judgment becomes more important, not less.

The human does not need to remain inside every routine execution step to remain accountable for the outcome.

Human contribution can move toward the places where ambiguity, consequence and novelty are highest.

There is another consequence of machine execution.

Work can become more visible.

Traditional knowledge work is difficult to observe.

Much of it occurs in meetings, messages, documents, individual reasoning and informal coordination.

Organizations often measure proxies.

1. Hours.
2. →Headcount.
3. →Tickets.
4. →Projects.
5. →Activity.

Machine execution creates a different possibility.

An agent can generate traces.

• The enterprise can know when execution began.
• Which tools were called.
• Which information was retrieved.
• Which decisions were made.
• Where confidence fell.
• Where a human intervened.
• Which model was used.
• How much compute was consumed.
• How long execution took.
• Whether the outcome passed evaluation.

This does not mean every form of work should become surveillance.

Nor does machine traceability guarantee meaningful measurement.

But it creates the possibility of observing execution at a level that traditional operating models often cannot.

The workflow can become both the unit of execution and the unit of learning.

Microsoft's 2026 research describes a related idea in its concept of the organization as a learning system. Agent execution generates signals about what worked, what failed and where outcomes drifted. The organizational question is whether those signals remain local or become part of how future work is designed.

That is a significant operating model shift.

The enterprise can learn from execution itself.

Enterprises already map processes.

AI Native workflow design is not process mapping with agents added.

A conventional process map describes how work is expected to move.

An AI Native workflow must govern how work actually executes.

It connects outcome, execution, authority, policy, technology, economics and learning.

It has to answer:

• What is happening?
• Who or what is acting?
• What authority does it have?
• What information is it using?
• What is the cost of execution?
• What outcome was produced?
• Where did execution depart from expectation?
• What should change?

That makes the workflow a living operating object.

Its design can change as evidence accumulates.

Its human and machine allocation can change.

Its authority boundaries can change.

Its models can change.

Its controls can change.

Its economics can change.

The workflow becomes something the enterprise operates, measures and improves. Not something it documents once.

The workflow is where the AI Native enterprise becomes real.

Transformation occurs when those capabilities change how an outcome is produced.

That happens inside the workflow.

The workflow connects the

The workflow connects the outcome the enterprise wants to produce with the work required to produce it.

It connects that work to the people, agents and systems capable of executing it.

It connects execution to authority.

Authority to control.

Control to observation.

Observation to economics.

And execution back to adaptation.

That is why the workflow becomes the primary unit of AI Native design.

It is the smallest useful operating system in which the major elements of the enterprise can be designed together.

This does not mean the enterprise should become a collection of automated processes.

It means the enterprise should understand how outcomes are produced before deciding where intelligence, automation and human judgment belong.

That distinction protects the AI Native model from a simple mistake.

The objective is not maximum automation.

The objective is better execution.

A workflow should use human capability where human capability creates the strongest result.

It should use machine capability where machine capability creates the strongest result.

It should combine them where neither is sufficient alone.

And it should preserve explicit accountability for the outcome.

The design question is therefore not:

That question changes the architecture of work.

It forces the enterprise to examine the workflow before preserving the job, the application, the approval chain or the organizational boundary around it.

It makes human participation intentional.

It makes machine participation intentional.

It makes authority explicit.

It makes controls part of execution rather than something applied after the fact.

And it makes the economics of the workflow visible.

This is the deeper shift.

The workflow is no longer a process that moves between parts of the organization.

It becomes an operating object that the enterprise can design, execute, observe and adapt.

That is the foundation of AI Native execution.

The practical starting point for AI Native transformation is not a catalog of AI use cases.

It is a portfolio of consequential workflows.

Choose an outcome that matters.

1. Map how that outcome is produced today.
2. →Identify the work.
3. →Identify the decisions.
4. →Identify the authority.
5. →Identify the systems.
6. →Identify the handoffs.
7. →Identify the controls.
8. →Identify the exceptions.
9. →Identify where human judgment creates value.
10. →Identify where human effort exists because the current architecture requires it.
11. →Identify the cost of execution.

Then redesign the workflow from the outcome backward.

Do not assume that existing tasks must survive.

Do not assume that existing roles define the allocation of work.

Do not assume that existing application boundaries define the execution path.

Do not assume that every human handoff is a control.

Do not assume that every technically automatable step should be automated.

Design the execution system the outcome requires.

Then determine the combination of human and machine capability needed to operate it.

1. Chapter 01The operating model is changing.
2. Chapter 02AI adoption and AI Native transformation are different.
3. Chapter 03The workflow becomes the unit.
4. Chapter 04The New Division of Work.

Chapter 01 established the structural premise.

When machines become participants in enterprise execution, the enterprise has to be designed for humans and machines working together.

Chapter 02 established the boundary.

AI adoption improves the existing operating model.

AI Native transformation changes it.

Chapter 03 establishes the unit through which that change becomes concrete.

The workflow.

But once the workflow becomes the unit, the next question is unavoidable.

Who does the work?

The answer can no longer begin with the existing job architecture.

Each part of the workflow has to be allocated according to the capabilities the work requires.

Some work requires judgment.

Some requires context.

Some requires accountability.

Some requires empathy, negotiation or interpretation under ambiguity.

Other work requires speed, persistence, retrieval, synthesis, monitoring or execution at a scale that machines can provide.

Much of the enterprise will require both.

The next operating problem is therefore not automation.

It is allocation.

1. What should humans do?
2. →What should machines do?
3. →Where should they work together?
4. →And how should the boundary between them change as capability, risk and economics change?

That is the new division of work.

Chapter 04 · The New Division of Work