Applications built by AI agents are creating an economic crisis around database persistence that traditional infrastructure wasn't designed to handle, according to a new analysis published by The New Stack. The report examines how Moonshot AI's Kimi platform enables non-technical users to describe applications in plain language, after which agents construct the frontend, backend, and database and deploy them within minutes — then maintain them over time. The central challenge isn't technical performance but rather the cost of keeping state alive when tens of millions of agent-created applications sit idle most of the time, the report finds.
The economics break down when tenant counts climb into the tens of thousands and beyond, according to the analysis. Traditional per-tenant database instances couple the logical experience of an isolated database to the physical reality of dedicated, always-on compute resources. In human-driven products, what teams provision and what users actually use track each other closely. In agent-driven products, those two numbers diverge wildly, because agents create infrastructure far faster and more casually than humans ever did, and most of what they create goes idle immediately. Kimi's earlier architecture used single-instance PostgreSQL and worked well until the tenant count reached the tens of thousands, at which point the cost structure inverted. The platform now provisions a database in approximately one second, using a warm pool of pre-initialized resources that are claimed and replenished behind each request.
"In a human-driven product, what you provision and what people use track each other," the report states. "In an agent-driven product, they diverge wildly." The analysis identifies what it calls "the idle cost trap" — teams walk into it without recognizing it, and by the time the economic pain becomes evident, the architecture that created it is already load-bearing. The report notes that agents maintaining applications face a second persistence problem: their own working environments. When an agent returns days or weeks later to maintain code, it needs source code, Git history, checkpoints, and records of incomplete tasks. If that context is lost, the agent doesn't resume work but instead reconstructs it, wasting compute, tokens, and user time.
The solution lies in separating durable state from ephemeral compute across both surfaces, the report argues. State belongs on shared, inexpensive, effectively infinite storage, while compute should be summoned when work arrives and released when it stops. Kimi saw code generation success rates improve after standardizing on a unified data layer, because fewer infrastructure decisions meant fewer opportunities for errors to enter agent output. The report concludes that agent-scale products require four properties simultaneously: tenant isolation so millions of agent-created databases never bleed into one another, instant provisioning in roughly one second, cost elasticity so idle tenants and workspaces cost almost nothing, and persistent state independent of compute. Each has been solved before in isolation, but the demand for all four at once, at a scale where any one failing breaks the product, represents the real infrastructure competition of the agent era. Teams that design for all four from the start can scale past the point where the per-tenant-instance model collapses; those that don't hit that ceiling at tens of thousands of tenants, sooner than expected, because agents fill a tenant table faster than any human-driven product ever has. The longer the industry waits to reconcile elastic pricing models with multi-tier state requirements, the harder it becomes to retrofit cost discipline into platforms already carrying legacy architecture debt. Products shipping agent-driven provisioning today are essentially running cost experiments at scale, and the ones that haven't pre-built escape hatches will discover their margins evaporate faster than their user counts grow.