Harness design: prior work still to read
The pieces the 2026 harness-design posts build on — Anthropic's earlier long-running-agent harness, context engineering, building effective agents, the frontend design skill — captured as references because the article bodies could not be fetched from this session.
The owner asked for the prior work linked from
the Anthropic harness-design post to go
into the inbox too. The bodies could not be retrieved by the ingest session that wrote this
page — www.anthropic.com returned 403 Host not in allowlist there — so this page is the
reference list, described from what the harness-design post says about each.
That blocker turned out to be per-session, not environmental. A later session (the
2026-07-26 oracle query on implementing the harness) fetched www.anthropic.com without
trouble, and the frontend-design skill is installed locally on the owner's machine. So all
four are reachable and this page can be replaced with real notes whenever /ingest is run
from a session that has network access. Tracked in
tasks/2026-07-26-clip-harness-design-prior-work.md.
The four
Effective harnesses for long-running agents — Anthropic Engineering. The direct predecessor and the one I most want in full. An initializer agent decomposes a product spec into a task list; a coding agent implements one feature at a time and hands off structured artifacts to carry state across sessions, with full context resets in between. Built on Sonnet 4.5, whose context anxiety is what made resets load-bearing. Two lessons carried forward into the newer work: decompose the build into tractable chunks, and use structured artifacts for handoff.
Effective context engineering for AI agents — Anthropic Engineering. Cited for the underlying failure mode: coherence decays as the context window fills. The distinction between compaction (summarize in place, keep going) and a reset (clean slate plus a handoff artifact) is the practical consequence.
Building effective agents — Anthropic Research. Cited for the principle the harness simplification was justified against: find the simplest solution possible, and only increase complexity when needed. Older than the rest and the most likely to be worth reading in full for its own sake.
The frontend design skill — anthropics/claude-code, plugin skill.
The prompt-engineering starting point that preceded the generator/evaluator work. In the
full-harness run it was given to the planner, which read it and derived a visual design
language for the app as part of the spec — which is a more interesting use of a skill file
than handing it to the agent that writes the CSS.
This one is no longer missing. It ships with the official Claude Code plugin
marketplace and is installed locally, so an agent session can read it from disk without
network access. Its most reusable part is a calibration list of the three looks AI design
currently converges on — cream #F4F1EA plus high-contrast serif plus terracotta;
near-black plus one acid accent; broadsheet hairline rules with zero border-radius — named
as defaults to avoid rather than as principles. That list is a ready-made fail condition for
an originality rubric; see Building a generator–evaluator harness: A practical implementation recipe.
No longer missing
The podcast where Karpathy uses "skill issue" — the one the owner recalled in
The harness is a skill issue without a link — has been captured and ingested. It is the
NoPriors episode of 2026-03-20; notes are in Skill Issue: Karpathy on code agents (NoPriors, 2026-03) and the
transcript is archived under sources/2026-07/karpathy-nopriors-skill-issue/. That
leaves the Leicht sovereign-AI piece and the returns-to-expertise paper as the two
outstanding items from tasks/2026-07-27-clip-sovereign-ai-and-expertise-sources.md.
Secondary
- Claude Opus 4.6 launch post — the capability claims the harness simplification leaned on: plans more carefully, sustains agentic tasks longer, more reliable in large codebases, better self-review and debugging, better long-context retrieval.
- Claude Agent SDK — what both harnesses were built on, and the source of the automatic compaction that replaced context resets.
- The "Ralph Wiggum" loop, Geoffrey Huntley — ralph and
loop — the community pattern both companies point at: hooks or
scripts that keep an agent in a continuous iteration cycle. OpenAI describes their
review-until-all-reviewers-are-satisfied loop as exactly this. Worth reading before
building anything similar here — though the pattern has since been absorbed into the tools
as
/goal,/loopand Stop hooks; see Keeping an agent running: goals, loops, hooks and schedules. - Execution plans as checked-in artifacts — referenced from the OpenAI harness-engineering post as how they handle plans for complex work. Directly relevant to the cross-session memory question in Agentic engineering: the work moves to the harness.
Linked from
- Agentic engineering: the work moves to the harnessThe emerging discipline around long-running coding agents — designing the scaffolding, feedback loops and environments that let an agent do reliable work, rather than writing the code yourself. Entry point for the harness-design cluster in this notebook.
- Building a generator–evaluator harness: A practical implementation recipeA staged plan for building the Anthropic generator/evaluator harness myself, cheapest step first — starting with the rubric alone and only adding orchestration where it earns its keep. Plus what's changed since the March post, and the third-party implementations worth reading.
- Loop engineering: from writing prompts to writing loopsThe claim that the unit of work is shifting from the prompt to the loop — Cherny, Osmani and Guzman all saying a version of it — and why the interesting question is not how to keep an agent running but who decides what "done" means.