Writing archive

Aug 23, 2026 · AI-native workflows

Every Human-Only Workflow Is Now a Design Question

Most business processes encode assumptions about human speed, attention, and coordination. AI will create real leverage only when organizations preserve the control objectives and redesign the execution model.

Rigid teal and copper blocks narrow into a cobalt junction before opening into broad curved painted fields

Anthropic's new AI-Native SDLC playbook begins with a specific problem: code is getting generated faster, but the planning, review, deployment and maintenance processes around it still move at human speed.

That mismatch relocates the bottleneck. If implementation collapses from weeks to hours while approvals still wait for meetings, security review still depends on a manual queue and incidents still become learning only after somebody writes them up, faster coding does not produce a faster system. It produces pressure on everything around the code.

Anthropic's answer is to redesign the lifecycle. Intent, specifications, plans, tests and incident records become connected artifacts that humans and agents can both act on. Evaluation runs continuously. Policies are applied while work happens. Human attention moves toward judgment, risk and exceptions.

Read narrowly, this is a software-development guide.

Read more carefully, it is a case study in institutional lag.

Every established workflow was designed around assumptions about who could perform the work, how quickly information could move, how much attention was available and where accountability had to be inserted. AI changes those assumptions far beyond software.

That makes every human-only workflow a new design question.

A process is a fossil record of old constraints

We tend to treat a process as if it were the work itself.

It is not.

A process is one implementation of the work under a particular set of constraints. Many familiar steps exist because people could not be everywhere, know everything or act continuously:

  • Work was divided into specialist roles because expertise was scarce.
  • Documents translated context between people who could not share it directly.
  • Handoffs moved work across organizational boundaries.
  • Batches made scarce review capacity economical.
  • Meetings synchronized people who operated on different information.
  • Sign-offs created evidence that somebody had checked the result.

These mechanisms were often rational. But they are not eternal requirements.

In 1990, Michael Hammer warned in “Reengineering Work: Don't Automate, Obliterate” that companies were using computers to accelerate processes whose underlying rules were already obsolete. His provocation was not that controls or outcomes should disappear. It was that digitizing an inherited sequence can preserve the very constraint the technology removes.

AI makes that warning urgent again.

A model or agent can now interpret unstructured input, produce an artifact, consult policy, use tools, test a result, monitor an event and route an exception. It can cross several boundaries that once required different interfaces and job roles.

If we simply insert AI into each old box, we may make every local step faster while preserving the handoffs, queues and coordination costs that made the process slow.

We automate the relay race without asking whether the batons still need to exist.

The task is too small a unit of transformation

Much of the AI-at-work debate asks which tasks can be automated.

That is useful for measuring exposure, but incomplete for redesigning an organization.

The International Labour Organization's 2025 global exposure study estimates that one in four workers is in an occupation with some generative-AI exposure. Its more important conclusion is that transformation is more likely than complete job automation because occupations contain interdependent tasks that still require human input.

But tasks do not sit alone. They are connected by a workflow.

A customer-support response depends on account context, product policy, previous interactions, authorization limits and the ability to escalate. A procurement decision depends on demand, budget, vendor evidence, contract terms and risk. A financial close depends on transactions, reconciliations, materiality thresholds and attestation.

Automating one task changes the volume, speed and error pattern of the tasks around it. The unit of redesign therefore has to be the whole path from intent to outcome—not the isolated activity where a model happens to perform well.

The evidence already hints at how much organizational structure may be contingent rather than fixed. In a preregistered experiment with 791 Procter & Gamble professionals, individuals using AI matched the performance of two-person teams without AI on product-innovation work. AI also helped participants produce solutions that crossed the usual boundary between technical and commercial expertise. Human judgment retained particular value in selecting among the generated ideas.

That does not mean teams are obsolete. It means some team shapes, role boundaries and handoffs existed partly to assemble information and capabilities that AI can now bring into one working context.

The workflow should be re-derived around that new fact.

Preserve the control objective, not the ritual

The hardest part of process redesign is distinguishing what a step is meant to achieve from how it currently achieves it.

A weekly approval meeting may exist to control financial risk. Manual review may exist to detect defects. A required document may exist to preserve an audit trail. A three-person handoff may exist to separate authority.

Those are control objectives.

The meeting, manual queue, document template and handoff are execution mechanisms.

Conflating the two creates a false choice between leaving the old process untouched and removing governance entirely. The better question is whether the objective can be enforced earlier, continuously and with better evidence.

  • A policy can become a machine-readable constraint applied while work is produced.
  • A universal review queue can become deterministic checks plus risk-based escalation.
  • A periodic reconciliation can become continuous monitoring with material exceptions routed to an accountable owner.
  • A status meeting can become shared state, explicit decisions and event-triggered intervention.

This is the central design move in Anthropic's SDLC playbook: keep accountability and control, but replace human-speed enforcement with artifacts, evaluations, hooks, thresholds and recorded decisions that operate at the speed of the work.

The same principle applies everywhere.

Three examples show inherited process rituals being replaced by AI-native mechanisms that preserve the control objective

