A briefing for the successor

Retrodict

An ARC-AGI-3 agent whose entire durable memory is one model-authored markdown file, governed by a prompt that ranks the raw log above it.

Carries 0 of 7 rubric mechanisms. Most systems here carry none or one (47%), and a dash means the mechanism was not found at this commit — not that the system needed it. Each mark is one LLM reviewer's reading of the code at this commit rather than a run of it — known limits.

  • Tombstone
  • Trust state
  • Bi-temporal
  • Scope enforced
  • Mutation audit
  • Human review
  • Negative evals

1. Executive Summary

Retrodict is an ARC-AGI-3 agent — 3,888 lines of Python, 46 commits since 5 July 2026 — that reports solving every level of all 25 public games at 99.86% mean RHAE for $654 of API list price, on a published scorecard.

The memory design is one file. "What it establishes about a game is curated into a playbook memory file that outlives its context window." The agent's context is dropped periodically to control cost; a fresh session resumes with the workspace and no recollection, reads playbook.md, and continues.

No marks, and the report exists because the contract around that file is the most carefully written statement of the summarise-for-your-successor problem in this corpus — and because none of it is machinery. Everything below is a prompt instruction addressed to a model that may or may not comply, with nothing in code checking that it did.

2. Mental Model

The prompt states the problem before the solution, which is why it is worth quoting at length:

"To control cost, your in-context conversation is periodically dropped and you resume in a fresh session with no memory of your own reasoning — only your workspace files survive. log.txt survives but is large and raw: it records every board and action, not the conclusions you drew from them, so a fresh session relying on log.txt alone re-derives and re-tests rules you already settled, wasting actions and cost. Prevent this by maintaining playbook.md, a curated briefing for the successor who wakes up with your files but none of your memory."

That is the clearest articulation of why a raw log is not memory that this atlas has read. The log is complete and useless at scale; the playbook is lossy and load-bearing; the successor needs the second and can check it against the first.

3. Architecture

Diagram — everything durable is two files, and every rule about how they relate is prose in a system prompt rather than code
Diagram source
flowchart TD
%% caption: everything durable is two files, and every rule about how they relate is prose in a system prompt rather than code
    M["model session"] --> ACT["proposes a plan queue<br/>each move carries predicted cells"]
    ACT --> RUN["runner plays the queue"]
    RUN -->|"prediction miss<br/>or queue exhausted"| M
    RUN --> LOG[("log.txt<br/>every board, action, plan")]

    M -->|"write · edit<br/>generic file tools"| PB[("playbook.md<br/>working model + working memory")]

    LOG -.->|"replay a hypothesis<br/>over past frames — free"| M
    DROP["context dropped<br/>to control cost"] --> SUCC["successor session"]
    PB --> SUCC
    LOG --> SUCC
    SUCC -.->|"prompt: raw log is ground truth"| PB

    PB -.->|"points marked<br/>checked vs assumed<br/>(prose convention only)"| PLAN["no multi-step plan<br/>on an assumed point"]

4. Essential Implementation Paths

Hypotheses are tested against the record before they cost anything. The agent writes Python that replays a candidate rule over past frames in log.txt, "where being wrong costs nothing." Only a hypothesis that survives the log earns real actions. That is a verification step, and it is the reason the playbook can carry a checked marking at all.

The plan queue makes a wrong belief cheap to detect. A committed queue carries, per move, the exact cells the agent predicts the board will show. The runner plays it out and returns to the model only when the queue is exhausted or a prediction misses — with the diff. A falsified model announces itself.

The playbook is written with generic tools. write creates or overwrites "a fresh, compacted playbook.md"; edit replaces a string for "cheap incremental updates." Grepping the harness for playbook finds it in prompts.py and nowhere else — not in runner.py, not in tools.py. The file is a convention between the prompt and the model, and the code neither creates, validates, parses nor backs it up.

5. Memory Data Model

There is none. playbook.md is markdown with a two-part structure the prompt asks for — a working model and a working memory — and no parser.

The trust convention is the part worth recording, because it is a good design that stops one step short of being a mechanism:

"Mark each point by how well the log supports it (checked against the log vs. still assumed), and do not build multi-step plans on merely-assumed points. The moment the log contradicts a point — or a plan built on it turns out impossible — [revise it]."

Two epistemic states, a rule about what may be built on each, and a trigger for revision. As a specification of trust_state it is better than several implementations in this corpus. As an implementation it is a sentence in a prompt: nothing extracts the marking, nothing refuses a plan built on an assumed point, and nothing detects a point that was marked checked without being checked. The mark is withheld for that reason and not for the design's quality.

The same is true of precedence. "The raw log is the ground truth" and "nothing here is permanent" are exactly the right rules for a lossy summary over a complete record — and they are enforced by the model choosing to obey them.

6. Retrieval Mechanics

The successor reads playbook.md first, then works over log.txt with code rather than by looking at frames. There is no index, no embedding and no ranking; retrieval is the model deciding what to grep. For a single-game workspace of one agent's own making, that is a defensible answer and it does not generalise past it.

7. Write Mechanics

Compaction is a full rewrite: the model lays down a fresh playbook when the old one has drifted. Nothing records what the rewrite dropped. If a point was falsified and the compaction removed both the point and the note that it was falsified, the successor's only path back is the log — which is exactly what the playbook exists to avoid re-reading.

That is the design's central risk and it is inherent rather than an oversight: a curated briefing that is cheaper than the record is also lossier than the record, and there is no diff.

