For most of Halo's life, it's been a single agent doing everything. One loop, one model, one context window juggling reconnaissance, exploitation, and self-correction all at once. That's worked well enough to get 24 tools integrated and a functioning failure cache scoped per engagement, but it's starting to show the seams you'd expect from any single-agent system asked to do too many jobs at once: the context gets crowded, the reasoning gets muddier the longer an engagement runs, and a mistake in one phase (say, a bad recon assumption) quietly poisons every phase after it.
The next major milestone for Halo is multi-agent orchestration, and I want to talk through the shape of it without turning this into a design doc.
Why Split It Up At All
A pentest isn't really one task. It's five or six distinct kinds of thinking stitched together: figuring out what to do, deciding who does it and in what order, actually doing it, finding weaknesses worth pursuing, and — critically — recognizing when something didn't work and correcting course. Right now Halo does all of that inside a single loop with one shared context. It works, but it means the "attacking" mindset and the "planning" mindset are fighting for the same mental real estate. Anyone who's tried to both execute a task and audit their own execution at the same time knows how that goes.
Splitting these responsibilities into separate agents means each one gets a smaller, more focused job and a context window that isn't polluted by concerns that belong somewhere else. It also means failures become easier to isolate. If an attack fails, that's a signal for the debugging agent, not something the planner has to untangle from a wall of tool output.
Five Agents, Five Jobs
Despite the "four agents" framing I started with, it's actually landing on five distinct roles:
The Planner. Takes the high-level engagement goal and breaks it into a sequence of objectives. This is the agent that thinks in terms of strategy rather than commands — what needs to be true before something else can happen, and what the overall shape of the engagement should look like.
The Orchestrator. Sits between the planner and everyone else, deciding which agent acts next and routing context between them. Think of it as the dispatcher — it's not doing the technical work itself, it's making sure the right specialist gets the right slice of information at the right time.
The Vulnerability Discovery agent. Focused entirely on finding things worth attacking. This is where scan output, enumeration results, and recon data get interpreted and turned into a prioritized list of weaknesses, rather than that interpretation happening as a side effect of whatever the attacking agent happens to be doing at the time.
The Attacker. Takes a specific, well-defined target and executes against it. This agent doesn't need to know the whole engagement plan — it needs a target, a method, and the tools to carry it out.
The Debugger. Watches for failure. When an attack doesn't land, or a tool call errors out, or something looks off, this agent's job is to figure out why and feed that understanding back into the system — ideally back into the failure cache that already exists, so the same mistake doesn't get repeated three engagements from now.
What This Isn't (Yet)
I'm intentionally not getting into message-passing formats, shared state, or how these agents will actually talk to each other here — that's architecture-sketch territory, and it's still being sketched. What I can say is that this is a sketch-first approach: get the roles and boundaries right on paper before writing a line of orchestration code. It's tempting to jump straight into building when you're excited about a design, but multi-agent systems are exactly the kind of thing where a wrong boundary early on gets expensive to unwind later.
Why This Matters for Where Halo Is Headed
The honest reason this split matters is that a single-agent pentester hits a ceiling. It can only hold so much context, reason about so many concerns at once, and recover from so many of its own mistakes before the whole loop needs a reset. Specialized agents with clear responsibilities and a coordinator managing the handoffs is how you get an autonomous system that can run longer, fail more gracefully, and actually improve over time instead of just repeating the same loop with a slightly bigger tool list.
This is very much a "next chapter" post rather than a "here's what shipped" post. But the shift from one agent doing five jobs to five agents doing one job each is the biggest architectural change Halo has seen since the original MCP server. We hope to provide as much transparency as we are able to so that the public can follow along on this journey as we progress.
Top comments (0)