the missing ai infrastructure

History’s Rhyme

During the Napoleonic wars, the British Empire had a pulley problem. A Royal Navy ship, at the time, required a thousand wooden pulley blocks. They raised the sails, moved the guns and controlled the rigging. These blocks were made by hand.

Marc Isambard Brunel grasped that the bottleneck wasn’t timber but method. Working with machinist Henry Maudslay, Brunel developed 45 steam-driven machines across 22 distinct operations, and installed them at Portsmouth Dockyard. By 1808, the mills were turning out 130k pulley blocks a year. Ten operators, it was reported, could equal the output that had previously required 110 skilled hands.

Brunel’s cleverness was not merely to mechanise the work. It lay in dividing a complicated task into separable operations that a machine could perform reliably, and in sequence.

The software equivalent of pulley blocks must constantly be created, updated and repaired to keep the ship moving. Dependencies need upgrading. Builds need fixing. APIs need migrating. Security vulnerabilities need resolving. Infrastructure and documentation need maintaining. Much of this work can be broken into separable tasks and automated by agents today.

So why don’t enterprises crack on with it?

Trust within Boundaries

Most enterprises don’t yet trust agents to act independently inside their software development lifecycle. Nor should they, blindly. An agent that can write code may also be able to access repositories, invoke tools, consume cloud resources, modify infrastructure, expose sensitive data or introduce defects into production. The more capable the agent becomes, the greater the potential benefit, and the larger the blast radius when something goes wrong. And so humans are kept forever in the loop, and the promised “new” economy never arrives.

Here Brunel instructs us. His machines earned trust not by being clever but by being bounded. Each did one defined thing, to a known material, within mechanically fixed limits, and handed its work to the next. No machine could decide to redesign the block, or wander off across the yard.

An enterprise must be able to specify which repositories an agent can access, which tools it may invoke, what credentials it can use, what changes it can make, how much it can spend and which actions require approval. It must be able to observe what the agent(s) did, verify the result and reverse the change when necessary. Trust, properly understood, is not sentiment. It is bounded authority, tied to an identity, attended by evidence.

How Automation Earns Autonomy

The path toward automation should therefore be progressive.

Begin with a separable, repeatable task whose successful outcome can be clearly verified. Let the agent observe the work. Then let it recommend a change. Then allow it to prepare the change in an isolated environment. Once its performance is understood, allow it to open a pull request. Later, allow it to merge changes that satisfy predefined conditions. Eventually, people need only review exceptions. Notice, autonomy is not granted with zealous hope but earned by degrees.

This is how enterprises can move from using agents as assistants to operating them as part of the production system: not through a single leap of faith, but through an expanding envelope of demonstrated trust. The first automations will live within individual teams. They might update dependencies, repair failing builds, migrate APIs, resolve routine security findings or keep internal documentation current.

From Isolated to Connected Automations

The larger prize, once individual tasks are trusted to agents, is to connect them: one agent identifying the work, another effecting a bounded change, a third verifying it, a fourth approving it by policy, across the human org boundaries that software has never much respected. This is no “swarm” running wild in the enterprise. It works only where every participant has a clear identity, a defined scope, observable conduct, and explicit rules of engagement.

In the old world, a dependency migration may begin with a platform team, require changes across hundreds of services, trigger updates to CI pipelines and infrastructure, and depend on approvals from security or compliance. People coordinate that work through tickets, meetings, messages and spreadsheets. Humans carry context from one team to another and wait for each group to act.

Brunel transformed production by properly designing a system of bounded, repeatable operations. There is a lesson for us in this. The necessary intelligence is already to hand. What remains to be built is the scaffolding of identity, boundaries, evidence and governance by which we might safely put these machines to work.