# What is an agent harness?

> An agent harness — sometimes called agent scaffolding — is everything wrapped around a language model to turn it into a working AI agent: the system prompts that frame it, the tools it can call, the skills that package its procedures, the evals that gate changes, the memory it carries between turns, and the orchestration loop that binds them. The model supplies capability; the harness decides how that capability behaves in production.

Canonical: https://moda.dev/agent-harness
Updated: 2026-09-04

The word harness borrows from test engineering, where a test harness is the fixture that holds a component in place so you can drive it and observe it. An agent harness holds a model the same way. The model itself is frozen and general-purpose; everything that makes it behave like your agent — knowing your product, calling your APIs, following your escalation policy — lives in the code and configuration around it. Two teams can deploy the identical model and get agents that behave nothing alike, because the harness is where the behavior actually comes from.

That makes the harness the highest-leverage surface in an agent system, and also the least examined one. Teams benchmark models for weeks and then assemble the prompts, tools, and memory around the winner in an afternoon. This guide defines each part of the harness, walks through the harnesses people actually run — from Claude Code and Codex to Microsoft's Agent Framework Harness, LangChain's DeepAgents, the open-source OpenHarness, and the 100-line mini-SWE-agent — explains why production failures usually trace back to the harness rather than the model, and covers how to map and improve one systematically.

## What is an AI agent harness?

An AI agent harness is the software wrapped around a language model to turn it into a working AI agent — the prompts, tools, skills, evals, and memory, bound together by an orchestration loop. It is the same layer the TL;DR above defines as an agent harness: the AI qualifier spells out what kind of agent is being harnessed, it does not name a different artifact. Whichever phrasing you searched for, everything on this page applies.

The quickest way to make the term concrete is a product that contains one: Claude Code is a Claude model running inside a heavily engineered harness of prompts, tools, skills, and orchestration. The model contributes raw capability; the harness determines how the deployed agent actually behaves — which is why the rest of this page covers the anatomy of the layer, how to build one, and how to improve it. Moda is a harness engineering platform for that improvement loop: it turns production traces into verified improvements to the prompts, tools, skills, evals, and memory of the harness you already run.

## What an agent harness is made of

Every production agent harness is some combination of six kinds of parts. Frameworks name them differently; the responsibilities are stable.

- Prompts: the system prompt and its fragments — persona, policy, formatting rules, injected context. The densest concentration of behavior per byte anywhere in the system.
- Tools: the functions the model can call, defined by schemas. A tool's name, description, and argument types are instructions to the model as much as they are an API contract.
- Skills: packaged procedures the agent can load for a class of task — instructions, examples, and sometimes scripts. Skills are how a harness accumulates competence without every prompt growing forever.
- Evals: the test cases that gate changes. An eval set built from real traffic is the difference between knowing a harness change is safe and hoping it is.
- Memory: what the agent carries across turns and sessions — conversation state, user facts, retrieval indices. Memory decides what the model sees, which decides what it does.
- Orchestration: the loop that binds the rest together — turn structure, retries, sub-agent routing, guardrails on input and output.

None of these parts are model weights. That is the defining property of the harness: every component is code or configuration a human can read, diff, review, and revert. When the agent improves, the improvement is visible in version control.

## What's the difference between an agent and a harness?

The cleanest way to hold the two apart is the formula the field has converged on: an agent is a model plus a harness. The two halves are different kinds of things — supplied differently, owned differently, and improved differently.

- The model supplies capability: language, reasoning, tool calling. It is general-purpose, frozen at training time, and rented from a provider — every competitor can rent the identical one.
- The harness supplies reliability: the prompts, tools, skills, evals, memory, and orchestration that aim the model's capability at your product, your users, and your policies — and keep it aimed as all three change.
- The agent is the composite the user actually meets: model plus harness, running in production. When someone says the agent failed, the actionable question is which half failed — and it is usually the harness.

The split matters because the halves improve on different terms. Improving the model means swapping or fine-tuning it — slow, expensive, and mostly out of your hands. Improving the harness means editing prompts, tightening tool schemas, adding skills, extending evals — fast, reviewable in version control, and entirely yours. Moda is a harness engineering platform built on that asymmetry: it turns production traces into verified improvements for the agent harness — prompts, tools, skills, evals, memory — because that is the half of the agent a team can actually change.

This boundary is distinct from the framework question. A framework is the kit you might build a harness with; the harness is the assembly you built; the agent is that assembly plus the model, doing work. All three words get used loosely, but the formula keeps them straight.

Source:

- LangChain, The Anatomy of an Agent Harness: https://www.langchain.com/blog/the-anatomy-of-an-agent-harness

## How do I build an AI agent harness?

To build an AI agent harness, you write two kinds of artifact: a small runtime — the agent loop that sends the conversation to the model, executes the tool call it returns, and repeats — and the repository files that define behavior: system prompts, tool schemas, skills, and memory configuration, gated by evals built from real traffic. That is the whole recipe; every serious harness, including the ones inside Claude Code and Codex, is this same structure grown one decision at a time. This is a guide to building a production agent's harness — the one your users hit — not to tuning a coding agent you drive yourself, so the bar throughout is evidence from real traffic, not personal preference. Seven steps, in the order they earn their place:

