Agentic AI
Agent-driven applications flip database economics: persistence, not speed, becomes the constraint
As AI agents scale to millions of autonomous applications that idle most of the time, the infrastructure challenge shifts from query speed to making cheap persistence viable at enormous scale.
The New Stack
When AI agents build and maintain applications for users at scale, a fundamental problem emerges: how do you keep vast numbers of idle systems alive cheaply while agents work on them intermittently? This economic reality, invisible at smaller scales, becomes the defining constraint of agent-driven platforms.
Moonshot AI's Kimi platform exemplifies this shift. The system lets non-technical users describe an application in language, and an agent automatically builds the frontend, backend, and database, then deploys it within minutes. Unlike earlier code assistants that handed off their work, Kimi's agents persist: they return days or weeks later to maintain those applications. That continuity exposes an infrastructure problem the industry hasn't systematically solved.
From thousands to tens of millions: when cost becomes fatal#
At modest scale—a thousand tenants—the cost of maintaining idle databases is manageable overhead. But agent-driven products diverge sharply from human-driven ones. Agents create applications far faster and more casually than humans, and most sit unused most of the time. At tens of millions of idle tenants, the math inverts. The cost to keep provisioned infrastructure alive when nobody is using it stops being a minor expense and becomes fatal to margins.
The industry's familiar database questions—query speed, failover, backup—no longer move to the front. A new question takes precedence: what does it cost to keep something alive that is currently doing nothing?
In products where humans build, what gets provisioned tracks closely with what people use. In agent-driven products, these metrics diverge wildly, forcing a reimagining of how infrastructure charges spread across millions of instances.
The core principle: separate state from ephemeral compute#
Every solution rests on one architectural move: decouple durable state from temporary compute. State—the data users and agents actually need—belongs on a shared, cheap, essentially unlimited foundation like object storage. Compute gets summoned when work arrives and discarded when it stops.
This separation makes idle cost negligible. Instead of paying for compute to remain active while databases sit unused, teams pay only for the data itself, which costs nearly nothing in storage. Cost tracking shifts from "how much have we created" to "how much work is currently happening."
Kimi applies this principle in two critical places where agent-scale products feel pain.

