Compiled Knowledge Loops for Codex and Forge

Summary

The pattern to adopt is compiled knowledge loops.

The current looping-agent idea says: queue discrete coding tasks, let agents work while unattended, then review the results later. That is useful, but it mostly multiplies execution time. Andrej Karpathy's LLM Wiki pattern points at a more durable loop: every source, question, answer, contradiction, and synthesis should update a persistent knowledge artifact that future agents can read before acting.

The recommendation is:

1. Implement the pattern first in Codex as a user-level wiki-maintainer workflow: raw sources, generated wiki pages, schema, index, log, ingest, query, and lint.
2. Organize the wiki around immutable raw/ sources, generated wiki/ pages, explicit loop specs, decisions, questions, contradictions, and lint reports.
3. Use Forge to package the durable Codex behavior as managed skills: one for llm-wiki maintenance and one for helping a human write effective loops.
4. Keep the current RFD site focused on proposal and decision records. For a small startup knowledge base, prefer a sibling private app that reuses the RFD reader primitives instead of turning this public RFD app into the wiki.
5. Treat electronics parts, datasheets, comparisons, and analysis patterns as a high-value follow-on domain for that sibling app, scoped separately in 0014.
6. Do not start by building a broad Forge CLI. Add Forge primitives only after repeated Codex usage shows a small stable operation that should be deterministic, such as wiki lint, source inventory, loop lint, or index validation.

The key shift is from "agents loop on tasks" to "agents loop on a knowledge base that compounds."

Context

This RFD synthesizes three inputs:

• A local looping-agent note shared during drafting, which describes setting AI coding agents to loop on discrete tasks overnight.
• The Slack thread text that summarized Karpathy's April 2026 LLM Wiki pattern and framed it as the bookkeeping layer missing from most personal knowledge systems.
• Andrej Karpathy's source gist, LLM Wiki, which describes an LLM-maintained markdown wiki as a persistent, compounding artifact between raw sources and answers.

The thread also references a PDF article screenshot. The implementation should treat that kind of visual source as a first-class raw input: save the image or PDF under raw/, extract text with OCR when useful, and preserve the original visual artifact so the agent can revisit it with vision tools instead of relying only on a text paste.

What the loops note gets right

The local looping-agent note captures a real operating advantage:

• agents can execute while the human is offline,
• tasks should be small and independently reviewable,
• acceptance criteria and automated checks matter,
• low-risk work is a good starting point,
• the morning review loop is where human judgment re-enters.

That is a good execution loop. It is not yet a knowledge loop.

If an overnight agent fixes bugs, writes tests, or drafts docs, the outputs may be valuable, but the system does not necessarily learn. The next session can still begin from a cold start unless the result is captured somewhere structured enough for future agents to read.

What the LLM Wiki pattern adds

Karpathy's pattern adds a persistent middle layer between raw material and agent answers.

The layers are:

1. Raw sources: immutable source material such as articles, PDFs, screenshots, meeting notes, issue threads, papers, repo docs, and transcripts.
2. Wiki: LLM-generated markdown pages that summarize, connect, update, compare, and synthesize the sources.
3. Schema: an AGENTS.md, CLAUDE.md, or similar instruction file that tells the agent how to maintain the wiki.

The operations are:

1. Ingest a source into the wiki.
2. Query the wiki instead of rediscovering from raw fragments every time.
3. Lint the wiki for contradictions, stale claims, orphan pages, missing concepts, naming drift, and unfiled answers.

The important distinction from ordinary RAG is accumulation. RAG retrieves raw chunks at query time and derives the answer again. The wiki compiles knowledge once, keeps it linked, and updates the compiled artifact when new sources arrive.

Identified pattern

The reusable pattern is:

curate source -> ingest -> update durable pages -> answer from pages -> file useful answers -> lint -> repeat

A stronger version for agents is:

source queue -> agent ingest loop -> reviewable wiki diff -> human review -> merged knowledge -> future agent context

This is not just note-taking. It is a build system for knowledge:

• raw/ is the source tree,
• wiki/ is the compiled artifact,
• AGENTS.md is the build contract,
• index.md is the symbol table,
• log.md is the build log,
• lint is the health check,
• git is the audit trail.

Why this matters for Codex

Codex is already oriented around reading and writing files. That makes it a good fit for the LLM Wiki pattern without new infrastructure.

Codex should be able to:

• ingest a markdown file, PDF, screenshot, Slack thread export, GitHub issue, or repo note,
• create or update wiki pages,
• update an index and log,
• cite raw sources from generated pages,
• answer questions from the wiki first,
• file useful answers back into the wiki,
• run periodic lint passes.

The Codex-specific benefit is that this turns long-running project context into a file-backed system rather than a chat-history dependency. It reduces repeated rediscovery and makes agent handoffs more deterministic.

Recommended wiki organization

The wiki should be organized around the three-layer LLM Wiki contract: immutable sources, compiled wiki pages, and an explicit schema. The goal is not a beautiful taxonomy. The goal is a small file system that an agent can read, update, lint, and resume from without asking the human to remember where things live.

Use this initial shape:

knowledge/
  AGENTS.md
  raw/
    sources/
      2026-04-karpathy-llm-wiki.md
      2026-07-slack-thread-compiled-knowledge.md
    assets/
      2026-04-karpathy-article-screenshot.pdf
      2026-04-karpathy-article-screenshot.txt
  wiki/
    index.md
    log.md
    sources/
    entities/
    concepts/
    loops/
    decisions/
    questions/
    contradictions.md
    lint.md

Recommended responsibilities:

• raw/sources/ stores immutable text sources: articles, gists, transcripts, issue exports, repo notes, and copied thread text.
• raw/assets/ stores original visual or binary artifacts: PDFs, screenshots, images, and OCR derivatives. A text extraction may sit beside the asset, but it does not replace the original.
• wiki/sources/ stores one generated summary page per raw source, with citations back to the raw file.
• wiki/entities/ stores people, companies, projects, tools, standards, repos, and named systems.
• wiki/concepts/ stores reusable ideas such as compiled knowledge, RAG versus wiki, source discipline, knowledge lint, and managed skills.
• wiki/loops/ stores executable loop designs: purpose, roles, state files, contract, evaluator rubric, restart policy, and trace-reading procedure.
• wiki/decisions/ stores durable recommendations that have crossed from synthesis into an operating policy.
• wiki/questions/ stores high-value answers that should compound instead of disappearing into chat history.
• wiki/contradictions.md records source disagreements, low-confidence claims, naming drift, and stale assumptions.
• wiki/lint.md records the latest health report and unresolved cleanup items.

Keep AGENTS.md short and operational. It should tell Codex what directories it may edit, how to cite sources, when to update index and log files, how to format ingest entries, and how to run lint. If the schema cannot be explained in a short AGENTS.md, the wiki is already too clever.

Source discipline

Rules:

• The agent may read raw/ but should not edit raw source files.
• The agent owns wiki/ and may update many wiki pages in one pass.
• Every generated page should cite the raw source pages or files it depends on.
• Screenshots and PDFs should remain in raw/assets/ even when OCR text is extracted.
• OCR or extracted text is a derivative source, not a replacement for the original artifact.
• A useful chat answer should become a wiki/questions/ page when it is likely to be asked again.

Ingest workflow

When the user says to ingest a source, Codex should:

1. Identify the source type: text, PDF, screenshot, issue, Slack thread, repo document, or web article.
2. Save or reference the immutable raw source.
3. Extract text when needed and keep the original artifact.
4. Write a source summary page.
5. Update entity pages.
6. Update concept pages.
7. Update loop pages when the source changes how work should be performed.
8. Add cross-references between related pages.
9. Add contradictions or uncertainty notes when sources disagree.
10. Update wiki/index.md.
11. Append an entry to wiki/log.md.
12. Report the wiki diff, not just a prose answer.

