Por que a estrutura ao redor do modelo — o “harness” — decide se um agente de IA funciona de verdade
Durante um bom tempo, o jogo foi aprender a se comunicar melhor com o modelo. Depois, o jogo virou garantir que ele tivesse as informações certas na hora certa. Hoje, é preciso ir além.
O que trava um projeto de IA agora é tudo aquilo que cerca o modelo: quem autoriza suas ações, quem audita seus resultados, o que ele consegue reter de uma execução para outra, até onde vai seu raio de ação, e se existe algum registro do que ele fez. Esse conjunto de mecanismos ganhou um nome — “harness”, ou estrutura de execução.
Vale notar que uma etapa não anula a anterior — ela engloba. Saber montar o contexto certo já pressupõe saber formular bem o pedido. E construir um harness robusto pressupõe as duas coisas anteriores, somando ainda um conjunto de capacidades que nem o melhor prompt nem o melhor contexto conseguem entregar sozinhos: gerenciamento de ferramentas, dupla checagem, memória entre sessões, controle de acesso, rastreabilidade, escolha inteligente de modelo e capacidade de aprender com os próprios erros.
Estatísticas recentes mostram que a esmagadora maioria dos projetos corporativos de agentes de IA — quase 9 em cada 10 — não sai do papel rumo à produção. E raramente é porque o modelo escolhido é fraco. O problema costuma estar em outro lugar: informações que se perdem ao longo de sessões longas, ausência de barreiras de segurança, incapacidade de manter estado entre uma interação e outra, ou mecanismos de correção que nunca fecham o ciclo. Coloque duas equipes usando exatamente o mesmo modelo, mas com estruturas de execução diferentes, e os resultados serão completamente distintos. O que separa sucesso de fracasso é essa estrutura — não o modelo em si.
Do que se trata, afinal
Pense no modelo como o cérebro bruto, a capacidade de raciocínio pura. O harness é o que transforma essa capacidade em algo em que se pode confiar na prática. É a ponte entre o raciocínio do modelo e as consequências reais no mundo: como as ferramentas são acionadas, como o trabalho é conferido, o que fica guardado na memória, quem pode fazer o quê, e o registro de tudo isso.
Uma estrutura madura tem, no fundo, sete frentes de trabalho — e cada uma delas resolve um tipo específico de problema.
Primeira frente – ferramentas: quem manda nelas
Um princípio central: o modelo jamais deve executar uma ação por conta própria. Ele apenas propõe — indica qual função quer chamar e com quais parâmetros. Cabe à estrutura ao redor validar se o pedido faz sentido, se há permissão para aquilo, executar de fato, e devolver o resultado. Esse intermediário é justamente o que impede que uma tentativa de manipulação maliciosa vire execução de código sem controle.
Na prática, isso funciona como um sistema de rascunho seguido de aprovação. Ações que podem causar dano são propostas, mas ficam retidas até alguém confirmar. Coisas inofensivas, como apenas ler um dado, passam sem barreira nenhuma. Já ações que alteram ou apagam algo esperam luz verde.
O ganho real aqui é que o agente nunca fica “no escuro”. Toda tentativa de usar uma ferramenta — tenha ela dado certo, sido barrada por falta de permissão, ou estourado o tempo — volta para o agente como uma resposta organizada. Isso poupa o sistema de ter que adivinhar o que aconteceu lendo uma saída de terminal crua e ambígua.
Segunda frente – loops de verificação: ninguém corrige a própria prova
Um princípio quase óbvio, mas frequentemente ignorado: quem produziu algo não deve ser também quem avalia se ficou bom. Um modelo tende a ser complacente com o próprio trabalho — ele já “acredita” na solução que deu, então uma segunda avaliação, feita por outra instância com instruções diferentes, tende a pegar falhas que passariam batido numa autoavaliação.
Um episódio real ilustra bem isso: em certo momento de 2026, o Claude Code apresentou uma queda perceptível de qualidade. Ao investigar, a Anthropic identificou três alterações distintas na camada de estrutura — nada relacionado ao modelo em si: um ajuste que reduziu o esforço de raciocínio permitido, uma falha de cache que descartava parte do histórico de “pensamento” do modelo, e um prompt que restringia demais a verbosidade das respostas. O modelo continuava sendo o mesmo modelo. O que mudou foi tudo em volta dele — e isso bastou para degradar a experiência inteira. A empresa publicou uma análise pública do ocorrido. A conclusão não foi “o modelo precisa melhorar”; foi “a estrutura de execução é, na prática, a qualidade percebida do seu produto”.
Essa checagem independente não precisa ser cara. Coisas simples — o código compila? os testes passam? a mudança ficou dentro do que foi pedido? — podem ser verificadas por um modelo leve e barato. Guarde o modelo mais caro e poderoso para os casos que exigem julgamento de verdade. O que importa não é o preço do verificador, e sim o fato de ele ser separado de quem produziu o resultado.
Terceira frente – contexto e memória: o que fica na cabeça do agente
A lição da era anterior foi: o que você mostra ao modelo pesa mais do que como você formula a pergunta. O passo seguinte é deixar de depender de um humano acertando manualmente o que entra no contexto toda vez — e passar essa responsabilidade para a própria estrutura.
Um sistema bem construído resume o que já foi feito, descarta resultados de ferramentas que já cumpriram seu papel, e mantém na “mesa de trabalho” apenas o que a etapa atual realmente precisa. Sem essa disciplina, conversas longas acabam lotando a janela de contexto disponível, informação relevante começa a ser empurrada para fora, e a qualidade do raciocínio despenca aos poucos.
A memória segue a mesma lógica, só que entre sessões diferentes, não dentro da mesma conversa. Regras, restrições e lições aprendidas ficam gravadas em arquivos que são recarregados automaticamente sempre que uma nova sessão começa. Assim, um erro cometido numa sessão anterior não se repete na próxima — porque a lição já está escrita em algum lugar que o sistema sempre consulta antes de agir. Sem esse hábito, cada sessão nasce do zero, sem aprender nada do passado. Com ele, o sistema realmente evolui ao longo do tempo.
Um teste simples para saber se isso está funcionando: se, quarenta interações depois, o agente ainda respeita uma restrição definida logo no início, a memória está fazendo seu trabalho. Se ela evapora bem antes disso, não está.
Quarta frente – Proteções (guardrails): as barreiras de proteção
Antes de qualquer resposta chegar ao usuário final ou a outro sistema, ela deveria passar por uma checagem contra regras estabelecidas. Isso deixou de ser um “extra” — regulamentações recentes (leis estaduais e regionais sobre IA, exigências de conformidade que já pedem prova de controles ativos sobre o que sistemas de IA produzem) tornaram isso praticamente obrigatório.
Um erro comum é tratar todo tipo de agente com o mesmo nível de rigor. Um assistente que só conversa com clientes não precisa das mesmas travas que um agente com poder de alterar um banco de dados de produção. O nível de exigência deveria acompanhar o risco real da tarefa — nem de menos, nem exageradamente mais.
Dá para pensar nessas travas em quatro grandes grupos: as que cuidam do tom e da segurança do conteúdo gerado; as que impedem vazamento de dados sensíveis ou informação pessoal identificável; as que controlam o que o agente pode ou não executar, principalmente ações irreversíveis; e as que limitam gasto — tempo, tentativas, custo em tokens — para que uma tarefa que deveria custar centavos não vire uma fatura de centenas de dólares por causa de um loop mal controlado.
Quinta frente – observabilidade: enxergar o que está acontecendo
Um agente que funcionava perfeitamente semana passada pode começar a falhar essa semana sem que uma única linha de código tenha mudado — o provedor do modelo pode ter feito um ajuste silencioso, uma API externa pode ter mudado o formato da resposta, ou simplesmente surgiu um caso de uso que nunca tinha sido testado. Sem visibilidade sobre o comportamento do sistema, você só descobre o problema quando ele já quebrou algo em produção. Com essa visibilidade, dá para perceber o desvio antes que vire dano de fato.
Times que conseguem acompanhar cada ação tomada por um agente, e identificar quando o comportamento começa a fugir do padrão, são os que conseguem dar mais autonomia ao sistema com segurança, aos poucos. Sem esse acompanhamento, cada nova liberdade concedida ao agente é um tiro no escuro; com ele, vira uma decisão baseada em dados reais.
Vale registrar cada chamada de ferramenta e seu desfecho — isso cria uma trilha auditável do que aconteceu. Vale medir não o volume total gasto, mas o custo por resultado realmente aproveitado — se a maioria do que o agente produz acaba sendo descartada, algo está desequilibrado. E vale comparar o padrão de comportamento de uma semana com o da anterior, para pegar uma eventual regressão antes que o usuário final perceba.
Sexta frente – roteamento e seleção de modelo: nem tudo precisa da artilharia pesada
Nem toda subtarefa exige o modelo mais potente disponível. Verificar formatação ou classificar um item não pede o mesmo poder de raciocínio que planejar uma mudança arquitetural complexa. Um sistema sem essa distinção manda tudo pelo modelo mais caro e reza para o orçamento aguentar. Um sistema bem desenhado escolhe, para cada etapa, o modelo mais econômico capaz de resolver aquilo — reservando o modelo topo de linha só para onde ele realmente faz diferença.
A régua prática é simples: tarefas mecânicas e repetitivas vão para modelos rápidos e baratos; tarefas que exigem julgamento, planejamento ou raciocínio mais sofisticado vão para os modelos mais robustos. E essa escolha deve acontecer automaticamente, de acordo com o tipo de tarefa — sem depender de alguém lembrar de trocar manualmente o modelo no meio do processo.
Sétima frente – feedback e autoaperfeiçoamento: aprender com os próprios tropeços
Um sistema estático se comporta do mesmo jeito na centésima execução e na primeira. Um sistema que incorpora feedback, por outro lado, registra cada rejeição, cada estouro de tempo ou orçamento, e transforma isso em uma regra escrita — regra essa que toda execução futura vai consultar automaticamente.
Isso não tem nada a ver com retreinar o modelo; os parâmetros internos dele permanecem intocados. O que muda é o ambiente ao redor: as regras ficam mais precisas, a escolha de modelo melhora, o contexto fica mais enxuto e relevante. Com o tempo, a etapa de verificação vai encontrando cada vez menos problemas, simplesmente porque as restrições acumuladas já impedem que os erros antigos se repitam.
Por que a maioria dos projetos não decola
Esse número alto de projetos que travam antes da produção não vem de modelos incapazes — vem de lacunas estruturais: etapas puladas, verificações ignoradas, desvios de comportamento que ninguém está monitorando. Alguns padrões se repetem:
Sessões longas acabam “esquecendo” restrições definidas no começo, porque o processo de resumir o histórico descarta instruções importantes ao longo do caminho — e o agente acaba fazendo exatamente aquilo que tinha sido proibido de fazer.
Quando não existe uma segunda checagem independente, o próprio agente valida seu trabalho — e tende a aprovar quase tudo que produz. Uma avaliação externa, feita por outra instância com critérios diferentes, revela uma fatia significativa de problemas que passariam despercebidos numa autoavaliação.
Sem controle de permissões por ferramenta, uma tentativa de manipulação externa — por exemplo, embutida no texto de uma tarefa ou ticket — pode virar execução de comando sem que nada a impeça no caminho.
Atualizações silenciosas feitas pelo provedor do modelo podem mudar sutilmente o comportamento do sistema, e sem uma referência de comportamento “normal” para comparar, isso pode passar batido por semanas.
A ausência de qualquer persistência entre sessões faz com que o mesmo contexto precise ser reconstruído do zero repetidamente, a um custo real — e os mesmos erros voltam a acontecer porque nada foi de fato aprendido.
E, sem limites claros de gasto, um agente preso num ciclo de tentativas repetidas pode gerar uma conta bem mais alta do que qualquer um esperava.
Em todos esses casos, o modelo em si não é o vilão. Troque-o por outro e o mesmo tipo de falha volta a acontecer. Ajuste a estrutura ao redor, e o mesmo modelo passa a funcionar bem. O momento ideal para pensar nessa estrutura é antes de qualquer usuário real interagir com o agente — não depois que o primeiro problema já causou estrago.
Os limites dessa abordagem
Uma estrutura de execução bem feita não conserta um objetivo mal definido. Se a tarefa em si é vaga, o sistema mais sofisticado do mundo vai simplesmente errar com muita consistência.
As travas de segurança também precisam de manutenção — permissões configuradas uma vez e nunca revisadas dão uma falsa sensação de controle; vale revisá-las periodicamente.
E existe o risco oposto: exagerar na quantidade de camadas de aprovação e verificação torna tudo lento e burocrático. Um sistema pensado para o setor financeiro, aplicado sem ajuste a um projeto pequeno e experimental, vai parecer desnecessariamente pesado. O nível de controle deveria ser proporcional ao risco real envolvido.
No fim das contas, essa estrutura é infraestrutura — não é o produto em si. Ninguém valoriza a estrutura de execução por ela mesma; o que importa é o resultado que o agente entrega através dela.
Para fechar
Se antes o desafio era formular bem uma pergunta, e depois passou a ser escolher bem o que mostrar ao modelo, agora o desafio é montar tudo o que cerca esse modelo para que ele possa operar de verdade em produção: quem autoriza suas ações, quem confere seu trabalho, o que ele carrega de uma sessão para outra, até onde ele pode ir, e se existe registro do que foi feito.
Continuar escolhendo qual modelo usar como se isso ainda fosse a decisão mais importante é responder a uma pergunta que já ficou para trás. O modelo é só o motor; a estrutura ao redor é o veículo inteiro. Não faz sentido entregar um motor sem nada em volta dele.
Não é preciso implementar tudo de uma vez. Comece pelo controle de ferramentas e por uma checagem básica de qualidade. Adicione memória quando perceber que as mesmas situações estão se repetindo entre sessões. Adicione travas de segurança quando o agente passar a interagir com algo visível ao cliente final. Adicione monitoramento quando precisar comprovar que o sistema está funcionando como esperado. Adicione escolha inteligente de modelo quando o custo começar a incomodar. E adicione a capacidade de aprender com os próprios erros quando quiser que o sistema realmente pare de tropeçar na mesma pedra.
São sete frentes de trabalho ao todo. Ignore a maioria delas e você tem, na melhor das hipóteses, uma demonstração interessante. Trabalhe nas sete, e você tem um sistema que efetivamente melhora a cada execução.
Fonte: Adaptado e resumido de: Harness Engineering: the skill that replaced prompt engineering in 2026 e publicado no LinkedIn
Indo mais a fundo: Agent Harness Engineering, by Addy Osman
As tais “Engenharias” do mundo de Agentes que se utilizam da IA Generativa
Engenharia de Prompt: mensagem/comando que informa o papel, o contexto, as instruções, alguns exemplos e o formato de saída.
Engenharia de Contexto: é a memória. Trata de como armazenar e recuperar informações relevantes ao Agente de IA.
Engenharia de Harness: É a máquina. Trata de tudo que envolve o cérebro do Agente (Modelo): Contexto, ferramentas, subagentes, RAG, integrações (via APIs ou MSPs), tratamento de erros, …
Engenharia de Loop: é a execução iterativa. Um mecanismo que decide se a máquina deve ser executada novamente. Para isso é necessário um objetivo definido no princípio, limites como um número máximo de iterações ou um orçamento de custo, e um critério automático que determine quando a tarefa realmente terminou. Vide Engenharia de Loop: Como Construir Agentes que Melhoram o Próprio Trabalho
Engenharia de Graph: é a coordenação. Quando vários loops têm que trabalhar juntos, é necessário definir o que se executa, quando se executa, o que pode ser feito em paralelo e quais componentes supervisionam os outros.
Em resumo: Prompt e Contexto estão na fase de coleta do harness; Harness executa um ciclo completo; Loop decide se o ciclo deve ser repetido; Graph decide quais loops executar e como eles se coordenam.
Veja também:
Blog do Nei 