8. Agent Integration

ThinHarness, gpt-5.6-sol at max reasoning effort, one workspace per game with arclog.py and a scratch/ package seeded from workspace_template/. The log-as-context and plan-queue foundation is credited to RGB-Agent.

9. Reliability, Safety, and Trust

The honest summary: this is a system whose memory guarantees are entirely prompt-level, in a setting where that is close to reasonable. One agent, one game, one workspace, no other principal, no adversary, and a raw log that can adjudicate any dispute. There is no scope to enforce, no audit consumer, and no second party to review.

What the corpus should take from it is the contract, not the architecture. The questions the prompt answers explicitly — why is the raw record not enough, what is the summary for, which parts of it may be planned on, what triggers a revision — are questions most memory systems in this atlas never write down at all.

10. Tests, Evals, and Benchmarks

1,435 lines of tests across eight files, and none of them touches the playbook. The suite covers the log writer, the plan parser, the live cache, the prompt assembly and the tool sandbox — including assert not result.ok, f"{module} must not be importable by the agent", a real must-not assertion, but about import isolation rather than memory retrieval. negative_eval is withheld on that: no committed case asserts that particular material stays out of a recall or out of the playbook.

The public result is unusually well qualified for a self-report. The README gives 99.86% mean RHAE at $654 against a linked official scorecard, names Tycho as scoring higher at 100.00% and an estimated $2,986, and sends the reader to a comparison methodology document with the warning that "cost methods and run-selection rules differ." A comparison that names the system beating it, and links the qualifications, is rarer than the number.

The scorecard is worth reading rather than the headline, because the headline undersells what happened. the official scorecard records 183/183 levels and 25/25 environments, every one WIN, in 7,703 actions. RHAE is relative human action efficiency, not a completion rate: 23 of the 25 games score 100.00 and the mean falls to 99.86 on two — sk48-d8078629 at 98.64 and sp80-589a99af at 97.77 — where the agent took roughly double Tycho's actions on those same two games. The 25 per-environment scores average to 99.8564, so the published figure recomputes from the table.

Stated that way the comparison changes shape. Both harnesses solved every level of every public game; the 0.14-point difference is action efficiency on two of twenty-five, and this one did it for $654 against $2,986 — 4.6× less for the same 183 levels. The README's own framing, that Tycho "scores higher", is accurate and reads as a larger gap than the scorecards support.

The listing is publication, not verification: the ARC Prize community leaderboard states that only ARC-AGI-1 and ARC-AGI-2 semi-private results are run and verified, and that "everything else is scored on a public set and self-reported." The per-environment table under each entry is what makes a self-reported score checkable, and this one checks.

Nothing was run for this review.

11. For Your Own Build

Write down why the summary exists. The paragraph explaining that a raw log makes a successor re-derive settled rules is the reason a curated file earns its cost. Most systems here have the file and not the argument.

If you ask a model to mark confidence, read the marking. Two states and a rule about what may be planned on each is a good design; it becomes a mechanism the moment something parses the mark and refuses the plan.

Record what a compaction dropped. A full-rewrite briefing with no diff can silently lose the note that a belief was falsified, and the only recovery is the record the briefing exists to avoid reading.

12. Open Questions

Does anything survive between games? The playbook is per-game. Whether a lesson learned in game 3 can reach game 17 — the thing that would make this a memory system rather than a per-run scratchpad — was not found in the tree.

What does a compaction actually keep? No committed artifact shows a before-and-after playbook, so the compaction's loss rate is unmeasured.

Is the checked/assumed marking honoured? The blog post may report on it; the repository does not, and no test asserts it.

Appendix: File Index

Path What it holds
src/arc3/prompts.py The playbook contract, the checked/assumed rule, the tool descriptions
src/arc3/runner.py The plan queue and the return-on-mismatch loop
src/arc3/tools.py write and edit, the only path to the playbook
src/arc3/logwriter.py log.txt, the ground truth the playbook is checked against
workspace_template/ The seeded per-game workspace
docs/arc-agi-3-harness-comparison.md The cost and run-selection qualifications

History

2026-08-2871672e8e… — same commit, second reading, covering the published scorecard. It records 183/183 levels and 25/25 environments, every one WIN, in 7,703 actions, and the 25 per-environment scores average to the published 99.8564. That reframes the README's own comparison: this harness and Tycho solved exactly the same levels, the 0.14-point gap is action efficiency on two games out of twenty-five, and this one cost $654 against $2,986. Section 10 says so. Marks unchanged at none.

2026-08-2771672e8e… — first reading, 3,888 lines of Python, 46 commits since 5 July 2026. Screened before reading: no auto-run surface, no unpinned surface, and one execution surface — tests/conftest.py, which runs on pytest collection before any test does. AGENTS.md and CLAUDE.md are addressed to a reading agent and were treated as data. Nothing was installed and nothing was run. No marks. The durable memory is one model-authored playbook.md written through generic write and edit tools; grepping the harness finds playbook only in prompts.py, so no code creates, parses, validates or backs up the file. trust_state is withheld although the prompt specifies two epistemic states — a point checked against the log versus still assumed, with a rule against building multi-step plans on the second — because nothing reads the marking; it is a convention addressed to the model. tombstone, bitemporal, scope_enforced, audit_log and human_review are absent. negative_eval is withheld: the suite's must-not assertions are about module import isolation, not about material staying out of a recall. The reading covers the prompts, the runner, the tools and the tests; the ThinHarness dependency and the linked comparison methodology were not traced.