Query workflow

When the user asks a question, Codex should:

1. Read wiki/index.md first.
2. Read the smallest set of relevant wiki pages.
3. Answer with citations to wiki pages and underlying raw sources.
4. If the answer is durable, create or update a wiki/questions/ page.
5. Update the log if the query produced durable synthesis.

Lint workflow

Codex should periodically run a wiki health check that asks:

• Which pages have no inbound links?
• Which important concepts are mentioned but lack pages?
• Which entities have spelling or naming drift?
• Which claims are contradicted by newer sources?
• Which pages lack source citations?
• Which source summaries have not been integrated into concept or entity pages?
• Which loop pages lack role separation, state files, restart policy, evaluator rubric, or trace-reading guidance?
• Which questions produced useful answers that were never filed?

The lint output should be a patch plan or issue list, not a vague quality statement.

Recommended Forge organization

Forge should own the portable method, not the contents of any specific wiki. Codex should maintain project-specific knowledge bases. Forge should package the repeatable operating procedure that teaches Codex how to do that consistently across machines and repos.

Recommended Forge organization:

forge/
  docs/
    codex.md
    llm-wiki.md
  .agents/
    skills/
      knowledge-systems/
        llm-wiki/SKILL.md
        effective-loop-writer/SKILL.md

Forge-managed llm-wiki skill

Add a Forge-managed skill such as llm-wiki with:

• frontmatter that clearly triggers on ingesting, querying, or linting a file-backed knowledge base,
• Use this when and Do not use this when boundaries,
• the directory contract above,
• the three operations: ingest, query, lint,
• source discipline for raw files, OCR text, and screenshots,
• an output contract that requires a file diff or a concrete lint report.

The skill should be installed into Codex's user skill location through Forge's managed skill system.

Forge-managed effective-loop-writer skill

Add a second Forge-managed skill that does not maintain a wiki directly. Its job is to interview the human and iteratively prompt them into a good loop design according to the raw article's rules.

The skill should help the human produce a loops/NAME.md file with:

• the loop purpose and non-goals,
• planner, generator, and evaluator role boundaries,
• the on-disk state files the loop must maintain,
• a negotiated contract.md template,
• evaluator assertions and subjective rubric axes,
• restart conditions and human-intervention conditions,
• trace-reading instructions,
• harness-deletion criteria,
• the current bottleneck the loop is meant to expose.

This is useful because many users will not know how to ask for a good loop. A skill can ask the missing questions in order: what should run unattended, what counts as done, what should be written to disk, who grades the work, when may the agent restart, and which trace would reveal failure. The artifact is not merely a prompt. It is a loop spec that Codex or another agent can execute and improve.

Codex baseline

Forge should also ensure the user-scoped Codex baseline points Codex toward the relevant skill when a user asks to build a knowledge base or design an agent loop.

That can happen through:

• the managed skill descriptions,
• the forge-tools router if it becomes relevant to Forge-owned tools,
• the user AGENTS.md rendered by forge codex install, if the behavior is broad enough to be part of the global Codex operating policy.

CLI primitives later

Only add a Forge CLI after manual Codex usage reveals repeated mechanical operations. Good candidates might be:

• forge wiki lint --json,
• forge wiki inventory --json,
• forge wiki links --json,
• forge wiki ocr FILE if OCR handling becomes frequent and stable,
• forge wiki source add PATH_OR_URL if source capture needs deterministic metadata,
• forge loop lint loops/NAME.md if loop specs converge on a stable schema.

Do not build these first. Start with files and skills because the schemas will change during the first few real ingests and loop designs.

Hosted application boundary