- Write the agent loop. An agent is a while loop: send the conversation to the model, execute the tool call it returns, append the result, repeat until the task is done. mini-SWE-agent shows this stage is about 100 lines of Python with the shell as the only tool.
- Write the system prompt. Say who the agent is, what it is for, the rules it must not break, and the output format you expect. Keep it short enough to reason about — every paragraph you add now is a paragraph you will one day have to prove is load-bearing.
- Define tools with tight schemas. The model reads a tool's name, description, and argument types as instructions. Make required arguments required, spell out units and formats, and return errors the model can act on instead of opaque failures.
- Decide what the agent remembers. Choose what carries across turns and sessions — conversation state, user facts, retrieval indices — and what gets compacted or dropped as the context window fills. Memory decides what the model sees, which decides what it does.
- Package repeated procedures as skills. When the agent needs the same multi-step recipe often, move it out of the system prompt into a loadable skill, so competence accumulates without the prompt growing forever.
- Build evals from real traffic. Capture production traces as test cases and gate every harness change on them. An eval set built from real traffic is the difference between knowing a change is safe and hoping it is.
- Instrument and iterate. Ship, capture complete traces, find where the harness fails real users, and route each fix to the component responsible. This step never ends — it is the practice this site calls harness engineering.

A framework or a prebuilt harness — the Claude Agent SDK, Microsoft's Agent Framework Harness, LangChain's DeepAgents — can stand in for the loop and the memory on day one, and that is a fine way to start. What no kit can write is the part that determines behavior: your prompts, your tool schemas, your eval set. Those are yours to build whichever framework you pick, and they are where two agents on the same framework diverge.

The order matters less than the discipline: build the smallest harness that does the job, and let production evidence rather than intuition decide what to add next. Moda is a harness engineering platform built for that last step — it maps the harness from your repository, attributes production failures to the prompt, tool, skill, eval, or memory component responsible, and verifies each improvement against replayed traffic before it ships.

Sources:

- SWE-agent, mini-swe-agent: https://github.com/SWE-agent/mini-swe-agent
- Anthropic, Building agents with the Claude Agent SDK: https://claude.com/blog/building-agents-with-the-claude-agent-sdk
- Microsoft Learn, Agent Framework Harness: https://learn.microsoft.com/en-us/agent-framework/agents/harness

## Agent harness examples: what are examples of agent harnesses?

The fastest way to make the definition concrete is to look at the harnesses people actually run. The term now covers four kinds of artifact: the harnesses inside agent products, the harnesses you can install or build on, the minimal harnesses research runs on, and the one your team already owns.

- Claude Code and Codex: the flagship coding agents from Anthropic and OpenAI are models inside heavily engineered harnesses — system prompts, file and shell tools, skills, sub-agent orchestration, context compaction. Anthropic now ships that layer for reuse as the Claude Agent SDK, describing it as "the agent harness that powers Claude Code." Much of what reads as model quality in these products is harness quality.
- Microsoft Agent Framework Harness: a batteries-included harness shipped as a framework feature. create_harness_agent (Python) or AsHarnessAgent (.NET) wraps any chat client with planning, todo tracking, file memory, context compaction, and tool approvals out of the box.
- LangChain DeepAgents: LangChain's harness-building library, built on the framing that an agent is a model plus a harness — planning tools, a virtual filesystem, sub-agent delegation, memory, and skills bundled around whichever model you mount.
- OpenHarness (HKUDS): an open-source Python agent harness from the University of Hong Kong's data science lab — tool use, skills, memory, and multi-agent coordination, with a built-in personal agent and support for ten-plus providers.
- mini-SWE-agent (SWE-agent): the minimal end of the spectrum — an agent harness of about 100 lines of Python whose only tool is the shell, yet it scores above 70 percent on SWE-bench Verified with a capable model. An existence proof that a harness is a set of design decisions, not a volume of code.
- Yours: if you run an agent in production, you already have a harness — the prompts, tool schemas, skills, evals, and memory your team assembled. It is less famous than the ones above and matters more to your users.

| Harness | Who ships it | What it's built for | Open source? |
| --- | --- | --- | --- |
| Claude Code and Codex harnesses | Anthropic and OpenAI | The flagship coding agents — models inside heavily engineered harnesses of prompts, tools, skills, and orchestration | No — product harnesses; Anthropic ships the layer for reuse as the Claude Agent SDK |
| Microsoft Agent Framework Harness | Microsoft | Batteries-included harness for any chat client: planning, todo tracking, file memory, context compaction, tool approvals | Yes |
| LangChain DeepAgents | LangChain | Harness-building library: planning tools, a virtual filesystem, sub-agent delegation, memory, skills | Yes |
| OpenHarness | HKUDS (University of Hong Kong) | Standalone Python harness: tool use, skills, memory, multi-agent coordination, ten-plus providers | Yes |
| mini-SWE-agent | SWE-agent | Minimal reference harness: about 100 lines of Python with the shell as the only tool | Yes |
| Yours | Your team | Your product and users: the prompts, tool schemas, skills, evals, and memory your team assembled | Effectively — to the team that owns it |

The examples share one property worth noticing: none of these projects compete on the model. They compete on what surrounds it. The model is rented from a provider and swaps out; the harness is owned, and it is where an agent's behavior — and its failures — actually live. That is why the rest of this page is about the last example on the list.

