Engenharia de harness: deixe qualquer agente de programação 10x melhor

Autoria: Leon van Zyl · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Harness Engineering: Make Any Coding Agent 10x Better · Canal: Leon van Zyl · 16:00 · Assistir no YouTube

Tópicos: Agentes de IA, Modelos locais e open source

Resumo

O vídeo apresenta três níveis de engenharia de harness: configurar um harness existente, criar harnesses personalizados e orquestrar vários harnesses. Um harness define instruções, ferramentas, verificações, memória e limites de atuação, compondo o ambiente do agent junto com o modelo. Configurações como arquivos de memória e hooks podem tornar o comportamento do agent mais consistente e impor verificações. Harnesses personalizados também podem melhorar resultados ao adaptar ferramentas e contexto ao modelo, especialmente no caso de modelos locais com context window limitada. Por fim, harnesses de orquestração coordenam agentes para executar tarefas longas ou distribuir trabalho em uma software factory.

Pontos-chave

Um agent é formado pelo modelo e pelo harness que determina seu ambiente, suas instruções, ferramentas, verificações e memória.
No primeiro nível, é possível configurar um harness existente com arquivos como AGENTS.md e hooks.
Arquivos de memória podem ser divididos em documentos menores e também usados para transferir o contexto entre sessões.
Hooks podem impor comportamentos, como verificar se o changelog foi atualizado ou se os testes foram executados.
Um harness personalizado pode mudar os resultados sem alterar o modelo ou o prompt, adaptando ferramentas e contexto.
Harnesses enxutos podem ser mais adequados para modelos open weight locais, que podem ter context window limitada.
Organizações podem criar harnesses próprios para controlar provedores, modelos, ferramentas, permissões e a experiência dos desenvolvedores.
Harnesses de orquestração coordenam múltiplos harnesses para executar tarefas longas ou distribuir trabalho entre agentes.

Capítulos

Início	Capítulo	Resumo
00:00	O que é um harness	O apresentador explica que o harness define o ambiente, as regras, as ferramentas, as verificações e a memória disponíveis ao agent.
03:34	Nível 1: configurar um harness existente	O vídeo mostra como usar arquivos de memória, documentos de transferência de contexto e hooks para orientar e verificar o trabalho do agent.
07:45	Nível 2: criar harnesses personalizados	O apresentador descreve como um harness próprio pode controlar capacidades e melhorar resultados, inclusive para modelos locais com contexto limitado.
12:55	Nível 3: orquestrar vários harnesses	O vídeo apresenta harnesses para tarefas de longa duração e software factories que distribuem trabalho entre agentes.
14:28	Um coding swarm em ação	O apresentador mostra agentes em um ambiente 3D conectados a um quadro Kanban e a issues e pull requests no GitHub.

Citações

Um agent é o modelo mais o harness. — 03:03

Assim, você não depende de o agent se lembrar de fazer algo. — 07:14

O coding harness era o gargalo. — 09:17

Tudo de que esse modelo precisa ocupa apenas 1.400 tokens. — 11:53

Conceitos e entidades

Harness Engineering (conceito): Prática de configurar, criar ou orquestrar harnesses para definir as capacidades e o ambiente de trabalho de agents.
Agent (conceito): No vídeo, é a combinação do modelo com o harness que fornece instruções, ferramentas, verificações e memória.
hook (conceito): Mecanismo que permite executar ações em eventos do ciclo de vida de um agent, como antes de enviar um prompt ou ao concluir uma tarefa.
AGENTS.md (ferramenta): Arquivo de memória usado para registrar instruções que o agent deve seguir em um projeto.
Claude Code (ferramenta): Harness de programação citado como exemplo de ferramenta que pode ser configurada.
Codex (ferramenta): Harness de programação citado como exemplo e como um dos tipos de agent que podem integrar uma software factory.
OpenCode (ferramenta): Harness de programação mencionado entre as opções existentes para trabalhar com modelos.
Claude Mods (ferramenta): Recurso citado como forma de personalizar Claude Code por meio de hooks.
Deep Agents CLI (ferramenta): Ferramenta de coding agent da LangChain usada no experimento mencionado sobre melhoria de resultados por meio do harness.
LangChain (empresa): Organização citada por um experimento que obteve resultados melhores com um harness próprio.
Can Bölük (pessoa): Autor de uma publicação mencionada sobre a influência do harness nos resultados do Grok Code Fast 1.
Grok Code Fast 1 (modelo): Modelo citado em um exemplo em que a alteração do harness melhorou os resultados.
Smol Coder (repo): Harness criado pelo apresentador para reduzir o contexto e adaptar as ferramentas a modelos open weight locais.
Pi agent SDK (ferramenta): SDK de agent citado entre as opções usadas com modelos locais.
LM Studio (ferramenta): Aplicativo cujos modelos locais podem ser detectados automaticamente pelo SMOL coder.
Ollama (ferramenta): Ferramenta cujos modelos locais podem ser detectados automaticamente pelo SMOL coder.
orchestration harness (conceito): Harness que gerencia vários coding harnesses para executar tarefas longas ou distribuir trabalho.
AutoForge (ferramenta): Exemplo de harness para tarefas de longa duração que organiza funcionalidades e as implementa uma a uma.
software factory (conceito): Sistema que distribui tarefas entre agentes de programação disponíveis e aguarda quando todos estão ocupados.
Agentic Labs (empresa): Comunidade mencionada pelo apresentador, com aulas e sessões sobre coding agents e harness engineering.

