Propel
Agents Overview
Thirteen subagents, dispatched for you. Eight read-only auditors that check the work, and five workers that do it — each in its own context window.
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
PostToolUse hook on Edit|Write|MultiEdit|NotebookEdit inspects the file just written — its path, and whether it actually contains JAX transforms — and states which auditors are required before the change can be presented at Gate 3. It skips scratch/, .claude/ and non-source files entirely. See Automatic Dispatch.
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 |
Worker Agents
Five agents do work rather than check it. They exist for one reason: context is the scarce resource, and the tasks that consume the most of it produce the least of the reasoning you actually need. An investigator reads forty files and returns eight lines. A trainer-operator absorbs a training log and returns a status card. A codex-bridge reads a long, confident, partly-wrong Codex reply and returns only what survived verification.
| Agent | Purpose | When it's dispatched |
|---|---|---|
| investigator | Trace one question and return file:line evidence and surprises | During investigation — several in parallel, one question each |
| implementer | Build exactly one approved plan task, no scope creep, no self-review | One at a time, after Gate 2 |
| spec-reviewer | Check code against the plan — especially undeclared deviations | Right after the implementer, before the auditors |
| trainer-operator | Launch and babysit a run; escalate anything that changes what it measures | Once a training command is approved |
| codex-bridge | Run the Codex consult and verify every claim against the repo | At every gate |
All Auditors
Propel ships with 8 read-only auditors. 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