10 Best Sources to Explore Harness

This study maps the components and design choices of a coding-agent harness. It discusses eleven coding-agent systems across seven subsystems, including the agent loop, tools, memory, permissions, and orchestration. It turns that comparison into 29 design patterns, 18 recommendations, and a 90-line starter harness. The comparisons describe implementations. It is a good source to start if you want to understand what sits around the model and how those pieces fit together.

It is our video where we discuss why better models can make some instructions and orchestration unnecessary, while agents still need tools, context, and permission controls. There is the tension behind harness engineering: adding support can help a model, but keeping that support after the model improves can get in its way. So we look at which parts of a harness to simplify and which responsibilities remain.

This video is about building agents whose tools and runtime components can change during execution with DeepSeek Harness. We explore its plugin architecture, where an agent can create a missing capability during a task, request permission to load it, use it, and remove it afterward. The interesting engineering problem is managing those plugins and their dependencies as the system changes.

Main idea:

How should an agent check its work? This study compares instructions, reminders, completion gates, and independent critics. A critic starts with fresh context, inspects the task and sandbox, and sends findings back for revision. Independent review improves accuracy across the tested Terminal-Bench and SWE-bench Verified subsets with relatively modest added cost. It gives builders concrete verification designs to test, while leaving open how well they transfer to other workloads.

HarnessMM stores already-resolved actions in executable decision graphs, with arguments, dependencies, and guards. When tool results satisfy those guards, the harness can execute the stored action without another model callback. New semantic decisions go back to the model. On one 98-task HumanEval test split, Codex used 29.54% fewer actor tokens at unchanged success. That is evidence for token savings in that setup, not a guarantee of lower latency or unchanged quality everywhere.

This paper organizes harness self-evolution by what an agent changes: prompts, memory, workflows, tools, runtime logic, or plugin composition. It separates proposing a revision from deciding whether to keep it, with accepted changes carried into later runs while model weights stay fixed. Its theoretical analysis examines generalization and regression control under explicit assumptions. It is a useful overview before exploring individual methods such as Harness² and OO-Harness that you’ll see further.

Harness² proposes harness edits, probes their behavior, and combines promising changes for an unfamiliar task. Its Propose–Probe–Compose loop works without ground-truth task feedback, and a second level retains lessons that can guide future edits. Model weights stay frozen. This is a useful starting point for task-specific adaptation

OO-Harness organizes specialized harnesses as subclasses that inherit shared behavior. An evolution agent uses execution records to group tasks and create targeted variants. A router then chooses a suitable class or retains the base result. This is a way to specialize without rewriting the entire harness for every task or imposing every change on every workflow. The system evolves code and routing lessons while keeping model weights fixed.

Harness Scaling changes the training setup. It varies five components: system prompts, tool interfaces, observations, context management, and workflows. A selected set of 18 harnesses exposes reinforcement-learning policies to structured variation, with evaluation on unseen combinations and external harnesses. Read this alongside the harness-editing papers: it asks how to train a model that transfers across execution setups, rather than how to find one better setup around a frozen model.

Main idea: Training agents to work across different harness configurations.

Models build a harness, receive feedback from five ARC-AGI-3 development games, and revise it twice. The researchers then test the resulting snapshots on twenty held-out games. Improvements on development games don’t reliably carry over: the confidence interval for average held-out improvement includes zero. This is a useful counterweight to self-improvement claims, showing why a working revision needs fresh evaluation.

Main idea: Separating improvements on familiar tasks from gains that survive held-out testing.

An agent harness is the software around a model that manages its execution: assembling context, exposing tools, running actions, recording state, and applying controls. Its design shapes what the model can do and how its work is checked.

Prompt engineering changes the instructions and examples a model receives. Harness engineering also changes the execution loop, tool interfaces, memory, permissions, verification, and recovery behavior. Prompts are one component of that broader system.

They still need software that connects them to tools and environments and enforces access rules. Better models may need fewer reminders or less prescribed orchestration, but model capability does not remove the need to manage execution and permissions.

Research systems can propose and evaluate changes to harness code or configuration. Harness² and OO-Harness explore different ways to do this with fixed model weights. Whether a change helps on new tasks needs separate testing; improvements on development tasks alone are insufficient.

Start with the eleven-system source-code study for the architecture, or the first video for the broader debate. Then choose verification, token efficiency, task-specific adaptation, or training across harnesses according to the problem you are trying to solve.

Thank you for reading! Share this list with a friend who likes to stay ahead of what’s happening in AI.