Propel
Agents Overview
Specialized subagents that audit code automatically — separate context windows, read-only access, and focused prompts for catching what humans miss.
What Are Agents?
Propel agents (also called auditors) are specialized subagents, each with its own separate context window, read-only file access, and a tightly focused system prompt. They exist for one reason: to catch problems that the main Claude session might miss because its attention is on implementation, not verification.
Each agent is defined by a markdown file in the agents/ directory. The file contains the agent's name, description, allowed tools, and a detailed system prompt that tells it exactly what to look for and how to report findings.
Agents have no conversation history. Every invocation starts from scratch with only the system prompt and the files provided. This means prompts must be completely self-contained — include all context the agent needs in the invocation, because it cannot ask follow-up questions.
How Auto-Dispatch Works
Agents are not invoked manually in normal usage. They are automatically dispatched by the main Propel pipeline after code changes, based on what type of component was modified. This happens at Gate 3 (the auditor gate) in the Engineer Mode pipeline, and during the investigation phase in Debugger Mode.
The dispatch logic examines the changed files and the nature of the change, then selects the relevant subset of agents. Not every agent runs on every change — only those whose expertise is relevant.
Dispatch Rules
| If the change involves... | Agents dispatched |
|---|---|
| Model architecture or loss functions | Paper Alignment Auditor, Silent Bug Detector, JAX Logic Auditor |
| Training loop or optimizer | Silent Bug Detector, Regression Guard, Code Reviewer |
| Data pipeline or preprocessing | Data Flow Tracer, Silent Bug Detector |
| JAX transformations (vmap, scan, jit) | JAX Logic Auditor, Silent Bug Detector |
| Environment integration or wrappers | Env Researcher, Data Flow Tracer |
| Any feature branch before merge | Regression Guard, Code Reviewer |
| Unexplained training failure | Failure Mode Researcher (+ delegates to others) |
| New paper implementation | Paper Alignment Auditor, Silent Bug Detector, Code Reviewer |
All Agents
Propel ships with 8 specialized agents. Each is documented in detail on its own page.
| Agent | Purpose | Auto-Dispatch? | Key Capability |
|---|---|---|---|
| Paper Alignment Auditor | Verify code matches the source paper | Yes | Equation-to-code cross-referencing |
| Silent Bug Detector | Find bugs that don't crash | Yes | 11-category silent failure catalog |
| JAX Logic Auditor | Audit JAX transformations and data flow | Yes | End-to-end axis/dimension tracking |
| Regression Guard | Prevent breaking existing pipelines | Yes | Displaced fix detection |
| Data Flow Tracer | Map data from input to output | Yes | Framework-agnostic semantic tracing |
| Failure Mode Researcher | Research unexplained failures | On demand | Cross-domain literature search + delegation |
| Env Researcher | Deep-dive simulation environment docs | On demand | API reference compilation and gotcha detection |
| Code Reviewer | General code quality + research awareness | Yes | Research-specific review checklist |
Auditor Results at Gate 3
In Engineer Mode, agent results are collected and presented at Gate 3 — the auditor checkpoint before final approval. The main session aggregates findings from all dispatched agents into a unified report:
- Critical findings block progress — they must be addressed before continuing
- Medium findings are presented for the user to decide whether to fix now or defer
- Minor findings and suggestions are listed for awareness
The user reviews the aggregated report and either approves the implementation or sends it back for revisions. This is the quality gate that catches issues the implementer missed.
The One-Shot Context Principle
Unlike the main Propel session which maintains a conversation, agents operate on a one-shot basis. Each invocation is independent — the agent receives its system prompt, the files to audit, and a description of what to check. It produces a structured report and terminates.
This design has important implications:
- Prompts must be self-contained — include all relevant context (what changed, what to look for, which files matter) because the agent cannot ask clarifying questions
- No memory across invocations — if you run the same agent twice, it starts fresh each time. Previous findings are not remembered.
- Focused scope — each agent is specialized for one type of analysis. This prevents context dilution and keeps the audit thorough within its domain.
- Parallel execution — because agents are independent, multiple agents can run simultaneously on different aspects of the same code change