Google made GKE Agent Sandbox generally available in May 2026 and, in the same post, introduced a second project called Agent Substrate. These two announcements concede a point that Kubernetes veterans have been reluctant to call out.

That indirect admission is that the platform that won the container decade is not the right control plane for AI agents. Agent Sandbox provides agents with a secure environment to run untrusted code. Agent Substrate adds a scheduling layer that routes around the Kubernetes control plane because the API server was never designed for how agents behave.

Compare agents to processes in an operating system rather than services in a data center, and the mismatch is obvious. A modern OS runs thousands of processes that spend most of their life asleep. It wakes each one on an event, hands it a slice of a CPU, then pages its idle memory out to disk to make room for the next. Agents behave almost exactly like those processes. Kubernetes was originally created to manage a fixed set of long-running, replicated services. This fundamental design explains why much of the agent infrastructure now runs on Kubernetes rather than being integrated into it as one of the workloads, such as a Deployment or a StatefulSet.

What an agent actually is as a workload

An agent is a long-running, stateful session that stays idle for most of its life, wakes to execute a burst of code, then goes quiet again. The code it runs is generated by a model at runtime. The host has to treat it as untrusted by default. Each session needs a stable identity, the ability to pause and resume without losing memory, and hard isolation from its neighbors.

Think of the agent as a process in a time-sharing OS. Just as the scheduler suspends a sleeping process and restores it the moment a keystroke arrives, an agent runtime must hibernate an idle session and restore it with its working memory intact. The wake path is where the user is waiting, so every millisecond on it is felt.

Consider a coding agent that a developer leaves open across an afternoon. It runs for ten seconds when a prompt lands, then waits twenty minutes for the next one. Multiply that by every developer on a team, and you have thousands of sessions that are alive on paper and asleep in practice.

The hyperscalers have already moved in this direction. The session-aware, isolated runtime for agents has now become the fourth compute offering in addition to virtual machines, containers, and serverless.

Sessions that sleep for hours

Agent sessions are bursty in a way web services never are. Holding a full Pod for each idle session wastes the memory and CPU that the Pod reserves, which is why the emerging runtimes snapshot idle sessions out of compute entirely.

Code the platform did not write

Because a model writes the code an agent executes, the runtime cannot assume the workload is well-behaved. It must be able to run a process capable of performing any action, which moves isolation responsibilities from the container boundary to the kernel boundary.

State that has to survive a nap

An agent that loses its context each time it suspends becomes unusable. So, the runtime must save its volatile RAM and filesystem state during hibernation and restore them upon resuming.

Why the Kubernetes control plane sits in the wrong place

Kubernetes schedules work through a central API server and a scheduler designed for a modest number of long-lived Pods. That design assumes placement decisions are rare and durable. Agents violate the assumption by generating a constant stream of fine-grained scheduling events, making the control plane the bottleneck rather than the referee.

The scheduling policies are the first to be strained. Researchers studying agent scheduling have documented that the round-robin and random placement strategies common in Kubernetes clusters work well when requests are short and arrival rates are high, because a bad decision is amortized quickly. Agent requests run longer and arrive less often, so a poor routing choice lingers, amplifying tail latency for the user stuck behind it.

The second pressure point is the API server itself. Storing every agent, active or idle, as a Kubernetes object would mean millions of resources in a system never sized for that many. Agent Substrate’s own architecture notes are blunt about this, acknowledging that there is no clever way to make the standard control plane hold that many objects, so the runtime keeps most agents out of it. Routing takes a similar detour, with a dedicated networking layer that sends each request straight to the correct session and wakes it if it is asleep.

Kubernetes is a fine data center scheduler, and it stays useful for provisioning the machines underneath. It is the wrong scheduler for a workload that looks like a swarm of sleeping processes.

Agent Sandbox, a secure box for untrusted code

Agent Sandbox is the layer that answers the isolation problem. It is an open-source execution environment built on Kubernetes that gives each agent a hardened place to run model-generated code, and Google moved it to general availability after roughly 16x growth in GKE sandboxes in under five months.

The mental model is a jail rather than a container. A normal container shares the host kernel and trusts the workload to stay in its lane, whereas a sandbox assumes the workload is hostile and puts a real boundary around it. Agent Sandbox reaches that boundary through gVisor by default, adds a default-deny network policy, and exposes a pluggable interface so teams can swap in Kata Containers for full kernel isolation.

Customers such as LangChain and Lovable are already running millions of agents on it, which is what forced the performance work. The result is a runtime that treats security and speed as the same problem rather than opposing ones.

