Alternatives considered

What alternatives did we consider for each layer of the agent factory, and why did the current choices win? A new candidate gets a row in the table. If it could replace a whole layer, it also gets a section under projects evaluated in detail.

In short:

• No candidate evaluated so far covers more than one or two layers. The factory, the rooms and the controls around them would stay ours whatever we adopted.
• A choice can be deferred rather than refused. Each detailed evaluation lists the concrete triggers that would make us reconsider it.

How candidates are evaluated

• Against code, not announcements. Claims are checked in the project’s repository at a pinned commit, and linked.
• On the work still ahead. What is already built does not count in its favour; what adopting a candidate would still leave us to build does.
• Against the platform’s requirements:
  • it runs on both EKS and GKE, on spot nodes;
  • every workload gets its own identity and network policy;
  • no long-lived credential reaches a sandbox;
  • open source first.

Where each tool fits

An agent platform has several layers. Most “agent platforms” cover one or two of them; ours needs all five.

    flowchart TB
  subgraph L5["Factory: issue → runs → PR, budgets, merge gate, stop switch"]
    F5["Ours: agent-factory controller + Kueue + policy-bot"]
    T5["Temporal: durable workflows (watched)"]
  end
  subgraph L4["Collaboration: shared sessions with humans and agents"]
    F4["Ours: rooms (room-broker + Postgres log)"]
    K4["kagent sessions: single owner"]
  end
  subgraph L3["Gateway: models, tools, per-run identity and budgets"]
    F3["agentgateway (chosen, live since 2026-10-16)"]
  end
  subgraph L2["Harness: the agent loop"]
    F2["OpenHands (chosen)"]
    A2["ax: Antigravity, Gemini only"]
    K2["kagent: Claude Code, Codex, own ADKs"]
  end
  subgraph L1["Runtime: isolation, lifecycle, identity"]
    F1["agent-sandbox + gVisor (chosen)"]
    S1["Agent Substrate (google/ax and kagent v1 run on it)"]
  end
  L5 --> L4 --> L3 --> L2 --> L1
  

Decisions at a glance

The full records are in the programme’s design documents, listed under Sources.

What would make us reconsider

Projects evaluated in detail

Candidates that could replace a whole layer. Each section states when it was checked.

google/ax

Checked on 2026-10-04 at ac23328.

What it is. Google’s agent orchestrator: it runs each task as an agent on Agent Substrate and bootstraps Google’s Antigravity agent inside it.

Why not.

