agentd is a managed agent server built with AgentGo and
Agent Ledger, with a pluggable Sandbox Engine.
It exposes the core Claude Managed Agents resources—Agent, Environment, Session, and Event—plus a
self-hosted Model registry for external model connections, while
running the agent harness and sandbox on infrastructure you control. The API transport uses Hertz.
The architecture separates the agentd control plane from per-Pod Agentlet instances. agentd
owns the Managed Agents API and schedules each Session; Agentlet exposes only an internal execution
API and manages assigned harness runtimes.
Before creating an Agent, register the external model connection with POST /v1/models. The Agent
references that Model resource by ID. Model credentials are write-only and are resolved by agentd
into the private WorkSpec sent to the assigned Agentlet; agentd does not provide a model inference
service of its own.
- Keep long-running work alive beyond a single process or model context window. A session and its history remain available when execution waits, stops, or moves elsewhere.
- Accept work asynchronously and stream progress and results as events, without tying the client's connection to the lifetime of an execution process.
- Provision execution capacity when it is needed, place sessions across available workers, and release idle compute without losing the session's identity.
- Run model-generated code in an isolated environment, separated from the control plane and its credentials.
- Preserve inputs, outputs, tool actions, checkpoints, and failures for recovery, audit, and trajectory analysis.
- Replace the agent harness or sandbox implementation behind stable interfaces as models and infrastructure evolve.
agentd owns the public API, durable managed-agent identity, and control state. It schedules each
Session onto an elastic Worker and routes execution through the Connector. A Worker is Agentlet's
workload form; on Kubernetes it is a Pod running Agentlet.
Agentlet drives the selected Harness—AgentGo is the first implementation—while the Sandbox Engine provides isolated tool execution. Checkpoints and append-only execution facts are persisted through Agent Ledger, so a Session can release its Worker and later resume on another one without making the control plane understand Harness-native state. The default Helm chart co-locates a Hostel sidecar only for quick start; a production Sandbox Engine is expected to have its own control plane and is not part of agentd Worker placement.
helm upgrade --install agentd deploy/k8s/agentd \
--namespace agentd --create-namespace
kubectl -n agentd port-forward service/agentd 8020:8020
curl http://127.0.0.1:8020/healthzThe public Managed Agents API is exposed by agentd on port 8020. Agentlet listens on port 8019
inside each Worker Pod and serves only agentd under /internal/v1; clients should not connect to it
directly.
The default Helm values install one agentd replica and a shared MySQL Deployment backed by a PVC;
agentd and every Agentlet use the same database. Production deployments can replace the built-in
database with an external MySQL DSN. The Helm topology is currently a preview
for quick start. See deploy/k8s/README.md for the topology, persistence
options, image settings, and current limitations.
The API uses the Claude Managed Agents beta paths and accepts
anthropic-beta: managed-agents-2026-04-01.
The stable product boundary, supported surface, and component flow are defined in
agentd/docs/kernel.md. Control Plane scheduling, Worker lifecycle, routing,
and Control State are defined in agentd/docs/agentd.md. Agentlet execution,
Checkpoint/Ledger integration, and recovery ordering are defined in
agentd/docs/agentlet.md. Harness execution and adapter boundaries are
defined in agentd/docs/harness.md. Sandbox capabilities and isolation
boundaries are defined in agentd/docs/sandbox-engine.md.