Se você já usou o Codex, Cursor, Claude Code, GitHub Copilot, Gemini CLI ou qualquer dessas ferramentas novas de IA pra ajudar a programar, você provavelmente já notou que tem coisas que o modelo no site ou app faz, mas que o Codex ou o Claude Code fazem muito melhor ou de maneira bem diferente.

O ChatGPT te dá o código em formato de texto como resposta. O Codex abre o arquivo, edita, salva, roda o teste, vê que falhou, edita de novo. Mas ué, não estão os dois com o mesmo modelo selecionado (GPT-5.5, por exemplo)? Como assim?!

Bom, se você está de olho no mundo da IA, já entendeu que o que está fazendo isso tudo não é o modelo de IA no sentido que a gente fala dele no Xuítter. É um cara que mora em volta dele, chamado harness, e que virou “a palavra de 2026”.

Se ninguém te explicou o que é isso, esse post é pra você.

Vou usar como exemplo o Codex, o harness/agente de programação da OpenAI, porque o código dele é totalmente open source, então deu pra literalmente só baixar o código e ir analisando como ele funciona por dentro.

A diferença entre “modelo” e “agente”

Vou começar separando duas coisas que a gente costuma juntar.

Um modelo de linguagem (LLM, como o GPT-5.5 ou o Claude Opus 4.7) é, fazendo uma analogia, uma função. Você manda texto, ele faz cálculos e te devolve texto. Só isso. Ele não roda comando, não abre arquivo, não tem memória do que conversou com você ontem, não acessa a internet por conta própria.

Se você manda “liste os arquivos da minha pasta Documentos”, o modelo te dá uma resposta plausível baseada no treinamento dele com milhões de conteúdos de pastas que ele viu, mas ele não vai realmente listar o que tem na sua pasta, porque ele não tem esse acesso.

Um agente é diferente. Geralmente dizemos que ele é composto por (pelo menos) três coisas:

• Cérebro: o LLM que vai pensar e planejar os próximos passos.
• Mãos: as ferramentas que darão ao modelo acesso à internet, ao seu computador, à API do tempo, etc.
• Memória: pode ser de curto prazo (lembra da sua conversa) ou mais de longo prazo (ainda não temos nada ótimo pra isso, e tem sido feito com arquivos Markdown salvos na máquina).

Quando você pede pro Codex ou pro Claude Code “ajeita esse bug aí”, ele consegue abrir a pasta onde o código está, ler o seu código macarrônico, identificar o erro, editar o arquivo, salvar, rodar o teste, ver se passou, refazer se for preciso, etc etc etc.

São várias ações de verdade, encadeadas, sem você ter que clicar em nada no meio. E ele consegue fazer isso porque tem esse harness em volta.

A palavra “harness” em inglês significa algo como rédeas ou arreios (de um cavalo), e é ela que vai controlar o seu cérebro (o LLM) tal qual um alazão rebelde, e fazer com que ele resolva o problema que você realmente quer que ele resolva.

Ou seja, pra esse caso, o harness é praticamente uma mistura das mãos e da memória do agente, tudo o que fica em volta do cérebro que é o nosso LLM. E aí, tudo isso junto, com o cérebro, seria o “agente”.

---

As sete coisas que um harness precisa fazer

Toda vez que você pede alguma coisa pro Claude Code ou pro Codex, esse harness precisa, mais ou menos:

1. Receber sua mensagem e montar o contexto pro modelo: inclui pegar o que você digitou, juntar com instruções de sistema, anexar algum histórico relevante daquela sessão e empacotar num formato que a API do modelo entenda. Aqui já mora um monte de decisão: quanto do histórico mandar, em que ordem, o que cortar quando o contexto fica grande demais, etc.
2. Receber a resposta do modelo em streaming: o modelo não cospe a resposta de uma vez; ele vai mandando palavra por palavra. O harness precisa lidar com isso e identificar tipos diferentes de resposta (texto puro pro usuário vs pedido pra executar uma ferramenta).
3. Identificar quando o modelo quer executar alguma ação: frequentemente, a resposta do modelo não é texto pra você, mas um pedido pro próprio harness do tipo “rode esse comando”, “leia esse arquivo”, “aplique esse diff”. O harness precisa reconhecer esse pedido e parsear os argumentos direito.
4. Executar a ação de verdade, com segurança: rodar comandos arbitrários no terminal do usuário é perigoso, então essa execução tem que passar por um sandbox e, dependendo do caso, por uma aprovação explícita do usuário.
5. Pegar o resultado e mandar de volta pro modelo: o resultado pode ser a saída de um comando, o conteúdo de um arquivo, uma mensagem de erro, o que for. Tudo isso vira input pro próximo round de raciocínio do modelo.
6. Repetir o ciclo X vezes até o modelo dizer “terminei”: cada ação pode disparar uma ou várias rodadas adicionais. O harness mantém o loop rodando, com cuidado pra não entrar em loop infinito (e sem deixar tudo travar quando você manda parar no meio).
7. Persistir tudo pra retomar depois: a sessão precisa ficar salva em algum lugar pra você poder fechar o terminal hoje e continuar amanhã do mesmo ponto, ou pra você revisitar o que aconteceu numa sessão antiga.

Cada um desses passos parece simples, mas não é. E o pulo do gato é que o que faz um agente ser bom não é só o modelo, mas sim o harness em volta dele.

Você pode ter o melhor modelo de código do mundo, mas se o harness dele for ruim (se ele trava, se ele não cancela quando você manda parar, se ele apaga seu repositório git por acidente, se ele esquece da conversa quando você fecha o terminal), você vai ficar puto.

Da mesma forma, um modelo que não seja tão excepcional, mas que tenha um excelente harness, pode funcionar melhor que o outro que eu citei acima.

Essa é a razão pela qual a Anthropic e a OpenAI estão investindo muito nesses harnesses, e o motivo de essa ter se tornado já a palavra de 2026 (assim como “agentes” era a palavra de 2025).

---

O loop: como o agente “pensa” e “age” alternadamente

Como falei, o código do harness do Codex é open source e está aberto no GitHub. Eu baixei ele pra dar uma olhada por baixo do capô. Resumindo bastante, uma sessão típica dele funciona assim:

Você digita algo como “adiciona no arquivo ’tal’ uma função que retorna a lista dos últimos 10 pedidos feitos na loja”. O Codex pega isso e manda pro modelo junto com instruções de sistema e contexto do projeto. O modelo não responde com código pronto. Em vez disso, ele responde com algo tipo: “primeiro preciso ler o arquivo routes.ts pra entender a estrutura”. Essa resposta é o que se chama de tool call: o modelo está pedindo pro harness executar uma ferramenta/tool (no caso, a ferramenta que consegue ler um arquivo).

O harness recebe esse pedido, usa a tool que lê o arquivo de verdade, e devolve o conteúdo pro modelo, que vai servir como o contexto do que a gente está falando. O modelo vê esse conteúdo e pensa: “ok, agora vou abrir o arquivo de pedidos pra ver o schema”, o que é mais uma tool call. Harness executa. Resultado volta. O modelo finalmente diz: “agora vou aplicar esse diff aqui”. O harness chama outra tool e executa o diff (te pedindo aprovação antes, se você configurou pra perguntar), depois chama a tool que salva o arquivo, depois chama a tool que roda os testes. Vamos supor que os testes falhem. Nesse caso, o harness avisa o modelo, o modelo identifica o erro e devolve o texto com a correção, e o harness chama de novo a tool que vai mandar um diff novo. Dessa vez, os testes passam. O modelo diz: “pronto”. Loop terminado.