• Its control plane has no authentication or authorization. The issue is open; its reporter says Google’s security programme rated it critical (ax#376).
• An unvalidated branch name reaches git fetch, a code-execution bug (ax#363).
• Gemini only, with the API key copied into every task (client.go, reconciler.go).
• Still being rewritten: v0.3.0 dropped its event log and replaced its harness, and the queue and controller were replaced a week later (dc4f36c, ac23328).

Adopting ax would replace the harness as well as the runtime, and lock the platform to one model provider.

Reconsider if ax closes #376 and #363 and supports other model providers without putting keys in the sandbox, on top of the Substrate triggers.

Agent Substrate

Checked on 2026-10-04 at 16b863a.

What it is. A runtime that packs many gVisor-isolated agents into shared worker pods and can suspend and resume an agent, memory included, from snapshots.

What it would bring. Fork from a running snapshot, and memory snapshots on any cluster (see below). agent-sandbox has disk-backed suspend since v0.5.0 (operatingMode: Suspended, which deletes the pod and keeps its volumes) and GKE-only memory snapshots driven from its Python SDK; the composition suspends only finished runs.

Why not yet.

Reconsider: see the triggers.

kagent

Checked on 2026-10-04 at bf8afa56 (v1) and v0.10.3.

What it is. A CNCF Sandbox project, mostly maintained by Solo.io, and really two products:

• v1 (alpha, where the project invests) runs only on its own fork of Agent Substrate, with pluggable harnesses (Claude Code, Codex, its own, or yours) and sessions.
• v0.10 (stable, called “legacy” by the project) runs one long-running Deployment per agent.

Why not.

Worth learning from: forking a session together with a snapshot of the running agent, which beats our fork. It depends on Substrate.

Reconsider: see the triggers.

Temporal

Assessed on 2026-10-04 against the factory’s needs; no proof of concept.

What it is. A durable-execution engine (temporalio/temporal, MIT). Workflows are written as code, and the engine keeps their state through crashes, with durable timers, signals, retry policies and a full history of every execution.

What it would bring.

• Timed human waits, such as remind after a day, escalate after two, close after a week, without re-check logic.
• Retry and resume policies declared per step.
• An execution history and UI per task.

It can keep its state in PostgreSQL, so on this platform the database would be a SQLInstance claim, not new infrastructure.

Why not now. The factory’s waits are re-checks of state that already lives in Kubernetes objects and GitHub, and a controller restart loses nothing. Temporal would add its server services and workflows that are versioned as code, which is heavy at today’s 20 tasks a day.

Reconsider under the conditions in the table above. The first candidate is the automatic resume of runs lost to spot reclamation, now being designed: if resume rules multiply, a workflow engine becomes worth its weight.

OpenAI Symphony

Checked on 2026-10-12 at the repository’s SPEC.md; last push 2026-09-15.

What it is. An Apache-2.0 specification for an orchestrator that polls an issue tracker, claims ready issues, gives each one an isolated workspace and runs a coding agent in it, with bounded concurrency, stall and turn-silence timeouts, exponential backoff and restart reconciliation without a database. An Elixir reference implementation exists; OpenAI calls it a “low-key engineering preview”. The agent is Codex only (its app-server protocol); the tracker is pluggable, with Linear, GitHub Issues, Jira Cloud, Asana and GitLab adapters in the reference.

Why not. It leaves our layers to each implementation: its non-goals include “Mandating strong sandbox controls beyond what the coding agent and host OS provide” and “Mandating a single default approval, sandbox, or operator-confirmation posture for all implementations” (SPEC §2.2). Workspaces are directories, locally or on SSH workers; tokens are tracked but not enforced; the merge is whatever the agent does from a hook.

Worth learning from: its continuation rule (SPEC §7.1): after each turn the worker re-checks the issue’s state and starts another turn while it stays active, up to max_turns per worker session, rather than spending fixed counters per trigger. It has no total per-issue budget. Its defaults are a baseline: stall 300 s, max_turns 20, backoff capped at 5 min, and a 1 h limit on a turn’s silence (not its length).

Reconsider if the spec gains a non-Codex agent adapter and a sandbox hook; even then it would replace polling and slot logic only.

Would rebuilding on kagent + Substrate be simpler?

It is the strongest challenge to this design, so it is judged on the work still ahead, not on what is already built.

What it would simplify:

Warm pools, disk-backed suspend and GKE memory snapshots are already in agent-sandbox; the spike compares Substrate against them.

What we would still build:

• The factory, whole.
• The core of rooms: several participants, roles, handoff and who may approve.
• Authorization for kagent itself, which means compiling our own controller around kagent’s Go library: in effect, maintaining a fork of an alpha.
• Short-lived GitHub tokens per run and role, through a custom Substrate credential provider.
• Budgets, at the gateway.

What blocks it today: no EKS until Kubernetes 1.37 lands there, no spot nodes, a possible snapshot-restore failure for a Python harness such as OpenHands (kagent reports one), shared pods that would need an amendment to the constitution, and two alphas changing fast.

Net: today it adds moving parts we do not control rather than removing them. If we move, Substrate as a backend behind AgentRun beats kagent + Substrate: kagent adds little we lack and brings its authorization gap.

Reconsidering Substrate: not now, deliberately open

We intend to reconsider Substrate, and kagent with it, in the near future. Until then, a run on a reclaimed spot node fails and is resumed from its branch; making that resume automatic is being designed. The design keeps the door open:

• AgentRun is the abstraction, so a Substrate backend would be a new composition behind it, not a rewrite.
• Run identity accepts tokens from any issuer.
• The room bridge avoids WebSocket, which Substrate’s egress blocks.

Next step: a two-day spike at the next gcp-0 rebuild. Run OpenHands as a Substrate agent on a gVisor worker pool, then suspend it, resume it and restore it on another node, and compare its start time with our sandbox pod.

• If OpenHands restores and continues its conversation, we design the Substrate backend.
• If it crashes, the path stays closed for OpenHands until it is fixed upstream.

We reconsider on the spike’s result, on 2026-12-15, or as soon as any of these holds:

• Substrate ships per-agent tokens (#1660) and enforces authorization by default;
• EKS serves the Kubernetes certificate APIs as stable (EKS 1.37);
• Substrate gains a story for spot nodes, such as suspending agents on preemption;
• for kagent: open-source authorization, sessions with several attributed participants, per-agent egress (#3019), and a v1 release with a migration path.

Sources

• Agent factory v1 review, 2026-10-12: build-or-adopt per layer, Symphony, agent-sandbox’s suspend and warm pools
• kagent evaluation, 2026-10-04
• ax and Substrate re-check, 2026-10-04
• Runtime research, with the first ax and Substrate evaluation
• Designs: programme, runtime, rooms, factory