Warm pools for the cold-start problem

Spinning up a fresh sandbox per request would add seconds of latency, so Agent Sandbox keeps a warm pool of pre-provisioned replicas. Google reports the API can allocate 300 sandboxes per second per cluster, with 90 percent of allocations finishing in 200 milliseconds.

Pod snapshots for idle sessions

Idle agents are suspended via Pod snapshots and resumed on demand in seconds, freeing the underlying compute rather than paying to keep a sleeping session resident.

Kernel isolation as the default

The isolation is not an add-on for the paranoid. gVisor and network lockdown ship as the baseline, on the assumption that any agent might run something it should not.

Agent Substrate, a runtime for millions of mostly-idle agents

If Agent Sandbox is the secure box, Agent Substrate is the runtime that decides which agent runs where. It reuses the secure runtime and snapshotting from Agent Sandbox and pairs them with a small, focused control plane that sits alongside a Kubernetes cluster, taking the standard control plane off the critical path.

The trick is virtual memory overcommit applied to compute. An OS lets programs address far more memory than the machine physically holds by paging cold pages to disk. Agent Substrate does the same with sessions, multiplexing a large registry of stateful actors onto a much smaller pool of pre-warmed worker Pods and snapshotting the idle ones out to storage. The project reports 30x or more oversubscription with sub-second activation, because the worker Pods are already running when an event arrives and never wait on the Kubernetes scheduler.

The developer-facing shape consists of two custom resources, a WorkerPool that defines the ready compute, and an ActorTemplate that defines the agents. Substrate is framework-agnostic, running ADK, LangChain, Claude Code, or any OCI container as an actor, which is what lets it host full agent harnesses rather than single agents.

A control plane beside Kubernetes, not inside it

Substrate does not replace Kubernetes. It uses Pods and autoscaling for provisioning and layers its own scheduler on top for the agent-specific decisions Kubernetes handles poorly.

The path to production through kagent

Solo.io has already wired Substrate into kagent, its Kubernetes-native agent platform, exposing Agent Substrate as a selectable runtime so an OpenClaw-style harness can be scheduled as an actor onto a worker pool from a single UI.

Choosing where your agents run

The two projects are not competitors, and neither replaces the cluster underneath. The decision is about which layer owns which job, and most real deployments will use all three together.

Requirement	Recommended layer	Rationale
Running untrusted model-generated code safely	Agent Sandbox	Kernel isolation via gVisor, though it adds overhead
Millions of idle sessions on limited hardware	Agent Substrate	Actor multiplexing trades some cold-path latency for density
Provisioning machines and long-lived services	Kubernetes	Proven at scale, but not tuned for bursty agents
A production agent platform with a UI	kagent on Substrate	Packages the runtime, still early and evolving

In practice, most teams will not pick just one of these. A team running coding agents at scale is likely to sandbox the code, schedule it through Substrate, and let Kubernetes provision the nodes beneath both.

What this means to the Cloud Native ecosystem

Anyone who has managed a busy cluster will easily recognize this pattern. The agent is a process, the worker pool is a set of CPU cores, snapshotting an idle session is paging memory to disk, and oversubscription is the same bet virtual memory has always made. Kubernetes remains the underlying machine, and the layer that schedules agents is being rebuilt on top of it to better match how agents actually run.

The open question is who owns that layer. Agent Substrate is a first look rather than a finished product; kagent is early, and rival runtimes will arrive as the cost of idle agents becomes a line item that platform teams can no longer ignore. The next thing worth watching is whether this agent control plane consolidates around a single open project, the way container orchestration once settled on Kubernetes. The alternative is that every hyperscaler ships its own, and the fragmentation that agents were meant to escape returns one layer up.

The post Kubernetes won the container decade. Google’s Agent Substrate wants the next one. appeared first on The New Stack.

In the same quarter, a $1.7 trillion social network and a shoe company both became cloud providers. Nobody’s operating model was designed for this.

On July 1, Bloomberg reported that Meta was building a cloud business to sell its excess AI capacity, signaling that one of the largest GPU fleets on Earth is about to get a price list.

As the report outlines, the company is still weighing two business models that are part of its Meta Compute initiative: it could offer hosted access to AI models running on Meta infrastructure (similar to AWS Bedrock), or directly rent raw compute capacity, à la the CoreWeave model.

