Muteki: a shared-blackboard swarm for CTF and offensive security automation

The dead-loop problem Muteki was built around

The README states the motivation plainly: a single AI agent working toward a goal "very easily falls into a dead-loop at one spot", cannot extract itself, and never reaches the target. The author also calls a single agent "extremely inefficient". Muteki is the answer to that specific failure, not a general agent framework with a security theme bolted on. The intended user is someone running CTF challenges or authorised penetration tests who already pays for more than one coding agent and wants them working the same problem at once. If you run one agent and it finishes your tasks, this project adds coordination overhead for no gain. The scope claim in the README goes beyond CTF: the author describes the architecture as goal-driven multi-agent collaboration for penetration testing, code auditing and cybersecurity work generally, with CTF as the baseline capability.

Heterogeneous workers on one blackboard

Muteki points several different coding agents at the same challenge and gives them a shared blackboard. The README names the current worker engines: Claude, Codex, Cursor, Pi, OMP, Kimi, Grok, OpenCode and DeepSeek Harness. The design bet is stated directly: the core is not "swap in a smarter brain" but heterogeneity plus shared evidence plus a provenance gate. Facts one worker discovers become usable by the others. Dead ends one worker walks are not retried by the rest. That second property is the more interesting one, because it depends on workers actually writing failure records rather than silently abandoning an approach. The README does not describe how a dead end is recorded, how long it stays on the blackboard, or what happens when two workers disagree about whether a path is exhausted. Those are the questions I would want answered in docs/工作原理.md before trusting the coordination layer.

The flag gate and the muteki-blackboard skill

A flag is accepted only when it appears verbatim in real execution output. That is the provenance gate, and it is the strongest design decision visible in the material: it removes the most common failure of LLM security agents, which is a model asserting a flag it inferred rather than observed. The data channel is equally specific. Workers talk to the blackboard through the muteki-blackboard skill, described as built into every worker and as "the only data channel between a worker and the blackboard". The consequence is a hard dependency. A worker without that skill installed cannot publish findings or read teammates' progress, so it degrades into a standalone agent and the swarm loses its point. The README does not document the skill's interface, so how a worker writes a fact, and what schema the blackboard enforces, has to be read out of the repository.

Install and run: what the README actually specifies

The concrete requirements in the material are narrow. Python 3.13 or newer, per the badge. AGPL-3.0, per the licence badge and the LICENSE link. Nine CLI agent engines that must be present as working CLIs before the swarm has anything to drive. Beyond that, the README as supplied does not give a pip install line, a uv command, a Docker invocation, or a sample config file. It points to docs/工作原理.md for architecture and to SECURITY.md for the trust boundary, and it shows release tags v0.3.0 through v0.3.2 dated 2026-08-20 to 2026-08-22. Anyone evaluating this should treat the missing install path as the first thing to check in the repository rather than something this article can supply. The README does contain one operational instruction worth repeating: run it in a dedicated, disposable environment, such as a dedicated VPS, a throwaway VM, or a standalone machine with no sensitive data, and not on your main workstation, a shared host, or production.

The trust boundary the author states himself

Muteki drives CLI agents to execute commands, invoke security tools and reach target services. The README says it does not promise to isolate malicious challenges. That is the central limitation, and it comes from the project rather than from a reviewer. A CTF challenge is untrusted input that the agent will act on with whatever privileges the host grants. The author then notes that he personally runs it on his own computer anyway because it is more convenient, which is honest but also tells you the recommended isolation is advice, not an enforced property. There is no sandbox described in the material, no container boundary, no seccomp profile, no network egress policy. If your threat model includes a challenge that tries to escape, corrupt the host, or exfiltrate, the README offers you a VM and nothing more. Multi-agent coordination also multiplies blast radius: nine agents executing commands is nine times the surface of one, and the blackboard is a shared channel through which one compromised worker's output reaches the rest.

Benchmark claims and what they are worth

The README carries a badge reading NYU CTF Bench 200/200 solved and states that full evaluation results appear at the end of the document, though that portion is not present in the supplied text. It also reports RIFFHACK 2026: three hours fully automated with zero human takeover, every challenge solved, 8th place. And a penetration-testing range called blackmaze on iChunQiu Yunjing, described as having zero solves for three months, where Muteki took first blood in two hours, with the platform showing 39 hours because of debugging and multi-flag mode work. These are the author's own reported results, published without an accompanying methodology in the material I have. There is no statement of how many attempts were made, what the baseline single-agent score was, or how the NYU CTF Bench was configured. Treat the numbers as claims to reproduce, not as measured properties. The 8th place finish is the most concrete of them, because a competition placement is externally observable.

Where a single-agent harness wins instead

The obvious alternative is a single coding agent with a shell tool, driven by a human who reads its output and redirects it when it stalls. That is what most people doing CTF with an LLM do today, and it has one advantage Muteki cannot match: the human is the blackboard. A person notices the agent looping and changes the prompt, which is exactly the intervention the README identifies as necessary. Muteki replaces that human with cross-agent evidence sharing, which only pays off if the workers genuinely diverge in approach. Point nine instances of the same model at a challenge and you have paid nine times the token cost for correlated failures. The heterogeneity is the mechanism, and it is also the cost: nine CLI subscriptions or API keys, nine sets of credentials on one host, and a coordination layer that has to be debugged when it misbehaves. A single-agent harness is the better tool when you are solving one challenge interactively, when you only have access to one model, or when the target environment cannot be isolated.

Licence, maintenance and upgrade cost

Muteki is AGPL-3.0. If you run a modified version as a network service, the licence's source-disclosure obligation is the part to read carefully, and that is a question for your own counsel rather than for this article. The project is not archived and last saw a push on 2026-08-27, with three releases in the two days before that, so the release cadence is currently fast. Fast cadence in an agent project usually means the worker adapters are chasing CLI changes upstream, because each of the nine engines is an external tool with its own interface. That is the real maintenance cost: you are not maintaining one integration, you are maintaining nine, and a breaking change in any single CLI can take a worker out of the swarm. The README's closing note that the author will "keep iterating and upgrading" the architecture is consistent with that. Pin a release, expect adapter churn, and check the changelog before upgrading if a specific engine matters to your setup.

Editorial conclusion

Adopt Muteki if you already hold API access or subscriptions for several of the nine supported CLI agents and you have a throwaway VM or VPS to point at CTF challenges or an authorised range. Do not adopt it as a general-purpose coding assistant, and do not run it on a workstation that holds credentials or client data, because the README states it does not promise to isolate malicious challenges. Before you commit, verify three things against the repository itself: that the nine engine names in the badge match the adapter modules actually present, that the muteki-blackboard skill is installed into each worker's own skill directory rather than only referenced in docs, and that the provenance gate compares flags against captured execution output rather than against model claims. If the blackboard skill is missing from a worker, that worker is isolated and the heterogeneity argument collapses.

Official sources

1. FishCodeTech/muteki on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases