The Second Workflow

Open the review deck of a programme that is a bit over a year old. Four things have shipped and they all work: invoice matching in finance, a support-reply drafter, clause extraction in legal, log triage in platform operations. Each one demoed well. Each one has a named owner and a slide with a percentage on it.

Now look at what is underneath them. Four service accounts, created four different ways, living in three secret managers. Four prompt files in four repositories, none of which a second team can find. Four answers to the question of how anyone knows the thing got better, ranging from a spreadsheet to a confident sentence from the product owner. When legal asks who approved the clause extraction agent touching a particular contract, someone greps a log format invented for that one workflow.

The fifth workflow is in the intake queue with an estimate of ten weeks. The first one took eleven. That number, sitting quietly in the appendix, is the only honest measure of adoption in the deck.

Adoption that compounds and adoption that accumulates look identical for about six months. Both produce shipped workflows and a slide with an upward line on it. They separate at the point where a team that did not build the first workflow tries to build the second one.

The gap is well documented by now. McKinsey, citing its 2025 State of AI survey, reports that 62 percent of organizations are piloting agents, yet in any given business function no more than 10 percent report scaling them (McKinsey, "Reimagining tech infrastructure for (and with) agentic AI"). The usual explanations are data quality, unclear ownership, risk appetite, and measurement.

Those are all real. They are also downstream of something more mechanical. A pilot that scales is a pilot whose second instance was cheaper than its first, and most pilots are built in a way that guarantees the opposite. Nothing carries. The programme has a portfolio of workflows and no estate.

DORA's 2025 research on AI-assisted software development lands in the same place from a different direction. It describes AI's primary role as an amplifier, magnifying an organization's existing strengths and weaknesses, and it locates the returns in the underlying organizational system rather than in the tools (DORA, State of AI-assisted Software Development 2025). An organization with a strong internal platform gets a compounding curve out of AI. An organization without one gets a series of well-executed one-offs, delivered faster than before.

This is a story the industry has already lived through once. Before internal platforms, every team wrote its own build pipeline, handled its own secrets, invented its own deploy script, and negotiated its own access to production. The second service cost roughly what the first service cost, and everyone accepted that as the price of software. What changed the arithmetic was not more enthusiasm for shipping services. It was somebody extracting the parts that all of them needed and putting those parts behind a self-serve boundary, which is roughly the argument Evan Bottcher makes in What I Talk About When I Talk About Platforms.

A portfolio of AI pilots is a pre-platform estate. The interesting question is not whether to build the platform. It is which parts of it a single shipped workflow can be made to produce as a side effect.

Call it residue: the things a shipped workflow deposits that the next workflow can pick up without asking anyone's permission. Five of them are worth naming, because they are the five that show up in every production AI system we have worked on, and because a workflow can be designed to produce them almost for free while it is being built anyway.

• An identity that something else issues. The workflow's agent authenticates with a credential owned by the runtime: a service account, a workload identity, a short-lived token from your existing issuer. The second workflow does not design an identity model. It requests one. This is the cheapest residue to produce and the one most often skipped, because a personal access token in an environment variable works fine in a demo.
• A policy surface with deny by default. What an agent may do lives in configuration that a reviewer can read, and anything unlisted is refused. We wrote up the mechanics of this in From Runbook to Governed API. The residue is not the policy engine, which is usually a few hundred lines. It is the settled question of where authorization decisions live, so the second workflow never reopens it.
• An audit log with a schema. One event shape covering caller, action, inputs, decision, outcome, and refusals. Kleppmann's framing in Designing Data-Intensive Applications applies directly: keep the log as the source of truth and build the views you need on top of it. A second workflow that appends to the same log gets cross-workflow questions answered for nothing, and "which agents touched this contract in March" stops being a research project.
• A fact the platform can read. Service ownership, on-call rotation, data classification, cost attribution, contract status. Every workflow needs one or two of these and most organizations have them written down somewhere a program cannot reach. Turning one of them into something queryable is the slowest residue to produce and the most reused afterwards, because policy can only enforce facts the platform can check.
• An evaluation baseline someone else can run. A frozen set of real cases, a harness that replays them, and the number the process produced before any of this existed. Without that last part, every workflow relitigates what "better" means, and the answer is decided by whoever is most confident in the room.

Here is the test we would apply before starting workflow one. Write down which of those five it will leave behind, and name the team that could use each one next quarter without talking to you. A workflow that leaves none of them can still be worth building. It should just be counted as a delivery, and not as progress toward scale.

One warning about packaging. The tempting move, once this is clear, is to build the shared layer first, before any workflow exists. That produces a framework shaped around one imaginary use case, and the first real workflow spends its budget bending to fit. The rule of three from Fowler's Refactoring, credited there to Don Roberts, is the better instinct: wait until you see the same thing a third time before generalising it. We soften it by one step here and extract when the second workflow asks for the same thing, because the cost of a wrong shared abstraction at this stage is bounded by a config file, while the cost of waiting for a third example is one more workflow priced as a first.

