Harness Engineering: Make Any Coding Agent 10x Better

Author: Leon van Zyl · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Harness Engineering: Make Any Coding Agent 10x Better · Channel: Leon van Zyl · 16:00 · Watch on YouTube

Topics: AI agents, Local and open-source models

Summary

The video explains that an AI coding agent consists of a language model plus a harness, which provides its instructions, tools, checks, memory, and working environment. It presents three levels of harness engineering: configuring an existing harness, building a custom harness, and creating orchestration harnesses that coordinate multiple coding agents. Examples show how hooks and memory files can enforce workflows, and how a tailored harness can improve results or reduce context use. The video concludes with examples of long-running agents and a 3D coding swarm connected to project tasks and GitHub issues.

Key points

An agent is the combination of a language model and a harness; the harness defines the agent’s capabilities and operating rules.
A harness can provide instructions, tools, checks, hooks, memory files, sandboxing, sub-agents, and workflows.
Level one is configuring an existing harness with files such as AGENTS.md and with hooks that enforce requirements.
Memory instructions can be split into smaller files, and handoff documents can help a new session continue previous work.
Level two is building a custom harness to control tools, policies, providers, and the developer experience.
A tailored harness can improve a model’s results; the video cites experiments where changing the harness improved reported performance.
The SMOL coder harness is designed for local open-weight models, with a small system setup and limited tools to reduce context use.
Level three is orchestration: managing multiple coding harnesses for long-running jobs or software factories.
A coding swarm can assign tasks to available agents and keep working through tasks in the background.

Chapters

Start	Chapter	Summary
00:00	What harness engineering is	The video introduces harness engineering and defines an agent as a model combined with the environment, rules, tools, and memory provided by its harness.
03:34	Level one: configuring a harness	The video shows how memory files, modular documentation, handoff notes, and hooks can configure an existing coding harness and enforce project workflows.
07:45	Level two: building custom harnesses	The speaker explains why organizations build their own harnesses and gives examples of tailoring tools and context for different models and development needs.
12:55	Level three: orchestration harnesses	The video describes long-running jobs and software factories that coordinate multiple coding agents, then demonstrates a 3D coding swarm connected to GitHub issues and pull requests.

Quotes

an agent is the model plus the harness. — 03:03

This way you’re not relying on the agent to remember to do something. — 07:14

The coding harness as he says here was the bottleneck. — 09:17

In an orchestration harness, you actually manage multiple coding harnesses. — 12:55

Concepts and entities

Harness Engineering, Agent, hook, AGENTS.md, Claude Code, Codex, OpenCode, Claude Mods, Deep Agents CLI, LangChain, Can Bölük, Grok Code Fast 1, Smol Coder, Pi agent SDK, LM Studio, Ollama, orchestration harness, AutoForge, software factory, Agentic Labs

Full transcript (original language)

00:00 Most people and companies think that the coding harness that you’re given is the only one you get. You install Claude Code, Codex or OpenCode, you configure the model, you add a few memory files, maybe a few hooks, a few tools, and you think that’s it. But in reality, that’s only level one of harness engineering. And most people building with AI never get past it. Harness engineering is something I’m really passionate about. And I’ve worked with a lot of people and teams to show them how they can effectively use coding

00:31 harnesses and even build their own. If you want to pursue a career as an AI engineer, or if you want to work with real customers, you do need to understand the three levels of harness engineering, which we will cover in this video. You’re really going to have a lot of fun. So enough talk, let’s jump into this. If you find these topics interesting too, then consider joining my community at Agentic Labs. We’ve got several classrooms on using coding agents to build really cool stuff. And every Thursday, we’ve got

01:01 deep dives, where we actually discussed harness engineering for an hour and a half. So if you do want to follow the entire session, you can find it in the classroom. And on Thursday, we’re starting a brand new series where I teach you how to go from zero to hero with working with coding agents. We’re also running a special at the moment that’s $100 off your annual plan. I do hope to see you there. If you’ve been using AI for a while, you’ve probably heard the word agent so many times. But what exactly is an agent? Well, an agent is actually the

01:31 model, like your large language model, and your harness. The model would be your large language model like Opus, Fable, GPT-6. Those are the actual models, which basically form the brain of the operation. The harness is the environment in which that LLM functions. The harness is a thing that allocates the rules that the agent needs to follow. It assigns the tools that the agent should have access to, like you know, the ability to write

02:02 files, search for files, browse the web, open the browser, etc. The harness also enforces the checks that need to be executed, like running test suites, lint, type check, you’ve probably seen these before. The harness can also expose things like hooks. These are certain events that happen throughout the agent’s lifecycle that we can hook into. Like maybe the moment we send a prompt to an agent, we first want to run a custom script that will check that

02:32 prompt for any sensitive information, and will mask that information before it reaches the actual agent. Hooks can be used for tons of different things. And in fact, Claude recently released Claude Mods, and this allows you to kind of customize your Claude Code experience, but under the hood, Claude Mods are basically using hooks. The harness also gives the agent access to memory files. This would be your AGENTS.md file, the design.md, SOUL.md, or even files within the docs folder. The

03:03 harness can also control how to sandbox the agent. Like for example, agents should work within a very specific workspace, or it should only be allowed to create new worktrees and feature branches, and never be allowed to change the main branch. So hopefully you’re starting to understand already that the harness is the thing that gives the capabilities to the agent and defines the environment and the rules that the agent is allowed to work in. So very simply put, an agent is the model plus the harness. The harness exposes the instructions, the

03:34 tools, the checks, and the memory that the agent has access to. Of course, this can be extended to additional capabilities like sub-agents and workflows too, but that is all exposed by the harness. Now that we have a high level idea of what a harness is and what an agent is, it’s time to discuss the three levels of harness engineering, which is the crux of this video. The first level is configuration. Now this is where the majority of you watching this video are right now. This is where you use a coding harness

04:06 that was built by the provider or some third-party tool. For example, if you’re using Claude Code, you are at this level. What you do in that instance is you kind of configure the harness to work however you want it to work. So if you want the agent to follow very specific rules, you can update the AGENTS.md file to give the agent those guidelines. Just to show you a quick example of what it actually looks like, in most projects you will set the rules in the AGENTS.md file. So this is called a memory

04:38 file. This means that any rules that we want the agent to follow whenever we create a new session, we can dump all of those rules into this file. And the next time we start a new Claude session, it will follow these rules. This does not just apply to Claude at all. The AGENTS.md file is actually an open standard. Any coding harness that’s worth using will honor this AGENTS.md file. The basic rule of thumb with this file is if the agent starts doing something that you really don’t like in the chat, add a rule to this file telling the agent to never

05:08 do that again, or you can give it guidelines on how it’s supposed to behave in the future. This file is also composable, which means you don’t have to add everything into this same markdown file. It’s going to get way too long. So what you can do instead is break all the rules up and store them into separate files. A common convention is to create this docs folder and then split your markdown files up into smaller files and you can install them in a very structured way in this docs folder. And then in your main AGENTS.md

05:39 file, you can have an index similar to this, which links to all these simple files in the docs folder. Each of these files are nothing more than smaller markdown files with very specific instructions for this specific part of the app. Another tip I can give you with regards to memory files is if your sessions are starting to get way too long and you’re about to hit your context window limit, what you can do is simply ask your agent to store the sort of progress and what still needs to be done in separate files. Like I

06:12 actually had to ask my agent to create this handoff document so like you start a brand new session with a new agent and I could just pass this handoff document to that agent. Now because of all the context we have available in these documents, that agent knew exactly what happened so far, what the project is about and how to continue. Of course you can configure the harness in many other ways as well, like you could add hooks to the harness as well. If I just switch over to VS Code for a second, I’ve got this very simple demo set up for you.

06:43 So in this app whenever we make a change to the application, our agent should write an entry to the changelog. Now I do not have any AGENTS.md file here. Ideally I should have one that instructs the agent to update the changelog but I can also enforce that behavior with hooks. Now most harnesses actually allow you to hook into certain events. So for example when we send prompt we might want to interject, grab the prompt, do something with it before passing it to the

07:14 agent. There are plenty of hooks available and one very valuable hook is the stop hook. Whenever the agent completes its work we can actually fire off this stop hook and do something with the conversation. This script will check if the changelog was updated and if it wasn’t it will actually talk to it, “hey you need to go back and add an entry to the changelog” enforcing that behavior. So you can do the same thing to check whether or not a PR was created or that a test suite was run. There’s really a lot of things that you

07:45 can enforce as part of the harness. This way you’re not relying on the agent to remember to do something. Now of course configuring the harness is only level one. Level two is where we build custom harnesses and trust me building your own harness is in high demand right now. Certain organizations need ability to control what the developers are allowed to do. Like enforcing policies, giving agents access to very specific tools or actually limiting certain capabilities. I’ve worked with a lot of

08:16 brands and I’ve seen a ton of custom harnesses out there. Now why on earth would you want to build your own harness and not simply use the existing ones out there? And is it very hard to do? Is it something that someone with no technical experience can do? Firstly let me tell you this. Anyone can build a harness. In fact I’ve got a free course in my free community that teaches you how to build your own coding harness and it’s been so cool to see the results that people have come up with. I’ve seen a few very cool

08:47 examples where only changing the harness actually took the same model and improved its outputs. Like for example LangChain did this experiment a while back where they took GPT-5.2 and it’s the exact same model with the same prompt and they actually managed to get better results out of the model by using their own Deep Agents CLI tool, their own coding agent harness. They were able to get the output from 53% to around about 66%.

