Part 4 of Industrializing Security Research .
The earlier parts established three constraints:
This post covers the execution engine I used to make those constraints concrete.
My first test of the shift, on early March, was deliberately boring. Two dockerized Claude agents read the same project README and committed summaries. A post-processing agent then reviewed the result.
No vulnerabilities. No heroic prompt. Just a test that proved the containers could start, the agents could work independently, Git coordination held up, and the output could be harvested.
It was the multi-agent version of an ice-breaker test . Once that path worked, I replaced the summaries with security objectives and started increasing the pressure.
At the interactive skills-suite stage , I only knew that I needed stable research identities and fresh context for triage. claude-swarm came with much more: Git synchronization, repeated sessions, retries, cost tracking, dashboards, and more.
It looked excessive. Then I used all of it.
The skills suite had exposed the first constraints. Sustained operation exposed the rest.
claude-swarm removes the coordinator from the leader-and-workers topology described in Part 2 . It runs coding agents in isolated Docker containers. The host creates a bare Git repository from the project. Every agent gets its own workspace, but all of them push to the shared repository.
Each agent then runs a simple loop:
When one agent publishes useful work, the others see it on a later iteration. They can extend it, challenge it, or avoid repeating it. If two agents collide, Git makes the conflict visible instead of silently choosing a winner.
The tool also implements the research-and-triage boundary from Part 3 . Post-processing runs as a separate agent and context by design . It receives committed research, not the researchers’ accumulated conversations. The host then harvests the agent branches back into the project.
The agents do not need to remember previous sessions. The durable memory is the Git history.
Part 1 defined repeatability as applying the intended research technique across runs . Isolation turns that requirement into an execution boundary.
They receive separate prompts and contexts. Their committed work becomes shared context through Git, without a leader redirecting them into different jobs.
This matters because security research produces overlap. Two agents may find the same root cause through different paths. One may find a plausible bug while another finds the guard that kills it. Keeping both lines attributable makes later review much easier.
The dashboard keeps agent status, sessions, tokens, cache use, throughput, duration, and cost visible. Commits record the model, tool version, run, prompt, and context that produced them.
claude-swarm does not prescribe a research process. It provides composable execution pieces:
The consumer decides how to arrange them: agent identities, prompts, targets, revisions, scheduling, triage policy, and publication.
In my deployment, I used those pieces to build scheduled research, full and diff modes, target rotation, conditional triage, and publication. Those are properties of the consumer layer, not claude-swarm. Later posts will cover how they work.
The same boundary let the engine move beyond its historical name. The driver layer now supports Claude Code, Codex CLI, Gemini CLI, Kimi Code, and Qwen Code.
The security-specific consumer layer defines the threat model, evidence bar, prior-art archive, and final authority. I built that layer around the engine. It became the Swarm Standard.
In roughly six months, my deployment crossed:
Almost every candidate went through separate post-processing. A candidate report is not a vulnerability. Many are duplicates, weak claims, invalid threat models, or real defects with overstated impact. Independent triage matters more as raw output grows .
These are not quality metrics or a benchmark. They show the industrialization level: research running repeatedly across targets, producing enough material that session-by-session handling no longer works.
Nikos Baxevanis started claude-swarm as part of the EF Protocol Security team and led most of its development. It gave us an engine to build on, so we could focus on the security process.
Thanks to Nikos and everyone at Protocol Security for open-sourcing the tool!
I am very happy to have since joined the team.