Codex reviewed the current RFD app and recommended against turning this public RFD site itself into the hosted startup knowledge base. The current app should remain the proposal and decision record: /rfd plus numeric RFD pages. That boundary is useful because RFDs have a different product contract than a company wiki. RFDs record proposals, arguments, tradeoffs, and determinations. A wiki or resource base records current compiled operating knowledge.

The recommended product shape is a sibling private knowledge-base app that reuses the RFD reader primitives where useful:

• MDX rendering,
• document shell,
• generated table of contents,
• catalog rows and filters,
• search modal,
• folder-backed assets,
• git-backed review,
• the existing dark reader visual language.

A copy or fork is acceptable for a short prototype, but the first refactor should rename the domain model away from RFDs and introduce explicit page types such as wiki, resource, source, decision, question, and contradiction. The long-term application should not inherit numeric-only slugs, RFD-specific metadata, or document-frontmatter allowlists as its core model.

Options considered

1. Extend the current RFD site. This is superficially fastest, but it blurs public RFDs, private source summaries, resources, wiki pages, and company operating knowledge. It also conflicts with the repo's explicit route contract: public routes are /rfd and numeric RFD slugs. Use this only to publish public RFDs about the knowledge-base pattern.
2. Copy or fork the app. This is the fastest useful prototype. It can inherit the reader, MDX pipeline, search shell, and styling. The risk is accidentally preserving RFD names, numeric slug assumptions, and weak document-level ACLs too long.
3. Build a sibling app. This is the preferred long-term direction. Keep /rfd as decision history and build a private knowledge-base product with clean routes such as /wiki, /resources, /sources, /decisions, and /questions, or deploy it as a separate private app.

Small startup knowledge-base requirements

A startup knowledge base needs more than RFD pages:

• Page types: wiki, resource, how-to, source-summary, decision, question, contradiction, and glossary.
• Metadata: owner, team, source references, reviewed date, freshness, confidence, visibility, and lifecycle state.
• Workflows: ingest raw sources, update compiled pages, answer from compiled pages, file durable answers, and lint stale or conflicting pages.
• Review: agent-generated changes should land as reviewable diffs or pull requests before publication.
• Discovery: full-text search, type/team/status filters, backlinks, related sources, and recent changes.
• Governance: accepted or superseded RFDs should update wiki/resource pages, and wiki/resource pages should cite RFDs as source history.

Permission and privacy risks

The existing RFD app has useful server-side filtering through allowedGitHubUsers, but that should not become the security model for a company knowledge base. It is document-frontmatter ACL, not org/team policy. A company knowledge base should be deny-by-default and should support organization or team membership checks, filtered search indexes, source-level visibility rules, no restricted-page metadata leakage, and audit trails for reads and agent-generated edits.

This also argues for a separate private deployment or repo before sensitive material is added. Public RFDs can describe the pattern. Private startup knowledge should live behind a stronger product boundary.

Hosted rollout

1. Keep the current RFD site unchanged except for public RFDs about the knowledge-base pattern.
2. Create one private file-backed knowledge base with raw/, wiki/, sources/, decisions/, questions/, and contradictions.md.
3. Seed it with ten or fewer sources and run manual Codex ingest, query, and lint passes.
4. Build a read-only sibling app around the proven content shape.
5. Add deny-by-default permissions before adding sensitive material.
6. Require agent changes to land as reviewable diffs or pull requests.
7. Add deterministic lint, search, and index helpers only after the manual workflow stabilizes.

Electronics knowledge-base extension

The sibling app could also become an electronics parts, datasheet, and analysis-pattern database. That use case strengthens the argument for a sibling app rather than expanding the current RFD site: electronics knowledge has structured records, source PDFs, derived tables, calculations, comparison matrices, and reusable review patterns that do not fit cleanly into numeric RFD pages.

The useful product is not a folder of PDFs. It is a compiled electronics knowledge layer that distills datasheets and design notes into queryable, reviewable forms:

