AI Agents Are Changing What Infrastructure Platforms Need To Know

Platform engineering has spent years trying to make infrastructure easier for people to use. That’s partly the point of an internal developer platform. Developers shouldn’t need to understand every Kubernetes setting, cloud service, network rule or deployment process before they can ship software. 

Instead, platform teams package much of that complexity into self-service tools, automated workflows and approved paths that make the right way to do something easier to follow. It works because people are remarkably good at filling in whatever the platform leaves out. 

An engineer can check a dashboard, read a ticket, search through documentation, ask someone on Slack or simply remember why a strange configuration exists in the first place. AI infrastructure is starting to introduce a very different user, and one that can’t compensate for missing information in quite the same way.

AI agents are moving beyond answering questions and generating code. Some can now investigate incidents, provision resources, analyse telemetry and trigger operational workflows. The Cloud Native Computing Foundation (CNCF) has already described agents as emerging consumers of infrastructure platforms alongside human engineers. 

Google Cloud, meanwhile, found that 83 per cent of more than 1,400 senior IT leaders surveyed believe their infrastructure needs upgrades to support production-grade agentic AI. The interesting problem isn’t whether an agent can connect to infrastructure because we’re getting increasingly good at giving it access. 

The harder question is whether the infrastructure can tell the agent enough for that access to be useful.

Infrastructure Platforms Were Designed Around Human Users

Internal developer platforms emerged partly because modern infrastructure became too complicated for every development team to understand in full. Kubernetes, cloud services, GitOps, networking, security controls and observability all brought useful capabilities, but expecting every developer to become an expert in all of them wasn’t realistic.

So platform engineering created abstractions. A developer asks for an environment rather than manually provisioning every component. Golden paths give teams approved ways to build or deploy something, while automation carries out predictable tasks behind the scenes. CNCF describes this model as one built around a fairly basic assumption: the person using the platform is human. 

That person may be a developer, platform engineer or site reliability engineer, but they can interpret incomplete information using experience and knowledge gathered from elsewhere. Agents don’t have that same advantage. An engineer looking at an unusual firewall rule may remember that it exists because of an old integration nobody has migrated yet. 

Someone reviewing a spike in latency might know that it happens every Tuesday morning when a particular job runs. A team may even know that one service technically belongs to Finance but shouldn’t be touched without speaking to Operations first. None of those details necessarily live in the infrastructure platform. 

As AI agents begin using the same platforms, those gaps become much easier to see. The platform is no longer serving only people who can compensate for missing information. It increasingly has to support software that can only reason over the context it can actually retrieve.

Giving An Agent Access Isn't The Same As Giving It Understanding

There’s no shortage of ways to connect AI agents to enterprise systems. Infrastructure APIs already expose resources and actions. The Model Context Protocol (MCP) is adding a standard way for AI systems to access tools, resources and contextual information, while platforms can also connect agents directly to monitoring systems, service catalogues, repositories and other operational tools.

But machine-readable infrastructure isn’t automatically machine-understandable infrastructure. Being able to retrieve a configuration tells an agent what has been configured. Telemetry can tell it what a system is doing now. An API may even give it permission to change something. 

None of those things necessarily explain why the environment looks the way it does or what will happen if it changes. AWS ran into this problem while applying agentic AI to network migrations. Enterprise network configurations contain information about firewall rules, IP addresses, zones and connections, which means an agent can reconstruct a great deal about the environment. 

But AWS still found that experienced engineers had to provide operational and business context that configuration alone couldn’t explain, including what workloads were being retired and what the target environment was supposed to become. That distinction becomes increasingly important as agents move from reading infrastructure to changing it. 

An interface can tell an agent how to do something, but it still needs enough operational context to decide whether doing it makes sense.

The Missing Context Is Spread Across The Organisation

Modern infrastructure environments already contain enormous amounts of information. The problem is that the information an agent needs to make a good operational decision may be scattered across several systems, documents and people. CNCF makes a similar distinction between telemetry and context. Logs, metrics, traces and events can describe what happened. 

Experienced engineers usually combine those signals with topology, ownership, deployment history, policies, previous incidents and organisational knowledge before deciding what the event actually means. That gives us a useful way to look at what infrastructure platforms know today and what experienced people are still supplying around them.

What the platform already knows

Most mature environments can represent at least some of the technical state of the infrastructure. Configuration management systems show what has been deployed and how it is configured. Observability tools provide infrastructure telemetry about performance and behaviour, while repositories and deployment systems can show what changed and when.

Some organisations also have service catalogues, configuration management databases (CMDBs) and topology tools that connect resources to services, teams and dependencies. The important qualification is that this information rarely sits neatly inside one platform. One system may know who owns a service. Another knows its deployment history. 

A monitoring platform knows it is failing, while a runbook explains what the team normally does about it. Humans are used to moving between those sources and piecing the story together. For an agent to do the same, the platform has to make those relationships much more explicit.

What experienced engineers still know

The harder knowledge is often the information that was never formalised because people already understood it. 

• Why does this exception exist? 
• Which dependency would actually cause a serious outage if it failed? 
• Is this unusual behaviour expected or genuinely concerning? 
• Can this system be restarted now, or will doing so interrupt a critical business process? 
• Who needs to approve a change, and what happened the last time someone tried it?

AWS highlighted this problem again when introducing custom SRE agents for its DevOps Agent. It gave examples of organisation-specific operating rules, such as one database replica being allowed to lag under certain conditions or a nightly ETL process being expected to behave differently at a particular time. 

