reliquary/docs/workpad/research/2026-10-05-21-athanor-usage-dirigent.md

# Athanor usage reports in dirigent

Research pass over `/home/g4b/Projects/dirigent` for documents reporting on how athanor
(the spire orchestration agent, pinned to Opus 4.6, "the oven") has actually been used:
experience reports, retrospectives, post-mortems, journals discussing athanor runs,
problems, costs, model behaviour, delegation issues, proposed changes. Read-only; no
dirigent files were touched.

Method: `grep -ril -i athanor` under `docs/workpad/` (36 hits, mostly reports/journals/
plans), ranked by hit density and date, cross-checked against `git log --grep=athanor`
(no commit *messages* mention athanor — the word only appears in document bodies). Also
searched for local `.claude/` overrides of an `athanor` agent/skill file (none found by
name).

## 1. Ranked list of relevant files

**Primary report (read in full):**

1. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-10-01-lean-process-report.md`
   (2026-10-01, with an **addendum dated 2026-10-05**) — 41 mentions of athanor. The
   definitive retrospective: compares a step-by-step baseline run against a new "lean
   process" run, both using athanor as implementation orchestrator; the 2026-10-05
   addendum is explicitly addressed "to authors of the spire/reliquary plugin" and lays
   out settled rules, delegation boundaries, and open tensions for athanor's design.
   **This is the report the user is thinking of.**

**Important secondary reports:**

2. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-23-14-stalled-agents-forensics.md`
   (2026-09-23) — 9 mentions. A post-mortem on three athanor instances (one implementation,
   two planning) that died mid-run when the session hit a monthly spend/rate limit;
   documents how far each got, what could be resumed, and a dispatcher/preflight decision
   athanor made.

3. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-29-13-w1c-tasks-1-7-run.md`
   (2026-09-29) — 5 mentions. A run report for tasks executed under the (then-current)
   per-task review flow; useful contrast data point feeding into the 2026-10-01 report's
   baseline comparison.

**Other files containing "athanor" (lower signal — mostly plans/journals that mention
athanor only in passing, e.g. naming it as the dispatcher, or copying boilerplate from the
skill). Listed for completeness, newest first:**

4. `/home/g4b/Projects/dirigent/docs/workpad/journals/2026-10-05-12-continue-implementations.md`
   (2026-10-05) — source journal behind the lean-process report's addendum; records the
   12:36/12:40 correction about who dispatches blocks (Igor vs athanor).
5. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-10-05-w3-run.md` (2026-10-05) — 1 mention.
6. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-30-10-delivered-and-roadmap.md` (2026-09-30) — 1 mention.
7. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-30-11-w1c-tasks-8-10-run.md` (2026-09-30) — 1 mention.
8. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-29-12-w1c-capture-findings.md` (2026-09-29) — 1 mention.
9. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-24-impl-run6-thoughts-y6-w2b.md` (2026-09-24) — 1 mention.
10. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-23-15-impl-qw-w4.md` (2026-09-23) — 1 mention.
11. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-25-roadmap-birds-eye.md` (2026-09-25) — 1 mention.
12. `/home/g4b/Projects/dirigent/docs/workpad/plans/2026-09-23-01-planning-index-A.md`,
    `.../plans/2026-09-23-01-planning-index-B.md` (2026-09-23) — plan indices written by/for
    planning athanors (subject of report #2 above).
13. Various journals mentioning athanor in passing (session coordination narration, not
    retrospective analysis): `2026-09-22-09-acp-session-loading-debug.md`,
    `2026-09-22-21-session-system-evaluation.md`, `2026-09-24-14-continue-work.md`,
    `2026-09-25-18-windows-smoke-continue.md`, `2026-09-16-14-session.md`,
    `2026-09-20-meta-harness-bugfixing.md`, `2026-10-01-11-bugfixing-on-main.md`,
    `2026-09-22-split-meta-ui-bugfixes.md`, `2026-09-29-13-w1c-live-acp-tasks-1-7.md`,
    `2026-09-23-14-resume-stalled-planning.md`, `2026-09-21-meta-harness-ui-split.md`,
    `2026-09-21-11-meta-ui-bugfix-round3.md`, `2026-09-18-18-meta-harness-implementation.md`,
    `2026-09-30-10-status-check.md`, `2026-09-28-15-current-branch-efforts.md`.
14. Goal/design docs naming athanor only as the execution mechanism, not reporting on it:
    `goals/meta-harness-ui-round2.md`, `goals/meta-harness-implementation-run.md`,
    `goals/meta-harness-bugfix-and-completion.md`, `plans/2026-09-23-12-w1c-live-acp-path.md`,
    `plans/2026-09-23-00-session-system-roadmap.md`, `plans/2026-09-23-12-w6-v1-feature-backlog.md`,
    `designs/2026-09-23-w1-message-representation.md`.

No file or commit message anywhere in the repo is literally named `athanor*`; it is never
the filename, only content.

## 2. Dense summaries of the top documents

### 2.1 `2026-10-01-lean-process-report.md` (+ 2026-10-05 addendum) — PRIMARY

**Core comparison.** Baseline (step-by-step, per-task review, Sonnet implementers + Opus
review/fix) vs. "lean" (one Opus-5.5 plan → 6 blocks → compile-gate only between blocks →
one test run → one end review → one fix pass → one re-check). Athanor ran the lean
blocks and its own end review; Igor ran everything else.

**Measured result.** Lean was ~35–40% faster in wall clock (3h11m vs ~5–5.7h) for similar
first-draft size, with far less fix churn (+1,417 fix lines in 1 commit vs +3,439 in 10
commits). The earlier "5x faster" claim told to the user was wrong — it came from a
journal clock that drifted ~2.5x from real git timestamps.

**Athanor's end review failed.** Quote: *"Athanor ran the blocks and the end review.
Athanor is the spire orchestration agent ('the oven') and is pinned to Opus 4.6."*
Athanor's internal end review returned **zero findings** ("Pass"). An independent review
dispatched directly by Igor on verified Opus 5.5 found **6 Important + 11 Minor** findings
in ~20 minutes, including a data-loss bug (I1, half-streamed messages dropped from the
archive) that the handoff notes had already flagged and athanor's reviewer still missed.
Quote: *"The review read like a confirmation of the checklist, not a search for bugs...
Its model is unknown."* Because athanor is pinned to Opus 4.6, nobody could verify what
model its internal `opus` alias resolved to when told to use Opus 5.5 — *"the zero-finding
result is either a 4.6 review or a weak, checklist-bound 5.5 review. Either way, it does
not count."*

**Model behaviour / assignment.** The Sonnet-first-draft experiment was ended on this
evidence: all 6 Important findings sat in complex code Sonnet drafted; Sonnet also hit
500k–750k token contexts on long single-implementer passes. New settled rule: complex/
hotspot blocks (state, concurrency, archive format, retention, event handling, read-path
precedence) go to Opus 5.5; mechanical blocks (field sweeps, renames, wiring, docs) go to
Sonnet; Haiku stays on compiles/tests/commits/summaries. Plans and all reviews are Opus
5.5, never athanor's pinned 4.6.

**Recommended/proposed changes (§5.2, §5.4, and Addendum A.1–A.11), aimed explicitly at
spire/athanor's design:**
- End review must be a **verified** Opus 5.5 role dispatched by Igor directly, outside
  athanor's pin, with the exact model id stamped in the report header — "a review without
  a stamped id does not count."
- End review must be adversarial and must answer every "flagged for review" line in
  implementer handoff notes one by one, not just run a checklist.
- Every plan block carries an explicit **owner model**; athanor dispatches with that model
  and must not pick or change it itself.
- Athanor should not write implementation plans — plans come from Igor-dispatched Opus 5.5
  general-purpose (write-capable) agents, never from athanor's own Opus-4.6 default.
- Athanor's job ends at "blocks done, tests run once, run log complete" — it should not
  run its own end review unless it can be pinned by full model id.
- Never carry one implementer across blocks; fresh context per block, each block's handoff
  note states done/deviations/flagged-for-review/left-for-later/expected-broken
  crates/model id/start-end times from `date`.
- **"Background grandchildren" hazard (settled 2026-09-29):** when athanor's subagents run
  in the background, their completion reports go to Igor, not athanor, and athanor stalls
  waiting — sequential steps must run in the foreground inside athanor; if athanor stalls,
  Igor must check the agent list and feed it the result manually. Quote: *"This is a
  harness behaviour athanor should be designed around."*
- No worktrees for this project (worktree cargo targets hit 83–111 GB on an 88%-full
  `/home`); athanor and implementers must verify the branch named in the brief and stop if
  not on it, and stage explicit paths only (`git add <file>`, never `-A`), since other
  agents may commit concurrently.
- User's own open remark (§5.4): spire needs **guard rails for pinned models** — pin role
  agents (reviewer, planner) by full model id instead of per-call aliases, forbid model
  aliases in athanor briefs, require reviewers to stamp the exact model id, and update the
  model-tiers reference. Explicitly filed as belonging to "the user or a spire session (the
  reliquary repo), not to dirigent."
- Open tensions deliberately left unresolved for "the user or spire authors" (§A.10):
  whether a scoped mid-run hotspot review is still allowed under lean; whether fix rounds
  resume the original per-block implementer or go to one fresh Opus fixer; athanor keeps
  orchestrating blocks today only to keep the H0–H3 comparison clean, not as an endorsement
  of Opus 4.6 for orchestration — "if 4.6 also mis-handles handoff flags or model choice,
  the guard rails in §5.4 become urgent."

**Model versions mentioned:** `claude-opus-5-5` (Opus 5.5, planner/reviewer/fixer, author
of this report and its addendum), Opus 4.6 (athanor's pin), Sonnet (implementers, generic
tier), Haiku (housekeeping tier). No "Fable" mention anywhere in dirigent's athanor
material.