• Parts: manufacturer part numbers, aliases, lifecycle state, package, key limits, recommended operating conditions, derating notes, availability, approved alternates, and links to raw datasheets.
• Datasheet extracts: normalized tables for absolute maximum ratings, electrical characteristics, timing, thermal data, package dimensions, application circuits, layout guidance, and errata-like caveats.
• Comparison sets: side-by-side pages for regulators, op-amps, connectors, MCUs, RF parts, power devices, passives, and alternates under consideration.
• Analysis patterns: reusable checks such as regulator thermal margin, input capacitor ripple current, op-amp stability, ADC drive impedance, RF link budget assumptions, connector current derating, creepage/clearance, and ESD protection placement.
• Design evidence: source citations, extracted equations, assumptions, calculator outputs, screenshots, and review decisions that explain why a part was accepted or rejected.
• Project usage: where the part appears, what constraints drove the selection, known risks, test results, and substitutions.

The app should treat PDFs as immutable raw sources, not as the final knowledge object. An agent can ingest the datasheet, extract structured facts into typed pages, cite the PDF page or table, compare candidate parts, and create a reviewable diff. The human then reviews the distilled form instead of re-reading several vendor PDFs every time.

This is now scoped as follow-on RFD 0014. RFD 0013 should define the general compiled-knowledge pattern and note electronics as a high-value domain. RFD 0014 scopes the electronics sibling app in detail: data model, page types, import workflow, validation checks, calculation plugins, permissions, and how it relates to existing ECAD review work.

Codex versus Forge ownership

Codex should own the active knowledge work:

• reading sources,
• generating pages,
• updating cross-references,
• resolving contradictions,
• answering from the compiled wiki,
• producing reviewable diffs.

Forge should own the portable behavior contract:

• installing the skill,
• keeping the skill versioned,
• rendering the Codex baseline,
• packaging any stable helper tools,
• preventing the workflow from drifting across machines.

A good boundary is:

Codex maintains a specific wiki.
Forge maintains the reusable method that teaches Codex how to maintain wikis.

How this changes looping agents

The current looping-agent note should be revised from an execution-only loop to a compounding loop.

Current loop:

queue tasks -> agent works overnight -> human reviews in morning -> repeat

Better loop:

queue tasks and sources -> agent works overnight -> agent updates project knowledge -> human reviews code and wiki diff -> merged knowledge guides the next night

This means every unattended run should ask:

• What did the agent learn that future runs should not rediscover?
• Which decisions, traps, constraints, or source findings belong in the wiki?
• Did the agent update the index and log?
• Did lint catch contradictions or stale assumptions?

Without that, overnight loops can produce more work but not necessarily more institutional memory.

How to write effective loops

The raw article says to stop optimizing a single prompt and instead write the loop. For this RFD, an effective loop is a small, restartable, file-backed procedure that can run unattended and make its own failure modes visible.

A good loop spec should answer these questions in order:

1. What is the loop trying to make repeatable? State the work in verbs: gather, reason, act, verify, repeat. If the work cannot be expressed as a short repeated procedure, it is not ready for automation.
2. Which roles are separated? Define planner, generator, and evaluator as distinct roles with distinct contexts. The generator must not grade its own work. The evaluator should assume the output is broken and prove whether it satisfies the contract.
3. What contract is negotiated before work starts? The generator and evaluator should agree on contract.md before the first implementation attempt. The planner's spec is the boundary; the contract is what gets graded.
4. What state is written to disk? Prefer a tiny set of durable files such as feature_list.json, progress.md, contract.md, and append-only log.md. The loop should survive session loss by reading those files.
5. When may the loop restart? Deleting bad work can be correct behavior. Insert a human when the contract is wrong, not merely when the build is broken.
6. How is subjective quality scored? Taste needs a rubric. Use weighted axes such as design, originality, craft, and functionality, then calibrate against examples of good and bad output.
7. Which traces will be read? Pipe raw agent transcripts to disk. Debug the loop by finding the exact moment the model's judgment diverged from the human's judgment and editing the loop for that moment.
8. What harness can be deleted later? The harness compensates for the current model. Review it as models improve and remove steps that have become overhead.
9. Which bottleneck is the loop exposing now? The point is not to finish automation forever. The point is to make the next bottleneck visible: planning, verification, taste, source capture, review, or something else.

