Multi-agent topologies are the default pattern in agentic pentest systems. We built one, measured it, and removed most of it. Across our measured runs, one agent in a purpose-built harness cut cost by about half and run time by up to 68%, with the same findings.
Every handoff between agents drops context. Current models can manage the whole task. A split across agents then costs more than it saves.
The outcome
Two tasks from our measured runs. Single agent compared with the subagent topology.
The orchestrator-subagent topology
We built the harness on a Deep Agents pattern. An orchestrator held a planning tool, a shared virtual file system, skills, and a set of subagents. Each subagent owned one phase: reconnaissance, live probing, source analysis, or record writes. Each subagent had its own system prompt, tools, and skills. The orchestrator routed work. Subagents exchanged state through files.
The topology was easy to audit. Small context windows. Narrow tool sets. One controlled path for writes. It also put a handoff between every phase.
The alternative is a single-loop topology. One agent plans, calls tools, reads the results, and decides the next step in one context. No handoff. No summary that can drop detail. The trade-off is a larger context window and fewer built-in boundaries between phases. Subagents still earn their place in three cases. A verifier can check work without seeing how another agent did it. Each parallel task can run in a fresh context and discard that context at the end. A subagent can hold permissions that the main agent does not have.
Measure first, then optimize
We did not pick a topology by taste. We treated the shape of the agent as a decision variable in an optimization problem.
The decision was discrete: keep a subagent split, or fold that work into the main loop. The setting was a cell of task type, model, and target environment. The objective was a vector, not a scalar: cost, wall-clock time, and task quality. Quality had a constraint. The folded design had to match the baseline findings, or beat them. We did not collapse those scores into one average. An average hides the cell where a topology fails.
We then ran an optimization search over those cells. For each cell we scored both topologies, kept the vector, and selected the design on the trade-off we care about: lower cost and lower time, with quality at least as high as the split. We also measured variance across environments. The same task behaves differently against an API with partial introspection, an application behind a WAF, or a test tenant with an unreachable backend. The subagent topology failed where responses were partial or noisy, because that is where summaries drop detail.
The model is part of the optimum. Subagents help a model that cannot hold the whole task in one context. Current models can hold it, so the handoff cost dominates. For our pentest agents, including ambient runs that proceed without a user turn, the selected design is one agent.
One agent, a precise harness
The optimization results supported a single-agent architecture, so we rebuilt the harness around it. Four rules shaped the new harness:
- One tool catalog. No agent owns a tool. The agent sees a short description of each tool and loads its full definition on demand.
- Procedures as skills. We cut the system prompt by about 80% and moved procedures into skills that load when the task needs them.
- Hard limits in code. Write tools stay hidden until the agent has evidence from a live test. Record writes require that evidence.
- Splits only for blind work. Agent-written code passes a fixed set of checks before it runs. A separate judge rules on each attack result. Both must stay blind to the conversation. All other work runs in one context.
Deferred tool loading makes one large catalog practical, but it does not explain the speed. In early tests, deferral alone slowed the first model call because it worked against the prompt cache. The gains below come from removing handoffs.
Evaluation 1: eliminating evidence compaction during subagent handoff
Task: recalculate the CVSS severity of an excessive-data-exposure finding.
Subagent topology. The orchestrator delegated the rescore. The first subagent returned a summary without the score. The orchestrator then tried to call the scoring tools itself, but another subagent owned them, so it delegated a second time. The second subagent returned a score but could not say if the confidentiality impact was low or high. No agent in the chain read the evidence that settles the question.
Single agent. The agent loaded the scoring tools and read the finding and its saved HTTP evidence in one context. It saw that the exposed records stayed within one tenant. It returned the same score with that reason, and named the one fact that would raise it. The score did not change, but evidence now supports it.
Evaluation 2: eliminating redundancy during multi-agent orchestration
Task: probe a GraphQL endpoint for unauthenticated data access.
Subagent topology. Reconnaissance returned an empty summary because introspection was partial. The probing subagent returned a truncated summary. The orchestrator reread the raw HTTP files itself and found two resolvers that leaked tenant data with no credentials. Source analysis then found a resolver that issued a presigned file-storage URL with no auth check. The orchestrator connected that code finding to a new live probe. It was the strongest step in the run, and it happened in the only context that saw both results.
Single agent. The agent saw the partial introspection and changed its plan in the same turn. It found the same two resolvers, searched the code, found the same presigned-URL resolver, and probed it immediately. The storage backend was unreachable in the test environment, and the agent reported that as a test limit. The agent found the same issues and did not repeat any work.
Ambient runs make this gap larger. There is no user in the loop to notice a dropped detail and ask again. If the summary is lossy, the rest of the run proceeds on the loss.
Three areas where multi-agent loops fail and single-agent loops excel
Tool ownership forces a routing guess. When a subagent owns a tool, the agent that manages the run must guess whom to ask. A shared catalog removes the guess.
Summaries drop the detail the next step needs. Three of our handoffs returned a condensed summary of what the subagent saw. Each summary lost a large part of the information. Each time, the next step had to detect the gap and recover the raw data.
The planner must also execute. An agent that plans and acts can change the plan when a result arrives. An orchestrator that waits on a subagent cannot do that.
Design for context, not for roles
We started with a specialist for each phase because that is how teams are drawn. We then scored that design against a single loop, cell by cell: task, model, environment. Cost, time, and quality stayed a vector. We did not average them. The search selected one agent for the work that shares context, and a subagent only where blindness, permissions, or parallelism require a wall. That is the rule we now use. Design the loop for the context the next step needs. Do not design it to match the org chart.
