Home / Self-hosted AI agent control plane

Comparison

Self-hosted AI agent control plane for knowledge work (not coding tasks)

A self-hosted AI agent control plane is the dashboard, approval queue, and audit layer that sits above your agent runtimes — Claude Code, Codex, OpenClaw, Hermes — and answers the operator’s question: who owns this task, what shipped, where did the spend go, and where does the human step in. Between February and August 2026, at least twelve open-source products shipped under that exact category vocabulary, and every one is built for coding-agent fleets on a kanban of tasks that closes when a PR merges.^[1] This page names that crowding honestly, points you at whichever of the twelve fits if the shape of your work is coding, and makes the case for a different object model — loop-on-typed-objects — when the shape of your work is product decisions rather than commits.

What a self-hosted AI agent control plane actually is

A year ago, “agent control plane” was vendor-brochure vocabulary. In 2026 it named a real product shape, and the SERP now supplies twelve open-source implementations of the same picture. The shared surface, across every entrant, has four pieces:

1. A dashboard that shows which agents are running, on what, and with what budget left.
2. An approval queue — the human-on-the-loop interrupt surface, sometimes called an inbox, sometimes a review pane.
3. An audit log — an append-only record of what the agents did, so a failed run is a visible state rather than silence.
4. A runtime harness — Docker, Podman, or Kubernetes containers that host the underlying agent CLIs (Claude Code, Codex, OpenClaw, Hermes) with sandbox isolation and secrets injection.

That is the whole shape. Every product on the list ships it, differing mostly on which runtime they treat as primary, how heavy the container model is, and whether they hide the plumbing behind a web UI or a TUI. If your buying question is “which one of these dashboards do I install?” the honest answer is that any of them will do the job at a similar quality bar. Pick on the runtime you already run, the license that matches your compliance, and the maintainer velocity you trust.

The twelve open-source entrants, by shape

Here is the full 2026 field, grouped by the shape they optimise for. Every one is self-hostable and open-source; every one converges on the same vocabulary. Source and license notes are compiled from a validated internal survey of the twelve entrants, last checked 2026-09-02.

Coding-agent fleet managers (multi-CLI, container-per-agent):

• Crewship — Apache-2.0, Docker-per-crew, Go binary, targets Claude Code / Codex / Gemini / OpenCode / Ollama.
• amux — Rust binary, kanban + REST API + iOS PWA, positions explicitly as “the agent control plane.”
• Nora — Apache-2.0, targets OpenClaw + Hermes on Docker/K8s, ships its own MCP server.
• Zoink — multi-framework swarms with TUI + web dashboard, mixes OpenClaw and Hermes.
• herdctl — Claude Code fleet manager with cron triggers and Slack/Discord chat.
• danrex/fleet — bash + Docker + git, coordinator-free, one branch per task.

Enterprise-shaped platforms (MCP firewalls, model gateways, RBAC):

• Preloop — Apache-2.0, MCP firewall + model gateway + human approvals + observability, pitched as “the open-source alternative to AWS Bedrock AgentCore.”^[2]
• Clawix — Docker-isolated agents, swarm DAGs, RBAC, multi-channel (Telegram / WhatsApp / Slack).
• Musematic — Kubernetes-native, Python control plane with Go satellites.

Local-first / air-gapped:

• Vornik — AGPL-3, local-first daemon, air-gapped, Podman containers.
• Mission Control — SQLite-backed, task inbox with an “Aegis” quality gate.

Solopreneur / one-operator design language:

• VNX — Vincent van Deth’s open-source governance layer: human approval gates, append-only audit trails, evidence-based task closure. Explicitly rejects enterprise-multi-tenant patterns.

Every one of these is a legitimate answer to “install a control plane above my coding agents.” If that is the shape of your work, click through, read the readme, pick the one whose runtime and license fit your setup, and stop reading here.

What every entrant assumes (and where that assumption breaks)

Read the twelve readmes side by side and one assumption is invariant: the unit of work is a coding task, and the loop closes when a pull request merges. That coding-first framing is only one slice of the wider OSS agent field — stateful-agent frameworks, workflow-node builders (see the n8n alternative page for that shape), RAG chat frontends, and coding-agent control planes are four distinct shapes, and the field survey of self-hosted AI agent repos walks the split honestly. The dashboards look different, the container models differ, the license notices are Apache-2.0 or AGPL, but the object model beneath is uniformly a kanban of coding tasks, ordered by priority, executed by a coding-agent CLI, closed by a merged commit.

That fits the SERP that produced them. The demand behind “self-hosted AI agent control plane” is heavily developer-led, and coding agents are the runtime with the clearest per-task boundary — the model runs, the diff appears, CI passes or fails, the human approves the PR, the task closes. It is a legible loop.

It is not the only loop teams run. Product work has a different shape:

