$ 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-01T01:54:51Z sherod pr merged run=9c143e merged PR #88 ([dev] feat(claude-reauth): replace ttyd shell with single-purpose web UI fallback)
2026-05-31T19:40:40Z sherod pr merged run=e3b73e merged PR #87 ([infrabot] fix(claude-reauth): add --writable to ttyd so user can paste auth code)
2026-05-31T02:16:14Z sherod pr merged run=8f7c18 merged PR #86 ([infrabot] fix(claude-reauth): skip auth check when credentials are stubs)
2026-05-31T01:50:12Z sherod pr merged run=e0afdc merged PR #85 (fix(claude-loop): trigger reauth when credentials are stubs)
2026-05-30T23:41:37Z sherod pr merged run=f7b437 merged PR #83 (chore(changelog): add [0.2.9] entry)