AI in Platform Engineering: When Agents Join Your Platform

AI agents are now among your platform users. They request environments, open pull requests, apply changes, and consume Golden Paths at machine speed, without the judgment a human developer brings to the same task.

Platform teams spent the last ten years building Golden Paths for people, from infrastructure and service templates to developer portals and self-service workflows. Agents are a new class of platform user and a new type of workload at the same time. They need the same paths through a different interface, plus their own identity, permissions, budgets, and audit trail.

What has become clear over the past few years, and is highlighted in the Spacelift 2026 Infrastructure Automation Report, is that AI is an amplifier. Organizations with well-structured platforms and governance, sane guardrails and controls in place, and clear paths to production get real gains from AI. Teams without them struggle to achieve collective benefits beyond personal developer speed gains.

In this blog, we explore what agents need from a platform and how to adopt agent-driven workflows while keeping things under control.

What we’ll cover:

1. Where AI meets platform engineering
2. AI agents are a new class of platform users
3. How platforms need to evolve for AI agents
4. A staged adoption path for AI agents in platform engineering
5. Open questions and considerations for teams starting now

The foundation for preparing AI and agent platforms already exists in most companies. According to DORA’s 2025 report, 90% of organizations use some form of internal platform, and 76% have a dedicated platform team.

Overall, AI and agents enter platform engineering from three directions:

Assistants

The first is code generation and question answering with AI tooling and agentic harnesses, and it’s an established practice by now. Code and configuration generation, docs Q&A over internal knowledge bases, service scaffolding from templates, and incident summaries are common in most engineering organizations in 2026.

Tools such as Claude Code, Cursor, Kiro, and OpenAI Codex cover the coding side, and portal assistants handle question answering directly within the platform with the right context.

Operators

The second is AI tools and agents, as a new class of users, embedded in the platform and acting on infrastructure to assist humans: SRE-focused agents, with multiple examples in the space, such as the AWS DevOps Agent, Resolve AI, OpsWorker, and PagerDuty SRE Agent.

These pull logs, correlate signals, propose remediations, automatically open pull requests, or perform actions on the platform to address incidents, bugs, and issues.

AI workloads

Another area worth mentioning is hosting and running custom AI workloads (GPU scheduling, model serving, inference endpoints, usage metering), which is also a hot platform engineering topic of its own that we will keep out of this blog’s scope.

Agents acting reliably on infrastructure through the platform are still a big challenge. These agents need tuning, identity, permissions, guardrails, observability, and often human oversight for critical approval flows. 

Even then, their behavior is not always deterministic, which means these systems should be designed with failure modes in mind.

A useful mental model is to treat agents as users who can make mistakes. They should be able to consume the same self-service paths as humans: request environments, deploy from templates, propose changes, and query catalogs. But they should also be restricted in what they can do and how much they can consume. 

For agents to be effective and act safely within your platforms, consider these requirements:

1. Agent-specific identity: Every agent gets its own identity details. Credentials are short-lived and least-privilege scoped, so you can clearly identify agent actions and quickly revoke specific permissions if needed.
2. Ownership and lifecycle: A named owner or team is responsible for agents’ lifecycles and actions. A kill switch should pause their actions if unintended behavior is observed. 
3. Guardrails, quotas, and budgets: Agents can work 24/7, and they usually work faster than humans. Guardrails and policies on what they can do, rate limits, maximum spend, and token caps per agent identity provide the necessary controls.
4. Observability: Every agent action must be attributable and searchable. That means detailed audit logs that record agent actions, traces, reasoning, and tool calls.

Wherever agents touch delivery workflows, such as agents in CI/CD reviewing pull requests, triaging build failures, patching vulnerable dependencies, and verifying deployments, these controls must be in place. 

Same paths, different interface

Agents should be able to consume Golden Paths like humans do, but the interfaces they need are different. 

• APIs, MCPs, and CLIs over UIs: Self-service actions for agents need an interface they can use, such as MCP servers.
• Context, docs, repos adjusted for agents: Docs should provide specific formats for agent consumption, such as markdown versions and compact overviews with links. Written text for agents should be adjusted for retrieval, which means keeping one topic per page, canonical examples per task, constraints, and “do not” rules at the top. The Open Knowledge Format (OKF) represents organizational knowledge as a directory of markdown files, built for progressive disclosure. 

For code repositories, configure agent markdown files, such as AGENTS.md or CLAUDE.md, skills, and available MCP tools.

The platform itself needs new capabilities to serve AI and agentic systems. An agentic development platform adds components on top of the classic internal developer platform, in four groups: identity and access, gateways, building blocks, and controls.