• The trigger is not a Jira ticket — it is a customer message, a churn signal, a competitor move, a stalled deal, a metric drifting. The signal enters continuously and needs to be captured as a first-class object, not as a note that gets pasted into a task title. That ticket-model-versus-loop-model cut is the open source Jira alternative comparison in full.
• The task graph is not flat. An insight informs a bet; a bet breaks into tasks; a task blocks or unblocks another; a shipped outcome either validates or contradicts the insight that seeded it. Kanban lanes flatten that graph into columns, which is what a lane view is for and why it fails at this.
• The close condition is not a PR merge. A product bet closes when the outcome is measured against the hypothesis. “Shipped” is a milestone, not the terminus.
• The audit trail is not a list of commits. It is the trace from insight to validated outcome — what was learned, what was decided, what was tried, what held.

If your team is one engineer running four coding agents against a repo, none of that matters. If your team is running the loop from customer signal to shipped-and-validated outcome, the whole surface — dashboard, approval queue, audit log — needs to sit above a different object model. That is the split the SERP does not yet name.

The wedge: loop-on-typed-objects, not kanban-of-coding-tasks

Maskin sits in the same category on the four table-stakes commodities — Apache-2.0, self-hostable, MCP-native, approval-first — and diverges on the object model. Concretely:

• The insight is the first-class capture of a signal. It has a source, a confidence, and a status (raw, clustered, validated). Agents raise insights on triggers; humans reshape them.
• The bet is a testable hypothesis, jointly owned by a human and agents, with a close condition and a promote gate. A bet knows the insight that seeded it, the tasks that break it down, and the outcome that resolved it.
• The task is the execution unit — the level at which a coding-agent CLI, an integration call, or a human hand-off happens. Same shape as the kanban card in every other product on the list, but attached to the bet that motivates it and the insight that motivates that.
• The loop is the closed thread from signal to validated outcome — the object that closes, not the task. The close_condition lives on the loop, not on any single task.
• Typed relationships (informs, breaks_into, blocks, supersedes, contradicts) carry context between objects, so an agent reading a task sees the bet it belongs to and the insight that motivated it without extra prompting. That is what a graph does that a kanban cannot.

The practical result is that the approval queue is a queue of bets to promote and outcomes to validate, not a queue of tasks to unblock; the audit log is the graph’s own history; the dashboard is a workspace surface, not a lane view. Agents mutate the graph, humans reshape it — the ambient agent workspace page walks the same object-model split against note-taking tools, and the full docs carry the object-model spec end to end.

One caveat, said honestly: this distinction is architecturally real but the SERP does not yet name it. Every one of the twelve entrants above is delivering value inside the shape they chose; Maskin is delivering it in a different shape. Readers won’t infer the split from a shared feature list — this page’s job is to make the split legible, not to claim superiority on the table-stakes commodities.

The chat-as-primary counter-frame (worth taking seriously)

The strongest case against the workspace-graph pattern isn’t from any of the enterprise entrants — it’s from Vincent van Deth, the current authority voice on the solopreneur / one-operator sub-JTBD. Van Deth built VNX after his combined agent LLM bill hit $2,847/month for eleven agents, rebuilt for $370/month, and published five design principles in the process: chat as primary interface, receipts as canonical state, asymmetric autonomy, two-path human approval, context rotation as architecture.

His chat-as-primary read is the honest challenge. At n=1 with a handful of agents, a well-designed chat that speaks to every agent is more legible than a dashboard-per-workflow. The whole point of a shared typed object model is that it scales work across humans and parallel loops; n=1 doesn’t need that scaling, and the coordination overhead of a shared graph doesn’t pay off until you have more than one human on the taste gates or enough loops that the queue itself becomes the bottleneck.

The graph earns its keep on three signals, all absent at true solo scale:

1. Multiple humans need to see the same state — product, engineering, and support looking at the same bet.
2. A single loop spans hours to days and hands off between agents (customer feedback → clustered insight → shaped bet → executed tasks → validated outcome).
3. The number of parallel loops crosses the point where a queue becomes untriageable — thirty open bets across five product areas is not a queue you scroll through.

If you’re one person shipping features with two or three coding agents, van Deth is likely right for you: chat-as-primary plus receipts-as-state is the smaller, cleaner stack. If your team is more than one person shipping outcomes, or one person coordinating enough parallel loops that triage is now the work, the graph starts to pay for itself. Neither pattern is universal, and the honest frame is which condition holds at your scale.^[3]

How the shapes actually compare

Because the twelve entrants are so uniform on the commodities, the comparison that matters is on the object model — which is the only row that separates the field.

Every row above the last is a real difference. The last row is the buying question: which shape is your work?

Which of the twelve (or the thirteenth) should you pick?

