What happens to your on-call rotation when the thing you’re supporting never stops running?
That’s the question I keep circling back to after reading Gizmodo’s report that OpenAI is pressing ahead with a new always-on agent. Not a chat session you open and close. Not a request-response cycle with a clean start and a clean finish. Something that stays up, stays resident, and presumably keeps doing things whether or not a human is watching.
From where I sit, that’s not a product announcement. That’s an infrastructure announcement wearing a product costume.
Always-On Is a Different Engineering Problem
Request-response systems are forgiving in ways people forget. A request comes in, you do work, you return a result, you release everything you were holding. If something goes sideways, the blast radius is one request. Retry it. Move on. The failure is bounded by design.
Persistent agents throw that out. Once a process is expected to run indefinitely, you inherit a whole category of problems that backend engineers know intimately and dread accordingly:
- State that has to survive. Something has to remember what the agent was doing across restarts, deploys, and crashes. That something is a database, and it will become your bottleneck.
- Memory that grows. Long-lived processes accumulate. Context, caches, references that never get collected. The leak you’d never notice in a 200ms request becomes an OOM kill at hour forty.
- Failure that compounds. A bad decision at step three doesn’t get retried away when steps four through nine already built on top of it.
- Cost that never dips. Idle request handlers cost close to nothing. Idle agents that maintain state and keep polling cost money continuously.
None of this is new. We’ve been running long-lived workers, daemons, and stream processors for decades. What’s new is doing it with a component whose behavior is probabilistic and whose compute footprint is enormous.
The Other Headlines Are the Interesting Part
Read the always-on agent story next to the rest of what’s coming out of OpenAI and a pattern shows up.
Gizmodo also reported that OpenAI’s head of data centers has apparently quit. I don’t know why, and I’m not going to speculate about someone’s career. But I’ll say this as an infrastructure person: data center leadership is the role that owns the physical reality behind every ambitious compute claim. Turnover there, at the same moment you’re committing to workloads that by definition never scale down to zero, is the kind of timing that makes operators raise an eyebrow.
Then there’s Sam Altman conceding it’s going to take a long time before AI goes mainstream. I actually find that refreshing, and it fits the engineering picture. Always-on agents are hard. The gap between a demo that works and a fleet of persistent processes that stays healthy across millions of users is measured in years of unglamorous operational work.
And the money side: OpenAI’s CFO reportedly downplaying an IPO to staff, framing things as “another fundraise.” Persistent compute is a recurring cost, not a one-time capital expense. Every always-on agent is a meter running.
The Security Angle Nobody Wants to Own
Gizmodo ran a piece admitting that most AI hacking reports get laughed off, but that a recent one sounded genuinely serious. I have the same reflex. Most of these stories are a researcher coaxing a model into saying something rude and calling it an exploit.
Persistent agents change the calculus, though. An always-on process is a long-lived attack surface. Sessions that end are self-limiting. Sessions that never end mean an attacker who gets something bad into the agent’s state gets to keep it there. Whatever credentials that agent holds, it holds them the whole time. Whatever it’s allowed to reach, it can reach indefinitely.
If you’re going to run these in production, the boring controls matter more than the model’s capabilities. Scoped credentials with short lifetimes. Hard limits on what the agent can touch. Audit logs on every action taken without a human in the loop. Circuit breakers that kill a runaway loop before it burns your budget or your data.
What I’d Actually Watch For
I’m not skeptical of always-on agents as an idea. Plenty of real work looks like a long-running process rather than a conversation. Monitoring, reconciliation, queue draining, anything where the job is to keep watching.
What I want to see are the operational primitives. How do you deploy a new version without losing in-flight work? What does graceful shutdown look like? How is state checkpointed, and how expensive is recovery? What’s the cost model when the thing is idle but alive?
Those answers tell you whether always-on is an engineering commitment or a marketing posture. Persistence is easy to announce and expensive to keep. Ask anyone who’s ever owned a daemon.
🕒 Published: