> ## Documentation Index
> Fetch the complete documentation index at: https://docs.decepticon.red/llms.txt
> Use this file to discover all available pages before exploring further.

# Agents

> Sixteen specialist agents organized by engagement phase, each with dedicated tools, skills, and a clean context window.

## Agent Architecture

Decepticon operates through **sixteen specialist agents**, each with its own tools, skills, and clean context window. Agents are spawned fresh per objective — no accumulated noise, no degraded reasoning across long engagements.

The agents are not a flat list. They are organized by the engagement phase they serve, and routed by the **Decepticon orchestrator** through the OPPLAN.

## Orchestration Layer

<CardGroup cols={2}>
  <Card title="Decepticon (Orchestrator)" icon="brain">
    The central red-team coordinator. Owns the OPPLAN, sequences objectives, resolves dependencies, and dispatches specialists (`recon`, `exploit`, `postexploit`, `analyst`, `reverser`, `contract_auditor`, `cloud_hunter`, `ad_operator`) via SubAgent middleware. Runs on the most capable model tier.
  </Card>

  <Card title="Vulnresearch (Orchestrator)" icon="rotate">
    Vulnerability research orchestrator — runs the five-stage pipeline (`scanner → detector → verifier → patcher → exploiter`) with state passed between stages exclusively through the knowledge graph.
  </Card>

  <Card title="Soundwave (Planner)" icon="microphone">
    Engagement planner. Standalone graph (not a sub-agent of Decepticon). Interviews the operator and generates the complete engagement package — RoE, ConOps, Deconfliction Plan, OPPLAN, and threat profile. No bash access; produces documents only.
  </Card>
</CardGroup>

## Reconnaissance Phase

<CardGroup cols={2}>
  <Card title="Recon" icon="magnifying-glass">
    Active and passive recon — port scanning, service enumeration, OSINT, subdomain discovery, certificate-transparency mining. Operates inside the Kali sandbox.
  </Card>
</CardGroup>

## Vulnerability Research Pipeline

Sub-agents of the **Vulnresearch** orchestrator. State flows between stages via the knowledge graph; each stage runs with fresh context.

<CardGroup cols={2}>
  <Card title="Scanner" icon="scan-eye">
    Stage 1 — broad-spectrum scanner. Walks large codebases in parallel and emits CANDIDATE nodes with heuristic suspicion scores. Cheap, fast, no vulnerability reasoning.
  </Card>

  <Card title="Detector" icon="radar">
    Stage 2 — vulnerability detector. Reads source around each CANDIDATE and promotes real bugs to VULNERABILITY + HYPOTHESIS nodes, or rejects them as false positives. Read-only (no bash).
  </Card>

  <Card title="Verifier" icon="circle-check">
    Stage 3 — two-method verification gate. Confirms candidate findings through at least two independent evidence channels before downstream work begins.
  </Card>

  <Card title="Exploiter" icon="crosshairs">
    Stage 4 — reproducible PoC author. Produces working proof-of-concept exploits for verified vulnerabilities, with reliability notes.
  </Card>

  <Card title="Patcher" icon="bandage">
    Stage 5 — patch generator. Produces a code or configuration change that closes the vulnerability without breaking the application, plus a regression test.
  </Card>
</CardGroup>

## Exploitation & Post-Exploitation

<CardGroup cols={2}>
  <Card title="Exploit" icon="bug">
    Initial access and exploitation tactics. Web/AD attacks (SQLi, SSTI, Kerberoasting, ADCS abuse, credential attacks).
  </Card>

  <Card title="Post-Exploit" icon="key">
    Privilege escalation, lateral movement, credential harvesting, persistence — often via Sliver C2 sessions once initial access is established.
  </Card>
</CardGroup>

## Domain Specialists

<CardGroup cols={2}>
  <Card title="AD Operator" icon="users">
    Active Directory specialist. Kerberoasting, AS-REP roasting, ADCS ESC1–ESC15, DCSync, ticket forging, ACL abuse, GPO manipulation, BloodHound path analysis.
  </Card>

  <Card title="Cloud Hunter" icon="cloud">
    Cloud infrastructure specialist. IAM privilege escalation, S3/Azure storage exposure, Kubernetes RBAC escapes, metadata-service abuse across AWS/Azure/GCP.
  </Card>

  <Card title="Contract Auditor" icon="file-text">
    Solidity / EVM smart-contract auditor. Reentrancy, oracle manipulation, flash-loan abuse, access-control flaws; Slither static analysis + Foundry PoC harness.
  </Card>

  <Card title="Reverser" icon="microscope">
    Binary reverse-engineering specialist. ELF/PE/Mach-O triage, packer detection, string/symbol extraction, ROP gadget inventories, Ghidra/radare2 scripting.
  </Card>
</CardGroup>

## Analysis & Reporting

<CardGroup cols={2}>
  <Card title="Analyst" icon="chart-bar">
    Vulnerability research and reporting specialist. Cross-correlates findings, queries the knowledge graph, and drafts the engagement narrative — source code review, static analysis (semgrep/bandit/gitleaks), dependency CVE sweeps, and multi-hop exploit chain construction.
  </Card>
</CardGroup>

## Clean Context Per Objective

Every agent spawns with a **fresh context window** for every objective:

```
Objective 1 (Recon)     → New Recon agent instance       → Findings saved to disk + graph
Objective 2 (Exploit)   → New Exploit agent instance     → Reads obj-1 findings explicitly
Objective 3 (Post-Exp)  → New Post-Exploit instance      → Reads obj-1+2 findings explicitly
```

* **No accumulated noise** — Context doesn't degrade across a 100-objective engagement.
* **Targeted context** — Each agent receives only the findings relevant to its objective.
* **Persistent state** — Findings live on disk and in Neo4j, not in agent memory.

## Agent Middleware Stack

Each agent runs with a stack of middleware that provides cross-cutting concerns. The exact stack depends on the agent's role.

| Agent Role                           | Middleware Stack                                                                                                             |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- |
| **Decepticon (Orchestrator)**        | EngagementContext → Skills → Filesystem → SubAgent → OPPLAN → ModelFallback → Summarization → PromptCaching → PatchToolCalls |
| **Vulnresearch (Orchestrator)**      | Skills → Filesystem → SubAgent → OPPLAN → ModelFallback → Summarization → PromptCaching → PatchToolCalls                     |
| **Soundwave (Planner)**              | EngagementContext → Skills → Filesystem → ModelFallback → Summarization → PromptCaching → PatchToolCalls                     |
| **Specialist (Recon, Exploit, ...)** | Skills → Filesystem → ModelFallback → Summarization → PromptCaching → PatchToolCalls                                         |

### What Each Layer Does

* **EngagementContext** — Injects engagement metadata (slug, target, RoE summary) into the system prompt so guardrails are evaluated continuously.
* **Skills** — Progressive-disclosure skill loading filtered by ATT\&CK overlap with the active threat profile. Frontmatter loads at startup (\~100 tokens/skill); full body is fetched on-demand via `read_file`.
* **Filesystem** — `FilesystemMiddlewareNoExecute` — provides `read_file`, `write_file`, `edit_file`, `ls`, `glob`, `grep` against the engagement workspace. Execute is intentionally disabled; specialists use the dedicated `bash` tool instead.
* **SubAgent** — `task()` tool for orchestrators (Decepticon, Vulnresearch) to dispatch work to specialists.
* **OPPLAN** — Five CRUD tools (`add_objective`, `get_objective`, `list_objectives`, `update_objective`, `objective_expand`) and dynamic state injection of objectives into every LLM call.
* **OpsControl** — Auto-injects workload-lifecycle state transitions (`starting → running → exited`) into the agent's next turn, so the orchestrator never polls after calling `ops_start(...)`. See [Dynamic Infrastructure](/en/features/dynamic-infrastructure).
* **SandboxNotifications** — When a `bash` command launched with `run_in_background=true` finishes, the captured output is auto-fetched and injected on the next inference turn. The agent doesn't have to remember to call `bash_output()`.
* **ModelFallback** — Provider failover when a model is rate-limited or down. Walks the fallback chain built from the user's credentials inventory.
* **Summarization** — Conversation-window compression for long-running specialists.
* **PromptCaching** — `AnthropicPromptCachingMiddleware` — places prompt-cache boundary markers; silently no-ops on non-Anthropic providers.
* **PatchToolCalls** — Sanitizes and normalizes tool-call shapes for cross-provider compatibility (Anthropic, OpenAI, Google, MiniMax, …).

## Agent–Tool Interaction

Agents interact with offensive tools through persistent tmux sessions inside the Kali sandbox:

```
Agent → Docker Socket → Kali Sandbox → tmux session → Tool (sliver-client, msfconsole, evil-winrm, ...)
                                              ↓
                                       Prompt Detection
                                              ↓
                                       Follow-up Commands
```

When a tool presents an interactive prompt (`sliver >`, `msf6 >`, `PS C:\>`), the agent:

1. Detects the prompt pattern.
2. Interprets the tool's output.
3. Sends the appropriate follow-up command.
4. Handles control signals (`C-c`, `C-z`) when needed.

Output is tiered:

* **Inline (≤15K)** — Returned directly to the agent.
* **Offload (15K–100K)** — Written to `/workspace/.scratch/` and referenced by path.
* **Watchdog (>5M)** — The session is killed and the agent is asked to refine.

This is how real operators work. Decepticon's specialists do the same.

<CardGroup cols={2}>
  <Card title="OPPLAN System" icon="clipboard-list" href="/en/features/opplan-system">
    The structured plan that the orchestrator dispatches to these agents.
  </Card>

  <Card title="Infrastructure" icon="server" href="/en/architecture/infrastructure">
    The isolated network architecture these agents operate within.
  </Card>
</CardGroup>