AWS notes that rules like these often live in engineers’ memories, runbooks or incident retrospectives rather than somewhere they can be applied consistently. That’s the gap agents expose. We’ve automated a great deal of infrastructure execution, but much less of the reasoning behind those decisions has been turned into information the platform can use.

Agent-Ready Infrastructure Needs A Context Layer

Making infrastructure more legible to agents doesn’t mean building one enormous database containing every piece of operational knowledge an organisation has collected. The useful shift is smaller than that. Platform teams need to think about context as part of the platform, not as information humans gather around it when something goes wrong.

CNCF describes context as an emerging first-class platform capability. Instead of giving agents isolated logs, APIs and resources, the platform connects operational information into a model that explains how applications, infrastructure resources, policies, ownership and history relate to one another.

A practical context model would need to answer eight basic questions:

• Resources: What exists?
• Relationships: What connects to or depends on it?
• State: What is happening now?
• History: What changed?
• Ownership: Who is responsible for it?
• Policy: What rules apply?
• Intent: Why is it configured or operated this way?
• Permitted actions: What can this agent do here?

Most organisations already have parts of this picture. Resources may exist in a CMDB or service catalogue. Relationships may be visible through topology or tracing tools. State comes from observability systems. and Infrastructure as Code (IaC) repositories provide change history. 

Policy engines describe some constraints, while runbooks and incident records contain operational knowledge. The architecture problem is making the right combination of that information available when an agent needs to make a decision. 

That can get difficult quickly because context can be stale, two systems may disagree, ownership metadata may be incomplete, and a runbook written three years ago may describe an environment that barely exists anymore. So the goal isn’t simply to collect more context. 

It’s to make relevant infrastructure context retrievable, current enough to trust and tied to the identity and permissions of whatever agent is using it.

More Context Shouldn't Mean More Authority

There’s another distinction infrastructure teams will need to hold onto as agents become more capable. Knowing what should happen isn’t the same as having permission to make it happen. Operational AI is already moving beyond simple copilots. 

AWS made its DevOps Agent generally available in 2026, with capabilities that include investigating incidents across observability data, deployment information and system relationships. Google has also described how its Site Reliability Engineering teams are using agentic AI to improve operational work. 

That doesn’t mean every agent should be allowed to independently change production infrastructure. A more useful way to design agentic operations is to separate three levels of capability:

• Observe: The agent retrieves information and interprets what is happening.
• Recommend: It uses that context to propose a response or infrastructure change.
• Act: It carries out the change itself.

Those levels don’t have to advance together. An organisation may be comfortable giving an AI SRE broad access to operational context while limiting its ability to execute changes. A low-risk remediation could be automated, while anything affecting a critical service still requires approval.

Escalation rules, rollback processes and clear boundaries around human intervention therefore become part of platform architecture. The richer an agent’s understanding becomes, the more useful it can be, but the level of authority it receives should still reflect the consequence of getting a decision wrong.

How To Assess Whether Your Platform Is Ready For AI Agents

For infrastructure leaders, the useful question isn’t whether the organisation has started experimenting with agents. It’s whether the underlying platform can provide enough reliable context for those agents to work with. A simple AI agent infrastructure readiness check starts with seven questions:

1. Can an agent identify what a resource is and what depends on it? It should be able to understand relationships, not just find isolated resources.
2. Can it determine who owns it and which policies apply? Technical access without ownership and policy context leaves important gaps.
3. Can it distinguish normal behaviour from an incident using more than raw telemetry? A threshold breach isn’t always a problem, while behaviour inside normal thresholds can still indicate one.
4. Can it reconstruct relevant changes and operational history? Recent deployments, configuration changes and previous incidents often explain what current telemetry cannot.
5. Can it determine why important constraints or configurations exist? If the answer lives only in an engineer’s memory, the platform is missing part of the context an agent may need.
6. Does it know which actions it may take independently and which require escalation? Context and authority should be defined separately.
7. Can a human reconstruct what context the agent used and what it did afterwards? If teams can’t understand the inputs behind an operational action, troubleshooting the agent becomes another infrastructure problem.

These questions become harder in organisations operating several infrastructure platforms at once. Platform Engineering’s 2026 State of Platform Engineering research found that 55.9 per cent of surveyed organisations operate more than one platform. 

That means useful context may need to cross several technical and organisational boundaries before an agent has enough information to make a reliable decision. If several of these questions don’t have clear answers, adding an AI interface probably won’t fix the underlying problem. 

It may simply give an agent faster access to infrastructure it still doesn’t understand.

Final Thoughts: AI Agents Need More Than Infrastructure Access

Platform engineering has been successful because it removed complexity from the people consuming infrastructure. Developers could ask for what they needed without becoming experts in everything happening underneath. AI agents expose the other side of that abstraction because people can work around incomplete platforms in ways software cannot.

Experienced engineers carry operational knowledge with them. They remember old decisions, recognise exceptions, understand informal dependencies and know when the technically valid action would still be a very bad idea. Agents can only reason over what the organisation makes available to them.

That doesn’t mean every piece of institutional knowledge needs to be encoded before an enterprise can experiment with agentic infrastructure. The requirement should grow with the consequence of what the agent is being asked to do. An agent summarising an incident needs less context than one restarting services, changing network rules or provisioning production resources.

But as agents move closer to the infrastructure control plane, platform engineering may increasingly become an exercise in making operational knowledge explicit. The quality of the model will still count, and so will the quality of the agent. Yet the decisions those systems make may depend just as heavily on whether the surrounding infrastructure can explain itself well enough to be understood.

As that shift develops, EM360Tech will continue tracking what it changes for the teams designing, operating and governing the infrastructure enterprises depend on every day.