{"slug": "the-interesting-part-of-an-agent-harness-is-what-you-add-on-top", "title": "The interesting part of an Agent Harness is what you add on top", "summary": "Martin Richards argues that the most important part of an agent harness is the content users add on top, not the runtime itself. Drawing on Viv Trivedy's formula Agent = Model + Harness, Richards separates harness into mechanism (plumbing) and content, which he further divides into Skills (context engineering) and Loop (loop engineering). He emphasizes that users shape the content layer—prompts, skills, orchestration—to teach the agent how to think and build.", "body_md": "# What’s Inside the Harness\n\nIn March I published [Building Your Own Agent Harness](https://www.martinrichards.me/post/building_your_own_agent_harness/). A harness, I said, is the skills, workflows, and methodology that teach your agent how you think and how you build. Since then, *harness* has taken on a different meaning: Claude Code, Codex, Cursor, the whole runtime wrapped around a model. In my terms, that combination is the agent. You can call it the harness too, but when you’re building with an agent, it is the part you have the least control over. I’m not going to fight the internet over what to call a harness. I care about what you put inside it.\n\n## The equation everyone’s using\n\n[Viv Trivedy’s formula](https://xcancel.com/i/article/2031408954517971368), quoted in [Addy Osmani’s April post](https://addyosmani.com/blog/agent-harness-engineering/), is `Agent = Model + Harness`\n\n. It draws a clear boundary: the model provides the reasoning, while the harness is everything around it that makes that reasoning useful. Trivedy’s full definition includes system prompts, tools, skills, MCPs, infrastructure, orchestration, and hooks. The runtimes behind Claude Code and Codex fit inside that definition, but so does everything a user adds to them.\n\nThe equation is easier to repeat than the definition. The feedback on my March post made it clear that plenty of people had read the TLDR as `Harness = Claude Code or Codex`\n\n. Use the word for anything else and, apparently, you don’t know what the hell you’re talking about. But that isn’t the definition given in the original posts. The runtime is part of the harness, but so are the prompts, skills, tools, orchestration, and everything else the user can configure. When you’re building with an agent, that configurable layer is the part of the harness that matters most.\n\nConcretely, a harness includes:\n\n- System prompts,\n`CLAUDE.md`\n\n,`AGENTS.md`\n\n, skill files, and subagent prompts- Tools, skills, MCP servers, and their descriptions\n- Bundled infrastructure (filesystem, sandbox, browser)\n- Orchestration logic (subagent spawning, handoffs, model routing)\n- Hooks and middleware for deterministic execution (compaction, continuation, lint checks)\n- Observability (logs, traces, cost and latency metering)\n\nClaude Code and Codex fit that definition, but so does everything a user adds to them. The shorthand loses that second half. It also hides an important distinction inside the list: mechanism and content.\n\nThe sandbox, the tool dispatcher, and the hook as an execution point are plumbing. They make the agent run. Prompts, skills, and orchestration rules tell it how to work. If you’re building an agent, both are part of the job. If you’re building with one, the content is the part you shape most. And that content sorts into two things.\n\n## Your harness = Skills + Loop\n\nOnce you separate content from mechanism, everything you provide as content does one of two jobs: it changes what the agent knows or changes the process it follows. Skills do the first. Loop does the second. These are roles, not file formats.\n\n**Skills** are context engineering: getting the right information into the context window at the right time. `AGENTS.md`\n\n, memory files, domain glossaries, my TypeScript conventions, and how I want migrations written all answer the same question: what does the agent need to know at this point in the work? Osmani’s section on “battling context rot” sits on the boundary between content and mechanism. Compaction and tool-call offloading are plumbing that protects the context window. Skill files provide the content, while progressive disclosure controls when that content reaches the model.\n\n**Loop** is loop engineering, the name [Osmani](https://addyosmani.com/blog/loop-engineering/) gave the discussion [Peter Steinberger](https://xcancel.com/steipete/status/2063697162748260627) started the day before. Research, plan, implement is a loop design. So is annotating a spec until you agree, or running fresh-context Ralph iterations against a plan file.\n\nThe packaging can be misleading here. My spec and code-review workflows are distributed as skill files, but much of their content defines loops. The spec workflow defines the research, planning, approval, implementation, and validation cycle. The code-review workflow defines when reviewers run, how findings are challenged, and how fixes return for another pass. A skill file is a delivery mechanism; what it tells the agent to do determines whether its content is a Skill or a Loop.\n\nA hook is plumbing. Deciding that an evaluator runs after every task, that failures return to the cycle, and what counts as done are loop decisions. The same applies to Osmani’s planner, generator, and evaluator split. The sandbox runs those roles; the loop defines how they work together.\n\nSkills plus loop is the whole harness. [Mitchell Hashimoto’s](https://mitchellh.com/writing/my-ai-adoption-journey) rule for harness engineering is that every agent mistake should become a permanent fix. At the content layer, that gives you two moves: teach the agent something new or change the process it follows. [Birgitta Böckeler’s “outer harness”](https://martinfowler.com/articles/harness-engineering.html) describes the same territory from the user’s side. Her feedforward guides map mostly to Skills. Her feedback sensors become part of the Loop when their output returns to the agent and triggers another pass. The sensor produces the signal; the Loop decides what happens next.\n\n## Mapping Atelier onto it\n\n[Atelier](https://github.com/martinffx/atelier) predates this distinction, which makes it a useful test. Mapped by purpose rather than file type, it splits cleanly. Code conventions, architecture principles, and domain glossaries are Skills: they provide information the agent needs. The spec and code-review workflows are Loop: they define stages, approval gates, checks, and when work returns for another pass. Some of those workflows are delivered as skill files, but the packaging does not change their role. Atelier was always doing both; it just did not have separate names for them.\n\n## What changes\n\nThe practice does not change. The vocabulary has been refined. The advice from the March post still stands: start with a research, plan, implement loop; add Skills for how you write code and think about design; and build your own rather than adopting mine wholesale.\n\nWhat changes is the boundary. *Agent harness* remains the broad term for everything around the model, including the runtime and the content configured within it. Böckeler calls the user-controlled part the *outer harness*. I call it *your harness*. Within that boundary, the equation is `Your Harness = Skills + Loop`\n\n, and each half now has a name precise enough to design against.\n\nThe two questions have not moved since March. What does the agent need to know at this point in the work? What cycle does it follow, and when does it check itself? The runtime may be proprietary or open, fixed or hackable. But those questions remain mine to answer.", "url": "https://wpnews.pro/news/the-interesting-part-of-an-agent-harness-is-what-you-add-on-top", "canonical_source": "https://www.martinrichards.me/post/whats_inside_the_harness/", "published_at": "2026-07-25 08:28:29+00:00", "updated_at": "2026-07-25 08:52:15.391402+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "developer-tools"], "entities": ["Martin Richards", "Viv Trivedy", "Addy Osmani", "Claude Code", "Codex", "Cursor", "Peter Steinberger"], "alternates": {"html": "https://wpnews.pro/news/the-interesting-part-of-an-agent-harness-is-what-you-add-on-top", "markdown": "https://wpnews.pro/news/the-interesting-part-of-an-agent-harness-is-what-you-add-on-top.md", "text": "https://wpnews.pro/news/the-interesting-part-of-an-agent-harness-is-what-you-add-on-top.txt", "jsonld": "https://wpnews.pro/news/the-interesting-part-of-an-agent-harness-is-what-you-add-on-top.jsonld"}}