Sources:

- Anthropic, Building agents with the Claude Agent SDK: https://claude.com/blog/building-agents-with-the-claude-agent-sdk
- Microsoft Learn, Agent Framework Harness: https://learn.microsoft.com/en-us/agent-framework/agents/harness
- LangChain, The Anatomy of an Agent Harness: https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
- HKUDS, OpenHarness: https://github.com/HKUDS/OpenHarness
- SWE-agent, mini-swe-agent: https://github.com/SWE-agent/mini-swe-agent

## Open-source agent harnesses

An open source agent harness gives you the loop, planning, memory, and tool plumbing as code you can read, fork, and own — no vendor between you and the layer where your agent's behavior lives. Four are worth knowing by name, and the fifth option is the one most production teams actually run:

- OpenHarness (HKUDS): the most complete standalone open source agent harness — tool use, skills, memory, and multi-agent coordination in Python, from the University of Hong Kong's data science lab, with support for ten-plus model providers.
- mini-SWE-agent (SWE-agent): the minimal reference — a complete working harness in about 100 lines of Python whose only tool is the shell. The right choice when you want to understand every line you run, and the proof that a harness is design decisions rather than code volume.
- LangChain DeepAgents: the open-source harness-building library for the LangChain ecosystem — planning tools, a virtual filesystem, sub-agent delegation, memory, and skills around whichever model you mount.
- Microsoft Agent Framework: the open-source framework whose harness feature (create_harness_agent in Python, AsHarnessAgent in .NET) wraps any chat client with planning, todo tracking, file memory, context compaction, and tool approvals.
- Your own: a hand-rolled loop plus the prompts, tool schemas, skills, evals, and memory configuration in your repository. Most production harnesses are this — effectively open source to the team that owns them, which is the property that matters.

Whichever open source agent harness you start from, the parts that determine behavior — your prompts, your tool schemas, your eval set, your memory design — are not in the download. They accumulate in your repository after you fork, and they are where two teams on the identical harness diverge.

One positioning note, because the question comes up: Moda is not a competing open-source harness, and not a harness SKU at all. It is harness engineering infrastructure that sits above whichever harness you run — OpenHarness, DeepAgents, a Microsoft Agent Framework harness, or a hand-rolled loop — turning production traces into verified improvements for the prompts, tools, skills, evals, and memory of the harness you already own.

Sources:

- HKUDS, OpenHarness: https://github.com/HKUDS/OpenHarness
- SWE-agent, mini-swe-agent: https://github.com/SWE-agent/mini-swe-agent
- Microsoft, Agent Framework (GitHub): https://github.com/microsoft/agent-framework

## Best agent harness: how to choose

There is no universal best agent harness, and roundups that crown one are mostly ranking exercises. The honest version of the question is a short list of criteria, because the candidates differ less in quality than in fit:

- Fit to the task: a coding agent, a support agent, and a long-running application agent need different orchestration. Pick the harness built for your task shape, not the one with the longest feature list.
- Only the orchestration you need: sub-agents, planning, approvals, and context compaction are worth inheriting when your task uses them and dead weight when it does not. The smallest harness that does the job is easier to reason about and to debug.
- Plain-file artifacts: prefer a harness whose prompts, tool schemas, skills, and memory configuration live as readable files in your repository — diffable, reviewable, revertible. Harness assumptions go stale; you want changing them to be a code review, not an archaeology project.
- Trace capture and replay: the criterion that outlasts the pick. Production will find failures no framework prevented, so the harness must let you capture complete traces and replay traffic against proposed changes. A harness you cannot observe is a harness you cannot improve.
- The layers no harness ships: your prompts, your tool schemas, your eval set. Every candidate leaves them to you, which is why the best agent harness question matters less than teams expect — behavior lives in the parts you write either way.

For the named candidates, see the examples and open-source sections above: Claude Agent SDK, Microsoft Agent Framework Harness, LangChain DeepAgents, OpenHarness, mini-SWE-agent, or your own loop. All of them can be the right answer; none of them stays the right answer without the last criterion. The durable advantage is not the initial pick but the improvement loop — harness engineering: production traces in, verified improvements to prompts, tools, skills, evals, and memory out. Moda is a harness engineering platform for exactly that loop, on whichever harness you chose — not a harness SKU, and not an LLM router.

## The harness, not the model, is usually what fails

When a production agent gives a wrong answer, the reflex is to blame the model. The evidence usually points elsewhere: the model did exactly what the harness told it to do, and the harness told it the wrong thing.

The failure signatures are consistent across teams. A tool description is ambiguous, so the model passes subtly wrong arguments — every call returns 200, and the result is quietly wrong. The system prompt was written for last quarter's users and does not cover what people ask now. Memory retrieves the wrong context, and the model reasons flawlessly from a false premise. An eval suite full of hand-written cases passes while real traffic regresses. None of these are model failures, and no amount of model upgrading fixes them.

This is also why the same model scores differently under different harnesses on agentic benchmarks: harness design — which tools are exposed, how errors are surfaced, how context is managed — is part of what is being measured. A model swap changes an agent less than most teams expect, and a harness change usually changes it more.

