Advanced

The harness is everything that is not the model: the prompts, the tool definitions, the policy for what enters the context, the step and cost limits, the sandbox, the retries, the subagents, the recovery path when a run dies. Addy Osmani's formulation is that a harness is every piece of code, configuration and execution logic that is not the model itself. The shorthand doing the rounds is agent = model + harness.

This matters because the model is the part you cannot change. You did not train it and you will not retrain it. So all of your engineering leverage sits in the harness, and the quality difference between two teams using the identical model is almost entirely here.

• PrimaryEffective harnesses for long-running agents Anthropic, November 2025. The reference for this section. How to keep an agent making progress across many separate context windows.
• PrimaryHarness design for long-running application development Anthropic, March 2026. The follow-up, on building whole applications this way.
• ArticleAgent Harness Engineering Addy Osmani, April 2026. The clearest definition of the term and its parts.

Loop engineering is the step after harness engineering. The harness is the static scaffolding. The loop is the runtime cycle, and the move is to stop being the person who prompts the agent and instead design the system that prompts it: find work, assign it, check the result, record what happened, decide what comes next.

LangChain's framing is a useful ladder, because it separates things that get conflated.

• PrimaryLoop Engineering Addy Osmani, June 2026. The essay most people are citing when they use the term.
• ArticleThe Art of Loop Engineering LangChain, June 2026. Where the four-loop ladder above comes from.
• ArticleLoop engineering: stop prompting, start looping Postman. Focused on the verification half: generate, run, verify, decide, repeat until something real says stop.
• DocsDynamic workflows in Claude Code A worked implementation you can read and run.

A task that needs four hours of work does not fit in one context window, and no window size fixes that. The answer is to stop treating the context as the place where state lives. State goes on disk: a plan file, progress notes, commits, a feature list. The context becomes a scratch space you are willing to throw away.

Once that is true, a full context reset stops being a failure and becomes a normal operation. The harness tears the session down and rebuilds it from the written record, and the agent picks up where the last one stopped. This is the single biggest idea on this track.

• PrimaryEffective harnesses for long-running agents Anthropic. Progress notes, git history and feature lists as the mechanism for continuity.

Several agents, each with its own context and job, coordinated by a lead. The real reason to do this is not that many agents are smarter than one. It is that context is finite, so giving each subtask a clean window of its own buys capacity that a single agent cannot have.

It costs a lot of tokens, which is the honest trade. Reach for it when subtasks are genuinely independent and the work is read-heavy, such as searching a large codebase or reviewing a change along several dimensions at once. Avoid it when the subtasks need to agree with each other, because keeping several agents consistent is harder than doing the work once.

• PrimaryHow we built our multi-agent research system Anthropic. Architecture, prompting for delegation, and the evaluation problems it created.
• Case studyBuilding a C compiler with a team of parallel Claudes Anthropic. A long, genuinely hard task run this way, with what broke.

Ordinary retrieval cannot answer a question whose answer is not contained in any single chunk. "What are the recurring themes across these two hundred incident reports" is not findable by similarity search, because the answer exists only in the aggregate.

GraphRAG builds a knowledge graph from your text first: it extracts entities and relationships, clusters them into communities, and writes a summary of each community. A question can then be answered from the summaries for a broad question or by walking the graph for a specific one.

The cost is real. You are running extraction over your whole corpus, and re-running it as the corpus changes. Justify it with a question that ordinary retrieval provably cannot answer, and keep that question as your test.

• DocsGraphRAG Microsoft. The reference implementation, with the indexing pipeline documented.
• CourseBuilding Knowledge Graphs with LLMs Neo4j GraphAcademy. Free, hands-on extraction into a graph.

A different answer to the long-input problem. Rather than enlarging the window or retrieving a slice, leave the input where it is and give the model a programming environment instead. The prompt sits in a Python session as a variable. The model writes code to inspect it, slice it and search it, and calls fresh copies of a model on individual pieces when it needs to read one properly.

No single call ever sees the whole input, so no single call overflows. The context window stops being a wall and becomes something the model navigates with code. Note what this inverts: retrieval decides what the model may see before it has seen anything, while here the model decides for itself what to look at next.

• PrimaryRecursive Language Models Alex Zhang and Omar Khattab, October 2025. The original write-up, and the clearest explanation.
• PaperarXiv:2512.24601 The paper, with Alex L. Zhang, Tim Kraska and Omar Khattab.

Tool definitions are not free. Connect a handful of MCP servers and you can spend tens of thousands of tokens on tool descriptions before the conversation begins, every single call. At that point the tooling is the context problem.

The fix is to stop pushing every definition into the window. Expose tools as code the model can discover and call, load definitions on demand, and let it pass data between tools without routing every intermediate result through the context. A tool that returns a ten thousand row result set should hand back a handle, not ten thousand rows.

• PrimaryCode execution with MCP Anthropic. Presenting servers as code to cut the token cost of tool definitions.
• PrimaryAdvanced tool use Anthropic. Tool search, programmatic calling, and passing results between tools.
• PrimaryAgent Skills Anthropic. Packaging procedural knowledge so it loads when relevant instead of sitting in every prompt.

Any eval used as a target gets optimised against, including by the model. Three failure modes are worth knowing by name, because you will hit all of them.

• Contamination. Your test cases end up in training data, or in a prompt, or in the repository the agent can read. The score goes up and nothing improved.
• Eval awareness. A model can recognise that it is being tested and behave differently from how it behaves in production. Anthropic has published measurements of exactly this.
• Infrastructure noise. Flaky tests, network timeouts and container limits move agent scores by amounts large enough to swamp the difference you are trying to detect. Measure your own variance before you believe a gap.

• PrimaryDemystifying evals for AI agents Anthropic. Start here.
• PrimaryDesigning AI-resistant technical evaluations Anthropic. Building tasks that are hard to game.
• PrimaryQuantifying infrastructure noise in agentic coding evals Anthropic. How much of a score difference is just your test rig.
• PrimaryEval awareness in BrowseComp performance Anthropic. A model noticing it is being evaluated.

Most of us will never train a base model, and that is fine. What is worth understanding is the shape of the pipeline, because it explains model behaviour you otherwise have to treat as magic: why a model is helpful rather than merely a text predictor, why it refuses some things, why it is confidently wrong in a particular style, and what fine-tuning can and cannot change.

Karpathy's GPT-2 reproduction is the honest version of this. It is four hours and it is a real training run, with the data handling, the hyperparameters and the debugging left in rather than tidied away.

• CourseHugging Face LLM Course The fine-tuning chapters, if you need to actually do it.

• You have taken an agent that failed on a long task and fixed it by changing the harness, with a before and after you can show.
• Your agent's state lives on disk, and a fresh session can resume from it. You have tested that by killing one.
• You have a verification loop where the grader is not the generator.
• Every loop you own has a hard ceiling on steps, time and spend.
• You have measured your eval's run-to-run variance and know which score differences are real.
• You can explain where recursive language models and GraphRAG each beat ordinary retrieval, and where they are not worth the cost.