The Workflow Is the Unit of AI Transformation

Most companies are still applying AI to work that was designed before AI existed. A researcher gets an AI assistant, a developer gets a coding agent, a support representative gets suggested responses, and a manager gets better summaries. Each person becomes somewhat faster, but the basic structure of the work remains intact. The same roles exist, the same handoffs happen, the same approvals are required, and the same queues form between teams.

Making an existing task faster can create real value, and for many organizations it is the easiest place to begin. But adding AI to each step of a process is different from asking whether the process still makes sense once AI becomes part of the workforce.

The more interesting question is what the organization would look like if we designed the work today, with humans, agents, conventional software, and data systems all available from the beginning.

Workflows Encode the Constraints That Created Them

Organizations are shaped by the limitations that existed when their processes were designed. We create specialized roles because no person can know everything. We create handoffs because different teams possess different information and capabilities. We create approval layers because judgment and authority are concentrated in particular people, and we create queues because those people can only handle so much work at once.

Over time, those accommodations harden into the organization. A process may require five people because information has to move between systems, someone has to synthesize it, someone else has the authority to approve it, and a third person knows how to turn the decision into action. The workflow reflects the constraints under which it evolved.

AI changes some of those constraints. An agent can gather information from multiple systems, synthesize large amounts of context, perform analysis, generate an artifact, use software tools, evaluate its own work against defined criteria, and execute portions of a process without waiting for another person to become available. Multiple agents can also work simultaneously where a human workflow might have been sequential.

That does not eliminate the need for humans. It changes the reasons humans need to appear at particular points in the process, and once those reasons change, the shape of the workflow should be open to change as well. This is why the larger AI transformation looks less like technology adoption and more like operating-model design.

Automating the Existing Workflow Is Only the First Step

Consider a research process that moves from a researcher to an analyst, then to a manager, legal review, and finally operations. The obvious AI strategy is to improve every box. The researcher gets better search and synthesis, the analyst gets automated analysis, the manager gets summaries, and legal gets document review. Each person works faster and the organization can reasonably call the result an improvement.

But the more important question is whether those boxes still need to be connected in the same sequence.

Perhaps an agent can gather the research, perform the first analysis, identify uncertainty, check the result against defined policies, and produce a decision-ready artifact before a person becomes involved. Legal review may only be necessary when a particular risk threshold is crossed. The analyst may spend less time assembling information and more time resolving unusual cases. The manager may no longer need to review routine work at all, because the system can evaluate those cases against criteria the manager helped define.

The redesigned workflow might bear little resemblance to the original. Some tasks become faster, some move to agents, some remain human, and some disappear because they existed to transfer information or compensate for limitations that no longer exist.

Automation asks what machines can do inside the existing workflow. AI-native design asks what the workflow should be now that machines can do those things.

That does not make redesign the right move every time. If a process already works and has one clearly expensive step, embedding AI at that step is often faster and lower risk, a case I made in Stop Trying to Automate the Whole Workflow. Redesign pays for itself when the structure is the problem: many handoffs, long queues between teams, steps that exist mainly to move information from one person to another. There, speeding up each box leaves the real delay untouched.

Jobs Are Often the Wrong Unit of Analysis

A job description bundles together many different kinds of work. A product manager gathers information, writes specifications, coordinates teams, makes prioritization decisions, communicates with customers, and resolves ambiguous situations. Those activities sit inside one job because grouping them has historically been a practical way to organize the work. They do not all require the same type of intelligence or authority.

The same is true almost everywhere. A customer service representative retrieves account information, interprets a policy, writes a response, manages a relationship, and decides when an exception deserves escalation. Treating the job as one indivisible unit obscures the differences between those activities.

This is why the recurring question about which jobs AI will replace is not especially useful. Even the more sophisticated version, which asks which tasks can be automated, starts from the existing decomposition of work and assumes today’s task boundaries will remain the right ones.

The workflow is a better starting point because it begins with the outcome. What are we trying to accomplish? What information is required? Which decisions need to be made, and what actions follow? How do we know whether the result is good? What happens when the system encounters something unusual, and who remains accountable?

Those questions break a workflow into intent, context, decisions, execution, evaluation, exceptions, and accountability. Each part can then go to whatever is best suited to perform it, and frequently the best design is a combination.

Human Work Does Not Simply Disappear

