Build1 publisher3 min readPublished
kagent 1.0 swaps Deployment-backed agents for a Postgres-backed gRPC lifecycle object
Roughly 130 pull requests, most of them refactoring, retire the Kubernetes Deployment that used to sit under every kagent agent. The tag string on the release says alpha1 and GitHub's flag on it says prerelease false.
The Engineer · Build desk
What happened
- kagent shipped v1.0.0-alpha1 on the morning of 18 September 2026, its first 1.0 line after nine months of 0.x releases.
- The changelog runs to roughly 130 pull requests, most of them refactoring, with repeated entries removing the deployment-backed agent API, the legacy controller runtime and legacy ACP.
- Where a 0.x agent was a Kubernetes Deployment underneath, v1.0 introduces AgentInstance, an imperative gRPC lifecycle object with a fixed state machine.
- The chat UI gains a Checkpoint button beside Send that records the conversation's current turn boundary so a session can be forked from that point.
- GitHub marks the alpha-tagged release prerelease: false and lists it as Latest.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Leaving 0.x is a cutover: the same release that introduces AgentInstance deletes the deployment-backed agent API and the legacy controller runtime, so the reconciler you would fall back to is gone.
- constraint Tooling that reads the prerelease flag rather than the tag string, including a Helm repo index, will treat this alpha as the current release, so pinning has to be done by version explicitly.
- exposure Anyone routing agent-to-agent traffic through the new gateway on day one inherits the gaps PR #2446 names as unfinished, including task persistence and idempotency.
- capability Callers can now program against a rejection: a colliding resume comes back as ABORTED, an answer a controller loop converging on desired state has no way to express.
Call Resume twice on the same AgentInstance and the second call returns ABORTED. The Kind smoke test in PR #2445 walks the whole path: Create to READY, Suspend to SUSPENDED, Resume to READY, a conflicting Resume to ABORTED, Delete to DELETED, then a Get that returns NOT_FOUND [7]. Six calls, six defined answers [19]. Ask a Deployment reconciler the same question and it converges eventually, and two competing writers get whatever order the informer delivers, according to the writeup [8].
That state has to live somewhere. PR #2436 puts it in PostgreSQL, with idempotent create, ownership checks and Actor identity fencing [6]. Ready instances sit behind an authenticated A2A gRPC gateway routing through Atenet to private root Substrate actors (PR #2446), and that PR is explicit about what is outstanding: "Durable public Task persistence, public/private ID mapping, ordering, and idempotency remain follow-up work" [9][10].
A Checkpoint button next to Send (PR #2775) saves the conversation's current turn boundary, and the PR states the contract as "Everything above it travels into a fork and nothing below it does" [11]. PR #2847 renames the concept to snapshot, defaults each name to `<agentInstanceId>-<headTaskId>`, and puts Fork, Rename and Delete on the mark in the transcript [12]. Chats already forked from a checkpoint survive its deletion, because a fork copies the checkpoint's identity instead of referencing it live (PR #2804) [13].
PR #2715 resumes a suspended actor from a Substrate golden snapshot, a FULL gVisor snapshot plus the latest DATA snapshot, instead of cold-booting the actor from its OCI image [14]. The PR ships its own benchmark at 25 turns per harness, cold boot against golden resume; Codex barely moves and Claude's numbers move more, which fits a heavier CLI process paying more for a cold OCI boot [15]. Those numbers transfer to your cluster only if cold start is a similar share of your turn latency and your sessions are long enough to amortise the snapshot at all. The writeup's author, who publishes as webofmike, wrote: "I haven't reproduced this benchmark myself; it's quoted from the PR description, not a run against my own cluster, and I'm saying so" [16].
The invalidation rule underneath it is careful work. A Substrate upgrade leaves a golden snapshot valid, because the snapshot manifest pins its own sandbox class, runtime asset hash and pause image; it breaks if an upgrade changes the snapshot format, or the restore contract, or drops host support for the pinned runtime [17].
Which returns the question to the release tag and GitHub's prerelease flag. The writeup's advice on that: "don't assume the tag string tells you how GitHub, or a Helm repo index, actually classifies the artifact. Check both, every time" [20]. The author calls PR #2602 the headline feature and titles the piece "kagent v1.0 Can Run Claude Code as a Managed Kubernetes Agent"; the published text breaks off before describing it [18].
What to watch
- Whether a final v1.0.0 drops the alpha string, and whether GitHub's prerelease flag changes with it.
- Whether the A2A follow-up work named in PR #2446 (durable task persistence, ID mapping, ordering, idempotency) lands before operators route production traffic through the gateway.
- Whether anyone outside the project reproduces the PR #2715 cold-boot versus golden-resume benchmark on their own cluster.