Identity and access

• Agent Identity: Workload identity standards such as SPIFFE extend naturally to agents with verifiable, short-lived identities. Cloud IAM roles with workload identity federation do the same with cloud provider native tools.
• Secrets: Secrets are stored in a vault and accessed at runtime, scoped to the agent identity and the task.

Gateways

• LLM gateway: This allows an organization to centralize model access for everyone through a single entry point. The LLM Gateway sits in front of different model providers such as Anthropic, OpenAI, AWS, Azure, Google Cloud, and so on. LiteLLM, PortKey, and Envoy AI Gateway are common choices that hold provider credentials; manage budget and rate limits per application, team, or agent; and help with per-identity spend caps, centralized observability, and attributable usage.
• MCP & tool gateway: Agents reach internal systems through Model Context Protocol (MCP) servers. A gateway gives you one governed entry point: central allowlists for which servers and tools are exposed, central logging of every call, and central credential handling so agents never hold long-lived secrets themselves. Amazon Bedrock AgentCore Gateway is a provider-specific option, while Envoy MCP Gateway and Docker’s MCP Gateway are two open-source starting points.

Building blocks

• Agent Harness: An agent is basically a model in a loop with some tools. What makes it usable in complex scenarios is the harness and the ecosystem around it: tools, guardrails, observability, governance, feedback loops, context, and memory management.Building and operating this harness is a new layer of platform work. For a detailed walkthrough of configuring an agentic coding tool for infrastructure work, see Claude Code for Infrastructure as Code: A Practical Guide.

• Registries for agents, skills, and prompts: Agents, skills, prompts, and other common infrastructure, systems, and templated components often need to be discoverable and consumable at scale via a self-service method. A central registry allows you to centralize ownership of such artifacts, avoid duplication of effort, and fast-track AI and agent usage within an organization in line with best practices.Agentic Resource Discovery (ARD) is an open specification that defines a shared format for describing agentic resources (agents, MCP servers, tools, skills) across cloud, on-premises, and SaaS systems.
• Context layer for agents. Agents need structured metadata and a way to navigate enterprise internal knowledge, service boundaries, dependencies, terminologies, ontologies, and various data systems. The quality of this context layer is important for building agents that are effective at their tasks, especially in large and complex enterprise scenarios.
• Golden Paths for agents: Following core platform engineering principles, these paths provide templated inputs, built-in policy checks, and a path to production that includes common data sources and tooling.
• Agent Sandbox: Agents need isolated or ephemeral environments to operate within clear boundaries. Especially for infrastructure work, they also benefit from having access to create sandbox accounts for short-lived preview environments to test their changes.

Controls

• Policies and guardrails: Security controls and policies intercept every tool call and validate it before it reaches its target. The policies cover security rules, what the agents are allowed to do, tagging standards, cost limits, and forbidden resource types and operations. Where the blast radius or the stakes are high, consider approval gates, especially for production systems.We covered the full control set, from generation-time controls to post-apply measurement, in Guardrails for AI-Generated Infrastructure.
• Earned and bounded autonomy: Agent systems need to earn their level of autonomy. Always start from lower-level environments and from non-critical use cases when testing autonomy in agentic systems. For business-critical systems, consider embedding human approvals for state-changing steps, while permitting read-only operations. Escalation paths are defined up front, so when the agent needs input or sees something outside its scope, it hands it off to a person.
• Drift detection: Scheduled drift detection catches changes that might bypass processes and pipelines, bringing the system back to its intended state.
• Audit trail: Workflows, runs, and changes are recorded and attributable to an identity, human or agent.

Let’s look at a practical plan for rolling out agents across a platform:

Stage one: fix platform quality first

AI amplifies the existing platform state. If templates are inconsistent, documentation is missing, and deployments are error-prone and require human oversight, agents will fail. Clean Golden Paths, reliable pipelines, and good metadata should be ready before rolling out agents.

Stage two: assisted workflows inside existing golden paths

Code generation, docs Q&A, incident summaries, and template scaffolding assist humans. This stage is low-risk and provides immediate feedback on where your context, docs, and existing processes might be insufficient.

Stage three: agent identities with read-only or minimal write access

Give agents their own identities and let them inspect, analyze, report, and propose. An agent that analyzes drift, summarizes failed runs, or drafts a remediation plan creates value without adding much risk, and it validates your identity and observability layers under real conditions. Afterward, you can start expanding and testing with write and edit access in non-critical use cases and test environments.

Stage four: scoped writes with approvals