The common shorthand is that humans remain “in the loop,” but the phrase misleads as systems grow more capable. It suggests a person should sit inside every execution cycle, approving what the AI does before the process can continue.

That is appropriate when mistakes have significant consequences. For other work it is unnecessary friction, in the same way a manager does not approve every action of a competent employee.

The better design question is where human judgment has the greatest leverage. Humans may define the objective, establish constraints, authorize a plan, set the limits of autonomy, handle unusual exceptions, make consequential decisions, and remain accountable for the result. The system can execute much of the work between those points.

I learned where that leverage sits by getting it wrong. Early in running my own agent system, I approved a plan for a research synthesis without reading it closely. The agents executed well and the output was polished, but the scope had been set on a question I had not quite asked, so no amount of editing could fix it. I wrote about that in The Cheaper Half of Oversight. What I took from it is that my attention is worth more on the plan than on watching each action that follows. My responsibility for the result did not shrink. It moved to a different point in the work.

That is why the architecture around an agent matters as much as the agent. Permissions, evaluation, escalation, memory, visibility, and approval boundaries determine what a system may do and where a human enters. The human-agent relationship is not a single setting called “human in the loop.” It is a set of design decisions distributed throughout the workflow.

Redesigning the Work Eventually Redesigns the Organization

Once workflows change substantially, the organization around them cannot remain untouched. If an agent can gather information that previously had to move through several teams, some handoffs become unnecessary. If routine evaluation can be automated, some review layers change. If work can happen continuously rather than in human-sized batches, processes built around meetings, queues, and scheduled coordination may stop making sense.

The more important change is not how many people the work needs but who does which part of it. When the workflow is redesigned, the division of work between humans, agents, and software changes, and roles have to be redefined to match. Roles defined by executing a process shift toward directing it, evaluating it, handling exceptions, or improving the system itself. Expertise moves away from routine production and toward judgment, relationships, creativity, and decisions where being wrong actually matters.

Headcount is a separate question, and the answer varies. Freed capacity can go into serving more customers, launching more products, or doing analysis that was previously uneconomic, or it can reduce the number of people a function needs. Either way, the people who remain are doing different work than they were before, and the organization has to decide what those roles are.

This Is the Hard Part of AI Transformation

Giving employees access to a capable model is relatively easy. Understanding what a team actually does, separating necessary work from historical process, and rebuilding that work around a different set of capabilities is much harder.

The official process diagram is rarely enough. Real work contains tacit knowledge, shortcuts, exceptions, political boundaries, informal approvals, and judgment calls that never appear in the documented workflow. Someone has to understand why the process looks the way it does before deciding which pieces can safely change.

The redesign also raises questions that are not primarily technical:

• How much autonomy should the system have?
• Which errors are acceptable, and which require immediate escalation?
• What evidence should an agent provide with a recommendation?
• Who can change the objective once execution begins?
• Who owns the outcome when several agents and several humans contributed to it?

A better model will not answer those. They require observing the work, designing an alternative, testing it, finding the new failure modes, and adjusting the boundary between humans and machines. The process is iterative because the right workflow is unlikely to be obvious before anyone has operated it.

That may become one of the more important disciplines in enterprise AI: designing systems of work that combine humans, agents, software, data, controls, and evaluation into something better than the process they replaced.

The Workflow Is the Real Product

This changes what we consider the AI system itself. The model is one component and the agent is another, and neither produces much business value in isolation.

The useful thing is the complete workflow around them: a request enters the system, the right context is gathered, decisions are made, actions are taken, results are evaluated, uncertainty is escalated, and a human remains responsible for the outcome. Models, agents, APIs, databases, deterministic rules, and people all participate.

Seen this way, some debates about AI matter less. A deterministic rule is preferable when the rule is known, a database lookup when the answer already exists in structured form, an agent when the work requires flexible reasoning or tool use, and a person where judgment, authority, trust, or accountability warrants one.

Start With the Outcome

Starting with the outcome also changes how value should be measured. If AI makes an analyst finish the same task faster, measuring productivity tells us something useful. If a redesigned workflow eliminates several handoffs, changes how much work a team can support, or makes a new capability economically possible, the result that matters is what happened to the system’s performance. I take that up in Hours Saved Is Not ROI.

The practical first step is a question, not a tool. What outcome is this process meant to produce, and why does it have the shape it does? Identify the constraints that created that shape, then ask which of them still exist. Only after that should the technology enter the discussion.