Quick answer
AX does not require Kubernetes for local evaluation, but its repository is Kubernetes-oriented and documents Agent Substrate as the preferred production deployment path. The current manifests assume a cluster with a compatible Agent Substrate control plane, build and push three images, deploy an AX server, connect to PostgreSQL, and configure snapshot storage.
The same official guide calls this path experimental and incomplete. Treat it as an engineering evaluation, not a stable installation contract. Pin every dependency, isolate the cluster, and prove recovery and rollback before exposing a real workload.
The documented topology
| Component | Current documented role | Operator-owned decision |
|---|---|---|
| AX server | Coordinates conversations and harness execution | Availability, authentication, network exposure, scaling, upgrades |
| Event-log PostgreSQL | Stores runtime events in the Kubernetes path | Managed versus self-run database, backup, encryption, retention |
| Agent Substrate | Provisions, suspends, and resumes actors | Compatible control plane, CRDs, worker pools, capacity, support |
| Snapshot bucket | Stores actor snapshots for compatible resumption | Location, access, lifecycle, encryption, recovery, deletion |
| AX images | Server and Go interactions harness | Registry, provenance, scanning, signing, architecture |
| Antigravity image | Python sidecar, SDK, local harness, and agent | Dependency pinning, credentials, model and data policy |
| ATEOM worker image | Pinned Substrate worker component | Version alignment and supply-chain verification |
The installation script targets linux/amd64, uses Docker or Podman for AX images, and uses ko for the worker image. Cross-building on macOS may use emulation. Confirm architecture, registry, builders, and generated manifest inputs in your own pipeline.
Version alignment is a release gate
The deployment guide says AX pins Agent Substrate in go.mod; the local Substrate checkout and the cluster’s installed Substrate CRDs and control plane must be compatible with that pin. This is not a loose “latest works with latest” relationship.
Record at least:
- AX Git revision and tree state;
- Go module lock and Substrate commit;
- container image digests, not floating tags;
- applied CRD and controller versions;
- generated manifests and configuration checksum;
- database schema or migration level;
- snapshot format and restore compatibility;
- rollback package and last successfully tested combination.
Reject a release if any of those cannot be reconstructed.
Identity and secret boundaries
The default harness can use a Gemini API key. The deployment guide separately describes an Antigravity Interactions harness using Vertex AI and Workload Identity, where the ax/default Kubernetes service account principal needs the documented AI Platform role in the target project.
Do not generalize one example to every harness. Inventory the AX server identity, actor identity, image-pull identity, database credential, snapshot-bucket identity, model credential, MCP and tool credentials, and operator identity separately. Bind the narrowest permissions and test denial, expiration, rotation, and revocation.
Never treat a Kubernetes namespace as the only tenant boundary. Network policies, service-account scope, volumes, secrets, event rows, snapshots, tool resources, and observability data need independent isolation evidence. Continue with the AX security and multitenancy guide.
Deployment and rollback gate
- Reproduce the build in a clean environment and retain image provenance.
- Deploy into an isolated test cluster with non-production credentials.
- Connect an external PostgreSQL service with backup and restore tests; use the bundled database only for its stated test purpose.
- Execute, suspend, resume, cancel, disconnect, reconnect, and terminate a reversible workload.
- Drain a worker, restart the AX server, interrupt the database, and deny snapshot access.
- Verify events, snapshots, tool actions, terminal states, alerts, and cleanup after each fault.
- Upgrade one pinned component at a time and run the same suite.
- Roll back binaries, manifests, CRDs where supported, and application code without losing or duplicating business actions.
The durable execution guide covers recovery semantics. The readiness checklist gives a local go/no-go gate.
Frequently asked questions
Does AX require Kubernetes?
No. It supports a local built-in server. Kubernetes is the project’s emphasized distributed deployment path.
Is the Kubernetes path stable?
No. The official guide says it is experimental and incomplete and may break without notice.
Can I use any Agent Substrate version?
Do not assume so. The guide requires alignment between the AX module pin, local checkout, and installed cluster control plane and CRDs.
Official sources
- Google: AX repository
- Google: AX Kubernetes deployment guide
- Google Cloud: Agent Executor announcement
- Google Cloud: Agent Substrate announcement
Source check: August 12, 2026; AX revision 2bcc1637b3c106c16963c5c5464aedb46c6da031. Recheck manifests, scripts, architecture targets, dependency pins, authentication, and warnings before deployment.