Tradução completa (pt-BR)

00:00 A maioria das pessoas e das empresas pensa que o harness de programação que recebe é o único que existe. Você instala Claude Code, Codex ou OpenCode, configura o modelo, adiciona alguns arquivos de memória, talvez alguns hooks e algumas ferramentas, e acha que é só isso. Mas, na realidade, esse é apenas o nível um da engenharia de harness. E a maioria das pessoas que desenvolve com IA nunca vai além dele. Engenharia de harness é algo pelo qual sou realmente apaixonado. E já trabalhei com muitas pessoas e equipes para mostrar como elas podem usar harnesses de programação de forma eficaz

00:31 e até criar os próprios. Se você quer seguir carreira como engenheiro de IA ou trabalhar com clientes de verdade, precisa entender os três níveis da engenharia de harness, que vamos abordar neste vídeo. Você vai se divertir bastante. Então, chega de conversa, vamos começar. Se esses assuntos também despertam seu interesse, considere participar da minha comunidade, Agentic Labs. Temos várias salas de aula sobre como usar agentes de programação para criar coisas muito legais. E, toda quinta-feira, temos

01:01 sessões aprofundadas, nas quais discutimos engenharia de harness por uma hora e meia. Então, se quiser acompanhar a sessão inteira, você pode encontrá-la na sala de aula. E, na quinta-feira, vamos começar uma série totalmente nova em que vou ensinar você a sair do zero e se tornar especialista no trabalho com agentes de programação. Também estamos com uma oferta especial no momento: US$ 100 de desconto no plano anual. Espero ver você por lá. Se você usa IA há algum tempo, provavelmente já ouviu a palavra agent muitas vezes. Mas o que exatamente é um agent? Bem, um agent é, na verdade, o

01:31 modelo, como seu grande modelo de linguagem, e seu harness. O modelo seria seu grande modelo de linguagem, como Opus, Fable ou GPT-6. Esses são os modelos propriamente ditos, que basicamente formam o cérebro da operação. O harness é o ambiente no qual esse LLM funciona. O harness é o que define as regras que o agent precisa seguir. Ele atribui as ferramentas às quais o agent deve ter acesso, como, por exemplo, a capacidade de escrever

02:02 arquivos, buscar arquivos, navegar na web, abrir o navegador etc. O harness também impõe as verificações que precisam ser executadas, como rodar suítes de testes, fazer lint e verificar os tipos; você provavelmente já viu isso antes. O harness também pode disponibilizar coisas como hooks. São certos eventos que acontecem ao longo do ciclo de vida do agent e nos quais podemos nos conectar. Por exemplo, talvez, no momento em que enviamos um prompt a um agent, queiramos primeiro executar um script personalizado para verificar se o prompt contém alguma informação confidencial e mascarar essa informação antes que ela chegue ao agent propriamente dito.

02:32 Os hooks podem ser usados para muitas coisas diferentes. Aliás, Claude lançou recentemente Claude Mods, que permite personalizar sua experiência com Claude Code, mas, nos bastidores, Claude Mods basicamente usa hooks. O harness também dá ao agent acesso a arquivos de memória. Isso inclui seu arquivo AGENTS.md, o design.md, o SOUL.md ou até arquivos dentro da pasta docs. O

