Platform engineering was designed around a fairly stable assumption: a human developer decides what needs to happen, then uses standardized tooling to make it happen.
AI agents change that assumption.
An agent can inspect code, query telemetry, provision an environment, run tests, update configuration, open a pull request, or initiate remediation without a developer performing each individual step. The platform is no longer serving only people. It is increasingly serving software that can make and execute decisions.
That changes the platform engineering problem. The priority is no longer just developer self-service. Enterprises need a controlled execution layer where humans and AI agents can operate without creating unacceptable security, cost, reliability, or governance risk.
For organizations already using Infrastructure Managed Services, this shift also changes what infrastructure operations teams will need to govern.
AI Agents Change the Platform User Model
Most internal developer platforms were designed around developers, platform engineers, and SREs.
The workflow is usually predictable:
A developer requests an environment. The platform applies a template. Infrastructure is provisioned through approved pipelines. The developer remains accountable for the request.
AI agents introduce a different operating pattern.
An agent may receive a task such as investigating a performance regression. It could query observability data, compare recent deployments, inspect configuration changes, identify a likely cause, generate a fix, run tests, and submit a pull request.
This aligns with CNCF's guidance on agentic platform engineering, which describes AI agents as platform consumers that provision infrastructure, deploy applications, investigate incidents, analyze telemetry, and invoke operational workflows alongside human engineers.
The individual actions are familiar. What changes is who decides when those actions happen.
That distinction matters because humans bring judgment that platform teams often take for granted. Engineers recognize unusual situations, understand undocumented dependencies, and know when an automation should not be trusted.
Agents operate on the context available to them.
This creates a useful way to think about agent readiness: AI agents expose weaknesses in platform maturity faster than developers do.
A developer may know that one production service cannot be restarted during a reconciliation window, even if the runbook never says so. An agent will not reliably infer that constraint unless it exists as machine-readable context or an enforceable policy.
Platform leaders should therefore classify workflows according to the autonomy they can safely support.
Some activities should remain advisory. Others can allow agent execution after approval. Low-risk and reversible tasks may eventually become fully autonomous.
The wrong starting question is, “Where can we use agents?”
A better question is, “Which parts of our operating environment are sufficiently standardized to let an agent act safely?”
The Internal Developer Platform Must Become Machine-Readable
Developer portals have become an important part of platform engineering because they simplify complicated infrastructure and delivery workflows.
But a portal optimized for humans is not automatically useful to an agent.
People can read documentation, interpret dashboards, search Slack, ask another engineer, and work around incomplete service catalogs.
Agents need more explicit interfaces.
An agent-ready platform should expose structured information about:
- service ownership and dependencies
- approved infrastructure templates
- environments and deployment states
- operational policies
- APIs and available tools
- runbooks and remediation procedures
- observability data
- permitted actions
This is where APIs, CLIs, structured service catalogs, event interfaces, and protocols such as MCP become important. The Model Context Protocol specification defines MCP as an open protocol that "enables seamless integration between LLM applications and external data sources and tools," providing a standardized way for AI agents to discover and invoke platform capabilities.
But enterprises should avoid interpreting MCP or another agent protocol as the complete solution. Connectivity tells an agent how to reach a tool. It does not determine whether the agent should be allowed to use that tool.
The platform API should remain the authoritative execution layer.
For example, an agent requesting a Kubernetes environment should not construct infrastructure however it chooses. It should call an approved platform capability that already contains the organization's rules around networking, security, tagging, observability, and cost controls.
This is an important evolution of the internal developer platform.
Today's question is often:
Can a developer perform this task without opening an infrastructure ticket?
The emerging question is:
Can an authorized agent understand and perform this task without relying on undocumented human knowledge?
That will become increasingly relevant for enterprises combining platform engineering with Infrastructure Managed Services, because operational knowledge must be encoded rather than remaining inside individual support teams.
Identity and Permissions Must Become Agent-Aware
Agent identity is one of the easiest areas to underestimate.
Enterprises already have service accounts, API keys, workload identities, and IAM roles. It can therefore be tempting to treat an AI agent like another application.
That approach becomes risky when the agent can dynamically choose actions.
A production agent should have a clearly defined identity, owner, permission scope, lifecycle, allowed tools, accessible environments, and audit trail.
Shared credentials are especially problematic.
If five agents use the same privileged service account, an incident investigation may show that the account changed a production resource but not which agent initiated the action, what task it was performing, or which human authorized it.
A better model connects:
Human identity → agent identity → task identity → action
Permissions should also reflect what the agent actually needs. This follows NIST's least-privilege access guidance (AC-6), which requires organizations to limit every user and process to the minimum access needed to perform assigned tasks and explicitly applies to "automated processes and system-level accounts" in addition to human users.
Consider an incident-response agent. It may need permission to read metrics, logs, recent deployments, and Kubernetes health information. It may be allowed to restart a predefined stateless workload.
That does not mean it should be able to modify IAM policies, delete persistent storage, or reconfigure production networking.
Where possible, permissions should be temporary and task-scoped rather than permanent.
This matters because an agent can make decisions faster than a human operator. A permission mistake that would give one engineer too much access can create a much larger blast radius when combined with automated execution.
Golden Paths Must Become Guardrailed Execution Paths
Golden paths have traditionally given developers recommended ways to provision infrastructure, deploy applications, or create services.
For humans, they are often guidance.
For AI agents, they need to become constraints.
An agent-ready golden path might define:
- which infrastructure templates can be used
- which tools can be called
- which environments are accessible
- which policy checks must pass
- when human approval is required
- what rollback mechanism must exist
- what cost ceiling applies
Consider an agent generating a Terraform change.
Allowing the model to generate code and immediately apply it to production would be a weak operating model.
A safer execution path could require the generated change to enter a sandbox, pass policy-as-code checks, complete security scanning, generate a cost estimate, produce a deployment preview, and request approval when the blast radius exceeds an agreed threshold.
The model should not be responsible for deciding whether its own output is safe.
Controls should sit outside the model.
This is where platform teams need more nuance than the common recommendation to “keep a human in the loop.”
Human approval for every agent action creates another ticket queue and eventually removes much of the benefit of autonomous execution.
A more useful decision model considers blast radius, reversibility, and sensitivity.
A low-risk action that can be immediately reversed may run autonomously. A change affecting persistent production data should face substantially stronger controls.
The goal is controlled autonomy, not maximum autonomy.
Observability Must Extend From Systems to Agent Decisions
Traditional observability helps answer questions such as:
What failed?
Where did latency increase?
Which deployment caused the problem?
With agents, another question becomes necessary:
Why did the agent take that action?
Platform teams will need telemetry that connects system behavior with agent behavior.
Depending on the use case, that may include:
- the task given to the agent
- model and model version
- context retrieved
- tools invoked
- policies evaluated
- permissions used
- approvals received
- retries
- token consumption
- infrastructure or application changes produced
Suppose an agent changes an application configuration and causes a production incident.
Knowing that a configuration deployment occurred is no longer enough.
An investigation should be able to reconstruct:
task → context → model decision → tool call → policy evaluation → deployment → operational impact
This is decision provenance.
It should become part of the observability architecture for autonomous systems.
Organizations using Infrastructure Managed Services should also consider how existing monitoring and incident-management contracts need to change. Monitoring infrastructure health while ignoring autonomous actions that modify that infrastructure leaves a major operational blind spot.
There is a tradeoff here. Recording every prompt, retrieved document, model response, and tool invocation indefinitely can create significant storage costs and may introduce its own security concerns.
The objective is not unlimited logging. It is enough evidence to establish accountability, diagnose failures, and satisfy governance requirements.
FinOps Must Move Into the Agent Execution Loop
Agents create another problem that traditional automation rarely faces at the same scale: they can consume resources repeatedly while trying to achieve an outcome.
A single task could generate costs through model inference, API calls, test environments, GPU capacity, storage, network traffic, and retries.
That means FinOps controls can no longer sit only at the monthly cloud reporting layer.
Agent workflows may need:
- task-level budgets
- token limits
- API quotas
- infrastructure ceilings
- model-routing rules
- automatic termination conditions
Model selection is part of this decision.
A simple log classification task does not necessarily require the organization's most capable and expensive model. More complex production diagnosis may justify escalation.
The useful metric becomes cost per successful task, not token cost in isolation.
An inexpensive model that repeatedly fails and retries may cost more operationally than a stronger model that resolves the task once.
Platform engineering, AI engineering, FinOps, and Infrastructure Managed Services teams will increasingly need a shared view of those economics.
Platform Teams Need a New Operating Model
The architectural changes eventually become organizational changes.
Someone needs to own the shared capabilities that allow agents to operate safely.
Platform teams are well positioned to provide common services such as:
- agent registration
- identity and authentication
- tool access
- execution environments
- policy enforcement
- observability
- cost controls
That does not mean the platform team should own every enterprise agent.
A centralized AI team controlling every workflow quickly becomes a bottleneck. The opposite model, where individual teams create agents independently, produces shadow AI, duplicated infrastructure, inconsistent controls, and unclear accountability.
A more sustainable pattern is:
centralized platform controls with decentralized domain ownership.
The platform team owns the execution environment.
Domain teams own the agent's business logic, success criteria, and domain-specific behavior.
A payments engineering team, for example, may own an agent that investigates reconciliation failures. The central platform should still determine how that agent authenticates, which production systems it can access, how actions are logged, and when approval is required.
This separation preserves team autonomy without abandoning enterprise governance.
Start With Controlled Autonomy, Not Maximum Autonomy
Technology leaders do not need to decide today whether agents should operate production systems independently.
They need a path for increasing autonomy safely.
A practical maturity model has four levels.
Level 1: Advisory
The agent analyzes information and recommends an action. A human performs it.
Level 2: Assisted
The agent prepares and executes the action only after explicit approval.
Level 3: Guardrailed autonomous
The agent independently performs predefined, low-risk workflows inside strict boundaries.
Level 4: Policy-driven autonomous
The agent can choose and execute broader workflows as long as identity, policy, cost, and risk controls permit them.
Organizations should move between levels based on evidence, not enthusiasm.
Good early candidates include test environment provisioning, incident summarization, log analysis, dependency updates, test execution, and non-production remediation.
Measure what happens.
Track successful autonomous tasks, human intervention rate, rollback rate, policy violations, cost per outcome, time saved, and production incidents caused or avoided.
The number of deployed agents is a poor maturity metric.
Platform Readiness Will Determine How Much Autonomy AI Can Have
AI agents will not remove the need for platform engineering. They place more pressure on it.
When software can decide which tools to call and which actions to perform, the platform becomes the boundary that determines what an agent can see, change, spend, and affect.
Technology leaders evaluating agentic engineering should assess six areas before increasing autonomy:
Identity: Who or what is acting?
Context: What information can the agent access and trust?
Capability: Which actions and tools can it invoke?
Policy: What prevents unsafe execution?
Observability: Can every important decision and action be reconstructed?
Economics: How much resource consumption can a task generate?
For every proposed agent workflow, ask:
What can it see? What can it do? What can it spend? What can it change? What evidence will it leave behind? When must a human intervene?
The organizations that scale agentic engineering successfully will probably not be those with the largest number of autonomous agents.
They will be the organizations that know exactly how much autonomy their platform can safely support.
Top comments (0)