AI Agents Are Infrastructure. Who's Going to Operate Them?

Everyone Can Build an Agent. And They Will.

People closest to a process often understand its frustrations well. They know where information has to be collected manually, where work waits for attention and which decisions would benefit from better context. Giving them the ability to explore improvements is valuable.

An agent can help carry work across those steps, using information and tools to decide what to do next. The business opportunity is in completing useful work more effectively. Whether it saves time, improves quality or makes a service more responsive still needs to be established through use.

A successful demonstration gives a team a reason to continue. Then someone starts using it regularly. Other people begin relying on the result. What began as an experiment now has expectations attached to it, sometimes before anyone has explicitly agreed to operate a service.

Several teams can reach that point independently and the convergence of ideas and solutions is now at an unprecedented scale. Each idea may be sensible, but together they create demand for access, infrastructure, security and support. People designing one workflow may have little visibility of what the other teams are building or what the shared services can sustain.

In my article on AI-native engineering, I explored how greater capability changes the demands on the rest of the organisation. Agents bring that question into everyday business operations too. Making them easier to build means preparing for more people to need somewhere dependable to run them.

When Something Goes Wrong, Who Picks Up the Phone?

From an operations perspective, the important change is when someone depends on the work being completed. At that point, there needs to be a response when it fails, produces an incorrect result or acts outside its intended scope.

Someone needs to notice, understand which systems are affected and have the authority to intervene. Someone also needs to keep the business process moving while the problem is investigated. Knowing who built the agent is useful, but that person may be unavailable or may never have agreed to provide ongoing support.

This is why shared understanding matters early. One team may believe it is exploring an idea while another thinks it is being asked to provide a production service. People can hear the same proposal and come away with different expectations. Comparing those expectations gives everyone a chance to ask what is missing before it becomes an operational problem.

The application team needs to own the agent's behaviour and support its workflow. Platform and IT teams need to be clear about the shared services they can operate. Security needs to help establish appropriate access and intervention arrangements. The business owner needs to remain accountable for the purpose and consequences of the work. Those responsibilities have to connect when an incident crosses several systems.

Atul Kumar's article on agents becoming infrastructure describes the need for an agent control plane, bringing together capabilities to authorise, observe and manage agents. My concern here is the operating commitment behind those capabilities. Who maintains them, who responds and who funds the capacity?

An investment decision needs to include that continuing work. Model consumption is only part of the cost. Supporting integrations, maintaining controls and responding to failures all require time and people.

Good Infrastructure Enables Innovation.

I want teams to have room to pursue useful ideas without having to become experts in every service underneath them. They should be able to understand what is available, what they can depend on and where they need help with something new.

That requires infrastructure and security teams to be involved while requirements can still influence the design. It also requires those teams to listen. A growing number of requests may reveal a useful business need that the current platform does not yet support. Understanding that demand is part of building a better service.

If the foundations remain unclear, teams will make their own arrangements. Dependencies accumulate, costs become difficult to explain and incidents take longer to investigate. Eventually, access may be restricted because the organisation cannot establish what is running. That reduces the freedom people hoped the technology would create.

In The best platform teams are almost invisible, I described the value of dependable services that let people work independently. Agents need the same continuing investment, with clear responsibilities for the work they perform. Teams should have enough context to use their judgement and enough support to ask questions when a decision affects others.

Start with one useful workflow. Bring together the people building it, those providing its dependencies and the person accountable for its business outcome. Agree what they are trying to achieve, what each team will operate and what needs investment before others can rely on it.

The companion article, From AI Experiment to Production, sets out who to involve at each stage and the practical checks to work through together.

That gives the next team a better starting point. Over time, the organisation becomes more capable of turning good ideas into services it can confidently use. That is the opportunity I want infrastructure leaders to help make possible.