09:17 Then this is a really popular post on X from Can Bölük, sorry if I’m butchering your name, but he was able to get really good results again just by changing the harness. The coding harness as he says here was the bottleneck. He managed to push Grok Code Fast 1 from only 6.7% all the way to almost 70% simply by changing how the underlying tools work. Now this is something I’ve got a ton of experience in. If you’ve been following my channel for a while you’ll know that I do like

09:48 to cover open weight models so models that run on your own hardware and I’ve been running these models in OpenCode, I’ve been running them in Claude Code, DeepSeek harness, you name it. And I also covered the Pi agent SDK as well. However, none of these harnesses were optimized for local models. Now just to respect your time I’m not going to go into all the details again, you can definitely check out my video on SMOL coder, but basically what happens is these harnesses, remember the harness is the thing that

10:19 injects like the system prompt, the memory files that makes the tools available, those harnesses inject way too much context for these small models. Typically your local models have a very tiny context window, especially on consumer grade hardware. If your entire context window is only like 32,000 tokens or 64,000 tokens, you cannot afford to inject Claude Code’s 30,000 tokens, which is just purely harness

10:50 stuff into the context window. So I decided to create this SMOL coder harness which strips away anything an open weight model will never need. Open weight models that run on your own hardware will never need to run things like MCP tools or subagents and it should have a limited set of tools as well. And the system should be tiny and just optimized for a specific function. And maybe if I can give you a really quick demo of what it looks like, it’s

11:21 just a normal CLI tool. There’s a web-based version as well of course, but this makes it really easy to pull in any model that you want. It automatically detects models from LM Studio and Ollama as well. And if you’ve ever tried to use open weight models with you know things like the Pi agent SDK or OpenCode or even Claude Code, there’s a lot of configuration that needs to be done up front. But this harness, because it’s custom and I can do whatever I want, makes it stupidly easy to detect models on your own hardware and it’s really

11:53 optimized for that model. All the tool definitions, the system prompt, everything this model needs only takes 1,400 tokens. And if I actually run Claude right now, let’s go to context. Before I’ve sent a single message to Claude, it’s already taking up over 30,000 tokens of my context window. So running an open weight model in this harness would simply not be practical. I’ve seen plenty of examples as well where organizations need custom harnesses and control what their

12:24 developer experience should look like. So for example, they do not necessarily want to be locked into any cloud, they might want to give their developers access to different providers like OpenAI as well. But the tools and the sort of experience needs to be consistent. So if you build your own harness, that’s really easy. You can change the providers, you can change the models, and it’s all controlled within that custom harness. You can implement organizational policies, you can control what tools you are allowed to assign, what administrative

12:55 rights there are. So you can really do really cool stuff with custom harnesses. Now once you learn how to build your own custom harness, it’s definitely worth stepping up and looking at building orchestration harnesses. In an orchestration harness, you actually manage multiple coding harnesses. So you can have a harness that facilitates long running jobs, and each job is executed by a specific coding agent or harness. So AutoForge is one example of a long

13:25 running harness. You plan out all the features that you want, they go into a bit of a to-do board, and then the agent will run implementing these changes one at a time. And there could be hundreds of features, and it could take the agent, you know, not just hours or days, but even weeks to get through all of it. But the important thing is you don’t have to sit there and babysit the agent, it can just do all of this work and test it on autopilot. Another example of an orchestration harness would be a software factory. Now this

13:57 is not really interesting to look at, I’ll show you a really fun example in a second. But a software factory is basically where you’ve got this agent swarm. So you’d have maybe 10 or 20 coding agents all sitting in the background. And these agents could be a mix of agents. You might have Codex agents, you could have Claude Code agents, maybe even your own coding harness. These agents are just kind of waiting for work. And what the software factory will do is whenever you need to do any of your projects, the software

14:28 factory will allocate that task to one of your available coding agents. If all of the agents in your swarm are busy, the software factory will deal with it. It will actually wait until an agent becomes available before allocating the next task. I do have a dedicated video on building software factories, which I’ll link to in the description of this video too. And finally, no one said an agent harness should be boring. This is my coding swarm represented in 3D space. And these

14:58 guys are working on an actual project. Each of these agents are running a coding harness. So this could be Claude Code, it could be Codex. If I run to any of these monitors, I can actually see like this guy is actually running Claude Opus. So this is using Claude Code. And some of them are using other coding harnesses as well, all represented in 3D space. And this also uses the Kanban board. And these are hooked up to actual GitHub issues.

15:29 So when I click on any of these, we can actually jump to the actual pull request sitting on GitHub. And just like with a long running harness, we can assign as many tasks as we want. This could be hundreds of tasks. And these agents will keep working away in the background until everything was pulled, tested and verified. And by the way, this project and all of my projects are open source. And you can use them today. If this video helped you in any way, hit the like button and subscribe to my channel for more agentic coding

16:00 videos. I also hope that you’ll join Agentic Labs and I hope to see you in the live sessions. Thank you for watching. I’ll see you in the next one. Bye bye.