The unit of transformation is the workflow

Start with an accountable piece of work

A platform team can count agents, integrations and model calls without being able to say whether a customer request is handled better. Those counts describe technical activity. Transformation requires a unit that connects the activity to responsibility and an outcome. I would start with the business workflow.

A workflow has a trigger, a defined population of work, a completion condition and someone accountable when it fails. Those properties make it possible to compare the current process with a proposed one. They also reveal work that disappears from an agent demonstration: checking inputs, reviewing exceptions, correcting records and communicating with the next team.

This is an operating-model argument, not a claim that every process should use an agent. Anthropic's distinction between predefined workflows and model-directed agents is useful here. Some work benefits from flexible action selection; some is better served by a constrained sequence. The business workflow can contain either.

Delegation changes the design problem

Suppose an internal service team considers an agent to prepare case responses. The useful question is not how many cases the model can summarize in a minute. It is which parts of the service the organization intends to delegate and what completion means.

A draft may be fluent and still omit the fact a reviewer needs. A reviewer may correct it quickly but spend longer checking its sources. An agent may close a work item while the receiving team reopens it. Measuring the local step would miss these consequences.

Before choosing a model, document the authorized inputs, the proposed outputs, the actions that remain human and the evidence needed to accept completion. Name the downstream team that can reject the handoff. If nobody owns that boundary, the proposed automation has exposed an existing operating problem that technology alone will not resolve.

Build a workflow contract

A useful workflow contract fits into an architecture review without becoming a substitute for it. Describe the trigger and population, the outcome, the permissions, the exception path and the accountable owner. Include the baseline against which the new design will be evaluated.

Then make the contract testable. “The agent supports case handling” is not a boundary. “The agent may retrieve the assigned case and prepare a draft; an authorized reviewer must approve the recipient and final text before sending” is a boundary a team can implement and challenge.

The contract should also say when the agent stops. A missing document, conflicting record or unavailable reviewer must lead to a defined state. Leaving the work in an explicit exception queue is often more useful than producing a plausible answer simply to keep the process moving.

Evaluate the whole cost of the handoff

Track accepted outcomes per eligible work item, elapsed completion time, reviewer effort, rework and total operating cost. Decide which quality failures are unacceptable before comparing productivity. Averages alone can hide a class of cases that consistently produces poor results.

Separate released capacity from cash savings. Ten minutes saved on a fragmented task is not automatically ten minutes removed from the budget. The value case needs a plausible plan for how the capacity will be used and a benefits owner who can verify whether that happened.

These are proposed management measures. This article does not offer an empirical estimate of productivity gains. The ROI calculator makes the assumptions explicit so the conversation can focus on which inputs need evidence.

Scale the control pattern

Once a workflow demonstrates useful outcomes, identify which capabilities should become shared services. Identity, permission enforcement, evaluation records and incident handling are candidates. The decision to delegate a specific business action should remain attached to the workflow owner.

This distinction matters when a central platform expands. Reusing an adapter can reduce implementation work. Reusing an approval without checking the new purpose can expand authority silently. A shared platform should make those changes easier to see.

The maturity model assesses the organizational capabilities around this unit of work. Its value is the evidence conversation: where the workflow is bounded, which controls operate in practice and what the organization still cannot demonstrate. An agent count cannot answer those questions.