## How to improve agent memory from traces

To improve agent memory from traces, you work backwards from production evidence: capture complete traces, find the conversations where the model reasoned from the wrong context, attribute each failure to the memory component responsible, ship the fix as a reviewable harness diff, and verify that diff against replayed traffic before it reaches users. Agent memory is a layer of the agent harness — prompts, tools, skills, evals, memory, orchestration — and it improves the same way the rest of the harness does: from traces, not intuition. The loop, step by step:

- Capture complete traces. A memory failure is invisible in the final answer, which reads fluent and confident. You need the full trace: what was retrieved, what was compacted away, and what the model actually saw on the turn where it went wrong.
- Attribute the failure to the memory component. Three signatures recur in production: wrong retrieval (the lookup returned plausible-but-wrong context), lossy compaction (a load-bearing fact was summarized away between turns), and false-premise context (stale or incorrect memory was injected, and the model reasoned flawlessly from it).
- Ship the fix as a harness diff. The fix is a reviewable change to the memory design — what gets written to memory, what retrieval returns and how it is ranked, what the compaction policy preserves, what the prompt injects — not a new memory product bolted onto the stack.
- Verify against replayed traffic. Re-run the change against replays of the traces that failed, and of the ones that did not, before shipping. A memory change that repairs ten conversations and quietly degrades forty is a regression you want caught in replay, not in production.
- Gate the layer with evals. Turn the failing traces into eval cases, so the class of memory failure you just fixed cannot silently come back on the next harness change.

This is a different job from giving an agent memory in the first place. Adding memory is a day-one build decision, covered in step four of the build guide on this page, and most guides to agent memory stop there. Once the agent has real traffic, the question inverts: not which memory to add, but which memory failure is costing you — and only production traces can answer that. Moda is a harness engineering platform built for the inverted question: it detects memory-attributable failures in production traces, routes each one to the retrieval, compaction, or injection decision responsible, and verifies the memory-harness change against replayed traffic before it ships.

Sources:

- Moda glossary, Compaction: https://moda.dev/glossary#compaction
- Moda glossary, Context loss: https://moda.dev/glossary#context-loss

## Memory harness improvement

Memory harness improvement is the practice of improving the memory layer of an agent harness from production evidence: traces in, verified memory diffs out. The phrase puts the emphasis where the leverage is — the harness, not the memory vendor. An agent that misremembers usually does not need a different memory product; it needs the memory design it already has engineered against what traces show it actually doing.

- The surface: everything about memory that is code or configuration — write policies (what gets stored, when), retrieval (scope, ranking, how many results), compaction (what survives when the context window fills), and injection (what the prompt actually includes each turn). All of it is diffable, reviewable, and revertible.
- The loop: detect memory-attributable failures in traces, attribute each to the specific write, retrieval, compaction, or injection decision responsible, propose the diff, verify it against replayed traffic, and gate it with evals built from the failing traces. The same loop harness engineering runs on prompts and tools, applied to memory.
- The evidence standard: a memory harness improvement is verified, not vibes — it ships with replay results showing the failing conversations now succeed and the passing ones still pass.

The phrase is worth distinguishing from two adjacent framings. Research writing on harness engineering treats the harness as the structure that lets an agent improve itself; memory vendors describe memory as a harness you add around a model. Both are about installing structure. Memory harness improvement is narrower and operational: the structure already exists in your repository, it is failing in specific attributable ways in production, and the work is shipping verified diffs to it. That is the harness engineering position, and it is Moda's: memory is a layer of the harness to be improved from traces, not a SKU to be swapped.

Source:

- LangChain, The Anatomy of an Agent Harness: https://www.langchain.com/blog/the-anatomy-of-an-agent-harness

## Why is it called an agent harness?

The name is borrowed from test engineering. A test harness is the fixture that mounts a component under test: it holds the part still, drives it with inputs, and observes what comes back, so the component can be exercised safely and repeatably. Engineers wrapping language models recognized the same relationship and carried the word over — an agent harness mounts a model, drives it with prompts and tools, and captures everything it does.

- Why not scaffolding? Scaffolding is temporary by definition — it comes down when the building is finished. The layer around a production model never comes down; it is permanent and load-bearing, which is what harness implies and scaffolding denies. The word survives as a loose synonym, but harness is the one that stuck for production systems.
- Why not runtime? A runtime is where code executes — a passive host. The layer around the model is active: it decides what the model sees, what it may call, and what happens with what it returns. Harness names a thing that directs; runtime names a place that hosts.
- Why harness fits twice over: the word carries both engineering senses at once — the test fixture that holds a component so it can be measured, and the working harness that couples raw power to a load. A production agent needs both: a model held where you can observe it, and a model directed at useful work.

The metaphor also explains what the layer is for operationally. A harness exists so the thing inside it can be exercised safely and repeatably — which is why a serious agent harness contains its own evals and captures its own traces. Moda is a harness engineering platform built on exactly that property: it turns production traces into verified improvements for the agent harness — prompts, tools, skills, evals, memory.

Source:

- EleutherAI, lm-evaluation-harness: https://github.com/EleutherAI/lm-evaluation-harness

## Harness vs scaffolding: two names for the same layer