Agents open pull requests, produce plans, and apply changes in sandboxes and lower-level environments, with humans approving critical changes. Autonomy is given gradually as confidence grows and as feedback loops enable the platform team to better assess where agents perform well on their own and where they need oversight.

Stage five: autonomy by exception

This feels more like a desired future state, not something we see happening at scale yet. For flows that are consistently performing well on stage four, agents can start applying changes without per-change approvals. Humans are still the escalation point for exceptions, and sampled reviews are still in place to ensure quality.

Autonomy is granted per workflow and agent, but agents must first pass all the other four stages successfully.

Next step: Based on their runs, agents propose changes to Golden Paths and templates to improve and evolve them, but the platform team approves them.

Measure

As well as the metrics you use for the platform itself, such as lead time for changes, incident rate, change failure rate, and time to restore, you also need new AI-specific metrics. These include cost per agent, volume of AI-generated code in pipelines, error rates of AI-generated changes, and drift attributable to AI changes.

Despite the clear adoption path, some problems have no definitive solutions yet. Here is the current thinking on the ones platform teams hit first:

• What happens if you add agents to a weak platform? Adding agents to a weak platform with no observability strategy, no controls in place, and no dedicated agent identities leads to weak outcomes.
• How do you run non-deterministic agents inside deterministic pipelines? Operations tooling and processes have been built with determinism in mind. Agents break that logic because two agent runs can produce different results. Retry logic and idempotency assumptions built into pipelines need rework, and deterministic checks, such as tests, scanners, and policies, should determine whether agent output is acceptable.
• Which standards can you safely build on today? MCP changes fast. The July 2026 specification moved the protocol to a stateless design for better reliability and scalability, and SDKs are still evolving. Agent-to-agent protocols, such as A2A, are also evolving.
• How do you forecast the cost of agentic workflows? Agentic workflows consume tokens in loops whose length depends on the task, so per-run cost varies widely. Budget caps per identity and per run are the practical answer until usage patterns stabilize enough to enable reliable forecasting.
• What skills does the platform team need now? In addition to DevOps, site reliability, and software engineering experience, platform engineers now need AI/ML and agentic engineering knowledge to review agent behavior, tool scopes, and permission boundaries. The platform role is expanding to include writing evaluations for agent workflows and tuning harness configuration.

Spacelift is an infrastructure orchestration platform that maps closely to the layers described above.

• Self-service platform: Blueprints and templates act as Golden Paths that both humans and agents can consume: templated, policy-checked self-service provisioning with typed inputs and pinned sources.
• Policy as code across the lifecycle: The OPA-based policy engine is the enforcement layer for agent-generated changes. Plan policies inspect proposed resources, push policies control how code enters the pipeline, and approval policies add human gates for state-changing runs.
• Spaces, contexts, and private workers: Spaces and contexts offer scoped access to implement bounded autonomy: agents operate within their defined space, and humans control and approve actions where it matters. Private workers keep runs within your own network when compliance requires it.
• Drift detection with remediation: Scheduled drift detection catches unintended changes made by any actor, agent, or human, and the audit trail records every run, change, and approval in an attributable manner.
• Spacelift Intelligence

To prepare your platform for agentic workloads, Spacelift Intelligence adds a family of AI-powered features:

1. Intent: Provision and manage infrastructure by describing what you want, directly from your own AI client such as Claude Code, Cursor, or VS Code. You connect through the Spacelift MCP server, and resources live in Intent projects that hold their state, operation history, policies, and cloud integrations. Intent has its own policies and OPA-based rules that define what the AI is allowed to do. Every write operation is checked against them before it executes.

2. Infra Assistant: An AI chat panel inside the Spacelift UI. In Ask mode, it answers questions about your infrastructure, explains failed runs, and searches the documentation. In Build mode, it creates and manages resources through conversation, governed by the same Intent policies. Admins enable it in settings and choose between ask-only and ask-and-build modes.

If you want to see what this looks like on your own stacks, start a free trial or book a demo with our engineers.

Agents are joining platforms as users and workloads, and platforms with well-structured foundations are the best suited to enable them. Strong and tested Golden Paths, per-agent identity, policy enforcement on changes, sandboxes for experimentation, and audit trails that make every action attributable are non-negotiable.

Fortunately, none of these primitives is new. What is new is applying them to a user (agent) that works at machine speed and might sometimes get things wrong with confidence.

Start by improving platform quality and adopting assisted workflows. Then increase agent autonomy gradually, behind approvals. Measure agent-driven changes against your existing delivery metrics, and let the results set the pace.