Two weeks before that report, Allbirds had finished becoming Smartbird. The erstwhile sneaker company — which hit its peak in 2022 in selling 3 million pairs — sold its footwear brand for $39 million, lined up a convertible note facility that it later expanded to $100 million, hired an ex-AWS executive as CEO, and set out to sell GPU-as-a-Service. 

When it first announced the pivot in April, the stock spiked nearly 600% in a day, adding more than $100 million in market value at its peak — all before the company had racked a single GPU.

One of these is a serious supplier, and the other is a public shell chasing an AI multiple, but I don’t think the distinction matters much. Compute supply is fragmenting faster than any enterprise can absorb it, and overbuild always finds a buyer.

Overbuild becomes inventory

Meta isn’t selling compute because its leaders woke up wanting to fight AWS. It’s selling compute because it provisioned for its own peak, and there’s a gap between what it built and what it uses. That’s what an accidental cloud is: Infrastructure that was never meant to be a product, monetized because the alternative is depreciation.

That’s what an accidental cloud is: Infrastructure that was never meant to be a product, monetized because the alternative is depreciation.

Meta won’t be the last. Everyone who bought more GPUs than they needed in the last three years is facing the same math. Some will eat the write-down. The rest will sell. Stack that on top of the neoclouds (CoreWeave, Nebius, Lambda), the sovereign clouds, and now the Smartbirds, and the list of places you can buy serious compute has gone from a handful to many in about two years. 

The market read the Meta news as bad for neoclouds. CoreWeave and Nebius both dropped double digits on the day, and I get why: Nebius has a $27 billion contract with Meta and CoreWeave a $21 billion deal. Both had Meta as a customer and later witnessed it become a competitor in the compute business. But I’d pull a different lesson from it. It’s not that one supplier wins and another loses. It’s that supplier positions are now unstable everywhere. 

If the suppliers can’t predict their position two years out, betting your operating model on any one of them is a risk you’re not pricing.

More suppliers should mean leverage. Mostly it means sprawl.

On paper, a fragmenting supply side is great for buyers: price competition, more choice, more leverage. Cheaper compute is coming, and for AI workloads, it’s coming fast.

Most teams I talk to can’t capture any of it. Every new supplier shows up with its own console, its own billing format, its own identity model, and its own hole in your governance coverage. Signing a supplier is cheap. Operating one is not. The security review, the tagging standards, the budget enforcement, the offboarding plan — all of it gets rebuilt per provider. Choice without governance isn’t leverage. It’s sprawl, and sprawl costs more than the discount that created it.

Choice without governance isn’t leverage. It’s sprawl, and sprawl costs more than the discount that created it.

This bites hardest with GPU capacity, because that’s where the fragmentation is happening and where the money is. Workloads end up pinned to whichever supplier had chips available the day the contract was signed, and they stay there. Not because moving is impossible, but because nothing above the suppliers makes moving routine, and the team that signed the contract usually isn’t the team on the hook for utilization. Those incentives don’t fix themselves.

The Smartbird end of the market makes this non-optional. Capacity from a vendor with no enterprise track record is only usable if you can exit it in a day. That’s something you design for up front, not something you negotiate into a contract.

The durable position is above the suppliers

Every argument about picking the right cloud assumes the list of clouds is stable. It isn’t, and it’s about to get less stable. The position that survives supplier churn is the layer above them: a single control plane where every provider — hyperscaler, neocloud, or accidental cloud — is just a target you provision to, under the same policies, approvals, cost visibility, and exit path.

This is the VMware argument, extended forward. Broadcom taught the industry what single-supplier dependence costs when the supplier’s incentives change. Meta just taught the follow-up lesson. The future holds more clouds, not fewer, arriving faster and from stranger directions than anyone planned for.

The enterprises that win the price war won’t be the ones that picked the right supplier. They’ll be the ones for whom the supplier stopped mattering.

The practical version of this is an abstraction layer that treats every supplier as a provisioning target rather than a separate operating model. When a new supplier appears — Meta Compute, or a neocloud that didn’t exist last quarter — it plugs into the governance the team already defined, rather than becoming a new operating model to build from scratch. The policies get written once; the supplier list underneath can churn.

Meta selling compute and a sneaker company selling GPUs are the same headline: supply is no longer scarce; it’s fragmented. The enterprises that win the price war won’t be the ones that picked the right supplier. They’ll be the ones for whom the supplier stopped mattering.

The post Meta and the rise of the accidental cloud appeared first on The New Stack.

