Agents Are Making Infrastructure Interesting Again

The more useful agents become, the more obvious it is that infrastructure is going to matter again. Agents are not normal app users. They run for longer, touch more systems, need more permissions, carry more context, browse more pages, call more tools, and create more artifacts. Sometimes they keep working while the human has moved on to something else.

For a while, infrastructure felt invisible. You wrote the app, pushed it somewhere, paid the cloud bill, complained about the cloud bill, and moved on. Agents are changing that because their workloads are more independent, stateful, and unpredictable than the ones traditional applications were built for.

“Agentic cloud” sounds like marketing, but the idea behind it makes sense. The old cloud was built around applications serving many users. Agents look more like semi-independent workers moving between tools, browsers, files, sandboxes, queues, identity systems, and permission boundaries.

Every good agent demo eventually runs into the same boring questions:

• Where does it run?
• What can it access?
• How long can it keep working?
• How do you stop it?
• How do you know what it did?
• How do you let it use the web without letting the web use it back?

The workload changed shape #

The weird thing about agents is that they make compute feel personal again. A web app can serve a million users with a shared backend. An agent often needs its own little world: a session, a browser, a filesystem, credentials, memory, logs, tool access, and maybe a sandbox where it can do something risky without ruining your day.

Multiply that by every knowledge worker running a few agents in parallel and the shape of infrastructure starts to change. It becomes less about one application handling requests and more about millions of tiny workers doing messy tasks for people.

This is why the browser keeps showing up in agent products. The web is still where work happens: forms, dashboards, documents, admin panels, and internal tools. An agent needs to see and act inside that world, so rendering, identity, network policy, rate limits, and bot permissions become product features instead of implementation details.

Security becomes the product #

The more autonomous an agent gets, the less cute the demo becomes. An agent that can write a todo app is fun. An agent that can access production dashboards, customer data, billing systems, deployment keys, internal documents, and browser sessions is a different thing entirely. It is also a security problem.

You need to know what the agent can touch, who approved it, how to replay its work, and how to contain poisoned instructions. You also need to keep it useful without giving every small worker the keys to the company.

This is why agent products start to feel more like operating systems than apps. They have to manage permissions, memory, tools, sandboxes, logs, review flows, rollbacks, and identity. The model gets the attention, but these control surfaces are what make autonomy usable.

The web has to adapt #

Agents are also moving beyond coding tools. Search, browsing, and research are becoming more agentic, so websites are no longer serving only humans and traditional crawlers. They are serving systems that read, reason, click, compare, summarize, and sometimes take action.

Sites now need to decide what agents can access, how content should be packaged for them, what good behavior looks like, and how to measure traffic that does not look like a normal human session.

Once agents become a real class of internet user, the web will need better rules for them. The old robots.txt world feels too soft for systems that may act on behalf of paying customers and make decisions with real consequences.

The funny part is that this makes websites feel programmable from the outside. A human sees a page. An agent sees a task surface. Small choices in layout, authentication, rate limits, canonical content, and bot policy can decide whether the agent can finish the job.

Infrastructure is the taste layer now #

Better models make infrastructure more important. If the model is weak, you mostly worry about output quality. If the model is strong enough to take action, you start worrying about its environment: permissions, context, tools, logs, rollback, review, and all the places where real work can quietly go wrong.

The next serious advantage in agents will probably be harness quality. The harness gives the model the right files, tools, permissions, memory, and path to production.

A product with a good harness will feel much better than a product with a smarter chat box and nothing around it. The model gets the attention. The harness decides whether it is useful.

DevOps becoming cool again was never on my bingo card. Somehow, here we are. The pipes became the product again.