Human in the loop is not a process design

When organizations become uncomfortable with automation, they often add a human approval step.

That sounds safe. At scale, it can become ceremonial.

If a person must inspect every agent action, machine throughput merely creates a larger human queue. Reviewers begin sampling, skimming or approving by habit. The control remains visible on the process map while losing substance in operation.

Automation research has warned about this problem for decades. Lisanne Bainbridge's 1983 paper “Ironies of Automation” observed that removing people from routine operation can leave them responsible only for abnormal conditions—the moments when intervention is hardest and their practical knowledge may be least exercised.

“Human in the loop” is therefore not enough. We need to specify which relationship the human has with the loop.

In the work

The person and AI iterate together because the work is ambiguous, relational or exploratory. The human frames the problem, adds tacit context, challenges options and shapes the result.

On the loop

The system handles routine execution while the person supervises performance, investigates exceptions and changes the operating rules. Attention is triggered by evidence, not by every transaction.

Above the loop

Humans define the objective, risk tolerance, authority boundaries and conditions under which the system may become more or less autonomous. They remain accountable for the operating design.

A serious workflow may use all three modes. The mistake is placing a person at every step without deciding where human judgment is uniquely valuable.

AI-native does not mean AI everywhere

Redesign is not a mandate for maximum automation.

AI capability is uneven even inside apparently similar work. A field experiment with 758 consultants found that AI improved speed, completion and quality on tasks within its capability frontier, but participants using AI were 19% less likely to reach the correct answer on a task deliberately selected outside that frontier.

An AI-native process must be designed for this jaggedness.

That means autonomy should vary with at least four things:

  • Consequence: What happens if the action is wrong?
  • Uncertainty: How well can the system recognize that this case differs from the routine?
  • Verifiability: Can correctness be checked cheaply and independently?
  • Reversibility: Can the action be undone before harm spreads?

A low-consequence, highly verifiable and reversible action may be safe to automate. A high-consequence decision with weak feedback and irreversible effects may require active human judgment even when the model appears capable.

The relevant boundary is not human work versus machine work.

It is bounded machine execution inside a human-accountable operating system.

This is also why governance has to move into the workflow. The NIST Generative AI Profile emphasizes governance, pre-deployment testing, content provenance and incident disclosure, and notes that generative AI may require different human–AI configurations depending on risk. A committee after the fact cannot provide the same assurance as constraints, evidence and escalation designed into execution.

A practical method for redesigning any workflow

The starting point should not be, “Where can we add an agent?”

Start with the outcome and work backward.

1. State the outcome and the non-negotiables

Define what the process must produce, for whom, under which constraints and with what evidence. Separate customer or business value from internal activity.

2. Perform process archaeology

For every step, ask why it exists. Does it create value, translate context, transport information, verify a result, authorize an action or compensate for an old system limitation?

This makes inherited assumptions visible.

3. Delete before automating

If removing a step does not weaken the outcome or a necessary control, remove it. If two roles only translate artifacts between one another, test whether they can share one human- and machine-readable state instead.

4. Encode repeatable judgment

Stable policies, thresholds, taxonomies and checks should become executable constraints where possible. Keep the policy owner, version history and escalation path visible. Probabilistic instructions can guide; deterministic controls should enforce what must never be violated.

5. Allocate attention by risk

Reserve human review for material exceptions, conflicting evidence, novel cases and consequential decisions. Do not spend the same attention on every instance merely because the old process did.

6. Replace handoffs with state and triggers

Each accepted artifact or event should be usable by the next actor, human or machine. Name the source of truth. Record who or what changed it, which policy version applied and what triggered the next action.

7. Close the learning loop

Measure the outcome, control performance and system learning together. Track cycle time and cost, but also exception quality, escaped errors, reversals, human overrides and how quickly incidents become new tests or rules.

The last step matters most. Without it, the organization gets a faster workflow. With it, the organization gets an operating loop that improves through use.

The organization itself becomes editable

Software is the first obvious domain because code, tests, policies and runtime evidence already live in machine-readable systems.

Other functions will be messier. Their logic is scattered across policy documents, emails, spreadsheets, tacit knowledge, meetings and exceptions that were never formally recorded. Redesigning those workflows will require more than connecting a model to existing tools. It will require making intent, authority, evidence and feedback explicit.

That is difficult work.

It is also where the real productivity gains are hiding.

The ILO's 2026 review of empirical evidence finds that reported time savings have not consistently translated into measured output, earnings or employment effects. That gap is exactly what we should expect when individual tasks accelerate inside operating systems that have not changed.

The constraint moves. The queue survives. The saved hour disappears into coordination.

Organizations that treat AI as another tool for each employee may still see useful local gains. Organizations that treat it as a reason to re-derive the work can change their throughput, learning rate and structure.

That does not begin with a model rollout.

It begins with a more uncomfortable question:

If we were designing this process today, knowing that humans are no longer the only possible executors, would we build it this way at all?

For many of our workflows, the honest answer will be no.

That is not a failure of the old design. It is an invitation to make the organization fit its new capabilities.

Sources