> ## 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.

# Autonomous Execution

> How Decepticon orchestrates multi-stage kill chains with fresh context per objective.

## Kill Chain Orchestration

Once the OPPLAN is generated, Decepticon's orchestrator takes over. It iterates through objectives autonomously, executing a full kill chain — reconnaissance, exploitation, privilege escalation, lateral movement, and persistence.

This isn't a linear script. The orchestrator adapts in real time based on what each agent discovers.

## Execution Loop

<Steps>
  <Step title="Select Next Objective">
    The orchestrator picks the next pending objective from the OPPLAN, resolving dependencies and prioritizing based on kill chain phase.
  </Step>

  <Step title="Build Context">
    A prompt is constructed with the objective details, RoE guard rails, available skills, and relevant findings from previously completed objectives.
  </Step>

  <Step title="Spawn Fresh Agent">
    A **new agent instance** is spawned with a clean context window. No accumulated noise from prior objectives — fresh reasoning every time.
  </Step>

  <Step title="Execute">
    The agent executes the objective using available tools and skills within the Kali sandbox. All commands run inside persistent tmux sessions with interactive prompt detection.
  </Step>

  <Step title="Parse Results">
    The orchestrator parses the agent's `PASSED` / `BLOCKED` signal, updates the objective status, and appends findings to disk.
  </Step>

  <Step title="Iterate">
    Move to the next objective. Findings from completed objectives inform subsequent agents, enabling multi-stage attack chains.
  </Step>
</Steps>

## Fresh Context Per Objective

<Info>
  This is a critical design decision. Each agent spawns with a clean context window per objective — preventing context degradation across a long engagement.
</Info>

Why this matters:

* **No accumulated noise** — Agent reasoning doesn't degrade as the engagement progresses
* **Clean state** — Each objective gets full attention without irrelevant context from prior phases
* **Persistent findings** — Results are saved to disk, not agent memory. The orchestrator injects only relevant prior findings into each new agent's context

## Interactive Shell Sessions

Real offensive security tools are interactive — `sliver-client`, `msfconsole`, `evil-winrm`, `sqlmap`, `impacket-psexec`. They don't just take a command and exit. They drop you into a prompt and expect a conversation.

Most AI agents can't handle this. They fire one-shot commands via `subprocess.run()` and call it a day.

Decepticon runs every command inside **persistent tmux sessions** with automatic prompt detection:

* When a tool presents an interactive prompt (`sliver >`, `msf6 >`, `PS C:\>`), the agent detects it and sends follow-up commands
* **Parallel named sessions** — multiple tool sessions running concurrently
* **Control signals** — `C-c`, `C-z` support for managing interactive processes
* **Stall detection** — recognizes when a command hangs and takes corrective action

The agent actually *operates* the tools — the same way a human operator would.

## Background Commands & Auto-Notification

Some commands take minutes — `nmap -p- -A`, a full Burp scan, a long-running fuzzer. Blocking on the prompt for ten minutes while the LLM waits is a waste of compute and turns. The agent kicks them off in the background instead and gets on with other work:

```
bash(
  command="nmap -p- -A target.lan -oN scan.txt",
  run_in_background=True,
  session="scan-1",
)
→ { "status": "started", "session": "scan-1" }
```

While the scan runs, the agent moves on — recon other surfaces, plan the next objective, query the knowledge graph. When the scan finishes, `SandboxNotificationMiddleware` **automatically captures the output and injects it on the next inference turn**:

```
Turn N:    bash(..., run_in_background=True)  → returns "started"
Turn N+1:  do other work
Turn N+2:  on entry, agent sees:
           <system-reminder>
           Background command in session scan-1 finished (exit 0).
           Output (2.4K):
           Nmap scan report for target.lan ...
           </system-reminder>
```

No `bash_output()` polling. No idle "is it done yet?" turns. The agent doesn't have to remember the command exists — completion comes to it. This is the same pattern that powers [Dynamic Infrastructure](/en/features/dynamic-infrastructure) workload-state notifications.

### Output tiering

Long-running commands often produce a lot. The sandbox tiers output so the agent's context window stays usable:

| Volume             | What happens                                                                                            |
| ------------------ | ------------------------------------------------------------------------------------------------------- |
| **≤ 15 KB**        | Inlined directly in the notification / tool result.                                                     |
| **15 KB – 100 KB** | Written to `/workspace/.scratch/` with a path + summary inlined. The agent reads the file when needed.  |
| **> 5 MB**         | The runaway session is killed, the agent is told to refine the command (narrower scope, output filter). |

Combined with ANSI stripping and repetitive-line compression, this keeps token spend predictable even on day-long engagements.

## RoE Enforcement

At every iteration, the orchestrator validates that the next action falls within the Rules of Engagement. If an objective would violate scope, timing, or technique boundaries defined in the RoE, it is automatically blocked.

<Card title="Skill System" icon="book-open" href="/en/features/skill-system">
  Learn about the progressive skill system that equips agents with ATT\&CK-mapped capabilities.
</Card>