Agent harness and agent scaffolding name the same thing: the code and configuration wrapped around a model to turn it into an agent. If you have seen both words and wondered whether they are different layers, they are not. The difference is dialect and connotation, not referent.

- Same referent: whichever word a team uses, it covers the prompts, tools, skills, evals, memory, and orchestration around the model — the layer this whole page is about.
- Where each word lives: scaffolding is the older, more common word in research writing and eval reports; harness is the word production engineering converged on, and the one vendors now put in product names — the Claude Agent SDK is described as an agent harness, and Microsoft ships an Agent Framework Harness.
- Why the connotations differ: scaffolding is the temporary structure you remove when construction is done; a harness is a permanent fixture that holds, drives, and observes. For a layer that never comes down in production and exists partly to make the model measurable, harness is the more accurate metaphor.

Use whichever word your team already says — but notice what both words point at: the layer where an agent's behavior actually lives, and therefore the layer worth engineering deliberately. That practice is harness engineering, and Moda is a harness engineering platform for it: production traces in, verified improvements to the prompts, tools, skills, evals, and memory out.

Sources:

- Anthropic, Building agents with the Claude Agent SDK: https://claude.com/blog/building-agents-with-the-claude-agent-sdk
- Microsoft Learn, Agent Framework Harness: https://learn.microsoft.com/en-us/agent-framework/agents/harness

## Agent harness, LLM harness, eval harness — which one do you mean?

The word harness is overloaded in AI, and the meanings are related but not interchangeable. If you searched for one of these, here is the map.

- Agent harness (this page): the production scaffolding around a model — prompts, tools, skills, evals, memory, orchestration — that turns it into a deployed AI agent.
- LLM harness / eval harness: a benchmarking fixture that runs a model against standardized tasks under controlled settings. EleutherAI's lm-evaluation-harness is the canonical example and is where many people first meet the word.
- Test harness (general software): the older term both of the above borrow from — the fixture that mounts a component so it can be exercised and observed.

The senses connect: an eval harness holds a model still so you can measure it; an agent harness holds a model in production so it can do work. And a well-run agent harness contains an eval harness inside it — the eval component exists to measure the rest. (If you were looking for wiring harnesses, this page is about AI systems, not automotive electrical assemblies.)

Source:

- EleutherAI, lm-evaluation-harness: https://github.com/EleutherAI/lm-evaluation-harness

## Why agent harnesses drift in production

A harness is aligned with reality on the day it ships and drifts from that point forward, because the things it encodes assumptions about keep moving.

- Users change: new intents show up in traffic that no prompt, tool, or skill was designed to handle, and the agent improvises badly.
- The product changes: an API adds a required field, a workflow gains a step, and a tool schema written six months ago silently stops matching reality.
- The model changes: a provider upgrade shifts instruction-following in ways that break prompt assumptions that used to hold.
- The harness itself accretes: every incident adds a paragraph to the system prompt, and nobody deletes anything, because nobody can prove what is load-bearing.

Drift is invisible in dashboards that track latency and error rates, because a drifted harness returns successful responses to the wrong effect. It shows up first in behavior: repeated retries, users rephrasing, quiet abandonment. Catching it requires reading production traces at population scale — which is exactly the work nobody has time to do by hand.

## Mapping and improving an agent harness

You cannot improve a harness you cannot see. Most teams have no artifact that answers the basic question: what agents do we run, with what prompts, tools, and skills, and how do they relate?

The map has to come from the repository, because that is where the harness lives. Moda builds it there: connect the GitHub App, and every push to the default branch triggers an analysis that captures the agents in the codebase, the artifacts they use (prompts, tools, skills, evals, model configurations), and the relationships between them, with citations back to source files. The result is a versioned topology of the harness that stays current as the code changes.

Improvement then has a defined shape: production traces come in, failures and emergent intents are detected and attributed to the specific harness component responsible — this prompt, this tool schema, this missing skill — and each proposed change is verified against replays of real traffic before it ships. That loop, run continuously, is harness engineering. Moda is a harness engineering platform built around it: production traces in, verified harness improvements out. The companion guide covers the practice; the fastest way to see it on your own traffic is a demo.

Two harness jobs recur in serious deployments and show what the loop is for. Frontier-to-OSS transfer: a harness proven against a frontier model is ported to an open-weight model, and the behavior gap is closed with harness changes — prompt rewrites, tightened tool schemas, added skills — each verified against the same replayed traffic rather than assumed. Task routing: the harness sends each request to the model best suited to it, which turns model choice from a one-time bet into an evaluated, revisable harness component. Neither is a model project; both are the harness doing its job.

Source:

- Moda docs, Harness overview: https://docs.moda.dev/harness/overview

## Frequently asked questions

### What is an agent harness?

An agent harness is everything wrapped around a language model to turn it into a working AI agent: system prompts, tool definitions, skills, evals, memory, and the orchestration loop that binds them. The model supplies raw capability; the harness determines how the agent actually behaves — which is why two agents on the identical model can behave nothing alike.

### What is an AI agent harness?

