Google released a piece of open-source software this week with a deliberately boring name: Agent Executor. There is no demo video, no flashy benchmark, no headline-friendly capability claim. It is a runtime, in the dryest sense of the word. It runs other people's AI agents and keeps them alive while they do their work. And it is one of the more revealing announcements the company has made in months, because of what it implicitly concedes about where the industry actually is.
The pitch, as Google described it in a blog post, is that long-running agent workflows, the kind that span minutes to days and involve multiple steps, system calls, pauses for human approval and recoveries from network interruptions, were not being well served by existing tooling. Agent Executor provides durable execution, secure sandboxing, session consistency for distributed workflows, connection recovery, and something it calls "trajectory branching," which lets a developer test alternative execution paths from a saved checkpoint without losing the prior context. It is, in other words, a set of infrastructure primitives that Kubernetes operators and site reliability engineers would recognise immediately.
Which is exactly the point. "Durability, orchestration, and resumability are the real blockers for any enterprise production agents," Broadcom site reliability engineer Advait Patel told Computerworld. "What kills enterprise adoption is agents that lose their state when a pod restarts, sessions that corrupt under concurrent writes, or long-running workflows that cannot recover from a network blip." Most enterprises moving past the prototype phase have, in his telling, been duct-taping these things together. Existing frameworks like LangChain and AutoGen are fine for tinkering. They fall apart, he said, once an agent has been running for hours and is taking real actions on real systems.
This is the part of AI that the press release ecosystem has been unable to dramatise. The interesting question for most companies right now is not "can an LLM write a function," because the answer has been yes for two years. The question is what happens to the agent on hour fourteen of a thirty-six-hour task when one of its three external API calls times out, the human who was supposed to approve a step has gone to bed, and the underlying container has just been rescheduled to a new node. Without something underneath catching the state and replaying it cleanly, the agent silently forgets what it was doing. Or worse, it does the destructive bit twice.
Google's strategic logic is also legible. Gaurav Dewan of Avasant noted that hyperscalers are converging on a shared playbook, give away the tools at the top of the stack, monetise the compute and the managed services underneath. Microsoft has done a version of this with AutoGen. AWS has done a version with Bedrock AgentCore. Patel drew the parallel to Kubernetes ten years ago: "Give away the runtime, drive consumption on Google Cloud via services such as the Gemini Enterprise Agent Platform and Managed Agents API." Proprietary agent frameworks, he argued, are not going to win the enterprise market. "The tools on top need to be open or nobody will trust them."
What this leaves unresolved is the governance layer. Agent Executor can keep an agent's state intact across a database failover. It cannot tell you whether the agent should have made the decision it just made, who is accountable for that decision, or how to explain it to a regulator or an angry customer. Dewan was careful to say so. Auditability and policy enforcement, he noted, "are likely to require additional governance and oversight layers beyond runtime infrastructure alone." Translation: the runtime is the easy part now, and the runtime was already very difficult.
If you are looking for the signal under the noise of the agent boom, this release is one. The fact that Google considered it worth open-sourcing a durable executor, rather than yet another agent-building SDK, is an acknowledgement that the enterprise market is running into the same wall it ran into with web services, then microservices, then containers. The clever bit is never the demo. The clever bit is what keeps it running on Tuesday morning when something has broken silently overnight.