A maior parte das discussões corporativas sobre IA agêntica em 2026 foca no modelo. Claude, GPT, Gemini, Llama. Vence quem responde melhor no benchmark da semana. Esse é o ponto errado de comparação. O que diferencia um piloto de agente de IA que entrega valor de um piloto que trava no primeiro mês de produção é o agent harness, a infraestrutura que envolve o modelo. Modelo é commodity em ascensão. Harness é onde mora a vantagem competitiva.
A diferença entre o modelo e o agente
Um modelo de linguagem (LLM) é uma função. Você dá um texto, ele devolve um texto. Stateless, atômico, isolado. O modelo não sabe que ferramentas existem, não tem memória do que aconteceu na conversa anterior, não decide sozinho quando parar de gerar e nem como recuperar de um erro. Tudo isso é responsabilidade do que está ao redor.
Um agente é o sistema que persegue um objetivo. Recebe uma instrução com intenção ("identifique os 3 produtos com queda de venda no Q1 e proponha próximo passo"), decompõe em sub-tarefas, consulta dados, formula hipóteses, valida, escreve relatório. Cada passo gera uma decisão sobre o próximo. O agente continua até concluir, esgotar o orçamento de execução ou bater num erro que não consegue resolver sozinho.
A diferença entre os dois é o harness. Mesmo modelo subjacente, harness diferente, capacidade radicalmente diferente. É por isso que o Claude Code consegue tarefas que o mesmo Claude na API direta não consegue, mesmo executando o mesmo modelo por baixo. O que mudou foi a infraestrutura.
Os componentes que formam um harness
Um harness completo tem seis componentes. Cada um resolve um problema específico que o modelo sozinho não resolve.
O loop de execução decide quando o agente continua, pausa ou termina. Pode ser um simples while-loop com critério de parada explícito, ou uma máquina de estados mais elaborada com replanejamento condicional. O loop é o que transforma uma resposta única em sequência de ações.
O gerenciamento de contexto controla o que o modelo vê em cada chamada. A janela de contexto é cara e limitada, então o harness decide o que cabe (instruções globais, histórico recente, resultados de ferramentas, arquivos relevantes) e o que sai (mensagens antigas, resultados resumidos, ramos abandonados). Esse é provavelmente o componente mais subestimado, e o que mais impacta o custo e a qualidade.
O sistema de prompts define as instruções persistentes do agente: identidade, regras, formato de saída, fronteiras éticas. No Claude Code isso vive em arquivos CLAUDE.md por escopo (global, projeto, subpasta), com herança hierárquica. Em outros harnesses, é prompt do sistema mais configurações de comportamento.
As ferramentas (tools) são o que o agente pode chamar pra interagir com o mundo: ler arquivo, executar comando, consultar banco, buscar na web. O harness define o catálogo, descreve cada ferramenta em linguagem que o modelo entende, e media a chamada. O Model Context Protocol padronizou a interface entre agente e ferramenta externa, o que permite trocar de harness sem reescrever as integrações.
As skills são pacotes de instrução, exemplo e ferramenta carregados sob demanda pra uma tarefa específica. O agente decide qual skill ativar, executa, e descarrega quando termina. Skill é a unidade reutilizável do harness.
A memória é o que persiste entre execuções. Pode ser explícita (arquivos que o agente lê e escreve) ou implícita (contexto recuperado por similaridade, no estilo RAG). Memória é o que distingue um agente que repete o mesmo erro de um agente que melhora com uso.
Por que o harness importa mais que o modelo
A pesquisa "Natural-Language Agent Harnesses" (Pan et al., Tsinghua) mostrou que harnesses descritos em linguagem natural superam harnesses programados em código quando a intenção de verificação é expressa com precisão. No benchmark do paper, o success rate de agentes saltou de 30,4% para 47,2% só com mudança de harness, mantendo o mesmo modelo. A descoberta é desconfortável pra quem comprou a narrativa de que basta esperar o próximo modelo melhor: quase metade do gap de qualidade não estava no modelo, estava no que envolve o modelo.
Caso público que mostra a mesma lógica: a Stripe construiu o sistema Minions, um harness multi-agente para tarefas financeiras, com modelos comerciais comuns por baixo. O ganho de produtividade reportado em discussões públicas da empresa veio quase todo do desenho do harness, não da troca de modelo. A mesma intuição aparece em relatos da Anthropic sobre construir agentes: o gargalo de qualidade migrou da inteligência do modelo pra disciplina de engenharia ao redor.
A consequência prática pro decisor é que comparar pilotos de IA agêntica olhando só pra qual modelo está rodando é olhar pro lugar errado. Dois pilotos com o mesmo Claude Sonnet 4.6 podem entregar resultado oposto se um tem harness disciplinado e o outro tem harness improvisado. Modelo é hipótese; harness é execução.
Os principais harnesses no mercado em 2026
Não existe um harness "vencedor", existem harnesses com foco diferente. A tabela abaixo lista os mais maduros, com o ângulo editorial de cada um. Não é ranking, é mapa.
| Harness | Mantenedor | Foco principal | Onde brilha |
|---|---|---|---|
| Claude Code | Anthropic | Engenharia de software via terminal/IDE | Tarefas longas com gerenciamento de contexto disciplinado e skills declarativas |
| Codex | OpenAI | Geração de código com paralelismo | Geração assistida em IDE e execução em sandbox |
| Gemini CLI | Agentes multimodais com integração Google | Tarefas que envolvem busca, vídeo e dados do ecossistema Google | |
| Cursor | Anysphere | IDE-first, edição assistida | Refatoração e edição em projetos grandes com indexação semântica |
| Aider | Open source | CLI minimalista, pluggable | Quem quer harness aberto, customizável e sem lock-in |
A escolha do harness é decisão arquitetural, não preferência. Pesa quem opera (engenheiro vs analista), quanto contexto cabe na tarefa típica, qual o nível de auditoria exigido, e quais sistemas precisam ser integrados.
Como avaliar o harness numa proposta de IA agêntica
Quando alguém apresenta um piloto de IA agêntica, quatro perguntas separam piloto sério de teatro técnico. Estas perguntas são complementares ao framework de avaliação de proposta de IA e focam especificamente na infraestrutura.
A primeira é sobre gerenciamento de contexto. Como o sistema decide o que entra e sai da janela do modelo a cada passo? Resposta tipo "manda tudo" é red flag. Custo explode, latência sobe, qualidade cai. Resposta tipo "filtramos por relevância e descartamos histórico antigo" merece um segundo nível: como mede relevância, como audita o que foi descartado.
A segunda é sobre recuperação de erro. O que acontece quando uma ferramenta falha? Quando o modelo gera resposta inválida? Quando a tarefa entra em loop? Sistema sério tem política explícita de retry, fallback e abort. Sistema improvisado tem stacktrace voando pra cima.
A terceira é sobre limite de execução. Existe orçamento explícito (de tokens, de tempo, de chamadas de ferramenta) que faz o agente parar de tentar? Sem limite, agente roda até o erro, ou até o cartão de crédito vencer.
A quarta é sobre auditabilidade. É possível inspecionar a sequência de passos que o agente tomou pra chegar no resultado? Sem trace, não tem como debugar regressão nem provar conformidade. E sem auditoria, não passa em compliance corporativo.
Quem responde essas quatro com clareza está construindo agente. Quem desvia para "o modelo cuida disso" está apresentando demo, não produto.
O que vem depois
A anatomia do agente continua nos próximos posts deste subcluster:
- O que são skills em agentes de IA — os artefatos que estendem o harness com capacidade reutilizável.
- O que são sub-agentes — instâncias filhas que delegam tarefa com contexto isolado.
- Equipe de agentes: quando multi-agent vale e quando vira teatro — orquestração de vários agentes e os anti-padrões mais comuns.