pods are workers now, not the agent

Kubernetes people love a good deployment unit.

Give us a thing that can be scheduled, named, observed, restarted, secured, and billed, and we will build a philosophy around it before lunch.

For years, the Pod has been that thing. It is the little box where work happens. A Pod runs containers. It gets an identity through a ServiceAccount. It has logs, labels, resource requests, network policy, and a lifecycle platform teams can reason about without consulting a horoscope.

Then AI agents walked in and made the abstraction smell funny.

CNCF published a useful post asking whether a Kubernetes Pod is the right deployment unit for an AI agent. The kagent story starts in the obvious place: run each agent in its own Pod, Service, and ServiceAccount. That gives isolation, identity, policy, scheduling, and observability with tools Kubernetes teams already know.

It is a good first answer.

It is also probably not the final answer.

The interesting part is not "Kubernetes bad" or "Pods dead." The interesting part is that AI agents are forcing us to separate where work runs from what the work is.

That distinction matters a lot.

a pod is an execution place

A Pod is a great execution place. It gives you a boundary. It gives the scheduler something to place. It gives observability a target. It gives network policy something to attach to.

For normal services, this maps well.

The service exists. The Pod runs one instance of it. If demand grows, we run more Pods. If one dies, another appears. The application identity is tied to deployments, service accounts, labels, namespaces, images, and the usual Kubernetes furniture.

AI agents are different.

An agent may wake up for one task, run for thirty seconds, call three tools, spawn two helper agents, pause for human approval, resume later, write a patch, then disappear. The important identity is not the Linux process. It is not even necessarily the container. It is the logical actor doing work on behalf of someone.

That actor may move.

It may suspend.

It may be replayed.

It may need an audit history that outlives the Pod that happened to execute step four.

If all of that is represented only as "some Pod ran", you have lost the plot.

agents have actor identity

The CNCF/kagent article describes agent-substrate as a layer where Kubernetes manages WorkerPools and execution Pods, while the substrate manages Workers and Actors. Pods become the workers. Actors become the logical agents.

Because the real question is not whether a Pod can run agent code. Of course it can. A Pod can run almost anything if you give it enough CPU, permissions, and misplaced optimism.

The better question is: what object should carry identity, ownership, policy, quota, and history?

For agents, that object probably needs to be above the Pod.

Imagine a support agent acting on behalf of Maria from customer success. It reads a ticket, checks a dashboard, drafts a refund recommendation, pauses for approval, then calls an API. Which identity matters most?

The Pod name?

The worker pool?

The service account?

Or the fact that this was agent refund-reviewer, version 2026-07-29, acting for Maria, inside tenant br, with one human approval before the write?

If you are debugging an incident, the last answer is the one you want.

The Pod is where the work happened.

The Actor is why the work happened.

observability needs to follow the work, not the container

This is where the usual platform dashboards start to look a little underdressed.

Logs by Pod are useful. Metrics by container are useful. Traces by service are useful. I do not want to make Prometheus sad.

But agent work needs another dimension.

I want to see the task, the actor, the user delegation, the tool calls, the approvals, the network calls, the model used, the retries, and the final artifact. I want that trail even if execution hopped between workers or resumed after a pause.

If the agent opened a pull request that broke production, "pod restarted twice" is not the story. The story is: what did the agent believe, what did it change, what evidence did it collect, and who allowed it to continue?

That is not traditional service observability.

That is work observability.

Kubernetes can carry some of this with labels, annotations, events, audit logs, and custom resources. Good. Use the machinery. But the mental model has to move. A short-lived Pod is not always the durable unit of accountability just because our existing tools already know how to graph it.

policy belongs where the risk lives

The same problem appears with security.

Kubernetes policy today mostly attaches to Kubernetes things: Pods, namespaces, ServiceAccounts, network paths, admission rules, images, runtime profiles. That is good and mature compared with the old days when our policy model was "ship it and pray."

But agent risk is often tied to the logical actor and the delegated task.

An agent that summarizes public docs is not the same risk as an agent that can read customer data. Drafting Terraform is not applying Terraform.

If the Pod is only the execution worker, the policy model needs to understand the actor above it.

That means answering boring questions early:

• Which actor template is allowed to use which tools?
• Which tenants can schedule actors onto this worker pool?
• Which human or service delegated the task?
• Which network destinations are allowed for this actor?
• Which actions require approval before continuing?
• Which artifacts must be retained after completion?

The Pod matters. It enforces part of the boundary. But the risk lives in the actor, the task, and the authority being exercised.

Security tools that only see containers will miss part of the story. Agent platforms that ignore container boundaries will also make a mess.

Sorry. More plumbing.

scheduling is not the same as ownership

There is also a cost angle here, because of course there is. Cloud computing has a gift for turning abstractions into invoices.

One Pod per possible agent is simple to demo. It can also become wasteful if most agents are idle. Agents are bursty. They arrive with a task, consume resources, wait, then vanish.

Worker pools make sense for this. Keep a fixed set of execution capacity and schedule logical actors onto workers when work exists. We already separate jobs from nodes, functions from runtimes, requests from servers, and queues from consumers.

The trap is letting the scheduling layer become the ownership layer.

Just because an actor ran on worker abc does not mean worker abc owns the business action. The owner is the team, product, tenant, service, human delegation, or workflow that created the actor. Billing, audit, quota, and cleanup should follow that.

Otherwise every investigation becomes archaeology through ephemeral infrastructure.

And yes, archaeology is noble. It is still a terrible incident response strategy.

the practical takeaway

If you are building or buying agent infrastructure on Kubernetes, I would not start with "Pod or not Pod" as a religious argument.

I would start with a simpler checklist:

• Can I identify the logical agent independent of the Pod?
• Can I connect every action to a user, team, tenant, policy, and version?
• Can observability follow the task when execution moves or resumes?
• Can I enforce policy at the actor level and at the container level?
• Can I separate worker capacity from agent ownership?
• Can I answer "what happened?" without reading random Pod logs like ancient scripture?

If the answer is yes, good. You are probably building a real agent platform.

If the answer is no, you may be running chatbots in containers and calling it architecture.

But this one will matter.

Agents are not only another workload type. They are delegated actors that perform work, sometimes with authority, sometimes across systems, sometimes with pauses and retries. A Pod can execute them. A Pod can isolate part of them. A Pod can give platform teams a lot of useful control.

But the Pod is not the whole agent.

The sooner we admit that, the less painful the next generation of agent platforms will be.

Kubernetes is still the right place to run a lot of this machinery.

It is just not always the right place to define what the machinery means.

references

• CNCF: Is a Pod the right deployment unit for an AI agent?
• kagent documentation
• Kubernetes documentation: Pods

To test my projects, I use Railway. If you want $20 USD to get started, use this link.