On Overlock, the agent is the author. It decides what infrastructure needs to exist, asks a provider to bring it into existence, drives it through its lifecycle, and tears it down when the work is done. The network's job is to make every one of those steps signed, permissioned, and auditable.

A concrete example

An agent has been asked to run an analysis that needs an MCP server exposing a private dataset. Step by step, what the agent does:

Provision a VM in the cloud and region that match the data residency requirements of the task.
Deploy an MCP server onto that VM with the right tools wired up to the private dataset.
Run the analysis by talking to the MCP server it just stood up.
Modify the deployment as the work evolves: bigger instance, extra tools, a sidecar for logging.
Destroy everything once the result is delivered. No orphaned resources, no credentials left lying around.

The same pattern works for a Kubernetes workload. The agent stands up the cluster in the requested cloud, configures the services it needs (ingress, secrets, observability), drives the workload, mutates the cluster as the task changes, and tears it down at the end.

What the network adds

Three things make this safe enough to run autonomously:

Signed configs. Every change the agent wants to make is a signed, versioned configuration. The provider executes it only if the signature and the capability token match.
Capability tokens. The agent's authority to act on a given resource is a short-lived, scoped token. Tokens are revocable and recorded on every use.
On-chain audit. "What did the agent do, where, with whose authorisation?" is answered by a block height.

That is the part that is hard to retrofit onto a normal cloud account, and it is the part that makes autonomous, infrastructure-creating agents something you can let near production.