In this piece
Google AX Agent Executor: Budgets and Self-Hosting
A sandbox can contain an agent without containing its bill. That is the most important distinction to understand before adopting Google's AX, the Agent Executor. Giving an agent a workspace and a fenced network is useful. Proving that it cannot overspend, repeat a destructive action or take its state hostage is a different engineering task.
AX is an Apache-2.0-licensed orchestration project in Google's GitHub organisation. Its current interface uses four resource types: Task, Workspace, Gateway and Model. The repository explicitly warns that major breaking changes can precede a stable release. Read the AX repository and release-status warning.
Sources reviewed on , with AX at commit d8ed0fe38bce. This is a source and architecture review, not a deployment test or throughput benchmark. The question here is narrow: what must you verify to run AX agents under your own operational control?
What do AX's four declarative primitives actually control?
AX separates the execution environment from the agent's reasoning. A task can run an agent, one delegated operation, or another executable workload. A workspace describes its starting environment; a gateway describes network access; a model resource centralises provider configuration.
| Primitive | Declared responsibility | Do not confuse it with |
|---|---|---|
| Task | Image, command, CPU and memory resources, workspace and gateway references. | A cumulative token budget or proof that the business task succeeded. |
| Workspace | Git repositories, MCP configuration, skills and optional goal-based preparation. | Automatic durable storage of every session file, secret and external side effect. |
| Gateway | Listeners and an outbound host-and-port allowlist. | Per-tool, per-tenant or per-document authorisation. |
| Model | Provider, model identifier, generation parameters and a Kubernetes secret reference. | Model weights, local inference or a universal configuration for arbitrary agent SDKs. |
These are the roles described by AX's core-concepts documentation. In particular, Model is a named configuration, not a newly released language model. AX's own components can consume it; an arbitrary program inside the task still needs a compatible integration.
Is AX an agent framework, a sandbox or a Kubernetes replacement?
AX is the orchestration layer above Agent Substrate, not a replacement for your agent's decision loop. Its API and controllers manage resources; Agent Substrate supplies the underlying execution lifecycle. Kubernetes remains part of the infrastructure.
The Kubernetes-shaped YAML can be misleading: AX's design stores resource state in Redis and distributes reconciliation work through Redis Streams, rather than storing every short-lived task as a Kubernetes custom resource. Controllers can be scaled by adding replicas. Inspect the control-plane architecture.
That is an architectural approach to high task volumes, not proof that your cluster will run billions of active agents. Capacity still depends on workload, worker resources, storage, model latency and operating limits. Treat the project's scale language as a design ambition until a representative benchmark establishes your own envelope.
Our agent harness engineering guide covers the reasoning loop, tool handling and feedback around a model. This article stays with AX's execution and ownership boundaries.
How do you restrict Google AX outbound network access?
Bind the task to a Gateway with explicit destinations, then test the resulting network boundary. The documented example contains host: "*" on port 443. That is broad HTTPS access, not a production allowlist limited to your model and Git servers. Check the current manifest examples.
The following is an illustrative Gateway, not a complete deployment. Replace the example hostname with an operator-controlled endpoint that your sandbox can resolve and reach. Provision the infrastructure separately.
apiVersion: ax.io/v1alpha1
kind: Gateway
metadata:
name: research-egress
spec:
egress:
allowlist:
hosts:
- host: llm-gateway.internal.example
port: 443Merge the following binding into the existing task's spec. A Gateway resource sitting unused in the control plane does not restrict that task.
gateway:
name: research-egress
debug: falseOur deployment recommendation is to require GatewayReady, verify denied destinations and keep debug: false unless a controlled debugging session needs it. Test redirects, direct provider access, internal metadata endpoints and alternate network paths. These are acceptance tests, not vulnerabilities we reproduced in AX.
A permitted hostname is still a large trust boundary. An allowed tool server might expose multiple tenants or perform its own outbound requests. Keep request-level authorisation on that server and verify downstream destinations. Use the existing agent sandbox security checklist for the wider containment review.
Does Google AX automatically stop runaway token spending?
Do not assume the current Task API provides a cumulative token or money cap. In the reviewed schema, field 9 of TaskSpec, previously policies for budget and approval configuration, is explicitly reserved and described as removed for now. Token counters in UsageStats and a PendingApproval status type remain, but types and counters do not prove an enforcement path. Inspect the pinned AX API schema.
CPU and memory limits constrain local compute. They do not bound how many paid model requests a low-CPU loop can send. Similarly, a provider's per-response output limit does not cap the aggregate cost of retries, parallel subtasks and repeated calls. The same schema gap means you should not assume that a business approval gate exists merely because an approval-related status field exists.
Google Cloud also distinguishes alerts-only budgets from spending controls: an alerts-only budget does not automatically stop usage or charges. Its documentation separately points to spend-cap budgets in preview for supported services. Neither fact establishes a job-level cap for every external model your agent can call. Read the Cloud Billing budget distinction.
Put the budget where the agent cannot rewrite it
Our recommended pattern is an operator-controlled model proxy with a shared budget ledger for the parent job and all descendants. Before admitting a request, reserve its bounded maximum cost atomically. Reconcile actual usage afterwards, account for retries and parallel calls, and deny new requests when the remaining allowance is insufficient. Keep the enforcement credentials and ledger outside the agent's writable environment.
Pair that with a wall-clock deadline, retry and step limits, fan-out limits and repeated-action detection. At the threshold, stop new model calls and trigger cancellation or suspension. Already-admitted requests may still incur charges, so define and test the maximum overshoot instead of promising an instantaneous zero-cost stop. Budget the workspace-preparation agent too, not only the final task command.
For the broader economics rather than AX-specific enforcement, see AI agent cost per action.
What survives AX suspend and resume?
The reviewed AX runner contract promises a restored workspace with a new process tree. It says that /workspace is the durable directory and that resuming restores it into a fresh container. Do not interpret this contract as a promise that the agent's live Python objects, sockets or unflushed memory continue unchanged. Read the runner lifecycle and replacement contract.
This statement is about AX's documented runner integration, not the maximum snapshot capabilities of every Agent Substrate backend. Keep your acceptance criterion at the layer your application actually uses.
Store the conversation or session checkpoint, completed-operation identifiers and restart instructions on the durable path. Resume through the agent's supported session mechanism. A filesystem snapshot cannot undo an email already sent or a payment already requested: external writes need idempotency keys and a durable completion record.
A ready sandbox is not a finished business task
The same runner contract says that the runner stays alive after the command exits and that the control plane does not currently read back the command's exit status. Monitor an explicit completion event or result artifact, not just Running, Ready or a responsive health endpoint. Test both a successful command and a failed one.
Can you self-host Google AX without GCP?
The available deployment paths are not exclusively GCP, but portable is not the same as plug-and-play. AX's quickstart requires Kubernetes, a container registry, Redis and a reachable Agent Substrate control API. Agent Substrate documents both a local kind development setup and a GKE path using Google Cloud resources. It also warns that it is early-stage software, not ready for production use, and not an officially supported Google product. Compare Agent Substrate's local and GKE setup instructions.
A local Substrate quickstart establishes a non-GCP development path for the underlying runtime. It does not prove that AX, your storage backend and your security configuration have passed an end-to-end on-premises deployment. Nor does a local execution plane make remote model inference local.
| Layer | What to verify | Evidence of control |
|---|---|---|
| Execution | Who administers Kubernetes, AX, Substrate and the images? | You can rebuild, deploy, isolate and stop a task without the workload's cooperation. |
| Inference | Which provider actually receives prompts during setup and execution? | Captured destinations and a tested replacement or local-model path. |
| State | Where are workspaces, sessions, snapshots and logs stored? | A successful export and restore under your retention policy. |
| Authority | Who controls secrets, spending admission and tool permissions? | Revocation and denial tests executed outside the agent's writable boundary. |
This is our operational definition of “own your AI”. A cloud deployment can preserve meaningful control; self-hosting can still depend on an external model, registry or credential service. Choose the trade-off consciously instead of using deployment location as a substitute for a threat model.
Is AX tied to Antigravity?
The concrete dependency to examine is goal-based workspace preparation. AX's default runner hands a workspace goal to an Antigravity agent, requires GEMINI_API_KEY for that step and documents a default ten-minute preparation timeout configurable through AX_BOOTSTRAP_TIMEOUT. That timeout is not a lifetime budget for the workload. Inspect the documented sandbox boot sequence.
That is more actionable than a claim that the whole project was “coded in Antigravity”. The runtime documentation establishes how Antigravity is used during preparation, not how every source file was authored.
For a more controlled setup, evaluate a prebuilt environment and omit the goal-based bootstrap, or implement a compatible custom runner. AX requires the runner executable at /usr/local/bin/ax-task-runner; setting a random agent image is not enough. Test the readiness endpoints, signal forwarding and durable-state handling from the runner contract before replacing it.
Can a Pi coding agent use AX's execution model?
Pi documents interactive, print/JSON, RPC and SDK modes. Those interfaces provide possible integration surfaces, but they are not evidence of a turnkey AX adapter. Read Pi's coding-harness documentation.
A reasonable experiment is to package Pi behind an AX-compatible runner, start it through spec.command, route model traffic through the external budget boundary and keep resumable session state under /workspace. That is a proposed integration design, not a configuration we deployed or a supported integration verified here.
You can also adopt the separation without adopting AX itself: declare the workspace, isolate execution, enforce network access outside the process, and keep model credentials and budget policy under operator control. The value is the boundary, not copying a cloud-specific implementation.
What should an AX pilot prove before receiving real credentials?
Start with one disposable repository, synthetic data and a low-privilege model credential. The following are our acceptance criteria, not claims that the current project already passes them.
| Test | Pass condition |
|---|---|
| Network denial | The task reaches the declared proxy; an unlisted destination and a direct provider route fail. |
| Budget exhaustion | A deliberately repetitive workload stops admitting calls at the shared job limit; concurrent calls have bounded overshoot. |
| Suspend and resume | The session restarts from durable state without repeating an already completed external action. |
| Completion and failure | Both command exit outcomes reach the job supervisor, even while the runner remains healthy. |
| Credential revocation | Revoking the task's authority blocks new privileged operations without asking the agent to cooperate. |
| Portability | An exported workspace and session can be restored in the alternate deployment you actually intend to use. |
Record the AX and Substrate revisions, runner image digest, active model route, gateway policy and observed results. Keep a rollback path while the APIs are changing. A small passing experiment is more useful than an unverified promise about fleet-wide scale.
Wavect's AI engineering services cover implementation and production hardening. The Twinsoft AI case study is separate implementation experience, not an AX reference deployment. Use our pre-launch QA checklist to turn the pilot into acceptance evidence, or discuss your agent runtime and ownership requirements.
Google AX: practical questions before deployment
What is Google AX Agent Executor?
AX is an open-source orchestration project for sandboxed agent workloads. It uses Task, Workspace, Gateway and Model resources and runs above Agent Substrate. It is not a new language model or a substitute for the agent’s reasoning loop.
Does AX enforce a cumulative token budget?
Do not assume that from the current API. In the reviewed commit, the Task policies field for budget and approval configuration was removed. Usage counters alone do not enforce a limit. Use an independently controlled admission layer and test the complete job, including subtasks and setup.
Is the example AX Gateway locked down?
The documented example permits every hostname on port 443. Replace it with explicit destinations, bind it to the task and verify denied paths. Host allowlisting does not replace request-level authorisation on an allowed tool server.
Does AX resume the exact in-memory agent state?
The reviewed AX runner contract describes restoring the durable workspace into a fresh container with a new process tree. Persist resumable sessions and completed-operation records explicitly. This is not a statement about every snapshot capability of the underlying Substrate backends.
Can AX run without Google Cloud?
Agent Substrate documents a local kind development path as well as GKE deployment. AX still needs its control plane and a reachable Substrate API. This establishes a non-GCP development option, not a verified production-ready AX installation on arbitrary infrastructure.
Is Antigravity mandatory for every AX workload?
The documented default runner uses Antigravity for goal-based workspace preparation. A prebuilt environment without that bootstrap or a compatible custom runner is worth evaluating. A replacement must satisfy AX’s runner contract, not merely provide an agent executable.
Can a Pi agent run inside AX?
Pi exposes print/JSON, RPC and SDK integration modes. Packaging it behind an AX-compatible runner is a proposed integration path, not an official ready-made adapter verified here. Check session persistence, model routing, budgets and signal handling before using real credentials.
Does open source mean you own the whole AI system?
No. Verify execution, inference, state and authority separately. Control means being able to inspect, export, revoke and stop the system. A self-hosted runtime can still call a remote model or rely on externally controlled credentials.
Final thoughts
Own the controls, not just a copy of the repository. AX offers useful execution boundaries; spending admission, recoverable state, meaningful completion signals and an exit path still need their own evidence. Start with a small pilot that can prove those properties.