Esse vai-e-volta entre “o modelo pensa o próximo passo” e “o harness executa o passo” é o que diferencia um harness de um agente de chat que nós estávamos acostumados até recentemente. Cada ida e volta dessas é uma chamada à API do modelo, com tudo que aconteceu até ali no contexto.

Um detalhe importante: cada uma dessas idas e voltas custa dinheiro. Toda chamada à API do modelo é cobrada por token (tanto o que você manda quanto o que o modelo responde, e o histórico vai junto em toda chamada). Numa tarefa simples, vão ser dezenas de chamadas. Numa sessão complexa, vão ser centenas.

Se você usa via API direto, isso entra no seu cartão de crédito (e a sua carteira vai ficar bem triste no final do mês). Se você usa via assinatura (Cursor Pro, Claude Pro, ChatGPT Plus, etc), a empresa absorve o custo, mas tem aqueles limites de 5 horas, diário e semanal. Quando você bate lá, ou tem que pagar extra ou esperar o próximo ciclo.

É por isso que harness travado é o pior pesadelo do dev de 2026 (junto com esses limites). Se o agente entra num loop infinito tentando consertar a mesma coisa de mil jeitos diferentes, quem chora é o seu cartão de crédito.

---

Sandbox: como o agente não destrói seu computador

Agora uma parte que eu achei bem legal do Codex.

Pensa comigo. Ele pode rodar comandos no seu terminal. Isso é poder absoluto, e não custa nada pra ele dar um rm -rf / e apagar o seu sistema inteiro. Se o modelo, por um motivo qualquer (alucinação, instrução mal-formada, prompt injection), decidir rodar um comando catastrófico, o que eu, você e a torcida tricolor queremos é que o harness não deixe ele fazer isso.

A solução do Codex pra isso é o que a gente chama de sandbox.

Pensa nele como um container Docker, mas pequenininho, criado só pra rodar aquele comando específico, e ser descartado em seguida. Dentro do sandbox, o comando pensa que está rodando no seu computador, mas na verdade ele só consegue mexer no que você autorizou naquele uso específico.

O Codex tem três níveis de restrição configuráveis:

• Somente leitura: o agente pode ler qualquer arquivo, mas não consegue escrever em nada. Bem útil pra quando você quer só uma análise, como “explica o que esse código faz”.
• Pode escrever só na pasta do projeto: o agente pode editar arquivos do diretório onde você está, mas não consegue mexer em /etc, em ~/.ssh/, nem em lugar nenhum fora do seu workspace. Esse é o modo padrão e é nele que o Codex roda pra você quando você manda ele resolver algum bug.
• Sem restrição: YOLO mode, vivemos perigosamente, dando acesso total. Use com cuidado, e só quando tiver certeza do que está fazendo.

Um detalhe é que o Codex tem três implementações de sandbox completamente diferentes, uma pra cada sistema operacional principal (macOS, Linux, Windows), todas escondidas atrás de uma interface única.

O agente em si não sabe em qual sistema está rodando. Ele só pede pra rodar um comando, e o harness se vira pra fazer isso no SO que estiver ali (e com segurança, claro).

---

MCP: a tomada universal pra ferramentas de agentes

Outra peça importante do harness moderno é como ele se conecta a serviços externos. Você quer que o agente leia sua issue no Linear, abra um PR no GitHub, consulte um documento no Notion e busque algo numa API interna da sua empresa, mas como ele vai fazer isso?

Antigamente (em 2023, “antigamente” são dois anos atrás na velocidade da IA), cada agente implementava integração caso a caso com as APIs dos serviços. O Cursor tinha o conector dele, o Claude Code tinha o dele, e todo mundo reinventava a roda.

Em 2024, a Anthropic lançou o protocolo MCP (Model Context Protocol). É um padrão aberto que diz basicamente: “qualquer serviço pode expor as funcionalidades dele de uma maneira padrão, e qualquer agente que entenda MCP consegue usar”.

A analogia que todo mundo faz desde aquela época é a de uma “tomada universal”. Tipo, antes, cada eletrodoméstico vinha com um plugue diferente, mas agora todos encaixam na mesma.

