The Disaggregation of Software

An application has traditionally been a bundle: a collection of capabilities that someone chose to integrate, package, market and support as a product. The bundle is often valuable. Shared state, predictable operation, one purchase and a coherent interface reduce the effort of using software.

But agents could progressively reduce the cost of discovering, combining and operating capabilities independently. That creates pressure for software disaggregation.

Smaller pieces can stand alone

A specialised operation that would be difficult to sell as an entire application might make sense as a small service used by many agents. Such software slivers could compete against features embedded in large suites.

The classic “everyone uses a different 10%” problem becomes less constraining when an agent can choose only the relevant pieces. Those pieces need not come from the same supplier.

Composition—and construction

Discovery and composition are only the first stages. If a suitable capability does not exist, an agent may be able to construct it on demand, combine it with existing services and discard it when no longer needed.

The resulting software may be triggered by human requests, incoming events, schedules or other agents. Some arrangements will persist for years; others may exist for a single task.

Even the human interface can become more fluid: small generated interface pieces can accompany a changing set of capabilities.

Continuity without a fixed bundle

People and organisations still need continuity. Stable data, predictable workflows, permissions, auditability and familiar experiences matter. An evolving solution might therefore keep a recognisable human surface while its underlying implementation changes repeatedly.

This suggests a possible separation between the durable things—the user's information, goals and relationships—and the increasingly replaceable software assembled around them.

A direction, not a deadline

Disaggregation will meet resistance where tight integration genuinely wins: low latency, complicated shared state, safety, reliability or support. It may also create new gatekeepers in agent marketplaces and discovery systems.

Still, over the next decade it seems plausible that more software will be discovered, composed, modified and created at the point of need, rather than acquired as a fixed product.

We may continue calling these arrangements “applications”, or invent some other category. The terminology is hard to predict. The more interesting claim is that the underlying unit of software could become increasingly fluid.

This is a consequence of applying intelligence late, and a natural extension of hybrid human–agent software.