Who Pays While the Agent Waits

Google's technical account of Agent Compute Engine, its new service for hosting AI agents, contains a sentence I'd like stapled to every agent pitch deck:

Google says only a small share of open agent sessions are doing anything at any given moment. It gives no sample size or percentages, but anyone who has watched an agent's log crawl by at 2 AM already believed it.

So Google engineered around the wait. Each agent runs in a sandbox, a walled-off virtual machine in Google's cloud. When the sandbox goes quiet, Google snapshots and suspends it, and the files and memory survive across turns, even across days. The pitch is blunt: "you don't pay for idle VMs."

From where Google sits, that's the right call. A cloud vendor sees compute, meters it and bills for it, so compute is the waste it knows how to attack. Agent Compute Engine pricing isn't published yet, and for ordinary suspended Compute Engine VMs, Google's terms still charge for saved memory, disks and reserved addresses, so "idle" doesn't automatically mean free. Whatever the final number, it will be the one cost of the pause that somebody is actually metering.

The pause also lands on people. Oracle's October 26 announcement about Fusion, its suite of finance, HR and supply-chain software, marks the spots where it stops an agent for a human. A payroll anomaly check ends with follow-up actions "for review and approval." Proposals for allocating scarce materials go to "teams to review, refine, and approve." An agent that moves system configuration runs only "approved migration steps."

Those are the places I'd want a human too. The announcement doesn't say who that human is or how fast they move. Oracle's docs say each customer configures approvals per application, and pending items show up flagged "Needs Action", which is to say they queue. The public material gives that queue no service-level target, and nobody is on the hook for how long things sit in it. Business queues are slow, too: APQC's benchmark of 1,181 companies puts the median time from purchase request to issued order at two calendar days, work and waiting combined.

Then the plan itself pays for that time. A suspended VM wakes up exactly as it went to sleep, which is lovely for the VM and a problem for the plan inside it. Say a plan for allocating scarce materials counts on Monday's stock and gets approved Wednesday. It comes back intact and possibly wrong, because somebody else bought those materials on Tuesday. Oracle's docs say Fusion Claw adjusts plans as conditions change, but neither that documentation nor the announcement says whether a plan sitting in an approval queue expires, or gets rechecked against current stock before it runs. If Oracle handles this, it isn't written down anywhere a buyer would look.

The problem predates agents. The City of Ottawa's auditor general found that slow invoice approvals caused "delays in payment and missed discounts," meaning the discounts suppliers offer for paying early. The city's system for flagging urgent invoices couldn't tell which ones had a discount about to lapse, so every invoice waited in the same line, some of them carrying deadlines nobody could see.

So while the agent sleeps, the vendor's clock stops by design, the queue's clock runs with nobody watching, and the opportunity absorbs whatever that time costs. Nearly all the engineering so far has gone into stopping the first clock.

Two things would change my reading: vendors publishing rules for when a pending plan expires or gets revalidated before it executes, or approval queues that sort by deadline instead of arrival order. Either would suggest someone has started instrumenting the expensive part of the wait.