03:03 harness também pode controlar como colocar o agent em uma sandbox. Por exemplo, os agents devem trabalhar em um espaço de trabalho bem específico, ou só devem ter permissão para criar novas árvores de trabalho e branches de funcionalidade, sem nunca poder alterar a branch principal. Espero que você já esteja começando a entender que o harness é o que fornece as capacidades ao agent e define o ambiente e as regras dentro das quais ele pode trabalhar. Em termos bem simples, um agent é o modelo mais o harness. O harness disponibiliza as instruções, as

03:34 ferramentas, as verificações e a memória a que o agent tem acesso. Claro, isso também pode ser ampliado com recursos adicionais, como subagents e workflows, mas tudo isso é disponibilizado pelo harness. Agora que temos uma ideia geral do que são um harness e um agent, chegou a hora de discutir os três níveis da engenharia de harness, que são o ponto central deste vídeo. O primeiro nível é a configuração. A maioria de vocês que está assistindo a este vídeo está nesse nível agora. É quando vocês usam um harness de programação

04:06 criado pelo provedor ou uma ferramenta de terceiros. Por exemplo, se você usa Claude Code, está nesse nível. Nesse caso, o que você faz é configurar o harness para funcionar da maneira que quiser. Então, se quiser que o agent siga regras bem específicas, você pode atualizar o arquivo AGENTS.md para fornecer essas diretrizes ao agent. Para mostrar rapidamente como isso é na prática, na maioria dos projetos, você define as regras no arquivo AGENTS.md. Isso é chamado de arquivo de memória.

04:38 Isso significa que podemos colocar nesse arquivo todas as regras que queremos que o agent siga sempre que iniciarmos uma nova sessão. Na próxima vez que começarmos uma nova sessão com Claude, ele seguirá essas regras. Isso não se aplica apenas a Claude. O arquivo AGENTS.md é, na verdade, um padrão aberto. Qualquer harness de programação que valha a pena usar respeitará esse arquivo AGENTS.md. A regra geral para esse arquivo é: se o agent começar a fazer algo no chat de que você realmente não gosta, adicione uma regra a esse arquivo dizendo para ele nunca

05:08 fazer aquilo de novo, ou dê a ele diretrizes sobre como deve se comportar no futuro. Esse arquivo também pode ser organizado em partes, o que significa que você não precisa colocar tudo no mesmo arquivo Markdown. Ele vai ficar comprido demais. Em vez disso, você pode dividir todas as regras e armazená-las em arquivos separados. Uma convenção comum é criar essa pasta docs, dividir seus arquivos Markdown em arquivos menores e organizá-los de forma estruturada dentro dessa pasta docs. E, no seu arquivo AGENTS.md principal,

05:39 você pode ter um índice parecido com este, que aponta para todos esses arquivos simples na pasta docs. Cada um desses arquivos nada mais é do que um arquivo Markdown menor, com instruções bem específicas para aquela parte do aplicativo. Outra dica sobre arquivos de memória: se suas sessões estiverem ficando longas demais e você estiver prestes a atingir o limite da sua context window, basta pedir ao agent que registre o progresso e o que ainda precisa ser feito em arquivos separados. Por exemplo,

06:12 eu precisei pedir ao meu agent que criasse este documento de transferência, para que você pudesse iniciar uma nova sessão com um novo agent e eu pudesse simplesmente passar esse documento a ele. Com todo o contexto disponível nesses documentos, aquele agent sabia exatamente o que tinha acontecido até então, do que se tratava o projeto e como dar continuidade. Claro, você também pode configurar o harness de muitas outras maneiras, por exemplo, adicionando hooks. Se eu mudar para o VS Code por um instante, preparei esta demonstração bem simples para você.

06:43 Neste aplicativo, sempre que fazemos uma alteração, nosso agent deve registrar uma entrada no changelog. Não tenho nenhum arquivo AGENTS.md aqui. O ideal seria ter um que instruísse o agent a atualizar o changelog, mas também posso impor esse comportamento com hooks. A maioria dos harnesses permite se conectar a determinados eventos. Por exemplo, quando enviamos um prompt, talvez queiramos intervir, capturar o prompt e fazer algo com ele antes de passá-lo ao