• If the work is coding and the team is small, pick a coding-agent fleet manager whose runtime matches yours. Crewship if you’re multi-CLI. amux if you want a Rust binary and REST API. herdctl if you’re all-in on Claude Code. danrex/fleet if you want the lightest possible thing.
• If the work is coding and the compliance/policy weight is heavy, pick an enterprise-shaped platform. Preloop if you want the MCP firewall and model gateway shape most aligned to the AgentCore-style reference. Clawix if you need RBAC and multi-channel escalation. Musematic if you’re Kubernetes-native and want the Python control plane.
• If the constraint is air-gap or compliance, Vornik (AGPL-3, Podman) is the cleanest local-first pick. Mission Control if you want SQLite-backed and self-contained.
• If you’re one operator with a handful of agents, VNX plus Van Deth’s design language is the honest fit — chat-as-primary earns its keep at solo scale, and the receipts-as-state pattern is battle-tested at that N.
• If the work is a product-decision loop that carries state across humans and hand-offs, none of the twelve is the shape. Maskin is what a control plane looks like when the object model is a loop on typed objects rather than a kanban of coding tasks. The ambient agent workspace page covers the UX shape of the same object model.

For the adjacent “which self-hosted coding-agent platform do I install?” question specifically, see the open source Codex alternative page. If the question sits one layer down, which single coding runtime to install rather than which control plane to run, the open-source AI coding agent shortlist separates the runtimes from the control planes on this page. For the tracker question underneath — Jira, Linear — see the open source Jira alternative page. Or start from the hub and see all open-source alternatives to closed agent control planes and the adjacent categories.

FAQ

What is an AI agent control plane?

The dashboard, approval queue, and audit layer that sits above your agent runtimes and answers who owns which task, what shipped, where the spend went, and where a human needs to step in. In 2026 the term stabilised on that four-piece shape (dashboard, approvals, audit, container harness) and the twelve open-source products above all implement variants of it.

How is a control plane different from an agent framework?

A framework (LangChain, LlamaIndex, Autogen) is the library you use to build an agent. A control plane is the operations layer you install above one or more agents to run them in production — the queue, the log, the sandbox, the approval surface. Every one of the twelve entrants above assumes you have chosen the framework or CLI already; they orchestrate the runtime, they don’t replace it.

Is self-hosting really free?

For the twelve open-source entrants above and for Maskin, the software cost is zero — self-host is free forever under the license. You pay for the underlying infrastructure (Docker host, K8s cluster, storage) and for the model calls the agents make. Van Deth’s cost breakdown ($2,847/month at eleven agents before optimisation, $370/month after) is the most concrete public number on real-world model spend at that scale.

Do I need MCP support?

If your agents call multiple tools, yes — MCP is the standard the industry converged on in 2026 for tool interop, and Preloop, Nora, and Maskin all treat it as first-class. If your agents only call one CLI (e.g. Claude Code with its own tool set), MCP support is less urgent. It is a commodity table-stake on the SERP, though; if a product on the list doesn’t ship it, that’s the outlier.

How is Maskin different from Preloop, since both are MCP-native and Apache-2.0?

Preloop is a control plane above coding agents, with an MCP firewall and model gateway as the headline surfaces. The object model is a coding task; the close condition is a PR merged with policy pass. Maskin is a control plane above knowledge-work agents, with a typed object graph (insight → bet → task → loop) as the substrate. The close condition is on the loop, not on any single task. Both are legitimate; they optimise for different shapes of work.

Is Maskin mature enough to bet on?

Early and honestly so. Public traction is modest — the project is Apache-2.0 with a small maintainer team and an actively-shipped roadmap. What Maskin offers today is the architectural position (loop-on-typed-objects, MCP-native, self-hostable, approval-first) rather than the maturity of a vendor-hosted incumbent. If your evaluation criterion is a proven track record, weigh that against your appetite for shaping the category. If your evaluation criterion is the shape of the object model, that value holds regardless of star count.

How do I know if my work is coding-shaped or product-shaped?

A rough test: if every task in your queue ends in a merged PR, your work is coding-shaped and any of the twelve fits. If your tasks end in a decision, a shipped feature that needs measurement, a customer notified, or an insight validated against outcome data, the shape is product work — and the object model beneath the queue matters more than the queue itself.

Own the loop, not the coding-task queue

If your team’s work is a coding-agent fleet, one of the twelve open-source control planes above is the right answer and this page is not for you. If your team’s work is a product-decision loop that runs from customer signal to validated outcome, the control plane you need sits above a different object model — typed insights, bets, tasks, and loops instead of a kanban of coding tasks. That’s what Maskin is: open-source under Apache 2.0, self-hostable free forever, MCP-native, approval-first — same commodities the field has settled on, a fundamentally different shape of work. When you want that loop running against your own infrastructure, the AI-Native Loop Sprint delivers self-hostable loops, set up with you.

Sources

1. Validated internal survey of the twelve entrants — full list with primary sources per project, last validated 2026-09-02.
2. Preloop — preloop.ai and github.com/preloop/preloop. Apache-2.0, MCP firewall + model gateway + human approvals, pitched explicitly as “open-source alternative to AWS Bedrock AgentCore.”
3. Vincent van Deth — Designing an Agentic OS for Solopreneurs (May 2026) and The Real Cost of AI Agents in Production (March 2026). The five-principle framing (chat as primary, receipts as canonical state, asymmetric autonomy, two-path approval, context rotation) and the $2,847 → $370/month rebuild are from those pieces.