Imagine you just finished a two-hour meeting. You were wearing a small AI work companion that promised to capture the conversation, structure it, and let you ask questions about it later. Two hours after the meeting, you open the app and ask for the transcript. You wait. The spinner turns. The whole reason you bought the device was so you’d never have to remember a meeting again, and now the one thing it promised to do well — recall what was said — is the thing that’s making you wait.

This is the failure mode that fascinates me about AI hardware products, because it’s not a model problem. The transcription was perfect. The summarization was good. The thing that frayed was the part nobody markets: getting the right bytes off disk and onto the screen at the moment the user asks. That’s a data problem. And for a product whose entire promise is memory, a data problem is a product problem. 

“For a product whose entire promise is memory, a data problem is a product problem.”

I want to walk through a real version of this because the team that hit it, Plaud, makes the most popular AI notetaker on the market, and the architecture that broke is the architecture almost every team in this category starts with. It feels reasonable at launch. It becomes a liability at scale. And the reasons why are worth understanding before you ship, not after.

First, what was built correctly

It would be easy to tell this story as “they made a mistake.” They didn’t. The original architecture was a sensible set of decisions, and I want to be precise about that before I dissect what went wrong, because the lesson is in the gap between “reasonable” and “right at scale,” not in anyone’s competence.

Plaud’s product generates two very different kinds of data per recording. There’s structured metadata: who recorded it, when, how long, what tags, what state the processing pipeline is in. And there’s the unstructured payload: the audio file and its transcript, which can run tens of megabytes per session. The team did the textbook thing. They put the structured metadata in MySQL, where relational queries and transactions are cheap, and they put the large objects in S3, where storage is cheap and effectively infinite.

If you’ve built systems, you’ve made this exact call. Object storage for blobs, a relational database for everything you need to query. It’s in every architecture diagram. It’s the default. And for a long stretch of the product’s life, it worked fine.

The problem is not that the decision was wrong. The problem is that it contained a hidden assumption: that the metadata and the content could live in separate systems because they would never need to be consistent with each other in real time. For most applications, that assumption holds. For a product whose core interaction is “give me back exactly what I recorded, right now,” it doesn’t. And the gap between those two worlds is where everything started to fail.

The transcript sidecar

In my article on RAG retrieval, I identified an anti-pattern I called the vector sidecar: the habit of standing up a separate vector database alongside your primary store, only to discover that the two systems can’t answer a single query together. The Plaud architecture is the same shape, applied to an AI hardware product. Call it the transcript sidecar.

The transcript sidecar is what you get whenever you split structured metadata from unstructured content across two systems with no shared transaction guarantee. The metadata says a recording exists, is complete, and is ready. The content lives elsewhere, reached via a separate call, with its own latency and failure modes. Nothing ties the two together. There is no transaction boundary that spans “the row that says this transcript is ready” and “the object that contains the transcript.”

This produces three distinct compounding problems.

• Retrieval latency is not a network problem; it’s a data locality problem. S3 is excellent object storage. It is not a database. When you make object storage the primary retrieval path for tens-of-megabytes payloads under concurrent load, you’re trading the consistency and latency guarantees of a database for the simplicity of a blob store. Under light load, the trade is invisible. Under heavy concurrent load, S3 retrieval latency and its variability become the user’s experience of your product.
• Consistency gaps open between two systems that fail independently. The MySQL row can indicate that a recording is ready a moment before the S3 object is durably reachable, or a replica can lag, causing the metadata a user sees and the content they fetch to disagree. With no shared transaction, the application layer inherits the job of papering over the gap, with retries, polling, and reconciliation logic that grows more elaborate every quarter.
• The schema becomes immovable at exactly the wrong time. More on this below, but the short version is that the metadata store hit a scale ceiling where changing the schema required a maintenance window. For a product still evolving its feature set, that’s a database governing the roadmap, rather than the other way around.

The unifying insight is the one I keep coming back to throughout this whole series: any time you split data across systems that can fail independently, you have handed the consistency problem to the application layer, where it is not solved so much as managed, and where it compounds over time.

When the database governs the roadmap

The most interesting failure in the Plaud story isn’t the latency. It’s the schema freeze, because it’s the one that teams least expect and feel most acutely.

With around 300 million rows, the team’s MySQL setup reached a point where schema changes such as adding a column or changing an index — the routine evolution of any growing product — could no longer be performed online without risk. DDL operations on a table that large, on that architecture, meant locking, replication strain, and the real possibility of downtime. So changes had to be batched into maintenance windows.