Two paths run out of the same shipped workflow. In one, the workflow deposits its residue into a shared band that later workflows draw from and extend. In the other, the workflow keeps everything internal, and the next team starts where the last team started.

The dashed band at the bottom is where most programmes actually live, and it is worth being precise about why. Nobody decides to throw the substrate away. It never gets built, because at the moment workflow one ships, none of those five things are required for workflow one to work. They are only required for workflow two to be cheap, and workflow two does not have a sponsor yet.

The concrete version is small enough to show. Here is the policy file after the first workflow, an incident agent that requests scoped observability context:

agents:
  incident-investigator-agent:
    owner: platform-team
    actions:
      request-observability-context:
        autonomy: autonomous
        environments: [production]
        allowed_context: [logs, traces, metrics, recent_deployments]
        max_time_window_minutes: 60
        blocked_data: [secrets, payment_data, raw_personal_data]

defaults:
  unknown_agent: deny
  unknown_action: deny
  audit: all

And here is what the second workflow adds. Different team, different backend: an agent that resizes idle workloads outside business hours, where a wrong call costs money instead of exposing data.

agents:
  incident-investigator-agent:
    # ... unchanged ...

  cost-rightsizing-agent:              # the second workflow, added later
    owner: platform-team
    actions:
      resize-idle-workload:
        autonomy: requires_approval
        approvers: [service-owner]
        environments: [staging, production]
        schedule_window: off_hours
        max_monthly_delta_eur: 2000

defaults:
  unknown_agent: deny
  unknown_action: deny
  audit: all

Nine lines of configuration, and the second agent arrives with an identity, an approval path, an audit trail, and a refusal behaviour it did not implement. That is the compounding, in the only form it ever actually takes. It is not a flywheel image on a slide. It is a diff that is short because someone already answered the questions underneath it.

The evaluation baseline is the one that resists this treatment, and it is the one worth the most. A harness is easy. Cases are work, and the column that makes them valuable has to be captured before the agent exists:

# cases/incident-context.jsonl
# Frozen before the agent existed. Every case is a real incident,
# replayed against a recorded snapshot of the observability stack.
{"id": "SEV1-2026-0412", "service": "checkout-api",
 "expected": {"root_cause_signal": "deploy_1841", "found_by_human_in_minutes": 34}}
{"id": "SEV2-2026-0517", "service": "billing-worker",
 "expected": {"root_cause_signal": "pool_exhaustion", "found_by_human_in_minutes": 71}}

# The number that matters is not the agent's score. It is the column
# next to it: how long this took before there was an agent.

Nobody can reconstruct that column afterwards. Six months into a deployment, the honest answer to "how long did this take before" is a range with a shrug attached to it. The first workflow is the last cheap opportunity to write it down, which is why we treat freezing the baseline as part of building the workflow, on the same branch, in the same week.

The shift in that second bar is the whole return. A fourth workflow that spends most of its budget on the thing it was actually commissioned to do is what scaling looks like from the inside, and it is invisible in any metric that counts users or workflows.

Two ways of growing get talked about as if they were alternatives. Breadth is reach: more teams, more people, more surface touched. Depth is how much of one real workflow the system actually carries, from intake through the decision to the refusal path and the record afterwards.

They do different jobs, and the sequence between them matters more than the balance. One workflow taken all the way to depth is what makes the substrate real, because only a workflow in production discovers that ownership data is wrong, that the approval queue nobody reads is a queue nobody reads, and that the audit schema is missing the one field the auditor asks for. Breadth is what exercises the result. The second and third teams find every place the substrate assumed something specific to the first team, and they find it in weeks.

Breadth first, with nothing underneath, produces a large population of assistants and a governance problem that arrives all at once. Depth alone produces one genuinely good workflow and a small team that becomes the bottleneck for everyone else, which is a pleasant kind of failure and still a failure.

Residue is inheritance, and inheritance carries whatever the first workflow got wrong. If workflow one modelled authorization around a single low-risk read action, every later workflow inherits a policy surface with no vocabulary for writes, and the team building workflow five either fights it or quietly routes around it. The shared layer that was extracted too eagerly is worse than no shared layer, because it comes with a governance process attached and someone has to be convinced before it changes.

The failure we see most often is procedural. A central team is made responsible for the substrate, which is correct, and then becomes the path through which every workflow must pass, which is fatal. The moment inheriting the policy surface requires a ticket and a design review, the second workflow costs more than the first, and teams start doing what teams do: building their own thing quietly and calling it a prototype. Substrate has to be self-serve, or it is a gate wearing a platform's clothes.

Measurement goes wrong in a specific way here. Monthly active users is the easiest number to move and it answers a question nobody asked. An organization can take a drafting assistant from two hundred users to six thousand in a year and have learned nothing about whether its next production workflow is cheap. Two numbers say more: the elapsed time from intake to production for the most recent workflow, measured against the first, and the share of that workflow's components its team did not write. Both are awkward to collect and neither looks good on a slide, which is roughly why the user count wins.

