AMD has open-sourced PrimusClaw, a managed agent runtime that keeps session state, the agent harness and per-session sandboxes on an operator’s own Kubernetes cluster beside AMD Instinct GPUs. The 6 November ROCm announcement describes infrastructure for long-running work such as tuning GPU kernels and optimising inference servers, rather than a new language model.
The intended user is an organisation that already operates GPU infrastructure and wants the agent’s working environment there too. AMD says the runtime has been in production internally since April 2026. Publishing the system makes that operating model available for others to examine, but the usage figures describe AMD’s deployments, not adoption across the wider market.
PrimusClaw separates durable sessions from disposable workers
The AMD-AGI repository describes agent orchestration on Kubernetes with autonomous coding-agent sessions in per-session sandboxes. AMD’s blog separates the architecture into a session plane, a harness plane and a sandbox plane. PostgreSQL holds the run records, while interchangeable harness replicas execute the agent loop and sandbox tools carry out file and shell actions.
A run is designed not to depend on the worker that first claimed it. The harness uses leases and checkpoints so another replica can take over, with recovery determined by what state survives. A surviving sandbox allows continuation from the checkpointed conversation; a replaced sandbox may require workspace restoration. If neither state survives, the system restarts cleanly rather than assuming the missing files still exist.
Authentication and multi-node GPU placement are delegated to Primus-SaFE. AMD says production installations require that platform, while an isolated evaluation cluster can run without it. PrimusClaw hosts Hyperloom for inference optimisation and GEAK for GPU-kernel optimisation, linking the runtime to workloads that need access to accelerators rather than only a text conversation.
The project is MIT-licensed except for its sandbox control plane, an Apache-2.0 fork of the Kubernetes SIG Apps agent-sandbox project. That exception matters for readers assessing the components they would operate or redistribute: the repository is not uniformly under one licence.
AMD’s activity totals describe workload, not model quality
AMD reports more than 40,000 sessions for more than 70 users across two deployments, adding up to over 100,000 agent-hours, more than four million tool calls and more than 500 billion prompt tokens. AMD says data were collected on 13 October 2026: the main deployment covers 20 April to 13 October, and the second covers 3 July to 12 September. The company reports a 3.4-hour median run on the main deployment.
Prompt tokens here are input tokens sent to models, not generated output. AMD defines agent-hours as recorded execution time, including failed runs, and its run-length measure also includes failures or timeouts. These are operational activity figures from specified internal configurations, not an independent performance benchmark or evidence that every run completed its task successfully.
That distinction complements Factory’s Droid coding-agent harness coverage, where the subject is company-reported coding comparisons. Runtime persistence and benchmark task scores answer different questions. DeepSeek’s open superagent prototype addresses another layer: organising repository work and human attention rather than proving the reliability of AMD’s infrastructure.
Security also depends on configuration. AMD says platform-wide credentials stay outside the sandbox, but the sandbox can carry the calling user’s key. Its default runc environment shares the host kernel and is not a hard isolation boundary. Session-bound tokens, egress filtering, checkpoint sealing and the VM-isolated Kata option are hardening settings, not all enabled by default. TSN’s Agent Substrate and CNCF coverage supplies related context on infrastructure for containing agent workloads.
Owning the runtime also means owning its boundaries
Keeping a session log and harness beside the compute changes who controls the operating environment. It can make the connection between an agent’s long conversation and the workspace it modifies more explicit. The checkpoint design recognises that recovering a conversation alone is insufficient if the files it refers to have disappeared. That is an infrastructure problem distinct from whether the model can solve a programming task.
The security distinction is equally important. Separating platform credentials from generated code narrows one exposure, but it does not make the user’s own credential inaccessible to that code. Nor does the presence of a sandbox establish that every optional isolation setting is active. An operator evaluating the release needs to consider those boundaries alongside the convenience of placing agents close to GPUs.
AMD’s production history provides a concrete account of the workload the design was built around. It cannot establish the same reliability, security posture or economics in another cluster. The relevant next evidence is therefore deployment-specific: whether an operator can reproduce the intended recovery behaviour and configure an isolation boundary appropriate to its users, rather than treating a large prompt-token total as a model-quality score.
For prospective adopters, the repository’s deployment and security guides are the next checkpoint before exposing a runtime to users.
Sources
Related stories
Google Moves Agent Substrate, gVisor and OpenRL to CNCF provides the closest next read on sandbox infrastructure, with a different project and isolation design.
Follow @tsnmediahub on X for breaking AI news as it happens.
Follow on X
