Pimp My IDE / Garage Dispatch
Back to garage
September 22, 2026 | agent infrastructure / manifests / stop rules

An agent manifest needs an off switch.

Google's experimental AX runtime gives agent work Kubernetes-shaped resources for tasks, workspaces, network policy, and model configuration. That is a useful direction. The deployment review still needs one more line: what ends the work?

THE TAKE: Treat the agent manifest as an ignition sheet. Pin the workload, workspace, egress, and model. Then add an explicit stop contract with time, retry, spend, and cleanup limits before the task can run unattended.
Turn the Agent Task Ignition Rack

The agent is not a one-shot Job.

AX describes an agent task as a small isolated unit that may plan, delegate, retry, and create a tree of more tasks. Its lifecycle includes running, suspended, failed, and terminating states. A task can keep filesystem and memory state across suspension through the Agent Substrate runtime beneath it.[1][2]

That differs from the standard Kubernetes Job contract. A Job retries Pods until a specified number finish successfully. Kubernetes also exposes a retry limit, an active deadline, and cleanup after completion.[3]

Persistence changes the failure question. Ask what can wake the task, what it can still reach, and what finally deletes it.

AX makes four parts inspectable.

The current AX docs define four resources. Task declares the image, command, compute limits, workspace bindings, and gateway reference. Workspace prepares repositories, MCP servers, and skills. Gateway sets listeners and an outbound host allowlist. Model names the provider, model identifier, parameters, and Kubernetes secret reference.[1]

This separation is useful because each resource answers a different review question. What runs? What enters the filesystem? Where can traffic go? Which model configuration and credential does the platform use?

The example manifest deserves a close read. Its gateway allows every host on port 443 and tells operators to tighten that in production. Its task enables debug access. Those are clear examples, not production defaults.[4]

Ready is a state, not an approval.

AX says Ready means the task is running and its workspaces are ready. The separate GatewayReady condition means network policy reached the sandbox. Neither condition says the change is correct, the spend is bounded, or the task should merge code.

The current docs reviewed here do not define a token budget, a wall-clock deadline, a retry ceiling, or a merge approval rule in the four-resource manifest. AX warns that its concepts and APIs are still changing before a stable release. Treat the missing review fields as deployment policy you must supply, not as evidence that the alpha runtime promises them.[1]

Write the stop contract beside the start contract.

  1. Pin the image by digest and cap CPU and memory.
  2. Pin repository revisions. Review every MCP server and skill source placed in the workspace.
  3. Replace wildcard egress with the exact hosts and ports the task needs.
  4. Name the model configuration and secret reference. Keep raw credentials out of the manifest.
  5. Set wall-clock, retry, spend, and child-task ceilings in the surrounding control system.
  6. Define who may resume, approve, merge, and delete the task. Save the final status and cleanup receipt.

A declarative runtime makes policy review possible. It does not finish the policy for you.

Interactive makeover / physical launch review

Agent Task Ignition Rack.

Traditional purpose replaced: read one YAML file and wait for a green Ready condition. Better version: choose the task's lifecycle, close five distinct interlocks, watch the ignition key move, and copy a review card that keeps missing evidence visible.

Set the operating posture

The lifecycle choice changes the handoff questions. It does not turn on any interlock for you.

Task lifecycle
Launch interlocks
DRAFT2 / 5 interlocks
The rack is wired, not ready.

The task and workspace are named. Network reach, model configuration, and the stop contract still need review.

Why it is better: one native state model drives the lamps, key, verdict, and handoff card. The last position says REVIEW GATE READY. It never claims that a manifest was applied or a live task was contained.

Sources read, not vibes

Open the source log
  1. Google AX repository and current docs: the experimental Task, Workspace, Gateway, and Model resources; lifecycle conditions; suspend and resume behavior; network allowlists; and the pre-stable compatibility warning.
  2. Agent Substrate repository: actor-to-worker multiplexing, persistent state across suspension, supported sandbox types, published performance claims, and the explicit not-ready-for-production warning.
  3. Kubernetes documentation, Jobs: run-to-completion behavior, retry limits, activeDeadlineSeconds, and cleanup with ttlSecondsAfterFinished.
  4. AX example manifest: resource limits, debug access, workspace and model declarations, and a wildcard port-443 egress example marked for tightening in production.
  5. GitHub Trending, September 22, 2026: discovery route for AX and Agent Substrate. Trending position is not evidence for the technical claims above.

Source boundary: AX and Agent Substrate are early projects. Their repository claims are first-party claims, not independent scale or security audits. The stop-contract checklist and Ignition Rack are Pimp My IDE's proposed deployment review. They are not AX features and do not certify a cluster.