Your internal developer platform was designed for a world of stateless containers. A request arrives, a pod handles it, the pod dies. Scaling is horizontal. Failure recovery is a restart. Observability is structured logs and request traces. Your platform team got very good at this.
Now hand that team a fleet of autonomous AI agents that hold conversation state for hours, spike GPU consumption unpredictably, call external tools on their own initiative, and fail in ways that look nothing like an HTTP 500. Same team. Fundamentally different workload. The question is not whether platform engineering owns this — it is whether the team evolves fast enough to operate it.
The CNCF Has Already Made the Call
In July 2026, the Cloud Native Computing Foundation published a technical analysis arguing that agentic AI systems should be built on existing cloud native infrastructure, not bespoke ML stacks. The core thesis: agents are distributed systems with additional reasoning capabilities, and the operational problems they introduce — securing identities, coordinating long running workflows, managing state, ensuring observability, recovering from failures — are precisely the problems the cloud native ecosystem spent the last decade solving.
The paper walked through a Kubernetes based multi agent security platform combining Dapr, OpenTelemetry, SPIFFE, Falco, and Kafka. No custom orchestrator. No special purpose scheduler. Just the same primitives your platform team already operates, extended with agent aware abstractions.
This is a deliberate signal. The CNCF is not positioning agents as a research curiosity that lives in a data science silo. It is positioning them as the next class of production workload that runs on the same infrastructure your platform team already owns.
Kubernetes 1.36: The Scheduler Learns About GPUs
If the CNCF paper was the strategic argument, Kubernetes 1.36 (shipped May 2026) is the tactical proof. The release is best described by the ScaleOps team’s summary: “less about brand new mechanics and more about the defaults catching up to two years of accumulated AI workload scar tissue.”
Three Dynamic Resource Allocation (DRA) enhancements — Partitionable Devices, Consumable Capacity, and Device Taints and Tolerations — all moved to Beta and shipped enabled by default. Together they replace the old integer GPU device plugin model, where a single card was allocated wholesale regardless of actual utilization, with primitives that can express how modern accelerators are partitioned, shared, and recovered when they fail.
For platform teams, the headline feature is Workload Aware Preemption (alpha). Before 1.36, the scheduler would preempt individual pods to make room for higher priority work, which could leave a distributed agent fleet with seven of eight workers running but unable to make progress. The new behavior treats a PodGroup as a single preemption unit and only proceeds with eviction after verifying the high priority group can actually fit.
There is also Mutable Pod Resources for Suspended Jobs (now beta, enabled by default). A queue controller can suspend a running job, adjust its CPU, memory, or GPU requests to match available cluster capacity, and unsuspend it — without destroying and recreating pods. For agent workloads that hold in memory state, this is the difference between a graceful resource adjustment and a hard restart that loses hours of accumulated context.
The message is clear: the Kubernetes ecosystem is building first class primitives for exactly the workloads platform teams are about to inherit.
AWS ECS: Auto Recovery for Agent Connectivity Loss
Managed container platforms are adapting too. On August 31, AWS announced that Amazon ECS now automatically detects and recovers container instances that lose agent connectivity to the control plane. ECS surfaces a new AGENT_CONNECTIVITY health event across Fargate, Managed Instances, and EC2. On Fargate and Managed Instances, recovery is automatic — drain, replace, deregister. On EC2, you wire the event into your own workflow.
This matters because agentic workloads are particularly sensitive to control plane disconnection. A stateless web server that loses its orchestrator is an inconvenience — the load balancer routes around it. An autonomous agent that loses contact may continue executing stale instructions, burn resources on obsolete work, or silently drop state that cannot be reconstructed. Auto recovery at the platform level is a prerequisite, not a nice to have.
What Actually Changes for Platform Teams
The operational model shift from stateless containers to autonomous agents is not incremental. Here is where the differences bite:
Scheduling becomes resource aware in new dimensions. Stateless containers need CPU and memory. Agents need GPU shares, sometimes fractional, sometimes across multiple accelerators. Your IDP’s resource request templates need to understand DRA claims, not just resources.requests.cpu.
Failure recovery is no longer “just restart it.” An agent that has been running for six hours, maintaining conversation state and accumulated tool call context, cannot simply be killed and restarted. Your platform needs checkpointing primitives, graceful drain hooks that give agents time to persist state, and recovery paths that restore context rather than starting from zero. The Kubernetes 1.36 in place vertical scaling feature is relevant here — resizing resources without restarting the pod means you can adapt to changing demand without losing state.
Observability must explain decisions, not just measure latency. Traditional traces show you the path a request took through your microservices. Agent observability needs to capture reasoning paths, tool invocations, and the context that led to each autonomous decision. OpenTelemetry is being extended for this, but your IDP’s default dashboards and alerting rules were not built for it. Dynatrace’s 2026 State of SRE and Platform Engineering report found that monitoring AI systems is now SREs’ number one use case at 58%, ahead of automation and SLO management. Your platform’s observability stack needs to catch up.
Cost attribution gets harder. A stateless container’s cost is predictable: CPU hours times instance price. An agent’s cost is variable: model inference tokens, tool call API charges, GPU time that fluctuates with reasoning complexity. The InfoQ Cloud and DevOps Trends 2026 report captures this well — Shweta Vohra from the FinOps Foundation described the current state as “agents’ chaos at the moment is bigger than the microservices times we saw.” Your IDP needs cost attribution that tracks token consumption per agent per task, not just pod level compute.
Why Not a Separate “AI Infra” Team?
There is a tempting pattern: stand up a dedicated AI infrastructure team, give them their own cluster, let them figure it out. Resist this.
The InfoQ trends report found that platform teams are evolving from builders to enablers. Mark Silvester noted that platform teams at his clients are becoming “AI native enablers” — and when the central platform is not good enough, teams build shadow platforms that fragment governance. An isolated AI infra team creates exactly this fragmentation: two deployment pipelines, two observability stacks, two cost models, two incident response processes. The agents still need network policies, secrets management, identity federation, and CI/CD — all things your platform team already provides.
The better model: extend the existing IDP. The platform team already owns the paved road. Widen it for a new vehicle type. Do not build a separate highway.
The Platform Team Audit Checklist
If you are on a platform engineering team, here is what to evaluate in your IDP today:
- GPU and accelerator support in your resource model. Can developers request fractional GPUs or specific accelerator types through your self service catalog? If your IDP still only exposes CPU and memory, you are already behind.
- State preservation primitives. Do you offer checkpointing, persistent volumes with fast attach, or graceful drain hooks with configurable timeouts longer than 30 seconds? Agent workloads need them.
- Agent aware health checks. Your liveness and readiness probes were designed for HTTP endpoints. Add checks that verify agent control plane connectivity, reasoning loop health, and tool call availability.
- Observability for reasoning, not just requests. Extend your default telemetry to capture tool invocations, token consumption, and decision traces. OpenTelemetry semantic conventions for GenAI are your starting point.
- Cost attribution per agent task. Integrate token level cost tracking into your chargeback model. If your FinOps dashboards only show pod level compute, they will miss the majority of agent operating cost.
The Road Ahead
The CNCF made the architectural argument. Kubernetes 1.36 shipped the scheduling primitives. AWS is hardening its managed platforms for agent resilience. The ecosystem is converging on a clear answer: agentic AI runs on cloud native infrastructure, and the platform engineering team is the natural owner.
The platform teams that move now — extending their IDPs with GPU aware scheduling, stateful recovery, agent observability, and token cost attribution — will be the ones that keep the paved road paved. The ones that wait will find their developers building shadow AI platforms in the same way they once built shadow Kubernetes clusters: fast, fragmented, and ungovernable.
Your platform engineering team built the internal developer platform. They are about to build the internal agent platform. Same team. Bigger mandate. Start the audit today.