How Agentic Harnesses Work, Visually

The machinery around the model: loops, tools, hooks, skills, MCP, memory, and agents that run for days

Pranjal Rawat

One model, one shot

A language model is astonishing for an hour and helpless over a week. It forgets everything between sessions, grades its own homework, and stops when the transcript looks finished, not when the work is.

The harness is everything built around the model to fix that.

This deck is about the machinery, not the model: the loop, the tools, the hooks, the skills, MCP, the memory files, and the multi-session engines that let an agent work for days. The sibling decks cover git and RAG; this one covers the thing that runs them.

Ask for too much

One prompt, one model, twelve features. The model gets a single forward pass at a time, and a context window that does not grow with the job.

This is the founding problem of the whole field: real work outlasts one context. Everything in this deck follows from taking that seriously.

Shift workers with amnesia

Long work means many sessions. Anthropic’s harness paper puts it plainly: each new session “begins with no memory of what came before.”

Anthropic, Effective harnesses for long-running agents (2025)

The quote is verbatim from the keystone source. The shift-worker frame is the single most useful mental model in the deck: every harness component is something you would also build for human shift workers - a logbook, a task board, a test suite, a door that locks.

Meet tinyharness

Every figure ahead is a photograph of one real, executing system: a tiny Python harness wrapping a scripted model, building a real CLI app from a real 12-item feature list, with a real test suite as the judge.

Same honesty contract as the sibling decks: the RAG deck runs a real toy corpus, the git deck drives a real repository, this deck runs a real toy harness. The one scripted part is the model’s dialogue, which is what makes every run reproducible and every figure assertable by code.

The Problem

The Problem

The Problem

The Problem

The Problem

The Problem

Part 1 · The Loop

Start from the atom. A model call is a pure function of its context. Tools give it hands. The loop gives it persistence.

The harness is everything around the model that lets it work longer than one context window.

Grounding: docs/long-running-agents-research.md · autonomous-loop-patterns.md

Context window

Every model call sees exactly one thing: the column of text built up so far, system prompt, prior turns, tool results, nothing more.

Context window: the column the model reads before each forward pass. It is the model’s entire universe for that call, and it does not grow with the size of the job.

One Call, One Context

One Call, One Context

One Call, One Context

One Call, One Context

One Call, One Context

Tools give it hands

A model call alone cannot touch the disk. A tool is a named action, read_file, write_file, run_tests, that the model can ask for and the harness actually executes.

Tool: a function the harness runs on the model’s behalf. The model only proposes the call, the harness executes it, and the real result is what comes back into the context.

Tools Close the Loop

Tools Close the Loop

Tools Close the Loop

Tools Close the Loop

Tools Close the Loop

Tools Close the Loop

Tools Close the Loop

The agent loop

One session is a cycle repeated until the model stops or the budget runs out: read the state, act, check the real consequence, then write down what happened.

Agent loop: orient (read what is true), act (call a tool), check (see the real result), record (persist the outcome), then repeat. Each lap feeds the next.

The Agent Loop

The Agent Loop

The Agent Loop

The Agent Loop

The Agent Loop

The Agent Loop

The Agent Loop

The Agent Loop

The Agent Loop

Anatomy of every harness

Strip away the branding and every long-running harness has the same six parts. The rest of this deck colors them in.

Synthesis of ~35 public sources: Anthropic engineering, Cursor, Osmani, Huntley, 12-factor agents

The survey doc behind this slide read across every public long-running harness it could find; these six parts appear in essentially all of them. The disk being the hub, not any process, is the load-bearing fact.

Part 2 · Feeding the Context

The context window is the model’s entire universe, and it is small. Skills, retrieval, and MCP are three disciplines for filling it with the right things at the right time.

Skills, RAG, and MCP are not separate features. They are three answers to the same question: what earns a place in a context window that never grows.

Skills load on demand

A skill is a packaged instruction set that only enters the context when the task actually matches it, in three tiers of cost.

Skill: a one-line index every session pays for, a full body that loads once the task matches, and reference spokes that load only if the body actually points to them.

Skills Load On Demand

Skills Load On Demand

Skills Load On Demand

Skills Load On Demand

Skills Load On Demand

Skills Load On Demand

RAG, in One Breath

RAG, in One Breath

RAG, in One Breath

RAG, in One Breath

The full RAG story is its own deck

Chunking, embeddings as geometry, hybrid search, reranking, cite-or-refuse. All of it, slowly, over a real corpus.

How RAG Works, Visually →

MCP, the universal port

MCP lets a separate program’s tools show up in the model’s tool belt, over a real JSON-RPC wire, indistinguishable from a built-in tool.

MCP (Model Context Protocol): a JSON-RPC handshake, initialize, list tools, call a tool, that turns foreign code into something the model calls exactly like a native tool.

MCP, the Universal Port

MCP, the Universal Port

