Google AX preview turns interrupted agents into resumable runtime work

Google Cloud announced Agent Executor on May 21, 2026. The abbreviated name is AX. Google's announcement describes it as an "open-source runtime standard" for agent execution, resumption, and distributed deployment. The first GitHub release, v0.1.0, arrived one day earlier on May 20, 2026. When the Korean article was researched on June 4, 2026, the repository showed roughly 1.5k stars and 80 forks.

This is not another model launch or chat interface. Google is pointing at the operational problems that appear when agents stop being minute-long assistants and start behaving like workers that run for hours or days. The Google Cloud post names failures, disconnected clients, human-in-the-loop checkpoints, and session-state conflicts as concrete reasons long-running agent workflows are hard to operate. AX pulls those concerns out of the model and places them in a runtime layer.

The GitHub README expands the acronym as Agent eXecutor. AX orchestrates the agentic loop, manages execution through event logging, and handles communication between local and remote actors. Its feature list includes distributed runtime, resumption, selection and execution of skills, tools, and agents, auditing and policy, portability, and a model- and harness-agnostic design. The built-in consistency section separately calls out a single-writer architecture, an event log, and advanced resumption on compatible platforms.

The announcement is easy to misread if AX is treated as a coding agent. The README explicitly says AX is not a managed service, not an agentic framework, not a specific harness such as Antigravity, and not a controller for one model. Google's chosen position is a "serving layer around harnesses." If a team already has Claude Code, Codex, Antigravity, or an internal LangGraph agent doing the actual work, AX is closer to the layer that wraps execution, reconnects clients, controls tool calls, and records what happened.

Google's five headline capabilities read more like an operations checklist than a product pitch. Durable execution uses event logs and snapshotting so actors such as agents, harnesses, skills, tools, and sandboxes can continue after failures. Secure isolation puts components into sandboxes when generated code or multi-tenant data would otherwise widen the blast radius. Session consistency uses a single-writer structure to reduce state corruption when several components touch the same session.

Connection recovery and trajectory branching are closer to the user experience and evaluation loops. The AX README's CLI example shows a client reconnecting with the last sequence number it observed, letting the server replay later events. That does not rewind the conversation. It catches the client up on missed output. A separate ax fork command is described as creating a new event log from a checkpoint so another execution path can be tested. For teams operating long-running agent runs, the cost boundary is no longer just "retry from the beginning." It is "resume after which sequence number, and branch from which checkpoint?"

ax exec \
  --conversation d85a4b4e-c53b-4c84-b879-f10d905bce40 \
  --last-seq 12 \
  --resume

Protocol support also explains AX's position. The README mentions AX native AgentService, Google ADK agents, an A2A protocol bridge, and experimental Colab agents as ways to implement remote agents. The project landing page foregrounds MCP, A2A, and other agentic protocol support. The Google Cloud announcement names LangChain/LangGraph, ADK, and A2A as supported targets. The message is less "use one Google agent app" and more "bring different harnesses and protocols onto one execution control plane."

Kubernetes is a separate part of the story. In the same announcement, Google also pointed to Agent Substrate. Its README describes a system for managing agent-like workloads on Kubernetes at higher scale and efficiency. Standard Kubernetes is built around many long-running services. Google argues that agent workloads can spend long periods waiting for external input while still generating millions of short tool-call interactions.

Agent Substrate maps actors onto ready worker pods and manages actor lifecycle operations such as create, destroy, suspend, resume, and routing. The README includes a demo description in which about 250 stateful actor sessions are multiplexed over 8 physical pods. It also names high-density stateful coding environments such as Claude Code and Codex, MCP server sandboxes, LangChain, and ADK compatibility as part of the supported range. If AX is the execution log and runtime controller, Substrate is closer to the placement layer that decides where an actor runs, sleeps, and wakes again.

The AX Kubernetes deployment documentation makes that relationship more specific. manifests/README.md describes AX being deployed as an isolated warm-standby actor on Agent Substrate. A worker creates a live snapshot at boot, a new conversation restores immediately from GCS, and the actor automatically suspends when it stops producing output. The setup path mentions GEMINI_API_KEY, BUCKET_NAME, WorkerPool, ActorTemplate, and ax-router. The document still reads like a developer preview, but it shows that Google is modeling "agent runtime" down to Kubernetes resources and snapshots.

