De Novo Capability Construction

Finding software and composing existing tools are only two ways to solve a problem. A capable agent can also build a missing piece.

Suppose a user needs a specialised transformation between two services. Rather than searching indefinitely for a product that almost fits, an agent might write a small adapter, test it and run it. It might keep the adapter, modify it as requirements change or discard it after a single task.

That is de novo capability construction: functionality comes into existence in response to an actual need.

A spectrum of responses

The agent might use an existing operation unchanged, compose several operations, adapt one with a small piece of code, or construct a new capability from scratch. These are alternatives along a continuum, not exclusive categories.

The associated human interface can be similarly fluid. A generated feature might need no UI, a conversational command or a temporary task-specific control.

Creation is not free

A newly generated capability can introduce faults, security problems and ongoing maintenance obligations. Its suitability depends on scope and consequences. Disposable low-risk transformations are very different from accounting, safety-critical control or persistent shared data.

Agents therefore need ways to test, constrain, observe, version and retire what they create. Sometimes purchasing a proven component remains the better choice.

Still, de novo construction deepens the disaggregation thesis. The future solution need not be a fixed bundle, nor even a fixed selection of available products. Parts of it may not exist until the need arises.

This is a particularly strong form of applying intelligence late: deciding not just which software to use, but what software should exist.