Fireteam Parallel Specialists
The Fireteam is RedAmon's mechanism for fanning out the AI Agent into N specialist sub-agents that investigate independent angles of the same target in parallel, then merge their findings back into a single consolidated chat surface. It turns what would normally be a sequential investigation ("first map the auth surface, then the route map, then the security headers") into a concurrent one — three specialists working at the same time on the same target, each with its own focused mission, each pausing for your approval on its own dangerous tools, all visible in one unified card on your screen.
This page explains how to enable Fireteam, what every project setting controls, and what you actually see in the chat when a fan-out is in flight.
Architecture deep dive. This page is the operator-facing guide — what the buttons do, what the settings control, what the cards mean. For the architectural deep dive — the Scatter-Gather ReAct (SG-ReAct) pattern, the 5-node member subgraph, the per-member
asyncio.Eventconfirmation registry, the wave-completion merge logic, and the impartial benchmark against other ai pentesting repos — read the RedAmon Agentic System — Technical Whitepaper.
- What Fireteam Is (and What It Is Not)
- Project Settings — Every Parameter Explained
- Enabling and Configuring Fireteam
- What You See in the Chat
- How a Fireteam Wave Actually Runs
- When the Agent Chooses to Deploy a Fireteam
- Fireteam vs. Wave Execution vs. Sequential
- Safety Guarantees
- Stopping and Recovering a Wave
- Troubleshooting
A Fireteam is a bounded, parallel deployment of N specialist sub-agents that all run inside the same backend process, in the same asyncio event loop, against the same target. Each specialist gets its own focused mission ("Investigate the authentication surface", "Map the application routes", "Audit the security headers") and runs its own miniature ReAct loop — think, choose a tool, observe, repeat — independently of the others. When all specialists finish, their findings are merged back into the parent agent's worldview and the parent decides what to do next.
What Fireteam is not:
- Not a separate process or container. All members live inside the same agent backend. There is no inter-process coordination cost.
- Not unbounded. Every wave has a hard cap on member count, an iteration budget per member, and a wall-clock timeout — a fireteam cannot run forever.
- Not recursive. A fireteam member cannot itself deploy another fireteam. The fan-out is exactly one level deep.
- Not a way to bypass safety. Every guardrail that applies to the root agent also applies to every member — same scope rails, same Rules of Engagement, same dangerous-tool confirmations (handled per-member, in parallel).
- Not the same as Wave Runner. Wave Runner is one agent running multiple tools in parallel. Fireteam is multiple agents each running their own multi-step reasoning loops in parallel. See Fireteam vs. Wave Execution vs. Sequential for the comparison.
Fireteam is configured per-project in the Project Settings → AI Agent Behaviour → Fireteam section. Every parameter is documented below with its default value, the file it maps to in the agent code, and what the operator should expect when they change it.
| Parameter | Default | What it does | Operational consequence |
|---|---|---|---|
| Fireteam Enabled | true |
Master on/off switch. When OFF, the deploy_fireteam action is stripped from the agent's vocabulary entirely — the agent literally never sees it as an option in the prompt. |
Switch off when you want to force the agent to stay sequential (cost-sensitive engagements, debugging, or when you specifically want every step visible without parallel branches). |
| Max Concurrent | 5 |
Maximum number of specialist members that can be actively running at the same time inside a wave. Implemented as an asyncio.Semaphore — if you deploy 8 members and Max Concurrent is 5, three will queue until a slot opens. |
Lower this when your LLM provider has tight rate limits or when you want to keep the visual surface manageable. Higher values shorten wall-clock time on large waves. |
| Max Members | 5 |
Hard cap on the number of members per wave. Even if the agent's plan emits more, the deploy node truncates to this number. | This is your safety ceiling. Raising it increases cost potential per wave linearly. Lower it to keep waves predictable. |
| Member Max Iterations | 20 |
Per-member ReAct iteration budget. Each member can think → act up to this many times before being forced to complete with status partial. |
Lower this for cheap/fast members; raise it when each specialist needs to do more reasoning before reporting back. The root agent's Max Iterations is independent. |
| Wave Timeout (seconds) |
1800 (30 min) |
Wall-clock ceiling on the entire wave — applied to the asyncio.gather over all members. When it fires, every still-running member is cancelled with reject signals propagated to any pending confirmation, and the wave is marked timeout. |
Tune to your engagement profile. A recon-only wave can be 600s; a wave that includes long Metasploit exploits may need 3600s or more. |
| Confirmation Timeout (seconds) |
600 (10 min) |
How long a member waits for your approval on its dangerous-tool request before auto-rejecting. The member then either picks a different tool or completes with a rejection note. | Raise this when you may step away for long stretches; lower it when you want unattended waves to fail-fast rather than hold member slots open. |
| Allowed Phases | [informational, exploitation, post_exploitation] |
The engagement phases in which the agent is allowed to deploy a fireteam at all. If the current phase is not in this list, the deploy_fireteam action is stripped from the prompt regardless of the Enabled toggle. |
Restrict to informational only when you want parallelism for fast recon but strictly sequential operation during active exploitation. |
Where this maps in the code. Every setting above corresponds to a
FIRETEAM_*key inagentic/project_settings.pyand is consumed insideagentic/orchestrator_helpers/nodes/fireteam_deploy_node.py. See the whitepaper for the full mechanism.
- Open your project in the Red Zone.
- Click Project Settings (gear icon, top-right of the project bar).
- Open the AI Agent Behaviour tab.
- Scroll to the Fireteam section.
- Toggle Fireteam Enabled ON.
- Adjust the seven parameters to match your engagement profile (see the table above).
- Save. The settings take effect on the next agent message — any in-flight session continues with its previous configuration.
Recommended starting point for a typical web-app engagement: Enabled ON, Max Concurrent 3, Max Members 3, Member Iterations 15, Wave Timeout 900s, Confirmation Timeout 600s, Allowed Phases all three. This gives you 3-way parallelism on independent angles without overwhelming the chat surface.
When the agent decides that the current objective decomposes into independent investigation angles, it emits a deploy_fireteam decision and the chat surface shows a Fireteam Card. This is the primary visual element you will interact with during a wave.
The outer wrapper of the wave. Every member panel is nested inside it. The card shows:
- Wave header — "Fireteam — N specialists" with a status badge (Running, Success, Partial, Cancelled, Timeout).
- Wave timeline — a single horizontal bar showing how many members have completed vs. are still running.
- Wave-level events — the deploy event at the top, the merge / completion event at the bottom.
Each member is rendered as a specialist panel inside the wave card. All panels are visible simultaneously — they are not modals, not collapsed accordions, not tabs. You see all members' work in parallel because that is exactly how the work is happening.
A panel shows:
- Specialist name and mission — e.g. "Auth Hunter — investigate authentication surfaces".
- Status badge — Running (blue), Success (green), Partial (yellow), Cancelled (grey), Timeout (red), Error (red).
- Iteration counter — e.g. "sub-step 3/20" showing how many ReAct iterations this member has used.
- Latest thought — the most recent reasoning text the member emitted.
-
Tool execution cards — one per tool the member has run, with their outputs rendered inline (the same
ToolExecutionCardstyle as outside a fireteam, just nested inside the panel). -
Plan-wave subcards — if a member emitted a
plan_toolsdecision, the parallel tools inside that nested wave appear here.
This is the most distinctive part of the Fireteam UX. When a member wants to run a dangerous tool (anything in the dangerous-tools list — nmap, nuclei, metasploit, hydra, kali_shell, code execution, browser automation, etc.), the member does not exit and surface a global modal. Instead, the member parks inside its own panel on its own approval card, and you decide on each panel independently.
This means N members can be awaiting approvals simultaneously, and you can resolve them in any order. While Member A is paused waiting for your decision, Member B is still actively running its tools and Member C is already analysing its outputs. There is no global queue, no serialised approval dialog stack.
Each pending approval card shows:
- The tool name and its full arguments.
- The member's reasoning for why this tool is needed now.
- Allow and Deny buttons inline on the card.
- A countdown to the Confirmation Timeout — when it expires, the request auto-rejects.
When you click Allow, the member resumes inside the same panel, runs the tool, streams the output into a card on that same panel, and continues its loop. When you click Deny, the member receives a rejection message in its context, the agent reasons about it, and the member typically picks a different tool or completes.
Each badge has a specific meaning:
| Badge | Meaning |
|---|---|
| Running | Actively reasoning or executing a tool |
| Awaiting | Paused on a dangerous-tool approval |
| Success | Completed normally with action=complete
|
| Partial | Hit the iteration budget — findings preserved but task not fully done |
| Cancelled | You stopped the wave or the parent session |
| Timeout | The wave-level wall-clock timeout fired |
| Error | The member crashed (LLM error, tool executor crash) — other members continue |
Behind the scenes, every wave follows this lifecycle:
-
The root agent decides to deploy. During its normal ReAct loop, the root's think node sees an objective that decomposes into independent angles (auth surface, route map, header policy) and emits an
LLMDecisionwithaction=deploy_fireteamand afireteam_planlisting N members with their individual missions. -
The deploy node fans out. A dedicated
fireteam_deploy_nodebuilds one isolated state object per member (snapshotting the parent's target info, current phase, tenant ids, and the per-member skills + task) and creates oneasyncio.Taskper member running a stripped-down 5-node ReAct subgraph. Tasks are started under anasyncio.Semaphorecapped at Max Concurrent. - Members run in parallel. Each member thinks, picks a tool, runs it, observes, thinks again — all interleaving naturally on the single event loop. There is no inter-member communication; members are independent by design.
-
Dangerous tools park members. When a member's think emits a dangerous tool, instead of exiting the member parks on its own
asyncio.Eventinside an in-process registry. The pending-approval card appears on its panel. The other members keep running. - You resolve approvals in any order. Each Allow / Deny click wakes only the targeted member's Event. The member resumes in-place — no new card spawns, no panel is recreated.
-
Members complete. Each member exits with a status (
success,partial,timeout,cancelled,error) and reports back its accumulated findings, target-info delta, and final iteration count. -
The collect node merges. Once all members have exited (or the wave timeout fires), the
fireteam_collect_nodemerges every member'starget_infodelta into the parent'starget_info, appends every member's findings to the parent'schain_findings_memory(each tagged withsource_agentso the root knows which specialist produced what), and auto-completes any TODO items whose description matches a successful member's name. - The root resumes. Control returns to the root agent's think node, which sees an updated worldview and decides what to do next — typically writing a consolidated report or planning a follow-up step that builds on the merged findings.
The agent is trained (via prompt) to deploy a fireteam when all of the following hold:
- The current objective genuinely decomposes into two or more independent investigation angles (the angles do not depend on each other's outputs).
- Each angle requires its own multi-step reasoning rather than just a single tool call. (If the angles were just N parallel tool calls with shared analysis, the agent would emit
plan_toolsinstead — see the comparison below.) - Fireteam is enabled for the current project and the current phase is allowed.
- Deploying a fireteam would actually save wall-clock time vs. doing the angles sequentially.
Examples of objectives that typically trigger a fireteam:
- "Parallelize deep recon across auth surface, route map, and security headers on www.example.com" — three independent angles, each multi-step.
- "Triage these 5 candidate CVEs in parallel" — five independent angles, each requiring its own search → use → info → exploit reasoning.
- "Investigate the API endpoints while also analysing the JS bundle" — two independent angles, each needing iterative exploration.
Examples that do not trigger a fireteam:
-
"Scan ports on 10.0.0.5" — one angle, single tool call (sequential
use_tool). -
"Run nmap and httpx and naabu against the same target" — three parallel tool calls but they share an analysis (Wave Runner /
plan_tools, not fireteam).
The agent has three execution modes and chooses the right one based on the work shape:
| Mode | Action | Concurrency | Reasoning shape | When the agent uses it |
|---|---|---|---|---|
| Sequential | use_tool |
None | One agent, one tool at a time | Single-step actions, dependent chains where each step's output feeds the next |
| Wave Execution | plan_tools |
N tools in parallel | One agent, multiple tools, single combined analysis | Several independent tool calls that share an analysis (port scan + CVE lookup + service detection on the same target) |
| Fireteam | deploy_fireteam |
N agents × M tools each | N agents, each with their own ReAct loop | Several independent investigation angles where each needs its own multi-step reasoning |
Wave Execution is also documented in the whitepaper's Wave Execution chapter.
Every safety mechanism that applies to the root agent also applies to every fireteam member. Specifically:
-
Hard guardrail. The deterministic domain blocklist (
.gov,.mil,.edu,.int, intergovernmental orgs) runs once at session start on the parent and is inherited by every member — no member can scan a non-authorised target even if its prompt was somehow corrupted. - Soft guardrail. The LLM-based scope check runs on the parent and propagates.
-
Phase gating. Each member's phase is snapshotted at deploy time and is immutable for that member's lifetime. A member cannot escalate phases, period. If a member's reasoning concludes a phase change is needed, that decision is stripped to
completewith a reason logged. - Rules of Engagement. Enforced at the tool-executor level, which is shared. Members get RoE for free.
- Tool confirmation. Every dangerous tool from any member still requires your approval — the mechanism is the per-member panel-inline channel described above, but the safety contract is byte-identical to the single-agent path.
-
No recursive deployment. A member cannot itself emit
deploy_fireteam— that decision is stripped tocompleteand logged as a warning.
-
Stop button (red square) — cancels the parent agent's task. The deploy node catches the cancellation, wakes every pending approval Event with a reject signal so no member orphans on
event.wait(), callstask.cancel()on every member, drains the gather, and the wave is markedcancelled. You see all member badges flip to Cancelled within a second. -
Wave timeout — if the wall-clock timeout fires before all members complete, the same cleanup path runs and the wave is marked
timeout. Members that completed successfully before the timeout retain their findings. -
Backend restart — fireteam waves are not durable across backend crashes. The persistent checkpointer at the parent level resumes the parent agent, but any in-flight members are marked
cancelledwith reasonbackend_restart. The root agent then sees the wave as completed-with-cancelled-members and decides what to do next (typically asks you whether to retry or move on).
| Symptom | Likely cause | What to check |
|---|---|---|
| Agent never deploys a fireteam | Fireteam not enabled, or current phase not in Allowed Phases | Project Settings → AI Agent Behaviour → Fireteam → verify Enabled is ON and the current phase is checked |
| Wave hangs with members showing "Awaiting" forever | You walked away and missed approval prompts; the timeout has not yet fired | Click Allow/Deny on each pending member panel — or wait for Confirmation Timeout to auto-reject |
| Fewer members run than the agent's plan asked for | Plan exceeded Max Members and was truncated | Raise Max Members or accept that the agent will plan smaller waves |
Member status partial on every wave |
Member Max Iterations is too low for the work | Raise Member Iterations to give each specialist more reasoning budget |
Wave status timeout consistently |
Wave Timeout is too short for the engagement profile | Raise Wave Timeout, or raise Max Concurrent so more members run in parallel |
| Dangerous-tool approval prompts queue up sequentially | This is not how it works — every member parks independently and you can resolve in any order | Verify you are looking at the correct member panel; multiple Allow/Deny buttons can be active simultaneously |
Member error status with no clear reason |
LLM rate limit, transient tool crash, or Neo4j timeout | Check the agent backend logs (docker compose logs agent) for the error_message; other members continue regardless |
- AI Agent Guide — full operator guide for the agent, including the chat interface, phases, and approval workflows.
-
Agent Workspace — the per-project filesystem every fireteam member shares with the parent agent;
fs_diff vs_last_readis how members detect each other's concurrent writes, andjob_spawnlets each member detach long-running scans without blocking the wave. - Rules of Engagement (RoE) — the contract framework that every fireteam member inherits from the parent.
- Agent Skills — built-in and user attack skills that drive the per-member missions when a wave is deployed.
-
Project Settings Reference — full reference for every project parameter, including the
FIRETEAM_*group. - RedAmon Agentic System — Technical Whitepaper — the architectural deep dive: SG-ReAct pattern, 5-node member subgraph, per-member confirmation registry, wave-completion merge logic, comparison against other ai pentesting repos.