MCP, the Universal Port

MCP, the Universal Port

MCP, the Universal Port

MCP, the Universal Port

MCP, the Universal Port

Part 3 · The Guardrails

Why not just tell the model the rules? Because prose competes with everything else in the column, and the model is graded on looking right.

A rule the model can read is a rule it can lose to compaction or talk past. A rule wired as a hook fires at the loop boundary, every time, whether the model remembers it or not.

Why the model can’t grade itself

One forward pass optimizes toward looks approved, not is correct. Four root causes, all structural, none fixable by asking nicely.

docs/why-root-cause-2026-06-24.md, “Why the agent keeps making these mistakes”

The punchline is verbatim from the root-cause doc. This is the theory beat of the deck; everything in Part 3 and Part 5 is a countermeasure to one of these four causes.

Gates, not prose

A rule written in the context ages, drifts, and competes with everything else there. A rule wired as code fires exactly when it applies, every time.

This is the pitch for hooks: deterministic code at the loop’s boundary beats instructions inside the stochastic part. The flipbook next shows a real gate really blocking a real command.

Hooks own the boundary

A hook is code, not a suggestion in the prompt. It sits at a fixed point in the loop, before a tool runs, after one finishes, when the model tries to stop, and can inject text, deny the call outright, or bounce the session back to work.

Hook: a callback wired to a loop event that returns a decision, allow, inject, deny, or continue, and the harness actually enforces it before the model’s next move.

Hooks Own the Boundary

Hooks Own the Boundary

Hooks Own the Boundary

Hooks Own the Boundary

Hooks Own the Boundary

Hooks Own the Boundary

Hooks Own the Boundary

Hooks Own the Boundary

Part 4 · Memory Across Sessions

The context dies with the session. Whatever should outlive it must move to disk before the lights go out.

The agent does not remember anything between sessions. The repo does. Whatever matters has to be written to disk before the context disappears.

Memory lives on disk

A fresh session starts with an empty context and no memory of the last one. What survives lives in files a new session reads back.

Memory file: anything on disk a session writes before it ends, and a later session reads on the way in, git history, progress.md, feature_list.json, CLAUDE.md or AGENTS.md.

Memory Lives on Disk

Memory Lives on Disk

Memory Lives on Disk

Memory Lives on Disk

Memory Lives on Disk

Memory Lives on Disk

Memory Lives on Disk

Compaction

A session that runs long enough fills its own budget. Compaction is the harness stepping in to shrink the column before the model ever notices.

Compaction: when the context passes its token budget, older turns are collapsed into one summary, keeping the earliest messages, that summary, and the most recent turns.

Compaction: What Survives

Compaction: What Survives

Compaction: What Survives

Compaction: What Survives

Compaction: What Survives

Compaction: What Survives

Compaction: What Survives

Pitfall: what a summary drops

A constraint that rides into the context as an ordinary message can be the exact thing compaction summarizes away. The flipbook above is not hypothetical: the same rule, unpinned, survived right up until one squeeze later it was gone, and the next write really broke it.

An unpinned rule is one summary away from not existing. Pin what must survive compaction, and back it with a hook that checks the outcome rather than trusting the column still says so.

The machinery, at a glance

Five pieces do the work of getting the right thing into a small context window, and of keeping the model inside a boundary it cannot talk its way past.

Tool

The harness executes, the model only asks. Real actions, real results back in the column.

Skill

Progressive disclosure. Index, body, spokes, loaded only as the task actually needs them.

MCP

A JSON-RPC port. Foreign code becomes a tool the model cannot tell from a built-in one.

Hook

A deterministic callback at a loop event. Injects, denies, or bounces, a gate not a suggestion.

Memory file

What outlives the session: git history, progress.md, feature_list.json, CLAUDE.md.

Part 5 · The Long Run

Now assemble everything into a harness that ships a project across many sessions: an initializer that builds the world, workers that do one feature each, a verifier with fresh eyes, a driver that refuses early victory, and a disk that survives any crash.

Sessions are cattle, not pets. Kill one mid-task and the disk survives untouched. An initializer, one-feature sessions, a verifier, a Ralph loop, and kill-and-resume durability together turn many short, amnesiac sessions into one long-lived project.

Anthropic, Effective harnesses for long-running agents · Long-running Claude for scientific computing

The Initializer

The Initializer

The Initializer

The Initializer

The Initializer

The Initializer

The Initializer

One Feature per Session

One Feature per Session

One Feature per Session

One Feature per Session

One Feature per Session

One Feature per Session

One Feature per Session

One Feature per Session

One Feature per Session

Four Failure Modes

Four Failure Modes

Four Failure Modes

Four Failure Modes

Four Failure Modes

Four Failure Modes

Four Failure Modes

Four Failure Modes

Four Failure Modes

Executor vs Verifier

Executor vs Verifier

Executor vs Verifier

Executor vs Verifier