For developers, the closest change is the evaluation checklist. Agent adoption is often reduced to model names, SWE benchmark numbers, or IDE convenience features. AX brings operations questions forward. If an execution disconnects in hour four, where does it resume? Who approved the tool call, and which event log records it? Can two workers mutate the same session state at the same time? How much cost does a retry spend again? Can a workflow that must remain inside an internal data plane be sent to a managed agent service at all?

The security angle sits one layer below the common phrase "the agent calls a tool." The README says a built-in planner can have a bash tool, but executions that start with the bash tool require a user-approval confirmation flow. The Google Cloud post connects secure isolation to multi-tenant data and generated code. That combination favors a controller and sandbox in the execution path instead of relying only on prompt instructions to constrain agent behavior.

The preview status deserves as much attention as the headline. The beginning of the GitHub README warns that AX is in active early development. It says the team is still refining core architecture, the resumption protocol, and the runtime specification, and that breaking changes may arrive before a stable release. External pull requests are temporarily paused while the core architecture stabilizes, with issues preferred for bugs and feature requests. AX should be read as Google opening a design for validation, not as a production standard already settled.

Community reaction is still early. On June 4, 2026, GeekNews surfaced an item titled "Agent Executor - Google's distributed agent runtime open source," summarizing reliability, safety, customization, efficiency, event logging, and local or remote actor communication. The research note did not find a large Hacker News discussion at the time. In Reddit's LLM developer community, AX appeared in comparisons with Cloudflare Agents, AWS Bedrock AgentCore, Claude Managed Agents, Agyn, Vercel, and other runtime or agent-platform efforts.

In those comparisons, AX fits the self-hosted distributed runtime slot. Cloudflare Agents maps more naturally onto Workers and Durable Objects. AWS Bedrock AgentCore leans toward a managed AWS runtime and IAM integration. Claude Managed Agents and OpenAI Codex-style products provide a stronger agent harness and user workflow. AX sits lower in the stack: bring the harness and model, then use the runtime to bind execution, state, audit, and recovery.

Teams can start with three practical questions. First, separate conversational assistants from long-running workers. If the workflow ends inside an IDE helper in under 10 minutes, a runtime such as AX may be unnecessary overhead. If the agent crosses repositories, tickets, browsers, databases, and MCP servers while waiting for approvals, an event log and resume protocol stop being optional engineering detail.

Second, treat data location and execution location separately. Google Cloud says AX gives teams options for on-prem infrastructure, proprietary workflows, compliance requirements, and self-managed compute. Managed agent APIs can deliver faster time-to-value. Organizations that cannot place code repositories, customer data, and internal tool calls under an external control plane will still evaluate self-hosted runtimes. AX moves that discussion into Google's open source and Kubernetes ecosystem.

Third, protocol names do not finish the standardization work. Supporting MCP and A2A does not automatically solve production agent behavior. Tool discovery, credential boundaries, approval, event replay, cost attribution, branch evaluation, and sandbox snapshots have to come with the protocol wiring. AX's direct signal to developers is that runtime semantics come after agent protocols.

One small inconsistency in the project text is worth noting. Google publicly announced AX through the Cloud Blog, while the README still contains language about announcing the project widely soon. The repository and blog are already visible, but project wording and the external PR policy still feel like early design validation. That same gap should shape adoption decisions. AX is worth reading now, but production use needs separate checks for API stability, security review, protocol compatibility, Agent Substrate dependency, and deployment experience outside Google Cloud.

AX does not mean every agent team suddenly has a default runtime. It does show that Google is not limiting the agent race to models, apps, or IDE surfaces. Once long-running agents enter real business systems, failure recovery, approval, audit, isolation, cost, and state consistency become as important as the visible chat or coding UI. The AX preview is Google's first open source move to pull those problems down into runtime and Kubernetes infrastructure.