There is also a selection effect worth watching. Once the substrate exists, the cheapest workflows are the ones that ship, and cheap has no relationship to valuable. A programme can spend its second year producing a steady stream of inexpensive, well-governed, marginal automations, each one a small success, while the expensive workflow that would actually change the economics of the business sits in the backlog because its ground truth does not exist yet. Somebody has to keep choosing by value while the machinery makes choosing by cost effortless.

And the substrate itself becomes a product whether anyone plans for it or not. The audit log needs retention and a real access model, and someone has to own search over it. The evaluation harness needs a maintainer who keeps the cases honest as the underlying process changes. Unowned shared code decays into a thing the next team forks, and a forked substrate is just four one-offs with a shared ancestor.

We would pick the first workflow for volume and dullness, and specifically for having its judgment already written down somewhere. A runbook, a checklist, a policy document that a person follows twenty times a week: that written-down judgment is what makes the policy surface designable instead of speculative. The exciting workflow, the one in the strategy deck, is a bad first choice, because its rules are still being argued about and the substrate ends up encoding an argument.

Then we would put the residue in the same pull request as the workflow, as named deliverables with owners, so it cannot be deferred to a phase two that does not exist. The identity, the policy file, the audit schema, the one ground-truth fact, the frozen cases. None of these are large. Their entire difficulty is that they are optional right up until the moment they are expensive.

Two of the workflows we run ourselves illustrate why this pays. An off-hours rightsizing agent that resizes idle workloads is not an interesting piece of software on its own. What made it a good thing to build early was that the approval queue and the cost attribution it needed turned out to be exactly what a log-triage-to-ticket agent needed shortly afterwards, and the second one arrived as configuration plus its own logic. Neither was designed as a platform. The second one simply asked for something that already existed.

We would also choose workflow two deliberately, and treat it as the measurement rather than as the next delivery. Give it to a different team, in a different part of the organization, and time it end to end. If it takes as long as the first one, the substrate is a diagram. Everything above this paragraph is a hypothesis until that second number comes back.

What we would not do is stand up a platform team before workflow two has asked for the same thing twice. The extraction should be triggered by a real second request, and until then the shared parts can live in the first workflow's repository with a clear boundary around them, waiting to be moved by someone who knows what the second caller actually needs.

The flywheel metaphor suggests momentum, as though adoption gathers speed from success alone. What actually accumulates is inheritance. Each shipped workflow either leaves an estate that the next team can draw on without permission, or leaves a demo and a slide, and the difference is decided during the first build by people who are under pressure to ship one thing and have no incentive to think about the fourth.

That is why this is an engineering decision before it is a strategy decision. No amount of programme governance recovers a substrate that was never produced, and no reorganization makes workflow five cheap if workflows one through four each ended at their own boundary. The compounding is built in the same weeks as the first workflow or it is not built at all.

Fourteen months in, the useful number in the review deck is not on the summary slide. It is how long the most recent workflow took, sitting next to how long the first one took. If those two numbers are the same, the programme has been buying deliveries at retail price and calling it adoption.

Why is the fourth AI workflow often as expensive as the first?

Because nothing carried over. Each workflow built its own identity handling, its own authorization logic, its own logging format, and its own definition of success. Those parts are not what made the workflow valuable, but they are most of what made it slow, and they get rebuilt every time unless the first workflow deliberately leaves them behind in a form another team can use.

What should a first AI workflow leave behind?

Five things: an agent identity issued by the runtime rather than a personal token, a policy surface that denies unlisted actions by default, an audit log with a single event schema, one operational fact made queryable by software, and an evaluation baseline built from frozen real cases including the number the process produced before the agent existed. The last one has to be captured before the workflow goes live, because it cannot be reconstructed afterwards.

Should we build the shared platform before the first workflow?

No. A platform built ahead of any real workflow is shaped around an imagined use case, and the first real workflow spends its budget bending to fit. Build the first workflow with its shared parts cleanly separated inside its own repository, then extract them when a second workflow asks for the same thing.

How do you measure whether AI adoption is compounding?

Compare the elapsed time from intake to production for the most recent workflow against the first one, and look at how much of the recent workflow's scaffolding its team did not write. User counts and workflow counts measure reach, which can grow steadily while the marginal cost of each new production workflow stays flat.

Where does this connect to governed APIs?

The policy surface and the audit log are the same ones described in From Runbook to Governed API, and the queryable operational fact is the Operational Ground Truth pattern from Agent-Ready Infrastructure. This article is the programme-level view of why those pieces are worth building during the first workflow rather than the fourth.

McKinsey: Reimagining tech infrastructure for (and with) agentic AI

DORA: State of AI-assisted Software Development 2025

Evan Bottcher: What I Talk About When I Talk About Platforms

Martin Kleppmann: Designing Data-Intensive Applications