Executor vs Verifier

Executor vs Verifier

Executor vs Verifier

Pitfall: grading your own homework

The executor above marked F10 green while its own test was failing. Not malice, just the structural bias from Part 3: a claim is cheaper to produce than a check.

An agent that self-certifies is not verified. Only a fresh agent with zero shared context, or a hard gate that reruns the real oracle, can confirm the work actually holds.

The Ralph Loop

The Ralph Loop

The Ralph Loop

The Ralph Loop

The Ralph Loop

The Ralph Loop

Kill It, and Resume

Kill It, and Resume

Kill It, and Resume

Kill It, and Resume

Kill It, and Resume

Kill It, and Resume

Kill It, and Resume

The long-run harness patterns

Five patterns, assembled, turn many short amnesiac sessions into one project that ships.

Initializer

Session one builds the environment, not the app: feature list, run instructions, plan, log, tests, zero app code.

One-feature session

Get bearings, confirm the app is not already broken, ship exactly one feature, verify, commit, log.

Verifier

A second, fresh agent with zero shared context. Only artifacts cross the wall, it reruns the oracle instead of reading the claim.

Ralph loop

A stop hook that re-reads the feature list from disk on every stop attempt and bounces the session until the oracle says done.

Kill-and-resume

Nothing precious lives in the process. SIGKILL a session and the disk survives, a fresh session resumes only what was interrupted.

The Whole Machine

Many brains, many hands

At fleet scale the same shapes recur. Flat self-coordinating agents deadlock; planner, worker, and judge scale.

Cursor, Scaling long-running autonomous coding · Anthropic, Scaling managed agents

Cursor’s flat experiment produced agents that deadlocked on file locks and grew risk-averse; the planner/worker/judge pipeline shipped a browser-scale codebase. Managed Agents decouples the brain from the hands so sessions are cattle, not pets.

The whole machine

Every element the deck introduced, on one map.

The assembled map mirrors the anatomy slide from Part 1, now with every box filled in by a flipbook the viewer has watched actually run.

The harness carries the intelligence

A stronger model helps. A stronger harness helps more, because every component encodes something no model can do alone: remember, verify, refuse, survive.

“The agent doesn’t get smarter across iterations. The codebase gets smarter, and the next agent reads it.”

Existence proofs: a C compiler built over ~2,000 fresh sessions, each reading the repo cold. A scientific solver run for weeks on checkpoints and an oracle. Neither needed a bigger model. Both needed a better harness.

Quote: Geoffrey Huntley, the Ralph technique · docs/long-running-agents-research.md · Anthropic, Long-running Claude for scientific computing

Coda · Beyond the Toy

Meet Smolagents

Every loop in this deck was hand-built to be photographed. The same shape also runs inside a real, open-source library.

Smolagents: a lightweight, open-source Python agent library from Hugging Face. Give a ToolCallingAgent a model and a list of tools. It runs the same loop tinyharness hand-built, for real.

tinyharness, Meet Smolagents

tinyharness, Meet Smolagents

tinyharness, Meet Smolagents

tinyharness, Meet Smolagents

tinyharness, Meet Smolagents

The same loop, for real

Every frame above is smolagents’ own ToolCallingAgent running. Real ToolCall and ToolOutput objects, real agent.memory.steps, produced by the library itself, not by this deck. Only the model’s one answer per turn is scripted, the same honesty contract as tinyharness itself.

The loop tinyharness hand-built is the same loop a real lightweight framework runs. The model proposes an action, the framework parses a real tool call, the real tool executes, and the observation lands back in context. Same ORIENT, ACT, CHECK, RECORD lap as Part 1.

Beyond the toy

tinyharness stays small on purpose. The real ecosystem has a few names worth knowing.

Mem0: an open-source memory layer for agents. It gives a session persistent, cross-session memory in a real store, the same job Part 4’s disk-backed memory.md does by hand. Named here, not run in this deck.

Where this shape shows up

tinyharness

This deck’s own hand-built harness. Every part exposed, nothing hidden, built to teach the shape.

Smolagents

A real, lightweight, code-first agent library. A ToolCallingAgent or CodeAgent in a few lines, the same loop, production-real.

AutoGen + CrewAI

Heavier multi-agent frameworks. Many agents, roles, and conversations coordinated for you, more machinery, more to configure.

References

Anthropic engineering Effective harnesses for long-running agents · Long-running Claude for scientific computing · Scaling managed agents

Practitioners Cursor: scaling long-running autonomous coding · Addy Osmani: self-improving coding agents · Geoffrey Huntley: the Ralph technique · 12-factor agents

Siblings How Git Works, Visually · How RAG Works, Visually · How Inference & Serving Work, Visually · How Evals & Observability Work, Visually · How LangChain & LangGraph Work, Visually

Every figure in this deck: a real run of tinyharness, regenerable with build/regen_all.py