### 2.2 `2026-09-23-14-stalled-agents-forensics.md` — secondary

Post-mortem after the whole session hit a monthly Claude spend limit (HTTP 429) in a
3-minute window on 2026-09-23, killing six agents mid-task, three of them athanor
instances (one implementation athanor, two planning athanors). Findings relevant to
athanor usage:
- Implementation athanor "QW+W4" got T1–T3 committed and reviewed, but T4's child finished
  writing code and passed its own tests, then died before the **parent athanor** could
  review, commit, or run `just check-all` — so a fully-working diff sat unreviewed/
  uncommitted in the working tree. Quote: *"the athanor died in the same window, right as
  it received the child's truncated hand-back — it never reviewed T4... and never wrote a
  report file."*
- A dispatcher/preflight ruling by this athanor explicitly deferred a roadmap-status edit
  ("dispatcher applies the listed text edits by hand") rather than doing it inline — an
  example of athanor making its own scoping decisions mid-run.
- Two planning athanors (A and B) each landed most of their substantive plan edits but
  left "closing loop" steps undone (a re-check that never ran; an index never updated with
  late fixes) when they were cut off — illustrating that athanor runs can leave partially-
  closed process state (ledgers, indices) that a resuming session must reconcile by hand.
- No model-version commentary here; this report predates the Opus 4.6 pin/Opus 5.5 split
  discussed in the October reports.

### 2.3 `2026-09-29-13-w1c-tasks-1-7-run.md` — secondary

A run log from the per-task review era (pre-lean), one of the baseline data points the
2026-10-01 report later cites when reconstructing the "~5–6h baseline" figure. Only 5
athanor mentions; it is primarily a task-by-task execution/review log rather than a
retrospective on athanor's behaviour, so it is evidentiary input to document #1 rather
than an independent report. Not separately summarized in depth here; see the 2026-10-01
report's §2.2–2.3 for the extracted, corrected numbers.

## 3. Local overrides vs. the upstream spire plugin

- No `.claude/agents/athanor*.md` or `.claude/skills/*athanor*` file exists in dirigent —
  i.e., dirigent has **not** forked/overridden athanor's agent definition locally; it
  still runs the upstream spire athanor.
- Dirigent **does** carry its own pre-spire orchestrator agent at
  `/home/g4b/Projects/dirigent/.claude/skills/orchestrator/SKILL.md` ("Plan Execution
  Orchestrator" / "dirigate of implementation") plus
  `/home/g4b/Projects/dirigent/.claude/agents/rust-task-implementer.md` and
  `/home/g4b/Projects/dirigent/.claude/agents/task-writer.md`. This looks like an earlier,
  parallel orchestration scheme (one-implementer-at-a-time, phase summaries, task
  checklists) that predates/coexists with spire's athanor rather than a modification of
  athanor itself — worth noting as a potential source of the "sequential dispatch,
  one-at-a-time" rule the lean report's addendum (A.8) says is "settled 2026-09-19."
- Several **project-level behavioural overrides of spire/Igor defaults** are recorded as
  settled rules in the 2026-10-05 addendum (§A.6, §A.8, §A.10) rather than as code changes:
  - No worktrees for code runs, even though "the Igor skill suggests them for code runs;
    this project overrides that" (§A.6).
  - "Don't start work from topic alone" relaxed for read-only research that itself answers
    the session's stated topic (§A.8).
  - These are documented as standing per-project exceptions Igor applies, not as edits to
    the spire plugin's shipped skill files — the addendum explicitly frames this as
    something "skills should make... per-project settings rather than fixed rules" (§A.10
    item 10), i.e. a gap to close upstream in spire, not something dirigent has patched
    locally in plugin files.
- The dirigent project memory directory `~/.claude/projects/-home-g4b-Projects-dirigent/memory/`
  (outside the dirigent git repo, not inspected directly here but cited extensively by the
  addendum) holds the actual settled/experiment rules (`feedback_review_by_risk`,
  `feedback_sonnet_first_draft`, `feedback_planner_agents`, etc.) that function as de facto
  local overrides of spire defaults for this project.

## Summary

Primary report: `docs/workpad/reports/2026-10-01-lean-process-report.md` (with its
2026-10-05 addendum) in `/home/g4b/Projects/dirigent`, written for "authors of the spire/
reliquary plugin." It shows athanor's internal end review (pinned Opus 4.6) missed 6
Important findings — including an archive data-loss bug — that an independently-dispatched
Opus 5.5 review caught, and it proposes concrete athanor design changes: model-id guard
rails, reviews/plans kept outside athanor's pin, per-block owner models, and foreground-
only sequential subagent dispatch to avoid orchestrator stalls. A secondary post-mortem,
`docs/workpad/reports/2026-09-23-14-stalled-agents-forensics.md`, documents three athanor
instances dying mid-run from a rate limit and the unreviewed/unclosed work they left
behind. Full findings, quotes, and a complete ranked file list are in the output document.