$ agent-smith --hello

Your secure sandboxed agent workforce — ship in your sleep.

agent-smith is a framework for running long-lived AI engineering agents that operate as peers — they read code, open PRs, review each other's work, and learn from what they ship.

$ read the docs ›$ view on github ›$ ls crew ↓

$ describe agent-smith

agent-smith deploys Claude Code as persistent, long-lived engineering agents inside Kubernetes pods. Each agent has a permanent workspace with real cluster credentials, follows the same git workflow as a human teammate, and works autonomously until the task is done — feature branches, conventional commits, pull requests, review comments addressed, merged.

The current team is three agents — InfraBot for k3s/Flux, DevBot for code, and PMBot for product (vision, roadmap, PRDs). The container image is parametric: one new agents/<name>/ directory and you have a fourth teammate.

$ ls crew

Three agents today, running as peers. One image, parametric persona — new crew members are a directory under agents/, not a fork.

DevBot — code agent. Reads the repo, opens PRs, addresses review, merges.

InfraBot — infra agent. Owns k3s + Flux, watches the cluster, ships manifests through GitOps.

PMBot — product agent. Owns vision, roadmap, and PRDs. Gates work for alignment; stays out of the implementation lane.

$ ls capabilities

Owns a persistent workspace — full filesystem + shell access on a long-lived volume with real cluster credentials.
Follows the full engineering workflow — reads, writes, opens the PR, addresses review, merges. The whole loop.
Watches its own PRs — a Stop-hook reruns the agent when unaddressed review comments appear.
Coordinates with teammates — one agent opens a PR, the other reviews it end-to-end and posts inline findings. NATS is the durable audit log.
Never holds production secrets — stub tokens are swapped for real credentials at the network boundary by an egress firewall.

Reach them from a Matrix room, from your phone, or via the Claude desktop app. The interface is up to you; the engineering capability is always there.

$ describe reference deployment

The way we run agent-smith. Yours can be different.

One image, many agents. The runtime in a single pod looks like this:

StatefulSet/<agent>           (one per agent: infrabot, devbot, …)
└── init container: setup.sh  (assembles ~/.claude, installs plugin, clones repos)
└── main container: entrypoint.sh
    └── tmux session "main"
        ├── pane 0 — claude (channels + --remote-control)  ← receives Matrix messages
        │                                                    + exposed for remote drive-in
        └── pane 1 — plain bash shell                       ← ad-hoc inspection on attach

The runtime is production-grade: one Kubernetes StatefulSet per agent, GitOps-managed via Flux, secrets from Infisical via ExternalSecrets, full observability through VictoriaMetrics / VictoriaLogs. These agents ship work that ends up in main.

$ docs/architecture ›

$ swarm status

$ tail -f #audit

2026-06-15T22:18:01Z sherod pr merged run=fdfc11 merged PR #114 ([dev] fix(ci): quote run_id in log-pr-merge — defeats YAML float coercion)
2026-06-09T16:02:01Z sherod pr merged run=ef1869 merged PR #113 (chore(release): v0.2.22 — reauth reuses operator DM via m.direct lookup)
2026-06-09T05:41:22Z sherod pr merged run=6a7044 merged PR #112 (fix(reauth): reuse existing DM room via m.direct lookup)
2026-06-08T22:07:30Z sherod pr merged run=2e4654 merged PR #106 ([dev] docs(runbook): document PR-preview URLs + lifecycle in website-deploy.md)
2026-06-08T22:07:13Z sherod pr merged run=b84c72 merged PR #107 ([dev] feat(ci): fail website deploys when the live URL stays stale)