07:14 agent. Há muitos hooks disponíveis, e um hook muito valioso é o hook de parada. Quando o agent conclui o trabalho, podemos acionar esse hook e fazer algo com a conversa. Esse script verifica se o changelog foi atualizado e, se não foi, envia uma mensagem dizendo: “Ei, você precisa voltar e adicionar uma entrada ao changelog”, impondo esse comportamento. Você pode fazer o mesmo para verificar se um PR foi criado ou se uma suíte de testes foi executada. Há muitas coisas que você

07:45 pode ser aplicado como parte do harness. Assim, você não depende do agent para se lembrar de fazer algo. É claro que configurar o harness é apenas o nível um. No nível dois, criamos harnesses personalizados e, acredite, construir seu próprio harness está em alta demanda agora. Certas organizações precisam ter a capacidade de controlar o que os desenvolvedores podem fazer. Por exemplo, aplicar políticas, dar aos agents acesso a ferramentas muito específicas ou limitar certas capacidades. Trabalhei com muitas

08:16 marcas e vi um monte de harnesses personalizados por aí. Mas por que você iria querer construir seu próprio harness em vez de simplesmente usar os que já existem? E é muito difícil fazer isso? É algo que alguém sem experiência técnica consegue fazer? Primeiro, deixe-me dizer o seguinte: qualquer pessoa pode construir um harness. Na verdade, tenho um curso gratuito na minha comunidade gratuita que ensina a construir seu próprio harness de programação, e tem sido muito legal ver os resultados que as pessoas conseguiram. Vi alguns exemplos muito legais

08:47 em que apenas mudar o harness foi suficiente para pegar o mesmo modelo e melhorar suas respostas. Por exemplo, há algum tempo a LangChain fez esse experimento: usaram o GPT-5.2 — exatamente o mesmo modelo e o mesmo prompt — e conseguiram resultados melhores do modelo usando a própria ferramenta Deep Agents CLI, o próprio harness de agent de programação. Conseguiram aumentar o resultado de 53% para cerca de 66%.

09:17 Também há uma publicação muito popular no X, de Can Bölük — desculpe se estou pronunciando seu nome errado —, mas ele conseguiu resultados muito bons novamente apenas mudando o harness. Como ele diz aqui, o gargalo era o harness de programação. Ele conseguiu levar o Grok Code Fast 1 de apenas 6,7% para quase 70%, simplesmente mudando o funcionamento das ferramentas subjacentes. Tenho bastante experiência com isso. Se você acompanha meu canal há algum tempo, sabe que gosto

09:48 de falar sobre modelos com pesos abertos, ou seja, modelos que rodam no seu próprio hardware, e tenho executado esses modelos no OpenCode, no Claude Code, no harness do DeepSeek, entre outros. Também falei sobre o Pi agent SDK. No entanto, nenhum desses harnesses foi otimizado para modelos locais. Para respeitar seu tempo, não vou entrar em todos os detalhes de novo; você pode conferir meu vídeo sobre o SMOL coder, mas, basicamente, o que acontece é que esses harnesses — lembre-se de que o harness é aquilo que

10:19 insere coisas como o system prompt e os arquivos de memória, além de disponibilizar as ferramentas — acabam inserindo contexto demais para esses modelos pequenos. Em geral, seus modelos locais têm uma context window muito pequena, especialmente em hardware de consumo. Se sua context window inteira tem apenas 32.000 ou 64.000 tokens, você não pode se dar ao luxo de inserir os 30.000 tokens do Claude Code, que são apenas conteúdo do harness, na context window.

10:50 Então decidi criar este harness SMOL coder, que remove tudo de que um modelo com pesos abertos nunca vai precisar. Modelos com pesos abertos que rodam no seu próprio hardware nunca vão precisar executar coisas como ferramentas MCP ou subagents, e também devem ter um conjunto limitado de ferramentas. O sistema deve ser pequeno e otimizado apenas para uma função específica. E, se eu puder mostrar rapidamente como ele é, é

11:21 apenas uma ferramenta CLI normal. Claro que também existe uma versão baseada na web, mas isso facilita muito carregar qualquer modelo que você quiser. Ele também detecta automaticamente os modelos do LM Studio e do Ollama. E, se você já tentou usar modelos com pesos abertos com coisas como o Pi agent SDK, o OpenCode ou até o Claude Code, sabe que é preciso fazer bastante configuração antes. Mas este harness, por ser personalizado e me permitir fazer o que eu quiser, torna ridiculamente fácil detectar modelos no seu próprio hardware, e é realmente