Hoje você instala um servidor MCP do GitHub e qualquer agente que saiba “falar MCP” (Claude Code, Codex, Cursor, e outros) consegue ler as suas issues, criar PRs, etc. Você instala um servidor MCP do Notion, e seus agentes conseguem ler os seus documentos. Outra analogia bacana é de um “marketplace de tools”.

Falando do Codex especificamente, ele faz uma coisa interessante. Ele é tanto cliente quanto servidor MCP. Como cliente, ele consome MCP servers que você configurar (GitHub, Notion, whatever). Como servidor, ele expõe o próprio Codex como uma ferramenta que outros agentes podem usar.

Isso quer dizer que, em tese, você pode rodar o Claude Code e configurar o Codex como uma das ferramentas dele. Vira um agente chamando outro. Muita gente fala que essa poligamia agêntica é o futuro do desenvolvimento de software.

---

Skills: a forma mais leve de ensinar truques novos pro agente

Tem ainda um segundo jeito de estender o que o agente sabe fazer, e que é importante diferenciar do MCP, que são as skills.

Uma skill, no Codex (ou no Claude Code, Cursor, etc), é basicamente uma pasta no seu computador com um arquivo SKILL.md (formato Markdown) que descreve pro agente como fazer uma tarefa específica do jeito correto ou do jeito que você quer que seja feita (tipo “revisar um PR seguindo o checklist da empresa”, “rodar nosso lint customizado”, etc), junto com scripts auxiliares quando precisa.

O Codex carrega essas skills automaticamente, e quando o que você pede bate com o que uma skill cobre, ele invoca a skill como ferramenta.

É basicamente um arquivo que contém um excelente guia de “passo a passo” que ensina o agente a fazer a Engenharia de Prompt ideal pra aquele caso específico.

Podemos pensar assim: se a sua equipe tem dez maneiras diferentes de revisar PR e você quer padronizar, use uma skill. Se sua empresa exige que toda alteração em produção passe por um checklist específico, use uma skill. Se você quer que toda vez que o agente vá gerar uma migration de banco ele siga uma convenção da casa, use uma skill.

A combinação MCP + skills é o que pode fazer um agente realmente virar um membro do time, e não um assistente genérico. O MCP encaixa ele nas suas ferramentas, e as skills ensinam ele a trabalhar do jeitinho que você gosta ou precisa.

---

Memória: o agente que lembra (e o que esquece)

Mais uma peça que dá pra observar no Codex.

Cada conversa que você tem com ele é salva num arquivo no seu disco. Você pode mandar o comando codex resume e ele retoma do ponto onde tinha parado ontem. Dá também pra forkar uma sessão, tipo “ah, eu queria ter tomado outra decisão lá no meio, deixa eu voltar pra aquele ponto e seguir em outra direção”, meio que como você faria criando um branch no GitHub, mas pras suas conversas com esses agentes.

Eles também têm a memória de longo prazo, que eu mencionei lá atrás. A ideia é que coisas que você falou ou que aconteceram numa sessão (preferências, decisões importantes, lições aprendidas) sejam destiladas e fiquem disponíveis pras próximas sessões.

O Codex implementa isso em dois estágios: primeiro extrai candidatos de memória sessão a sessão; depois, periodicamente, um agente dedicado (sim, um sub-agente rodando dentro do harness) consolida tudo num documento de memória persistente.

Como falei, essa parte da memória de longo prazo é um calcanhar de Aquiles de qualquer agente ou harness hoje em dia, e é onde provavelmente veremos muitas novidades nos próximos meses.

E é basicamente isso o que tem no código dele!

Da próxima vez que alguém te disser “essa nova ferramenta de IA usa o modelo X, então é boa”, você vai saber que isso é metade da história. Talvez nem isso.

A outra metade está no harness.

E agora você sabe onde olhar.