Part 13

Decide

Work through five questions in order to pick ax, kagent, or wait or pilot, then check the summary table for the evidence behind each answer.

  • Resolve conflicting needs with an ordered question flow.
  • Recognise when neither project is ready for your workload yet.
  • Trace each recommendation back to the page that justifies it.

Question flow

Ask the questions in this order and stop at the first one that gives an outcome. The diagram and the list below describe the same five questions.

Figure: Check cluster readiness first, then ask about conversation history, fan-out, existing agent loops, and the web UI with shared MCP tool servers.
  1. Can your cluster serve the certificates.k8s.io/v1beta1 APIs that Agent Substrate needs? Both projects need Substrate, which needs the cluster to serve the certificates.k8s.io/v1beta1 PodCertificateRequest and ClusterTrustBundle APIs. Substrate's GKE guide documents Kubernetes 1.36 or later,13 but that is not a universal minimum: kagent's own kind setup runs Kubernetes 1.35.0 with the ClusterTrustBundle, ClusterTrustBundleProjection, and PodCertificateRequest feature gates and certificates.k8s.io/v1beta1 runtime config.34 Managed clusters that cannot enable beta APIs or feature gates, such as EKS today, cannot. If no, the outcome is Wait or pilot. See Setup and Maturity.
  2. Do you need a conversational agent with durable history? If yes, choose kagent (C4, C7). kagent keeps each Session in PostgreSQL.9 See Lifecycle.
  3. Do you need massive fan-out of short, isolated jobs? If yes, choose ax (C1, C3). ax is built for "billions of tasks per cluster".1 See State.
  4. Do you already have your own agent loop or CLI agent? If yes, choose ax (C2). ax runs your command per Task and does not model the agent.3 See Agent loop.
  5. Do you need a web UI and shared MCP tool servers? If yes, choose kagent (C5, C6, C8). kagent ships a UI and an MCP server with Kubernetes, Helm, and Prometheus tools.8 If no, the outcome is Wait or pilot. See Interfaces.

Summary table

Each row names one need. The ID column lets you refer to a row in discussion; the flow above shows how to weigh rows that disagree.

Needs, the project each one favours, and where the evidence is
IDIf you needLean towardsWhy
C1Massive fan-out of short-lived, isolated agent jobs, for example one sandbox per repository per pull request.axState: ax is built for "billions of tasks per cluster".1
C2To run an existing agent binary from any framework with no code changes.axAgent loop: ax does not model the agent.3
C3Pre-cloned repositories and prepared toolchains before the agent starts.axResources: a workspace binding's goal prepares the Workspace before the command runs.45
C4Long-lived conversational agents with durable history.kagentLifecycle: Sessions persist in PostgreSQL.9
C5Agents that other agents and clients call over A2A or MCP.kagentInterfaces: port 8083 serves A2A and MCP.10
C6GitOps, with agent definitions as CRDs reconciled by Argo CD or Flux.kagentArchitecture: ax uses no CRDs for Tasks.2
C7Checkpoint and fork of conversations today.kagentLifecycle: implemented in kagent, roadmap in ax.96
C8Kubernetes operations tooling out of the box, such as Kubernetes, Helm, and Prometheus MCP tools.kagentInterfaces: kagent ships an MCP server with these tools.8

The projects are not exclusive in principle, because both target the same Substrate Control API. Neither project documents whether they can share one Substrate install, including atespaces, WorkerPools, and versions, so test that before planning on it.

Local constraints

Readers at Akuru should also read the Akuru notes appendix, which records internal context that affects this decision on EKS.