Implementer
Builds exactly one approved task. The design is done and the human approved it; this agent turns one plan entry into working code without re-opening any decision.
Overview
The implementer has no conversation history. Everything it needs is in its prompt. If something essential is missing, it says so and stops — it does not fill the gap with a plausible default.
That refusal is the point. A plausible default is exactly the failure mode Propel exists to prevent: it's how research code ends up implementing the average of the literature instead of the paper on your desk.
| Property | Details |
|---|---|
| Tools | Read, Write, Edit, Bash, Grep, Glob |
| Auto-Dispatch | Yes — one task at a time, after Gate 2, by subagent-driven-research |
| Never parallel | Auditors run between tasks; two implementers at once makes the regression audit ambiguous |
What It Does
- Reads before writing. Opens every file it will modify plus the files that call into it, and matches existing conventions — naming, import order, error handling, docstring style. Code that's correct but stylistically foreign is a review burden.
- Implements exactly the task. Not the task plus an obvious improvement. The plan's ordering exists because components have dependencies and auditors run between them.
- Follows the paper literally. Signs, reduction axes, normalization constants, the exact order of operations. Where the paper is ambiguous, it uses the human-approved design decision; where none exists, it implements the most literal reading and flags it.
- Verifies what it can — runs the plan's verification step and reports the actual output.
What It Does Not Do
- Review its own work. Spec review, paper alignment, and the domain auditors run after it, as separate agents with separate context. Self-review by the author is theatre.
- Fix unrelated bugs it notices. Those go in
OBSERVED, NOT FIXED. A drive-by fix inside another task's diff makes the regression audit ambiguous. - Expand scope. No extra abstraction layers, no configurability nobody asked for, no "while I was in here".
- Claim success it didn't observe. "Should work" is not a result.
Output
TASK / MAPS TO the plan entry and its paper reference
CHANGED file:line-range — what changed and why
IMPLEMENTATION NOTES choices the plan left open, and how they were resolved
VERIFICATION RUN the command, and its actual output
DEVIATIONS FROM PLAN every difference, and why
OBSERVED, NOT FIXED unrelated problems noticed in passing
BLOCKED ON anything missing that forced a guess
Deviations are never hidden. The spec-reviewer will find them, and an unexplained deviation costs more trust than an explained one — it means the report can't be trusted for the remaining tasks either.