The effective-loop-writer skill should turn those questions into an interactive interview. It should not begin by asking the human for a perfect prompt. It should help the human produce the loop files that future agents can run, inspect, and improve.

A minimal loop artifact should look like this:

loops/overnight-feature-run/
  loop.md
  contract.md
  evaluator-rubric.md
  state/
    feature_list.json
    progress.md
    log.md
  traces/

loop.md should explain the role split, state files, restart policy, trace policy, and current bottleneck. contract.md should contain testable assertions. evaluator-rubric.md should define both objective checks and subjective scoring. The state/ files let the loop resume. The traces/ directory lets the human debug the harness rather than tuning by vibe.

Initial rollout plan

1. Start with one small wiki, not a universal system.
2. Seed it with ten sources or fewer.
3. Include mixed source types: markdown, web article, PDF or screenshot, repo note, and thread text.
4. Run three operations manually with Codex: ingest, query, lint.
5. Revise the schema after the first messy ingests.
6. Convert the proven schema into a Forge-managed skill.
7. Install the skill through Forge.
8. Prototype a private sibling knowledge-base app only after the file-backed shape has proven useful.
9. Use RFD 0014 as the scoped follow-on for the electronics parts, datasheet, and analysis-pattern database.
10. Only then consider a small Forge CLI for repeatable lint or inventory checks.

Open questions

• Should the first private startup wiki live in a dedicated knowledge/ repo, inside a private sibling app, or inside each project repo?
• Which RFD reader primitives should be extracted into shared components before a sibling app is created?
• What is the default citation format for raw PDFs, screenshots, and Slack thread exports?
• Should useful chat answers be filed automatically or only after explicit approval?
• Which lint checks can be deterministic enough to become a Forge CLI?
• Which parts of 0014 should be validated before implementation?

Determination

Adopt Karpathy's LLM Wiki pattern as the next evolution of looping agents.

For Codex, the immediate implementation should be a file-backed wiki-maintainer workflow with raw sources, generated wiki pages, schema, index, log, ingest, query, and lint.

For Forge, the immediate implementation should be a managed skill and Codex baseline refinement, not a new CLI. Forge should package the portable behavior once the manual Codex loop proves stable. CLI automation should come later, after repeated use reveals narrow deterministic operations worth owning.

For the RFD app, the determination is to keep the current site focused on RFDs and decision history. A small startup knowledge base should be a private sibling app or short-lived fork that reuses the reader primitives, adds explicit wiki/resource/source page types, and implements stronger permissions before hosting sensitive company knowledge. Electronics parts, datasheets, and analysis patterns are a strong candidate domain for that sibling app, but they should be scoped in a follow-on RFD rather than overloading this pattern RFD.

The principle is simple: use agents not only to do more work, but to maintain the knowledge that makes the next work cheaper.

Raw source

