AMD PrimusClaw — Lease-claimed durable agent runs — What does it mean?
The news. On November 6, 2026, AMD published PrimusClaw, an open-source managed agent runtime (a session store, an agent harness and per-session sandboxes) that runs on your own Kubernetes cluster next to AMD Instinct GPUs. AMD says it has been in production use since April 2026: two deployments hosted more than 40,000 sessions, over 100,000 agent-hours and more than 4 million tool calls. Its headline design choice is in AMD's own takeaway list: runs are not tied to one worker. Read the release →
Picture a ward where nurse A has looked after the patient in bed 3 for two hours, then is called away for good. If the care plan lived only in nurse A's head, the next nurse would have to start from the admission desk. A ward avoids that with two habits: the plan lives in the chart at the station, and a whiteboard says who owns each bed, with initials that must be refreshed. When nurse A's initials go stale, nurse B reads the chart and carries on. The patient belongs to the ward, not to the nurse.
When a run lives only in the memory of the worker process that started it, a deploy, a node failure or an out-of-memory kill can end the run, and AMD's post names "runs that are not tied to the worker process that started them" as the first need of a managed runtime. PrimusClaw moves the run's state object out of the worker: each run is a row in PostgreSQL, and that row is the source of truth. The harness replicas (AMD calls the harness the Brain) are interchangeable, so a replica holds a run only while it holds that run's lease.
Dispatch is split in two, like a call bell and a chart. The API writes the run's specification and a sealed credential blob into the row, then rings a doorbell on NATS JetStream that carries only the run's identity. A replica with a free slot answers by claiming the row with a compare-and-swap on its lease: the claim succeeds only if the lease is absent or expired, and the credentials are unsealed only after the claim succeeds. A saturated replica simply leaves the row for someone else.
The important line in AMD's design is that liveness is the lease, not the queue's acknowledgment. An acknowledgment proves that some worker received a message at one moment; it proves nothing about that worker an hour later. The lease is a fresher signal: the holder must renew it (by default every 15 s, with a 45 s TTL), and once it lapses any replica can try to claim the run. This is the pattern the durable execution platforms step describes, applied to a multi-hour agent loop.
A lease only says who may continue; the checkpoint says where to continue from. The Brain checkpoints the conversation after every completed turn. On a planned exit, the replica's shutdown handler (it runs on SIGTERM, the signal Kubernetes sends before it stops a process) also writes the conversation and syncs the workspace to object storage within a 300 s grace period, then hands the run back. The new owner then chooses its recovery path from what actually survived, like a nurse who checks the room before following the handoff note:
| What survived | What the new replica does | Why |
|---|---|---|
| Sandbox still alive | Continues from the checkpointed conversation | Files and processes match what the conversation refers to |
| Sandbox replaced | Restores the workspace snapshot, then continues | The new room is empty until the belongings are brought back |
| Neither | Restarts the run cleanly | Resuming a conversation about files that no longer exist would mislead the model |
Deploys use the same machinery. In a rolling release of the harness, new replicas start before any old one stops (maxUnavailable: 0). The rollout then publishes a new minimum version to a NATS key-value bucket; an old replica stops claiming new runs but keeps executing the runs it holds, so it drains instead of dying. Moving the marker back is the rollback.
Worked example. Hold three values fixed: the default 45 s TTL, renewal every 15 s, and a run two hours into its work. A short network problem that blocks one renewal changes nothing: after a renewal at time 0, the attempts at 15 s and 30 s can both fail before the lease lapses at 45 s (arithmetic from the defaults). Now kill the replica 10 s after its last renewal. Its lease lapses 35 s later, any replica can claim the run, and it resumes from the last completed turn. The cost is about 35 s of idle time plus one unfinished turn, instead of two hours of redone work. The worst case is a crash just after a renewal: 45 s of idle time.
That unfinished turn is where the remaining risk sits. If the sandbox survived, a tool call from that turn may already have changed a file, and the resumed conversation does not know it. AMD's post does not say how PrimusClaw handles this case, which is why idempotent tools still matter when the harness itself is durable.
AMD reports production numbers that test the design. On the main deployment, 2,140 runs lost their sandbox mid-flight and 2,047 (95.7%) still succeeded. Across three rolling upgrades of the API, 583 runs were in flight: 580 (99.5%) ran to completion, 544 (93.3%) succeeded, and AMD says the 36 failures reported agent or sandbox errors, not a lost worker. Note what these numbers cover: they are upgrades of the API service, and the harness-upgrade path is described as designed to work this way. Other runtimes share parts of the idea: AMD's comparison notes that Anthropic describes a stateless harness that resumes from a durable session log, and that Microsoft Foundry previews lease-based recovery.
Goes deeper in: Agent Engineering → Production Harness Architecture → Durable Execution Platforms
Related explainers
- Idempotency keys vs read-back verification for exactly-once tool effects — what to do about the tool call that runs twice after a resume
- Sandman: pooled persistent sandboxes for agent RL — the sandbox side of keeping long agent work alive