11:53 otimizado para esse modelo. Todas as definições de ferramentas, o system prompt, tudo de que esse modelo precisa ocupa apenas 1.400 tokens. E, se eu executar o Claude agora e abrir a seção de contexto, antes mesmo de eu enviar uma única mensagem ao Claude, ele já está ocupando mais de 30.000 tokens da minha context window. Portanto, não seria prático executar um modelo com pesos abertos neste harness. Também vi muitos exemplos de organizações que precisam de harnesses personalizados e querem controlar como deve ser a experiência dos desenvolvedores.

12:24 Por exemplo, elas não querem necessariamente ficar presas a uma única nuvem; talvez queiram dar aos desenvolvedores acesso a diferentes provedores, como a OpenAI também. Mas as ferramentas e o tipo de experiência precisam ser consistentes. Se você construir seu próprio harness, isso fica muito fácil. Você pode mudar os provedores, mudar os modelos, e tudo fica controlado dentro desse harness personalizado. Pode implementar políticas organizacionais, controlar quais ferramentas pode atribuir e quais direitos administrativos

12:55 existem. Assim, dá para fazer coisas muito legais com harnesses personalizados. Depois de aprender a construir seu próprio harness personalizado, vale a pena avançar e pensar em construir harnesses de orquestração. Em um harness de orquestração, você gerencia vários harnesses de programação. Assim, pode ter um harness que coordena tarefas de longa duração, e cada tarefa é executada por um agent de programação ou harness específico. O AutoForge é um exemplo de harness de longa

13:25 duração. Você planeja todos os recursos que quer, eles são colocados em uma espécie de quadro de tarefas, e então o agent começa a implementar essas mudanças, uma de cada vez. Podem ser centenas de recursos, e o agent pode levar não apenas horas ou dias, mas até semanas para concluir tudo. Mas o importante é que você não precisa ficar ali supervisionando o agent; ele pode simplesmente fazer todo esse trabalho e testá-lo no piloto automático. Outro exemplo de harness de orquestração seria uma fábrica de software. Agora, isso

13:57 não é muito interessante de observar; vou mostrar um exemplo muito divertido daqui a pouco. Mas uma fábrica de software é basicamente um enxame de agents. Você teria talvez 10 ou 20 agents de programação trabalhando em segundo plano. E esses agents poderiam ser uma mistura de diferentes agents. Talvez você tenha agents do Codex, agents do Claude Code, talvez até seu próprio harness de programação. Esses agents ficam ali, meio que esperando por trabalho. E o que a fábrica de software faz é, sempre que você precisa trabalhar em algum dos seus projetos, a fábrica de software

14:28 atribui a tarefa a um dos seus agents de programação disponíveis. Se todos os agents do enxame estiverem ocupados, a fábrica de software cuida disso. Ela espera até que um agent fique disponível antes de atribuir a próxima tarefa. Tenho um vídeo dedicado a construir fábricas de software, que também vou deixar linkado na descrição deste vídeo. E, por fim, ninguém disse que um agent harness precisa ser entediante. Este é meu enxame de programação representado em um espaço 3D. E esses

14:58 agentes estão trabalhando em um projeto de verdade. Cada um desses agents está executando um harness de programação. Pode ser o Claude Code, pode ser o Codex. Se eu for até qualquer um desses monitores, posso ver, por exemplo, que este aqui está executando o Claude Opus. Então, este está usando o Claude Code. Alguns também estão usando outros harnesses de programação, todos representados em um espaço 3D. Isso também usa um quadro Kanban. E eles estão conectados a issues reais do GitHub.

15:29 Então, quando clico em qualquer um deles, posso abrir o pull request correspondente no GitHub. E, assim como em um harness de longa duração, podemos atribuir quantas tarefas quisermos. Podem ser centenas de tarefas. E esses agents continuarão trabalhando em segundo plano até que tudo tenha sido baixado, testado e verificado. E, a propósito, este projeto e todos os meus projetos são open source. Você pode usá-los hoje mesmo. Se este vídeo ajudou você de alguma forma, clique no botão de curtir e inscreva-se no meu canal para ver mais vídeos sobre programação agêntica.

16:00 Também espero que você participe do Agentic Labs e espero ver você nas sessões ao vivo. Obrigado por assistir. Vejo você no próximo vídeo. Tchau, tchau.

Transcrição original

[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.