AMD's agent runtime shows hour-long sessions are now normal

Most teams building agents still design for a request that ends. Ask a model, call a tool, return an answer, drop the process. AMD published its production numbers on November 6 and they describe a different workload: on its main deployment the median agent run lasted 3.4 hours, the 99th percentile 11.5 hours, the longest 50.1 hours.

The vehicle is PrimusClaw, an MIT-licensed managed agent runtime AMD has run in production since April 2026. Not a launch with a pricing page, but a 4,400-word engineering post with telemetry, a public repository, and an unusually honest section on which security controls are off by default. That makes it the most useful document on agent infrastructure this week, and the least comfortable one for anyone who assumed agents are short-lived handlers.

What AMD actually shipped

PrimusClaw splits a managed run into three parts. The API is a Fastify service owning sessions, events, memory, skills, plugins, A2A and MCP, with PostgreSQL as the source of truth and events streamed over SSE with resumable cursors. Brain is the harness: a stateless replica running the agent loop, calling models through an Anthropic- or OpenAI-compatible gateway and managing the sandbox. Hands is an MCP tool server inside each sandbox exposing shell, file and patch operations.

The sandbox control plane is an Apache-2.0 fork of Kubernetes SIG Apps' agent-sandbox project, so isolation is converging on one upstream component across vendors. Authentication and multi-node GPU placement go to Primus-SaFE, AMD's separate cluster platform. The interfaces are deliberately boring: an API compatible with Anthropic's Claude Managed Agents quick-start flow, A2A v1.0, MCP in both directions, and model choice through LiteLLM. The code is public on GitHub under MIT.

The numbers that reframe the problem

Across two deployments between 20 April and 13 October 2026, PrimusClaw hosted more than 40,000 sessions for over 70 users: 100,000-plus agent-hours, 4 million tool calls and 500 billion prompt tokens, with a 0.29% tool call error rate.

The distribution is what matters. On the main deployment, with over 30,000 runs, the median was 3.4 hours, the 90th percentile 7.1 hours and the 99th percentile 11.5 hours. Seventy-one percent of runs lasted more than an hour and more than 2,000 lasted longer than eight. At the June 2026 peak that deployment ran more than 800 concurrent runs and 700 sandboxes; between 5 and 13 October, 95.6% of prompt tokens came from cache.

A runtime sized for bursty sub-second calls is now asked to hold a workspace of files an agent has edited for six hours, a live process tree, and a conversation whose prompt cache decides whether the unit cost is viable.

Why hours break the runtime you built

A runtime hosting four-hour runs cannot treat a deployment as an outage. PrimusClaw's answer is to make a run a row in PostgreSQL under a lease rather than a message pinned to a process. A Brain replica with spare capacity claims the row through a compare-and-swap, the lease carries a 45-second TTL renewed every 15 seconds, and credentials are unsealed only at claim time, not when the work notification arrives.

Rolling upgrades follow the same logic. New replicas start before any old one stops, a version marker in NATS tells stale replicas to stop claiming work while they finish what they hold, and a SIGTERM handler writes a checkpoint and syncs the workspace to object storage within the 300-second grace period. Checkpoints can be bound to a run, so a replayed one is rejected.

The results are the interesting part. On the main deployment, 2,140 runs lost their sandbox mid-flight; the runtime rebuilt each sandbox and 2,047 of those runs, 95.7%, still succeeded. Across three rolling upgrades of the API, 583 runs were in flight: 580 completed and 544 succeeded, with all 36 failures attributed to agent or sandbox errors rather than a lost worker.

Idle detection gets the same treatment. Background processes are invisible to the HTTP call that created them: an agent runs nohup python train.py &, the call returns instantly, and the job keeps burning a GPU. So each command runs under a shim acting as a subreaper that tracks adopted descendants and reports a roster. The probe returns four outcomes, empty, non-empty, unknown and tracking lost, and only positive evidence of emptiness lets the reaper act. Idle time alone never triggers it.

The security defaults worth reading twice

The post is candid that its defaults are not the hardened configuration. Sandboxes run on runc, which shares the host kernel and is not a hard isolation boundary; Kata is available, and the security guide is what you read before exposing a deployment. Session-bound tokens, the egress proxy that blocks cloud metadata and loopback ranges, and checkpoint sealing are options rather than defaults. The one control on by default is failing closed when control-plane authentication is missing.

The rule worth copying is simpler: platform and provider keys stay with the harness and never enter the sandbox, and the only credential a sandbox carries is the calling user's own key, so injected code is capped at that user's scope. AMD adds the consequence, that the key must be scoped, rate-limited and revocable per user.

Why a chip vendor ships an agent harness

AMD is not alone, and the post's comparison table makes the convergence explicit. Anthropic describes a stateless harness resuming from a durable log; Google's Agent Substrate restores paused agents in under 500 milliseconds; AgentCore gives a micro-VM up to eight hours, or instances up to 14 days. The anatomy is settled. What differs is where the harness runs and how upgrades treat work already in flight.

AMD's bet is GPU proximity. Agents on an Instinct cluster spend their time tuning kernels, profiling inference servers and running hours-long experiments, so sandboxes must request GPUs and start from ROCm images. Two of AMD's own optimization agents, Hyperloom for inference and GEAK for kernels, run as PrimusClaw sessions with more than 2,000 runs each. A silicon vendor shipping the runtime its own agents live in is the inverse of a moat: it makes accelerators easier to keep busy without making the software harder to leave.

What builders should copy

• Size sessions in hours. Checkpoint state and workspace to object storage, and make the checkpoint the resume point, not the process.
• Assume deploys land mid-run. Drain replicas, stop claiming work, hand off in-flight runs, test recovery as a first-class path.
• Detect idleness on evidence. Timeouts kill running jobs; a probe that can answer "unknown" costs less than a destroyed training run.
• Treat runc as a convenience, not a boundary. For untrusted code, VM isolation is the default you want, not an option enabled later.
• Keep credentials above the sandbox, and insist on standard interfaces (A2A, MCP, a provider-agnostic gateway) so the runtime stays switchable when the economics change.

The trade-off AMD names plainly is ownership: self-hosting means the certifications and service levels of a managed offering become yours. For teams already running Kubernetes next to their own accelerators, that is usually the whole reason they are not on a hyperscaler runtime.

The open question is adoption. PrimusClaw has 451 commits and six stars, so this is an engineering disclosure rather than a market event, and the signal to track is whether the agent-sandbox upstream it forks becomes the neutral substrate both vendors build on.