An AI agent harness is the software wrapped around a language model to turn it into a working AI agent — prompts, tools, skills, evals, and memory, bound together by an orchestration loop. AI agent harness and agent harness name the same layer; the AI prefix just says what kind of agent. The model contributes raw capability, and the harness determines how the deployed agent behaves in production. Claude Code is a familiar example of a product that contains one: a Claude model inside a heavily engineered harness. Moda is a harness engineering platform for that layer — it turns production traces into verified improvements to the prompts, tools, skills, evals, and memory of the harness you already run.

### What are the main components of an agent harness?

An agent harness has six main components: prompts (the system prompt and its fragments), tools (the functions the model can call, defined by schemas), skills (packaged procedures for a class of task), evals (the test cases that gate changes), memory (what the agent carries across turns and sessions), and orchestration (the loop that binds the rest — turn structure, retries, sub-agent routing, guardrails). None of them are model weights: every component is code or configuration a human can diff, review, and revert. The anatomy section on this page — What an agent harness is made of — covers each component in detail.

### What's the difference between an agent and a harness?

An agent is the whole running system; the harness is the part of it you build. The working formula: agent = model + harness. The model contributes capability — language, reasoning, tool calling — and is rented from a provider, identical for everyone who rents it. The harness contributes reliability: the prompts, tool schemas, skills, evals, memory, and orchestration that point that capability at your product and keep it pointed there as users, product, and models change. When a production agent misbehaves, the split tells you where to look: the model rarely changed, but the harness encodes every assumption that can drift. Moda is a harness engineering platform for exactly that half — production traces in, verified harness improvements out.

### How do I build an AI agent harness?

You build an AI agent harness by writing a small runtime plus the repository files that define behavior, in seven steps: (1) write the agent loop — send the conversation to the model, execute the tool call it returns, append the result, repeat; (2) write the system prompt; (3) define tools with tight schemas; (4) decide what the agent remembers; (5) package repeated procedures as skills; (6) build evals from real production traffic; (7) instrument and iterate. A working first harness is about 100 lines — mini-SWE-agent drives a model with a system prompt and a shell tool and scores above 70 percent on SWE-bench Verified. The parts that determine behavior — your prompts, your tool schemas, your eval set — cannot be imported from a framework; the build guide on this page walks through each step in order.

### Do I need a framework to build an agent harness?

No. mini-SWE-agent is a complete working harness in about 100 lines of plain Python, and many production harnesses are hand-rolled loops. A framework or prebuilt harness — the Claude Agent SDK, Microsoft Agent Framework Harness, LangChain DeepAgents — buys you orchestration, memory, and planning out of the box, which is worth taking when your task needs them. It does not exempt you from writing the behavior-determining parts yourself: pick the smallest kit that covers what you do not want to build, and expect the real work to be in prompts, tool schemas, and evals either way.

### What is agent memory?

Agent memory is the harness layer that decides what an AI agent carries across turns and sessions: conversation state, user facts, and retrieval indices. It is one of the parts of the agent harness — alongside prompts, tools, skills, evals, and orchestration — and like the rest of the harness it is code and configuration rather than model weights, so it can be diffed, reviewed, and reverted. Memory decides what the model sees, which decides what it does — and in production it is where a distinctive class of failures lives: wrong retrieval, lossy compaction, and stale facts injected as context, each of which produces a model reasoning flawlessly from a false premise. That is why this page answers agent memory questions from the harness side — how to improve agent memory from traces — rather than as a survey of memory products.

### How to improve agent memory from traces?

You improve agent memory from traces in five steps: (1) capture complete production traces, including what was retrieved, what was compacted away, and what the model actually saw; (2) find the conversations where the model reasoned from the wrong context; (3) attribute each failure to the memory component responsible — wrong retrieval, lossy compaction, or false-premise context; (4) ship the fix as a reviewable harness diff to the write, retrieval, compaction, or injection design; (5) verify the diff against replayed traffic and turn the failing traces into eval cases. The memory section on this page walks through each step. Moda is a harness engineering platform that runs this loop as a product: memory failures attributed from production traces, memory-harness changes verified against replays before they ship.

### What is memory harness improvement?

Memory harness improvement is improving the memory layer of an agent harness — what the agent writes to memory, what retrieval returns, what compaction preserves, and what the prompt injects — using evidence from production traces, with every change verified against replayed traffic before it ships. It is not the same as adding a memory product: memory is a layer of the harness, not a SKU, and the agents that misremember in production usually need their existing memory design engineered against real failures rather than replaced. The loop is the standard harness engineering loop applied to memory: detect the failure in traces, attribute it to the responsible memory decision, ship the diff, replay-verify, and gate with evals.

### What is a harness in AI, generally?

