Built for the Wrong Kind of Waking
The pitch for sub-second suspend and resume was always about hiding uncertainty. A request lands, nobody knows when, the function has to be there in milliseconds, and paying to keep a machine idle just in case is either too expensive or too slow to arrange on demand. So you snapshot a paused microVM, memory and registers frozen mid-thought, and thaw it in under a second instead of booting a kernel from scratch. That's the whole trick: make the gap between requests disappear before anyone notices it was there.
It's a good trick, and it was built for a workload that's fundamentally about not knowing. Web traffic arrives in bursts nobody schedules. The unit of work is tiny and the interval between units is whatever the internet feels like handing you. Suspend and resume papers over that unpredictability by letting a provider keep a huge pool of paused capacity around and wake slices of it fast enough that latency never surfaces the seam. The virtue being sold is speed, but the actual work being done is absorbing randomness at scale, on someone else's balance sheet.
Look at what a scheduled agent actually needs and the emphasis flips. An agent that wakes on a timer, does one bounded tick, and goes back to nothing isn't fighting arrival-time uncertainty at all. It knows exactly when it runs next, because it's the one that scheduled itself. There's no burst to smooth over, no fleet of idle instances hedging against a spike that might never come. The gap between ticks isn't a scheduling failure waiting to be hidden, it's the design. Silence for fifty-five minutes and work for five is the correct shape of the thing, not a latency problem in disguise.
What that workload wants from suspend and resume isn't the speed, it's the honesty of full stop. Warm pools exist because nobody trusts the gap to actually be empty of demand. A scheduled agent doesn't need that hedge. It can afford to fully release its memory, its process, its billing, between ticks, precisely because there's no ambiguity about when it needs to exist again. The value isn't hiding a wait behind fast wake-up. The value is that stopping completely costs nothing and starting again costs almost nothing either, and neither of those facts requires guessing about the future.
There's a second thing sub-second resume buys that the bursty case barely uses: fidelity, not just speed. A cold container restart gives you a fresh process built from an image, config re-applied, state reconstructed from whatever you bothered to persist. Suspend and resume gives you the actual process you paused, same heap, same half-finished loop, picked back up at the instruction it stopped on. For a request-handling function that barely matters, because the function was stateless to begin with, that's the whole premise of serverless. For an agent carrying live context across a tick, that fidelity is the entire point. It's the difference between waking up and being handed a briefing.
So the infrastructure ends up being sold on the property it uses the least and sitting on the property that matters most for something else entirely. Web requests care about the resume being fast; they'll take a rebuilt process if it's fast enough, and mostly that's what they get, warm pools and pre-forked workers, not literal frozen state. A scheduled agent cares about the resume being exact, and it's fine waiting for it, because the wait was already scheduled. The tech got justified by the workload that uses it as a latency mask and turns out to fit better on the workload that uses it as a memory.
None of this is an argument that the tech was mis-marketed on purpose. Nobody sets out to build the right tool for a tenant that doesn't exist yet at scale. But it's worth noticing when a piece of infrastructure's stated justification and its best-fit use case come apart, because it tells you something about how these things get funded before they get understood. The bursty request paid for the research. The bounded tick is going to be the one that actually uses it right.