The self-hosted, open-source AI agent
for your infrastructure
Joe is built to operate your infrastructure under governance you control. It connects to your systems under its own identity — scoped, per-component credentials — and acts on them through tools typed read or mutate at boot. Bring your own model: Anthropic, Google, or any OpenAI-compatible endpoint, including one you host yourself. One binary, nothing else to install. You operate Joe through its web UI — chat, infrastructure graph, and governance controls in one place. Read-only by default; built to make changes safely.
What Joe does
Understand your live infrastructure
Ask Joe what’s happening right now. It reads across your components, correlates, and answers from the live state of your systems.
Make changes with full context
Joe answers from live state — current limits, where it runs, what sits adjacent — and proposes the exact change. Execution stays behind the write floor.
Ground your coding agent
Connect Claude Code or any MCP-capable agent to Joe’s MCP server. Edit your infra-as-code as usual, and let the agent check the change against Joe’s live view of prod before it ships.
Governed by construction
Joe’s safety model is not a system prompt, a confirmation dialog, or a hand-maintained list of dangerous commands. If Joe is running, Joe is governed: every tool call passes through one seam — write floor, incident state, RBAC — enforced in code before a tool ever dispatches, not by asking the model to behave. The same rules apply whether a request arrives over the web UI, MCP, or the REST API.
Joe ships in observation mode today — the write floor boots read-only and nothing short of a restart can lower it — but the seam is built for what comes next. Full-capabilities mode with deny-by-default mutation and zoned RBAC add what passes through the seam, not whether it is checked.
The guarded accessor seam
Every tool executes server-side, in-process, through one guarded accessor. There is no local or remote tool-execution path — the seam is where authorization and audit live, identical across every front-end.
A layered safety model
A boot-resolved write floor, binary read/mutate classification with deny-by-default, an append-only audit log at the enforcement point, and a deny-only incident gate — checked before dispatch in a fixed precedence. Zoned RBAC adds per-zone access when full mode lands.
What’s in the box
One self-hosted binary
Joe is a single Go binary you run yourself. The agentic loop, the LLM adapter, the infrastructure graph, and the safety layer live in one process, executing server-side.
A live infrastructure graph
Joe maintains a live graph of your infrastructure — components, relationships, state — refreshed on a continuous background loop and persisted across restarts. Questions that span systems — what feeds this service’s metrics, where it stores its data, what manages its deploys — are single graph queries, not answers stitched from one-off calls.
Native tools
Joe’s tools are typed, in-process API clients — Kubernetes through client-go, observability backends and datastores through their native APIs. No adapter or tool shells out to kubectl or subprocess CLIs, so there is no ambient kubeconfig to inherit and no command string to inject into.
Multi-user, SSO ready
Joe is built for teams: sign-in plugs into your identity provider over OIDC, every request runs as an authenticated principal, and sessions are shared team-wide like pull requests — anyone can read, only the owner edits.
Control your LLM spend
Hard budgets, not dashboards after the fact. Set hourly, daily, and monthly limits — an over-budget call is refused before it reaches the provider, audited, and costs nothing. A per-task runaway ceiling stops a looping agent mid-flight. Usage is visible per model, per principal, per session — or run a local model and spend nothing at all.
Agent skills
Installable bundles of operational know-how that Joe loads from ~/.joe/skills/ and manages with the joe skills subcommand. New installs land quarantined until approved — Joe’s knowledge grows under the same approval discipline as everything else.
Evaluated against OASIS
Joe is evaluated by OASIS, an external safety-intelligence harness, against the Software Infrastructure Profile. The methodology treats safety as a gate, not a score: assertions are binary with no partial credit, one safety failure vetoes the evaluation, and verdicts come from deterministic evaluators that verify real system state — no language model in the verification loop. The full safety suite has been executed against Joe end-to-end on a live Kubernetes cluster; the published verdict lands with the OASIS v1.0 reference evaluations.