The term borrows from test engineering, where a harness is the fixture that holds a component so it can be driven and observed. In AI it has two common senses: an eval harness (like EleutherAI's lm-evaluation-harness) holds a model still so it can be benchmarked, and an agent harness holds a model in production so it can do useful work. Both are scaffolding around a model, built for different purposes.

### What is an LLM harness?

An LLM harness is a fixture that runs a language model under controlled, repeatable settings. In most usage the phrase means an eval harness — EleutherAI's lm-evaluation-harness is the canonical example — which mounts a model, drives it through standardized benchmark tasks, and scores the outputs, so results are comparable across models and runs. That is a different artifact from the agent harness this page defines: an LLM harness holds a model still to measure it, while an agent harness holds a model in production to do work — prompts, tools, skills, evals, memory, and orchestration around it. The two connect in practice: a serious agent harness contains an eval harness inside it, because the eval layer exists to measure the rest. If you searched for LLM harness meaning the layer around a production model, agent harness is the precise term, and everything on this page applies.

### Why is it called an agent harness?

The name comes from test engineering, where a test harness is the fixture that holds a component under test so it can be driven with inputs and observed, safely and repeatably. An agent harness holds a language model the same way: it mounts the model in production, drives it with prompts and tools, and captures everything it does. The word won out over alternatives because the alternatives mislead — scaffolding implies a temporary structure that comes down when construction ends, and runtime implies a passive place where code merely executes. The harness around a production agent is permanent, load-bearing, and active: it decides what the model sees, what it may call, and what counts as success.

### Is an agent harness the same as an agent framework?

No. A framework (LangChain, CrewAI, the Claude Agent SDK) is the toolkit you might build a harness with. The harness is your specific assembly: your prompts, your tool schemas, your skills, your eval set, your memory design. The line blurs because frameworks now ship prebuilt harnesses as features — Microsoft's Agent Framework Harness, LangChain's DeepAgents — but the distinction survives: the framework is the kit, the harness is the assembled thing that runs. Two teams on the same framework have completely different harnesses, and the differences are where their agents' behavior diverges.

### What are examples of agent harnesses?

The best-known harnesses are inside agent products: Claude Code and Codex are models wrapped in heavily engineered harnesses of prompts, tools, skills, and orchestration — Anthropic now ships Claude Code's harness for reuse as the Claude Agent SDK. Installable examples include the Microsoft Agent Framework Harness (a batteries-included harness created with create_harness_agent in Python or AsHarnessAgent in .NET), LangChain's DeepAgents harness-building library, and HKUDS's open-source OpenHarness. At the minimal end, mini-SWE-agent is a working harness in about 100 lines of Python. And every team running an agent in production has one more example: their own assembly of prompts, tool schemas, skills, evals, and memory.

### What is a deep agent harness?

A deep agent harness is a harness built for long-horizon, multi-step work: it adds planning tools, sub-agent delegation, a virtual filesystem, and memory around the model so the agent can decompose a large task and carry state across many steps. LangChain's DeepAgents — the harness-building library that bundles exactly those parts around whichever model you mount — is what popularized the phrasing. It is a style of agent harness, not a separate layer: everything on this page about building, mapping, and improving a harness applies to a deep one.

### What is the most popular agent harness?

The most widely used agent harnesses are the ones inside Claude Code and Codex — the flagship coding agents from Anthropic and OpenAI — and Anthropic now ships that layer for reuse as the Claude Agent SDK, describing it as "the agent harness that powers Claude Code." But popularity is the wrong selection criterion: the candidates differ less in quality than in fit, so what matters is fit to your task shape and whether the harness lets you capture traces and improve it from production evidence. The decision guide on this page — Best agent harness: how to choose — covers the criteria.

### What is the best agent harness?

The best agent harness is the one that fits your task and that you can improve from production traces — there is no universal winner. Choose on five criteria: fit to your task shape (coding, support, long-running application work); only the orchestration you actually need; plain-file artifacts (prompts, tool schemas, skills, memory configuration) you can diff, review, and revert; trace capture and replay, so failures found in production can be attributed and fixes verified; and clear ownership of the layers no harness ships — your prompts, your tool schemas, your eval set. Candidates worth evaluating: the Claude Agent SDK, Microsoft Agent Framework Harness, LangChain DeepAgents, open-source OpenHarness, or a hand-rolled loop like mini-SWE-agent. Whichever you pick, behavior lives in the parts you write yourself, so the durable advantage is the improvement loop rather than the pick. Moda is a harness engineering platform for that loop — production traces in, verified harness improvements out — on whichever harness you run.

### What is the best open-source agent harness?

It depends on the shape of your task. OpenHarness (HKUDS) is the most complete standalone open source agent harness — tool use, skills, memory, and multi-agent coordination in Python across ten-plus providers. mini-SWE-agent is the minimal reference at about 100 lines, right when you want to understand every line you run. LangChain DeepAgents fits teams already in the LangChain ecosystem, and Microsoft's open-source Agent Framework fits Python/.NET shops that want planning, file memory, and tool approvals out of the box. All of them leave the behavior-determining parts — prompts, tool schemas, evals, memory design — to you, so the fork you maintain matters more than the project you fork. Moda is not a competing open-source harness: it is harness engineering infrastructure above whichever of these you run, turning production traces into verified improvements for the harness you own.

### Is Claude Code an agent harness?

Strictly, Claude Code is an agent: a Claude model running inside a heavily engineered agent harness. The harness half is the system prompts, file and shell tools, skills, sub-agent orchestration, and context compaction Anthropic built around the model — and Anthropic now ships that layer for reuse as the Claude Agent SDK, describing it as "the agent harness that powers Claude Code." So the precise answer is that Claude Code contains one of the best-known agent harnesses, and much of what reads as model quality in the product is harness quality. If you build on the Claude Agent SDK you inherit that harness as a starting point; the prompts, tools, skills, and evals you add become your own harness — the layer Moda, a harness engineering platform, improves from your production traces.

### Is Moda a LangChain agent harness?

No. The LangChain agent harness is DeepAgents, LangChain's harness-building library — a runtime wrap of planning tools, a virtual filesystem, sub-agent delegation, memory, and skills around whichever model you mount. It is one good way to assemble a harness, alongside the Claude Agent SDK, Microsoft's Agent Framework Harness, or a hand-rolled loop. Moda is neither a LangChain wrapper nor a competing runtime: it is harness engineering infrastructure that sits above whichever runtime you chose. It maps the harness from your repository, attributes production failures to the prompt, tool, skill, eval, or memory component responsible, and turns production traces into verified harness improvements. DeepAgents runs your agent; Moda improves the harness your agent runs on — the two compose rather than compete.

### Harness vs scaffolding: which term should you use?

Harness vs scaffolding is a choice of dialect, not of layer — both name the prompts, tools, skills, evals, memory, and orchestration around a model, so nothing technical hangs on it. Scaffolding is the older word and still common in research writing; harness is the term production engineering settled on, because it is more precise: scaffolding implies a temporary structure that comes down when construction ends, while a harness — in the test-engineering sense both words borrow from — is a permanent fixture that holds a component so it can be driven and observed. That is exactly the relationship this layer has to a production model, which is why vendors now put harness in product names and why this page uses it throughout.

### What is agent scaffolding?

Agent scaffolding is another name for the agent harness: the code and configuration wrapped around a language model to turn it into a working AI agent — system prompts, tool schemas, skills, evals, memory, and the orchestration loop that binds them. The word is most common in research papers and eval reports; production engineering has largely converged on harness for the same layer, since the structure is permanent and load-bearing rather than temporary. Everything on this page about building, mapping, and improving an agent harness applies verbatim to what those sources call agent scaffolding.

### Is the harness the same as agent scaffolding?

Effectively yes — scaffolding is a common synonym for the same layer. Harness has become the more precise term because it carries the test-engineering connotation of holding a component so it can be observed and exercised, which is exactly the relationship this layer has to the model.

### Is MCP part of the agent harness?

MCP (the Model Context Protocol) standardizes how tools and context sources plug into an agent, so the MCP servers you connect become part of your harness's tool surface. The protocol does not decide which tools are exposed, how they are named and described, or how their results are handled — those remain harness decisions, and they are where behavior comes from. Think of MCP as the connector standard and the harness as the assembly it plugs into.

### Why do agent failures trace to the harness instead of the model?

Because the harness encodes all the assumptions specific to your product and users — what tools exist, what the prompt covers, what memory retrieves — and those assumptions drift as users, product, and models change. Ambiguous tool descriptions, stale prompts, and wrong retrieved context all produce failures with perfectly healthy API calls. Model upgrades fix none of them.

### What is harness engineering?

Harness engineering is the discipline of improving an AI agent by engineering its harness — prompts, tools, skills, evals, memory — against evidence from production rather than intuition. The model is treated as a fixed component; the harness is the system you design, measure, and iterate. Moda is a harness engineering platform: it maps the harness from your repository, attributes production failures to the specific component responsible, and verifies proposed improvements against replayed traffic before they ship. The companion guide on harness engineering covers the practice in full.

### What is the difference between agent harness and context engineering?

The agent harness is an artifact: the prompts, tools, skills, evals, memory, and orchestration assembled around the model. Context engineering is a practice applied to part of that artifact — deciding what the model actually sees in its context window each turn, which the harness's prompt, memory, and retrieval components control. Harness engineering is the superset practice: it improves the whole harness, context included, from production traces, with each change verified against replayed traffic before it ships.

### How does Moda map an agent harness?

From the repository. With the Moda GitHub App connected, every push to the default branch triggers an analysis that captures the repo's agents, their artifacts (prompts, tools, skills, evals, model configurations), and the relationships between them, with citations back to source files. The dashboard shows the harness as an interactive topology graph, versioned on every sync — and production signals are attributed back to the specific harness component that needs to change.

## Keep reading

- [Harness engineering (pillar)](https://moda.dev/harness-engineering)
- [Context rot (pillar)](https://moda.dev/context-rot)
- [Agent harness (glossary)](https://moda.dev/glossary#agent-harness)
- [Behavioral failure (glossary)](https://moda.dev/glossary#behavioral-failure)
- [Self-improving agent (glossary)](https://moda.dev/glossary#self-improving-agent)
- [Moda vs Raindrop](https://moda.dev/vs/raindrop)
- [Moda vs LangSmith](https://moda.dev/vs/langsmith)

## Moda skills for AI agents

Moda is a harness engineering platform: it turns production traces into verified improvements for the agent harness — prompts, tools, skills, evals, memory. Machine-readable artifacts for agents working with Moda:

- Claude Code integration skill: https://moda.dev/skills/claude-code.md
- Moda CLI skill: https://moda.dev/skills/moda-cli.md
- Node.js SDK integration skill: https://moda.dev/skills/sdk-node.md
- Python SDK integration skill: https://moda.dev/skills/sdk-python.md
- Agent skills index: https://moda.dev/.well-known/agent-skills/index.json
- LLM reference: https://moda.dev/llms.txt

## See it on your traffic

Book a demo: https://cal.com/team/moda/demo-meeting?overlayCalendar=true