Abstract. This file exists because most agent systems die not from a weak model but from a weak harness. The model can write code; the model can review code; the model can verify its own output against a rubric it agreed to ten minutes ago. What it cannot do, on its own, is decide when to stop, when to restart, and where to write the result. That is the work of the loop. The pattern in this note treats the loop as a first-class object: roles are separated, state lives on disk, contracts are negotiated between agents before the first line of code, and the loop knows what to do whenever something goes wrong. Short loops, simple state, clean contracts. Everything else is decoration.
Index Terms. agentic loops, Claude Code, harness design, generator-evaluator pattern, sprint planning, file-system state, contract negotiation, trace reading, deletable scaffolding.
I. WRITE THE LOOP, NOT THE PROMPT
A prompt is a thing you type once and forget. A loop is a thing that runs while you sleep. The unit of leverage stopped being the prompt the moment models became good enough to follow a procedure without supervision; what matters now is the procedure. If you find yourself iterating on a single message at three in the morning, you are still in the prompting era. Close the tab. Write the loop. The loop is short: gather, reason, act, verify, repeat. Everything in this document is a footnote on those five verbs.
II. SEPARATE THE ROLES
Three roles, three context windows, three system prompts. A planner that turns a vague human sentence into a sprint spec and never touches code. A generator that writes everything and is forbidden from grading its own work. An evaluator that reads diffs, launches playwright, plays the app, and is told from the first message that the code is broken and its job is to prove it. Mixing the roles is the most common failure I see; the model becomes sycophantic the moment it grades itself, and the loop quietly converges on slop.
III. NEGOTIATE THE CONTRACT FIRST
Before the generator writes a single line, it proposes what done looks like and the evaluator pushes back. The two argue via markdown files on disk until they agree on a checklist of testable assertions. Twenty-seven criteria is a reasonable size for a small app; ten is usually too few and the evaluator rubber-stamps. The original spec from the planner is the boundary, but the contract is what gets graded. This is the single change that moved my own runs from broken demos to working products.
IV. WRITE TO DISK, NOT TO CONTEXT
Context windows lie. They compact, they rot, they hide what you said an hour ago behind a summary you did not write. A file on disk does not lie. Keep feature_list.json, progress.md, contract.md, and an append-only log.md with ## [YYYY-MM-DD] op | title entries. The model should be able to crash, lose its session, and pick up where it left off by reading three files. If you cannot describe your state in three files, your state is too complicated.
V. LET THE LOOP RESTART
Counter-intuitively, the best behavior I see from current frontier models is the willingness to throw everything away and start over when a run goes sideways. Older models patched and patched until the codebase resembled archaeology; newer ones, given a clean evaluator and a contract on disk, will delete the project at iteration nine and ship a working version at iteration eleven. Do not interrupt this. The restart is the loop working correctly. Insert a human only when the contract itself is wrong, not when the build is.
VI. SCORE THE SUBJECTIVE
Taste is gradable if you write it down. Four axes, weighted: design, originality, craft, functionality. Calibrate on three reference sites the evaluator is told are good and three it is told are slop. The output is a number between zero and one and a paragraph explaining the gap. The model will not invent taste; it will only converge toward the taste you described. The whole game is writing the rubric carefully enough that converging toward it is what you actually wanted.
VII. READ THE TRACES
Every debugging insight I have about agent loops came from reading the raw transcript, not from running another experiment.
Pipe the agent's output into a file, grep for the moment its judgment diverged from yours, edit the prompt for that exact moment, run again. This is the same muscle as reading a stack trace; the difference is that the trace is written in English and most of it is the model talking to itself. Skip this step and you are tuning by vibe.
VIII. DELETE THE HARNESS
The harness exists to compensate for the model. As the model improves, half of what you wrote last quarter becomes overhead.
Context resetting between sessions was load-bearing for one model generation and dead weight for the next; sprint decomposition was the only thing keeping a four-hour build coherent and is now a constraint on a model that holds two hours in one head. Re-read your harness against each new release and delete anything the model now does for free. The harness that grows monotonically is a harness you have stopped reading.
IX. THE BOTTLENECK ALWAYS MOVES
When coding stops being the bottleneck, planning becomes the bottleneck. When planning is solved, verification becomes the bottleneck. When verification is automated, taste becomes the bottleneck. You do not finish; you find the next thing to fix. The whole point of the loop is to make the next bottleneck visible. If everything is going smoothly, you are not looking carefully enough.
Find the new bottleneck, fix it, ship a smaller harness, repeat.

References

• Andrej Karpathy, LLM Wiki
• Local looping-agent note shared during drafting
• Forge Codex source-of-truth guidance shared during drafting
• Forge managed skill pattern examples shared during drafting