Sit with what that means. A maintenance window for a schema change is the time the database allows the product team to ship. The roadmap now bends around the database’s limitations. A feature that needs a new column will wait until the next window. The product’s cadence is set by the operational fragility of the data layer. Most teams don’t notice this inversion because it happens gradually, and then one day a product manager asks why a small change is a two-week project, and the answer is “the database.”

“A maintenance window for a schema change is the time the database allows the product team to ship. The roadmap now bends around the database’s limitations.”

The 300-million-row ceiling is a forcing function that teams hit later than they expect and should hit later than they do. Expect, because single-instance MySQL feels limitless right up until it doesn’t. Should, because the architecture that gets you to 300 million rows is rarely the architecture that takes you past it, and the migration is far more disruptive at 300 million rows than it would have been at 30 million. The ceiling is real; it is predictable, and most teams plan for it only after they’ve hit it.

What changing the architecture actually fixed

Plaud’s resolution was to consolidate the metadata layer into a distributed SQL database (they moved to TiDB), which removed the single-instance ceiling and restored online schema changes. I’m going to use their numbers, but not as a product pitch. I want them as evidence for a claim about where architectural debt goes in a product like this.

Before (dual-store-brain at scale)	After (consolidated metadata layer)
Throughput strained under concurrent load	~10x QPS headroom
Tail latency variable under load	P95 under 10 ms
Schema changes require maintenance windows	Online DDL, no downtime
Single-instance ceiling at hundreds of millions of rows	Horizontal scale across multiple clusters

QPS headroom and tail latency matter, but the first result I’d point to is the online DDL. Restoring the ability to change the schema without a maintenance window is what handed the roadmap back to the product team. The database stopped governing the release cadence. That’s not a performance win you can put on a benchmark chart, but it’s the one the product organization feels every week.

Also notice what the fix did not do: it did not attempt to store 30-megabyte audio files in the database. Large objects can still be stored in object storage. The point was never “put everything in one system for its own sake.” The point was that the metadata layer, the part that has to be consistent, queryable, and evolvable in real time, needed to actually behave like a database at scale, instead of becoming the fragile half of a split-brain architecture.

Where architectural debt goes

Here’s the claim the Plaud numbers are evidence for. When the database is the product, architectural debt does not accumulate in some back-office system that only the platform team feels. It accumulates in the product experience, where every user feels it.

This is the structural difference between an AI note-taker and, say, an internal analytics tool. For a product like this, every meaningful user interaction is a database operation. Recording creates rows and objects. Transcription updates state. Retrieval is a read. Editing is a write. Search is a query. There is no part of the product that isn’t, underneath, the database doing something. Architectural problems surface as product problems, one-for-one. A consistency gap becomes a transcript that is briefly missing. Slow retrieval reads as a product that is slow to remember. A frozen schema means features arrive late.

No user will ever file a bug report that says “your metadata store and your object store lack a shared transaction boundary.” Left unaddressed, this class of debt manifests as a product that feels less dependable precisely when someone depends on it. For a product whose entire value proposition is “trust me to remember,” the debt lands on the promise itself. This is why Plaud’s decision to re-architect when it did matter. The team fixed the data layer before the failure became noticeable to users.

“You can have the best transcription model in the category and still ship a product that feels unreliable, because reliability for this kind of product is a data architecture property, not a model property.”

This is why I say the database is the product. Not as a slogan. As a literal description of where the product’s quality is determined. You can have the best transcription model in the category and still ship a product that feels unreliable, because reliability for this kind of product is a data architecture property, not a model property.

The trap is waiting for the whole category

AI hardware is having a moment. Note-takers, wearables, ambient recorders, pendants, badges — each built on the premise that the device will remember so you don’t have to. The category is growing, and the products are getting better at the parts everyone talks about: the models, the form factor, the battery life.

But underneath, almost all of them start with the same architecture Plaud started with, because it’s the reasonable default. Structured metadata in a single-instance relational database. Large content in object storage. No shared transaction boundary. A schema that’s easy to change at ten million rows and frozen at three hundred million. The trap is identical, and it’s waiting at the same place on the growth curve for every team in the category.

The teams that will do well are the ones that recognize this early, understand that, for a memory product, the metadata layer is not back-office plumbing but the spine of the user experience, and plan their data architecture for the scale they’re trying to reach rather than the scale they’re at. Plaud’s migration is the pattern worth studying before you hit 300 million rows, not after. The lesson is cheaper to learn from someone else’s 300 million rows than from your own.

When your database and your product are the same thing, you don’t get to treat the database as someone else’s problem. It is the product. Build it like one.

The post “The database is the product”: What breaks when memory devices scale appeared first on The New Stack.