Quando penso em contratar alguém muito competente, não imagino que a contratação dispense uma definição de responsabilidades. A pessoa continuará precisando saber quais informações são confiáveis, que decisões pode tomar, quando deve consultar alguém e como demonstrará que concluiu o trabalho. Uma organização não entrega as chaves de toda a operação a um novo profissional simplesmente porque seu currículo impressiona. Curiosamente, essa cautela parece desaparecer em algumas conversas sobre inteligência artificial: esperamos que um modelo excepcional compense, por conta própria, tudo aquilo que a empresa ainda não conseguiu organizar.
É por isso que considero importante compreender a expressão “Harness AI”, que começa a circular nas discussões executivas. Antes de adotá-la como mais uma categoria de investimento, vale desfazer uma ambiguidade: “harnessing AI” pode significar simplesmente aproveitar o potencial da IA; um “AI harness” ou “agent harness”, no vocabulário técnico, designa a estrutura que sustenta a atuação de um agente. Não é o nome de um novo modelo nem uma metodologia universalmente padronizada. É uma maneira de nomear aquilo que permite ao modelo trabalhar com ferramentas, contexto, limites e continuidade.
Uma palavra antiga para um problema que ganhou outra escala
A palavra inglesa harness é muito anterior à computação. Sua trajetória passa pelo inglês medieval e pelo anglo-francês harneis, associado a equipamento e aparelhamento. Entre seus sentidos está o conjunto de arreios que conecta um animal de tração ao trabalho que ele realizará. Como verbo, também significa mobilizar uma força para determinado propósito. A metáfora é útil desde que não seja tomada como definição técnica: a existência de potência não dispensa uma estrutura que permita utilizá-la.
Na engenharia de software, o termo já aparece em test harness: o ambiente que prepara, executa e acompanha testes de um componente. A documentação da IBM, por exemplo, descreve estruturas que reúnem casos de teste, código sob avaliação e componentes auxiliares. O harness não é o sistema que está sendo testado; é a organização do ambiente que permite testá-lo. Essa anterioridade importa porque impede que uma palavra antiga seja apresentada como invenção recente de alguma empresa de IA.
Na evolução dos agentes, há marcos públicos que ajudam a reconstruir o uso contemporâneo. Em 26 de novembro de 2025, a Anthropic publicou um relato sobre harnesses para agentes de longa duração: sistemas que precisavam continuar o trabalho ao atravessar diferentes janelas de contexto, sem perder o progresso nem presumir que tudo já estava pronto. Em 5 de fevereiro de 2026, Mitchell Hashimoto descreveu sua prática de harness engineering, relacionando erros observados à criação de instruções e ferramentas que ajudassem o agente a evitá-los.
Seis dias depois, em 11 de fevereiro, Ryan Lopopolo publicou, na OpenAI, um relato de engenharia centrada em agentes. O texto descreve uma equipe cujo trabalho se deslocava da escrita manual de código para o desenho do ambiente, das restrições e dos mecanismos de feedback utilizados pelo Codex. Esses registros documentam a consolidação do vocabulário, mas não demonstram uma autoria única ou uma primeira ocorrência absoluta. Prefiro essa precisão a oferecer uma história de origem mais elegante do que as evidências permitem.
O modelo, o agente e as condições para trabalhar
Para explicar a diferença, separo capacidade de organização da capacidade. O modelo recebe entradas e produz saídas, inclusive propostas de uso de ferramentas. O agente é o sistema que utiliza essa capacidade para perseguir um objetivo ao longo de etapas. O harness organiza a execução: entrega contexto, disponibiliza ferramentas, preserva estado, trata respostas e estabelece controles. Não se trata necessariamente de um único produto; essas funções podem estar distribuídas por diferentes componentes.
Um prompt é uma instrução. A engenharia de contexto cuida do que o modelo precisa encontrar no momento adequado. A engenharia do harness trata de como esse sistema poderá agir, verificar resultados, continuar depois de uma interrupção e permanecer dentro de limites definidos. São disciplinas que se combinam, não modas que tornam as anteriores inúteis. Um prompt bem escrito continua importante; apenas não substitui uma autorização real, um registro de transação ou um teste de resultado.
Há uma diferença decisiva entre pedir ao modelo que respeite uma regra e construir um sistema que não permita a violação dessa regra. Na primeira situação, a política depende do comportamento do modelo. Na segunda, existem controles no caminho da execução. Minha leitura para as empresas é que nem toda obrigação deve ser negociada dentro de uma conversa com a IA; algumas precisam ser impostas pelo sistema que recebe e executa a ação.
A distância entre dizer “resolvido” e resolver
Imagine uma situação ilustrativa: um cliente solicita a devolução do valor de uma compra. Um assistente sem acesso à operação pode explicar a política e redigir uma resposta cordial. Um agente conectado pode tentar consultar o pedido e solicitar o reembolso. Um desenho empresarial responsável precisa especificar muito mais do que a frase que esse agente devolverá ao cliente.
Eu começaria pela identidade e pelo contexto: estamos falando com quem tem legitimidade para solicitar a devolução? Qual compra está em discussão? O produto foi devolvido? Existe um atendimento anterior? Qual versão da política se aplica àquela transação? Duas informações corretas, mas pertencentes a momentos diferentes, podem produzir uma decisão errada quando combinadas sem critério.
Depois vem a autoridade. No desenho que proponho para esse exemplo, a IA pode identificar a intenção, reunir evidências e formular o encaminhamento, enquanto regras verificáveis determinam se o caso está dentro da alçada automática. Uma exceção comercial não deveria surgir porque o cliente escreveu uma mensagem convincente. Se o caso exige julgamento humano, o sistema deve encaminhá-lo com o contexto necessário, em vez de esconder a dúvida atrás de uma resposta confiante.
A execução também precisa considerar o que acontece quando o mundo não coopera. O serviço de pagamento pode demorar a responder depois de receber a solicitação. Repetir a operação sem consultar seu estado pode gerar uma segunda devolução. Por isso, eu exigiria mecanismos que reconheçam uma mesma operação, permitam retomá-la com segurança e diferenciem “solicitação enviada” de “transação concluída”. São requisitos do processo, não talentos que se presume existir no modelo.
Por fim, a verificação deve olhar para o resultado registrado, e não apenas para o relato do agente. A Anthropic faz essa distinção em seu trabalho sobre avaliação de agentes: a trajetória da execução e o estado final precisam ser examinados. Uma conversa convincente não demonstra que o objetivo foi alcançado. Em uma empresa, essa diferença separa a qualidade de uma demonstração da confiabilidade de um serviço.
Perceba o deslocamento: a questão deixou de ser se a IA sabe explicar um reembolso e passou a ser se a organização sabe delegá-lo. O harness torna explícitas as condições dessa delegação. E, ao fazê-lo, revela problemas que podem ter ficado escondidos enquanto funcionários experientes resolviam as ambiguidades informalmente.
Meus cinco pilares deixam de ser conceitos e passam a ser requisitos
É nessa tradução para o trabalho empresarial que conecto o tema aos cinco pilares que utilizo: dados, contexto, interoperabilidade, orquestração e governança. Não os apresento como uma taxonomia oficial de harness engineering, mas como minha maneira de relacionar a arquitetura de IA às decisões que as lideranças precisam tomar.
Dados respondem quais fatos sustentam a ação. Contexto estabelece o significado desses fatos naquela situação, incluindo histórico, objetivos, restrições e validade temporal. Interoperabilidade permite consultar e acionar sistemas diferentes sem transferir permanentemente essa tarefa para uma pessoa. Orquestração define sequência, dependências, continuidade e tratamento de falhas. Governança estabelece quem responde, quais limites existem e que evidências devem permanecer disponíveis.
No exemplo do reembolso, isso significa saber de onde vem a informação do pedido, qual política se aplica, como conversar com o pagamento, o que fazer se uma etapa falhar e quem pode autorizar a exceção. Quando esses elementos não existem, a empresa acaba usando um profissional como componente invisível da arquitetura: é ele quem copia dados, identifica contradições, confere resultados e recompõe o processo. A automação parece funcionar porque alguém sustenta manualmente o que não foi projetado.
Essa é uma pergunta que eu levaria a qualquer reunião de aprovação de investimento: quanto da confiabilidade demonstrada pertence ao sistema e quanto depende da presença silenciosa de uma pessoa experiente? A resposta muda o custo, a capacidade de escala e a responsabilidade sobre o projeto.
Mais estrutura não significa mais burocracia
Seria um erro transformar harness engineering em justificativa para uma arquitetura excessiva. Já em dezembro de 2024, a Anthropic defendia padrões simples e combináveis para a construção de agentes e distinguia fluxos previamente definidos de sistemas nos quais o modelo decide dinamicamente o caminho. A lição continua útil: a autonomia deve responder a uma necessidade do problema, e não à ambição de parecer tecnologicamente avançado.
Uma classificação de mensagens, uma recomendação de conteúdo e uma alteração de pedido não precisam do mesmo grau de liberdade nem dos mesmos controles. Também não basta acumular documentos, ferramentas e instruções. No relato da OpenAI, concentrar orientações em um manual gigantesco dificultava o uso do contexto. A alternativa descrita foi estruturar o conhecimento de maneira navegável, com verificações e limites aplicáveis ao trabalho.
Minha preocupação é que uma organização desenhe um ambiente tão pesado que o custo de operá-lo supere o valor da tarefa. Por outro lado, simplificar não pode significar ignorar falhas. Eu esperaria de um projeto critérios claros de interrupção, testes com situações adversas, acompanhamento de custo e um caminho de recuperação. Nenhum desses elementos transforma um modelo probabilístico em infalível; eles tornam o comportamento observável e as consequências mais administráveis.
O que muda na conversa entre CEO, CFO e tecnologia
O indicador que me interessa não é apenas o custo de uma resposta. É o custo de um resultado correto e utilizável: processamento, integração, revisão, manutenção, retrabalho e tratamento das exceções que realmente ocorrerem. Reduzir o preço do modelo enquanto cresce a necessidade de conferência humana pode piorar a economia do processo. Da mesma forma, um sistema um pouco mais caro por execução pode ser melhor se produzir resultados verificáveis com menos intervenção.
Eu acompanharia, portanto, quantas tarefas terminam dentro das regras, quantas precisam ser refeitas, quais erros se repetem e quanto custa absorver uma mudança de política ou de modelo. Também perguntaria quanto tempo a empresa leva para perceber que um agente começou a se comportar de outra maneira. Avaliações deixam de ser uma cerimônia anterior ao lançamento e passam a fazer parte da manutenção do serviço.
Minha hipótese para os próximos anos é que parte importante da diferenciação empresarial estará nesse conhecimento operacional organizado: não apenas saber o que a empresa faz, mas conseguir expressar como faz, sob quais condições e com quais evidências. Componentes técnicos poderão se tornar mais acessíveis; o entendimento de uma exceção relevante, de uma responsabilidade e de uma decisão continuará exigindo trabalho da própria organização.
Isso também muda o papel das pessoas. Em vez de imaginar apenas quem terá tarefas automatizadas, eu perguntaria quem ajudará a transformar experiência em critérios, quem validará os resultados e quem terá autoridade para interromper uma automação. O profissional que conhece as contradições do processo pode ser mais importante para o sucesso do agente do que aquele que produz a demonstração mais impressionante.
Harness AI, compreendido dessa maneira, não é uma promessa de retirar os humanos da equação. É um convite a abandonar a ideia de que inteligência, sozinha, equivale a competência operacional. Antes de perguntar quanto podemos delegar a uma máquina, precisamos reconhecer quanto da nossa própria organização ainda depende de regras não ditas, acordos improvisados e pessoas que sabem resolver aquilo que nunca chegamos a definir.
