You Don't Need to Transform Everything at Once. Start Where the Friction Is.

Legacy modernization taught us how to change an operating business without breaking it. Enterprise AI has not repealed those lessons. It has only made them urgent.

I've led transformations of 20-plus-year-old legacy systems into cloud-native, event-driven microservices architectures.

The technology was difficult. But some of the hardest questions were not technical.

They came from the people running the business every day:

• Where do we start?
• What do we change first?
• What happens to the systems that already work?
• How do we modernize without disrupting the business?
• How much should we change at once?

Those concerns were rational. Legacy systems may be old, fragmented, and difficult to change, but they also carry years of business logic, operational knowledge, integrations, controls, and human habits. You cannot simply declare a new architecture and expect an operating organization to move into it overnight.

The transformations that worked were progressive.

We identified important bottlenecks. We created boundaries around the work. We modernized one meaningful piece at a time, while allowing the existing environment to continue operating. We learned from each step and expanded from there.

Now I see the same anxiety emerging around enterprise AI — only the technology is moving much faster.

AI used to recommend.

Now AI acts.

And once AI acts, execution itself has to be governed.

That shift can make the transformation feel enormous. Leaders hear about autonomous agents, new models, Model Context Protocol (MCP), AI-native systems, multi-agent architectures, and entire operating models being redesigned around intelligence. The natural reaction is:

My answer is the same principle that worked in large-scale modernization:

Find one high-friction workflow. Find the bottleneck inside it. Start transforming that now.

Keep the systems that already work. Make the first scope bounded enough to adopt, but meaningful enough to matter. Govern the actions. Verify the outcomes. Learn from what actually happens.

Then iterate — faster and better.

Start with friction, not with AI

Every enterprise already has workflows where the friction is visible.

A request moves through too many hands.

A decision requires people to reconstruct context from several systems.

An exception sits waiting because ownership is unclear.

A recommendation is produced automatically, but humans still have to determine policy, authority, next action, and whether the outcome actually happened.

Those are better starting points than asking:

"Where can we deploy an AI agent?"

Ask instead:

"Where is work unnecessarily hard today?"

Then find the bottleneck.

The difference is not rhetorical. Starting from the technology can produce a pilot that has to go looking for a problem. Starting from friction ties the work to an improvement the business can recognize and measure.

The First Workflow Test

Not every high-friction workflow makes a good first one. The best first workflow is small enough to adopt, real enough to matter, and structured enough to govern.

Six questions:

1. Is the friction visible and measurable today?

Not "we think this is inefficient," but a queue, a backlog, a cycle time, a rework rate, an escalation volume, a team that already complains about it by name. If you cannot describe the cost of the current state, you will not be able to demonstrate the value of the new one — and you will spend the whole engagement arguing about whether anything improved.

2. Does the workflow have a clean boundary?

A clear trigger, a clear owner, and a clear definition of done. Boundaries are what make progressive transformation possible. They are also what stop a first scope from quietly expanding into a program.

3. Can the systems that already work stay in place?

If the first workflow requires replacing a system of record before anything can improve, the scope may be too large for a first step. Look for a starting point that works across the systems you already have.

4. Is the judgment repeated and policy-shaped?

The strongest candidates involve decisions made many times against rules that already exist — even if those rules currently live in a senior operator's head rather than in a document. Repetition is what produces learning. Existing policy is what gives execution something to be governed against.

5. Are the actions consequential — and recoverable?

A low-stakes automation can be useful, but it may tell you little about how the system handles consequential decisions. Choose work that matters. Then, among the work that matters, prefer the version where a mistake is detectable and reversible. Consequence is what makes the governance real. Recoverability is what makes the first step survivable.

6. Can the outcome be verified?

You need to be able to confirm that the downstream state actually changed — not that a step completed successfully. This is the failure mode I wrote about in #01: an intermediate successful action is not a business outcome. If you cannot verify the end state, you are measuring activity.

A workflow that passes all six is a first scope. A workflow that fails one of these tests may still be worth transforming — but it is probably not the place to start.

What not to start with

• The workflow with no agreed way to resolve uncertainty. Operators do not have to agree on every case, but there must be a clear owner and an escalation path when judgment differs.
• The workflow chosen because it demos well. Impressive is not the same as load-bearing. A first workflow that nobody depends on produces applause and no adoption.
• The end-to-end process spanning six departments. That is the destination, not the entry point.
• The workflow that only works if everything else changes first. See question 3.

Small and self-contained does not mean shallow

A useful first workflow tests more than connectivity. A simple integration can deliver real value, but it may leave open the harder questions: whether the system has enough context, when a human must intervene, and how the final outcome is confirmed.

Consider an operational exception where required evidence is missing. The bounded workflow is to identify the missing evidence, request it, review the response for sensitive information, route any required approval, and verify that the outcome was recorded in the existing business system.

That is a small part of a larger process, but it addresses a recognizable source of delay and repeated follow-up. Success can be measured through resolution time, manual handoffs, and rework. Completing the evidence request does not, by itself, authorize the consequential action that follows.

Choose work that matters enough for operators to care whether it succeeds, and bounded enough that the organization can learn safely when it does not.

Progressive transformation gets mistaken for slow transformation. It is the opposite.

Boundaries are what let you move quickly, because they make the consequences of moving quickly containable. An unbounded transformation cannot go fast — every decision touches something nobody has fully mapped, so every decision waits.

The first workflow is also where an organization establishes capabilities the second workflow can build on: how context is assembled, how authority is bounded, where humans intervene, how outcomes are verified, and how decisions are explained afterward. Those foundations should not have to be reinvented from scratch for every workflow. Establish them under real conditions, and the next workflow can build on those foundations while accounting for its own requirements.

That is the compounding value of starting small: each workflow gives the next one a stronger starting point.

Then govern the first one properly

Once you have chosen the workflow, the question changes. It stops being where do we start and becomes what has to be true before this is allowed to execute?

That is a different discipline from choosing a model or demonstrating an integration. In many enterprise workflows, model intelligence is no longer the primary bottleneck. A capable model can read the case, gather the context, and propose the right action. What limits the outcome is everything around that proposal: whether the workflow supplied enough context to decide, what the system is authorized to do with the conclusion, how the action actually reaches the systems of record, whether the result is verified downstream — and whether the organization trusts it enough to stop checking the work by hand.

That is the thing worth building on the first workflow: governed execution loops by design — from AI decision to authorized action to verified outcome.

Capability is not authority. An agent that can perform an action has not thereby been authorized to perform it. The five control surfaces we use to evaluate a production workflow — context sufficiency, action permission, runtime governance, decision lineage, and feedback memory — exist to keep that distinction from collapsing under deadline pressure.

Applied to a first workflow, they are practical questions, not architecture:

• Does the system have enough context to decide, and what does it do when it doesn't?
• Which actions may it take on its own, and which require a human?
• What happens when the case goes off the happy path?
• Can you explain, later, exactly why a decision was made?
• Do the outcomes come back and change what happens next time?

Answer those for one bounded workflow and you have something better than a pilot. You have a governed piece of production, running next to everything else you did not have to change.

You don't need to transform everything at once

The legacy modernizations that worked did not begin with a new architecture diagram. They began with a bottleneck that hurt, a boundary drawn around it, and an organization that kept operating while one meaningful piece changed.

Transformation does not have to begin with a transformation program. It can begin with one bottleneck.

Enterprise AI is moving faster, and the stakes moved with it: the system is no longer recommending an action, it is taking one. That raises the governance requirement. It does not change where to start.

At Apova, that is what we are building Agent Atlas to do — simplify one fragmented operational workflow at a time, and govern what is permitted to execute.