You Automated 25 Steps. You Never Asked Whether You continue to need all the 25 anymore?

 

Why the next wave of value is capability re-imagination, not agent proliferation

Almost every one I speak to, is building agents. Budgets are approved, pilots are running, and the results are genuinely encouraging. But look closely at how the work is being scoped, and a pattern emerges that should worry us.

Let's take a simple case. Assume, a business capability with five processes, each with roughly around five steps. Twenty-five steps in total. Teams are diligently working through them, asking: which of these twenty-five can AI do faster, cheaper or better? They find eight or nine, build agents for them, and report a productivity gain.

The question nobody is asking is whether, with AI in the mix, the capability still needs five processes and twenty-five steps at all.

Many of those steps exist for reasons that AI has just made obsolete. They exist because information had to be re-keyed between systems, a human had to read a document and classify it, or a handover was needed between two teams who could not see each other's context. Since the control was manual, a checkpoint was inserted. Those steps are not business logic. They are scar tissue from an era of constrained software. Automate a step that should not exist and you have made waste efficient. That is a productivity gain. It is not optimisation.

Productivity gain versus structural optimisation

A genuine re-imagination might conclude that the capability no longer needs five processes of five steps. It may need three processes of six. The headline number barely moves here - twenty-five to eighteen, but the handovers, reconciliations, queues and control points that consume real cost and real elapsed time fall away. That is where the economics change.

Why this is an architecture conversation, not an AI conversation

Here is the uncomfortable part: many organisations cannot re-imagine a capability even when they can see the opportunity. The process shape is fossilised in the application estate. Steps exist because a package demanded them. Sequence exists because of a nightly batch. Ownership boundaries exist because someone bought the system in 2014.

Composability is the antidote to that fossilisation. If a capability was assembled from a discrete, set of independently owned building blocks, each with a clear contract, its own data boundary, and no assumptions about who calls it or in what order, then the process shape becomes a choice rather than an inheritance. This allows re-sequencing steps, may be remove a step entirely, or let an agent collapse three into one, because nothing downstream is structurally dependent on yesterday's arrangement.

If the estate is monolithic, re-imagining the capability means a re-platforming exercise; where as when it is composable, re-imagining the capability is just a re-wiring exercise. The difference between those two is usually eighteen months and a business case nobody wants to write.

This is exactly what loosely coupled, domain-driven, composable architecture was always meant to solve, and it is why the principles matter more now, not less:

• Model the capability, not the screen. Bounded contexts should follow business meaning, not the seams of the packages you happen to own.
• Make the process the composition, not the code. If your process sequence is hard-coded across six systems, you cannot redesign it. If it is orchestrated above services that expose clean contracts, you can.
• Contract-first, replaceable components. A capability you can re-shape is one where any component - including an agent, or a model can be swapped without a migration programme.
• Events over integrations. Asynchronous, re-playable domain events remove the queues and reconciliations that generate most of the steps you are trying to delete.
• Isolate the legacy, do not enshrine it. Wrap it behind an anti-corruption layer so that yesterday's system does not dictate tomorrow's process design.

Composability is what makes re-imagination physically possible. Without it, you can only decorate the existing process with intelligence.

So, What good looks like

The recommendation is deliberately unglamorous:

An AI-native capability application built on conventional enterprise application architecture, with bounded agentic intelligence embedded where ambiguity, reasoning and language understanding create measurable value.

Read that carefully, because both halves are load-bearing.

Conventional architecture still holds the spine. Process state, sequencing, transactions, entitlements, segregation of duties and audit belong in deterministic code and workflow, not in a prompt. A regulator will not accept probabilistic evidence that a control was applied.

Bounded agentic intelligence goes where determinism has always been weak: interpreting unstructured documents, reasoning over ambiguity, synthesising across sources, drafting, explaining exceptions. Scoped agents, typed tool contracts, explicit workflows, human approval at the points that carry consequence.

Agents are a component type in your architecture. They are not the architecture.

The tooling has caught up

The encouraging news for CIOs and CTOs is that - this no longer requires an exotic skill set. Development framework or libraries like the Microsoft Agent Framework gives you abilities to build custom agents, explicit workflows, tool calling, memory, checkpointing, human-in-the-loop and observability natively as first-class constructs in .NET and Python. Additionally, MCPs for governed tool exposure, durable workflow for the deterministic spine, existing API and event platform, and a modern SPA or Teams surface for the human in the process. In other words all that is required is already in the current application engineering capability.

Where to start

1. Pick one capability that is expensive, slow and evidence-heavy. Do not start with the easiest.
2. Map the current processes and steps honestly, then classify each step: business-essential, control-essential, or compensating for a system limitation.
3. Delete the third category on paper first. Design the target shape assuming reasoning is cheap and abundant.
4. Decide what must remain deterministic, and draw the boundary explicitly. This is the single most important architectural decision.
5. Build the composable spine and embed agents inside it, with evaluation, tracing and audit from day one.
6. Measure capability economics: cost per outcome, cycle time, exception rate, rework. Not agent count.

And a closing thought for my fellow software engineers

If the last two years have made anyone nervous about their profession, this is the reassuring part. Someone has to decide where the deterministic boundary sits. Someone has to design the bounded contexts, the tool contracts, the event flows, the failure modes, the evidence trail, the fallback when the model is confidently wrong at two in the morning.

AI made reasoning abundant. It did not make architecture optional. If anything, it just made the architects and engineers who can think in capabilities rather than components considerably harder to replace.

We are not automating ourselves out of a job. We are being handed a much more interesting one.