

Google AX (Agent Executor) explained: alternatives in 2026
Google AX, also called Agent Executor, is Google's open-source agentic orchestrator for tasks that run in isolated sandboxes on Agent Substrate. If your coding agents need to run generated code, repository tests, scripts, or APIs, compare code execution options by workload, isolation, startup, concurrent capacity, and retained state.
- Northflank is a strong fit for isolated AI-agent code execution: run coding agents, AI-generated code, repository tests, scripts, and APIs in sandboxes. Northflank sandboxes boot in under a second and support thousands of concurrent sessions.
- E2B fits applications that need persistent sandbox sessions for iterative code execution and analysis.
- Modal Sandboxes fit configurable command workloads, including GPU-backed work with explicit runtime and interruption considerations.
- Amazon Bedrock AgentCore Runtime fits teams that want managed agent hosting on AWS.
- Temporal fits teams that need durable workflow coordination and can run workers plus a separate sandbox for generated code.
Google AX coordinates agent tasks on sandbox infrastructure that your team runs. If you want a managed option for AI-agent code execution, Northflank provides isolated sandboxes for generated code, tests, scripts, and APIs, plus Cloud Harnesses for running coding agents in remote workspaces. Try Northflank with your workload or talk through your requirements.
If you're comparing alternatives to Google AX, start with what you need to run. This guide briefly explains Google AX, then compares sandbox providers and related execution options for AI-agent code execution, including coding agents, AI-generated code, tests, scripts, and APIs. It covers isolation, startup, concurrency, and state, followed by workload fit and deployment choices.
Google AX, or Agent Executor, is Google's open-source agentic orchestrator for tasks that run in isolated sandboxes on Agent Substrate. The AX project is not a hosted sandbox API: teams deploy AX with Agent Substrate on Kubernetes and operate that execution stack themselves.
AX is in active development, and breaking changes may arrive before a stable release. Running it means maintaining AX, Agent Substrate, and the Kubernetes cluster they use.
AX describes an agent task with three resources:
- Task: selects the image, command, compute resources, and workspaces for an execution.
- Workspace: prepares repositories and supporting tools, including MCP servers, skill registries, and skills.
- Model: configures model-provider settings and credential references.
As an example, this manifest defines a workspace for a Node.js API repository and a task whose workspace goal is to prepare its dependencies. Replace the repository URL and branch with your own.
# task.yaml
apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
name: api-workspace
spec:
git:
- repo: https://github.com/your-org/your-api.git
branch: "main"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
name: api-task
spec:
workspaces:
- name: api-workspace
goal: "Install Node.js and the dependencies needed to work on this API."
debug: true # Enables access through ax ssh
This example assumes AX and Agent Substrate are deployed, with model credentials configured for goal-based setup. It prepares the workspace; it does not start the API or run tests.
When a task resumes, its durable workspace is restored into a fresh container; the previous process tree is not restored. The runner must preserve required files and avoid cloning or initializing over that state. This differs from a sandbox pause that preserves process memory.
Compare what each option runs, how it isolates execution, and what happens to state when work pauses or resumes.
| Platform | Execution role and isolation | State and continuity | Workload fit |
|---|---|---|---|
| Google AX | Agent-task orchestration on Agent Substrate sandboxes | Durable workspace returns in a fresh container | Teams operating Kubernetes, Substrate, AX, and the runner |
| Northflank | Isolated AI-agent code execution; CPU microVM/GPU gVisor sandbox isolation options | Attached-volume files survive pause; processes stop and ephemeral files are discarded | Coding agents, AI-generated code execution, repository tests, scripts, and APIs |
| E2B | Firecracker sandbox execution and code interpretation | Normal pause retains memory and files; filesystem-only pause reboots | Iterative code execution and analysis |
| Modal Sandboxes | Configurable gVisor or VM command execution, including GPUs | Filesystem and memory snapshots differ; memory snapshots are alpha | Custom compute and command workloads |
| Amazon Bedrock AgentCore Runtime | Managed agent hosting on AWS, with microVM or Instances compute | Session state and persistent volumes depend on compute mode | Agent applications and tools on AWS |
| Temporal | Durable workflow coordination, not a sandbox | Workflow history supports recovery across worker failures | Multi-step workflows paired with a separate execution environment |
Temporal is not a sandbox provider: its workers execute activities on infrastructure your team supplies. Pair it with an isolated environment for generated code.
Northflank, E2B, and Modal provide sandboxed code execution for AI-generated or other untrusted code. Amazon Bedrock AgentCore Runtime hosts agent applications, while Temporal coordinates durable workflows and needs a separate execution environment for generated code. Northflank also offers Cloud Harnesses for teams that want to run a coding agent in a persistent remote workspace.
Northflank provides isolated sandboxes for AI-agent code execution. Run coding-agent tasks, AI-generated or other untrusted code, repository tests, scripts, and APIs in environments configured for the workload.
Core capabilities
- Secure AI-generated code execution: Northflank's sandbox API and SDKs give applications isolated, image-based environments to run commands, exchange files, and collect results for coding-agent tasks, AI-generated code, tests, scripts, and APIs.
- Startup and concurrency: Northflank Sandboxes boot in under a second and support thousands of concurrent sessions, giving AI-agent applications capacity to run many isolated code tasks in parallel.
- Isolation and GPUs: Northflank Cloud isolates CPU sandboxes with microVMs and GPU sandboxes with gVisor, providing an execution boundary for agent-generated or other untrusted code. Isolation is automatic on managed cloud; GPU availability depends on the project region.
- Files and pause: Agents can save checkpoints and artifacts to attached volumes for use after a pause. Pausing stops processes and terminal sessions, and discards ephemeral data, so commands must be restarted when the sandbox resumes.
- Coding-agent workspaces: Northflank Cloud Harnesses are persistent remote workspaces where coding agents such as Claude or Codex can work with a connected repository. The harness runs the coding agent; the sandbox API lets an application run code-execution tasks in separate environments.
- Where agent code runs: Use Northflank Cloud or self-serve bring your own cloud (BYOC). With BYOC, Northflank acts as the control plane, provisioning and managing Kubernetes for coding-agent sandboxes in your AWS, GCP, Azure, Oracle Cloud, CoreWeave, Civo, or Nebius account and network environment. With BYOK, your team connects and manages an eligible cluster. For either own-cloud setup, select a supported sandbox runtime; microVMs require compatible hardware.
Northflank is a strong fit for AI-agent code execution when you need isolated environments for coding agents, AI-generated code, tests, scripts, or APIs. Use Cloud Harness for a remote coding-agent workspace, or the sandbox API when your application creates and controls execution environments. Try Northflank with your workload, or talk through your requirements.
E2B provides Firecracker-isolated sandboxes that agents can control through Python and JavaScript/TypeScript SDKs. It fits applications that run code, inspect results, and return to the same analysis environment.
Core capabilities
- Code execution: Python and JavaScript/TypeScript SDKs and templates support agent code execution and analysis.
- State: Normal pause preserves filesystem and memory; filesystem-only pause keeps files but reboots the sandbox on resume.
- Plans and deployment: E2B Cloud has plan-specific usage and concurrency limits. Provider-operated BYOC is an Enterprise option. E2B Embed is an open-source runtime and dashboard that your team operates on one machine.
Modal Sandboxes provide configurable command environments for applications that need selected images, resources, and GPU compute.
Core capabilities
- Command execution: SDKs configure images and resources, then run commands and return results.
- Isolation and GPUs: Choose gVisor or VM runtimes. GPU sandboxes use gVisor; VM runtime supplies a separate Linux kernel.
- State and interruption: Filesystem snapshots retain the root filesystem but exclude mounted volumes. Memory snapshots are alpha, have workload restrictions, and do not support GPUs. GPU sandboxes can be preempted, so save progress that can be rebuilt.
- Billing: Sandbox compute is billed by the second using the higher of requested or actual usage. Include storage and retries in task estimates.
Amazon Bedrock AgentCore Runtime hosts agent applications and tools on AWS. It fits teams that want managed agent hosting with a choice of framework and model.
Core capabilities
- Agent hosting: Serverless sessions use microVMs; Instances use AWS-managed EC2 in your AWS account.
- Longer sessions and GPUs: Instances support persistent volumes and supported GPU types. AWS replaces the instance when a stopped session resumes, reattaching its volumes; process memory is not restored.
- Your application: You provide agent code and configure AWS permissions and networking. The two compute modes have different lifecycle and billing characteristics.
Temporal coordinates workflows that must continue through failures, retries, or waits for human input. It complements a sandbox provider rather than supplying the sandbox itself.
Core capabilities
- Workflow coordination: Workflows track progress while workers run activities, such as requesting approval or starting tests in a sandbox.
- Deployment: Use Temporal Cloud or operate the Temporal service yourself. Your application supplies worker infrastructure and an isolated execution environment for generated code.
- Retries: Activities may run again after failures. Make side-effecting actions safe to retry by checking whether the action already succeeded.
Choose the alternative based on which part of your AX workflow you need. For isolated AI-generated code execution, tests, scripts, or APIs, start with sandbox providers; Northflank is a strong fit for coding-agent workloads, custom environments, fast sandbox startup, and GPU execution where available. For managed agent hosting on AWS, consider AgentCore Runtime. For durable workflow coordination, consider Temporal and pair it with a separate sandbox for generated code.
Test each candidate with one representative workload before planning a migration:
- Prepare the real repository, image, dependencies, and tools, then measure the path to useful execution.
- Interrupt a task and inspect filesystem state, process state, and the agent's own progress separately.
- Test outbound access boundaries against both required and denied services.
- Simulate a lost response after an external action succeeds and check whether retrying creates a duplicate.
- Estimate total cost, including compute, retained storage, model calls, retries, and the work of operating the integration.
Compare environment capacity separately from creation rate. The persistent versus ephemeral sandbox guide explains retained-state choices. For isolated execution, test command and lifecycle behavior with Northflank's sandbox quickstart.
These answers distinguish AX itself from products that handle only one part of an agent system.
Yes. Google AX is open-source declarative orchestration for agent workloads on Agent Substrate. It is under active development, with breaking changes possible before a stable release.
Task describes execution, Workspace prepares resources such as repositories and skills, and Model configures provider parameters and credential references. AX runs on Agent Substrate with Kubernetes prerequisites. Runner resume restarts its container, so the runner must handle required state.
A sandbox can provide code execution if your application already handles coordination, workspace preparation, and recovery. Map AX responsibilities before migrating; a command API alone does not reproduce its orchestration layer.
E2B Embed is an open-source runtime and dashboard for a single machine your team operates. Temporal can be self-hosted for workflow coordination. These serve different roles and should not be treated as feature-for-feature AX replacements.
Yes. With Northflank's self-serve bring your own cloud (BYOC), Northflank acts as the control plane and provisions and manages Kubernetes for coding-agent sandboxes in supported cloud accounts, including AWS, GCP, Azure, Oracle Cloud, CoreWeave, Civo, and Nebius. E2B's provider-operated BYOC is an Enterprise-only offering. Amazon Bedrock AgentCore Runtime Instances use AWS-managed EC2 in your AWS account. Compare who operates the cluster, sandbox runtime, and agent application for each option.
No. Filesystem retention, process-memory restoration, and workflow progression are separate. Your application must determine whether external actions completed before interruption to avoid unsafe duplicates.



