Kubernetes was built for work that ends. A request arrives, a container serves it, the pod dies, and nothing is supposed to be lost because nothing was supposed to persist. The cloud native community spent a decade perfecting infrastructure on that assumption, and it gave us one of the most successful open ecosystems in software. At KCD Bay Area this week you could hear the assumption creaking in every room, because the unit of work is changing underneath it. Work used to be something a human triggered and software executed. Increasingly it is something software carries on a human’s behalf, for hours or days, accumulating state the whole way.
You could read the shift right off the agenda. A developer platform “for both humans and agents.” Guardrails for agentic GitOps. Incident response agents that start the root cause analysis before you do. A talk literally titled “Nodes Lie, Caches Lag.” This community is discovering, in public and in production, that the stack it built for episodic work is being asked to host persistent workers.
Three moments made the shift concrete for me.
The scheduler learns new physics
The afternoon panel put Nvidia, Google, CoreWeave, Adobe and Intuit on one stage, and the honest sentence of the day was: ask any AI engineer who lands on Kubernetes and they will tell you this platform was not built for them. Training jobs run for weeks and need gang scheduling, where the old world assumed small, restartable, interchangeable pods. Inference is bursty and topology sensitive. The AI conformance effort Janet Kuo and Rita Zhang described is the community’s attempt to restore the original promise, build once and run anywhere, for workloads the original design never imagined.
The moment I keep replaying was smaller. Janet described Agent Sandbox, a project that exists because agents in pods run arbitrary code, and arbitrary code needs stronger isolation than a default container runtime. The moderator joked about what happens when agents escape the cluster, and the room laughed. Then it went quiet for a beat, because everyone was doing the same math. Isolation for code we wrote is a solved problem. Isolation for code that decides what to do next is a different discipline, and it is being invented now, in a SIG, by the same people who hardened RBAC a decade ago.
One more line from that panel stayed with me. Upgrading Kubernetes will not solve this; the whole ecosystem around it has to upgrade, because agents arrive with needs the native constructs never modeled: MCP gateways, token rate limits, identities for nonhumans. The substrate is fine. The assumptions above it are what break.
Completion is not delivery
Venkat Gattupalli from OpenAI told a detective story about a single lost packet. One inference request would stall in clean 20 second steps. Nodes healthy, GPUs healthy, cluster healthy, application unbothered. But modern inference is coordinated work across many ranks, and TCP is an ordered stream, so one unacknowledged byte quietly froze the whole choreography while every other GPU sat busy and blameless. The forensics traced the packet down through the guest stack to the virtual driver, where the transmit ring advanced, the completion fired, and the driver declared victory. The packet never arrived. The team’s conclusion deserves to be printed on a poster: completion is not a delivery. The system that reports success and the system that verifies arrival are different systems, and the boundary between them sat exactly where their visibility ended, at the hypervisor line only the cloud provider could see across.
I heard that story as a parable, because it is the agent problem in miniature. Every layer of the emerging stack now contains a gap between claimed completion and verified outcome. The agent says the task is done. The trace says the steps ran. The commit says the code changed. None of that proves the work is right, and as machine work becomes abundant, the cost of establishing that an action is acceptable is becoming its own budget, separate from the cost of producing the action. The most interesting infrastructure I see is being built inside that gap.
You cannot helm-install a reorg
The third moment happened away from the stage, in a long conversation with a founder who sells reliability engineering to post product market fit companies. His observation: engagements start as technology problems and become organizational ones within a quarter. Dev and QA still throw work over walls. Nobody holds end-to-end context because the people who had it churned. His fix is patient and human, one team, visible improvement, let trust spread, and he calls the philosophy good enough engineering, which I found more honest than most reliability marketing.
I told him what I have been seeing from the investing side, and it is the same structure one level up. AI is making individuals dramatically more productive and organizations initially more fragmented, because the reasoning and execution that produce the work now happen in private sessions, and the shared systems only receive the artifacts. The coordination layer, human and technical, is where the cost is moving. No tool fixes that by itself. The tools that matter will be the ones that turn independently produced machine work back into durable shared state without asking humans to reconcile it by hand.
A name we reached for
Walking the hall with the Plural team, I kept looking for a word for what all of this is, and we landed on a working one: cognitive infrastructure. I hold it loosely. Others have used the phrase before for other things, and the name matters much less than what it points at.
Compute infrastructure runs the work. This other layer holds what the work means. Concretely, it carries the context a machine worker needs before it acts, the state it accumulates while acting, the permissions it acts under, and the evidence that lets its output be accepted afterward. Call it cognitive infrastructure or call it nothing yet. The four things are what I am watching: context, state, permission, evidence.
Kubernetes and its ecosystem answered the first question of the cloud era: can this workload run anywhere? The question this community was circling all day at KCD is the next one: can this worker’s context, memory, authority and proof survive anywhere, across sessions, across clusters, across the boundary where one system’s completion meets another system’s delivery?
Conformance made compute portable. Something will have to do the same for machine work’s state and trust, and nobody has built it yet. The founders I met this month disagree about where that layer even lives, which tells me the boundaries have not been discovered. That is usually the most interesting moment a stack ever has, and the whole opportunity sits in one gap: between the system that reports completion and the system that verifies delivery.
If you are building here, or debugging some weird infrastructure problem that does not have a category yet, I want to hear about it. That is not politeness. Finding the people who see these structures before the structures have names is the entire job. Email me oana@motiveforce.ai
Cheers to Aaron and Plural for making it possible for me to attend the conference at the Computer History Museum yesterday!
