O modelo não é o agente: o verdadeiro salto está no AI Harness.

Muitas vezes vejo uma certa confusão sobre o que é AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → Harness, e creio que talvez possa colaborar com este artigo trazendo uma perspectiva um pouco mais técnica.

Quando comparamos dois produtos de IA que utilizam modelos semelhantes, é perfeitamente possível que um se comporte como um chatbot sofisticado enquanto outro consiga executar tarefas complexas durante longos períodos. A diferença nem sempre está no modelo. Ela pode estar na arquitetura construída ao seu redor.

Gosto de pensar, de forma simplificada, em três camadas: modelo, harness e ambiente de execução. Não como uma taxonomia universal, pois os limites entre harness, runtime, framework e camada de aplicação variam conforme a arquitetura, mas como uma maneira útil de raciocinar sobre sistemas agênticos.

O modelo processa o contexto recebido e produz respostas, planos ou solicitações de ações. Pode apresentar capacidades impressionantes de linguagem, raciocínio e geração de código. Mas, isoladamente, não executa operações em sistemas externos.

É aí que entra o harness. O termo ainda não possui uma definição única e padronizada. Em geral, é usado para descrever a camada de software que organiza a operação do modelo dentro de um sistema agêntico, como contexto, ferramentas, memória, estado, orquestração, execução, políticas, recuperação de falhas e avaliação. A própria literatura e documentação recente usam o termo com diferentes graus de abrangência.

Essa distinção é importante. O modelo pode produzir uma solicitação para consultar um banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →. Isso não significa que a consulta será executada pelo próprio modelo. Uma camada de execução precisa interpretar a solicitação, aplicar políticas e permissões e, se autorizada, executar a ferramenta e devolver o resultado. O modelo propõe; a infraestrutura decide, executa e controla.

As ferramentas podem incluir APIs, sistemas de arquivos, bancos de dados, navegadores, terminais, repositórios de código e outros serviços.

Depois vem uma camada que considero particularmente importante que é contexto, memória e estado. São conceitos relacionados, mas não idênticos. Contexto é aquilo que o modelo recebe para uma determinada decisão. Memória permite preservar ou recuperar informações ao longo do tempo. Estado representa a situação operacional da tarefa,  o que já foi feito, o que falta fazer, quais decisões foram tomadas e quais resultados foram obtidos.

Um agente executando uma tarefa durante muito tempo não pode depender apenas da janela de contexto do modelo. O sistema precisa recuperar informações relevantes, resumir históricos, preservar estado, criar checkpoints e eventualmente recuperar-se de falhas.

Por isso, vejo context engineering como algo muito mais amplo do que simplesmente melhorar prompts. Trata-se de projetar quais informações o sistema recebe, quando recebe, de onde vêm, como são priorizadas e como são atualizadas durante a execução.

O terceiro elemento é o loop agêntico. Em vez de pergunta → resposta, temos algo mais próximo de: objetivo → planejamento → ação → observação → avaliação → nova ação → verificação → conclusão.

É esse ciclo que permite executar sequências de ações. Mas um bom loop também precisa saber quando parar, quando tentar novamente, quando pedir intervenção humana e como recuperar-se de uma falha.

E aqui está um ponto fundamental: autonomia não é simplesmente uma propriedade do modelo. Ela depende da combinação entre modelo, ferramentas, contexto, estado, ambiente, políticas e grau de autoridade concedido ao sistema.

Por isso, o mesmo modelo pode apresentar comportamentos muito diferentes quando colocado em harnesses diferentes.

Mas existe outro lado: o harness também se transforma em uma superfície de risco. Quanto maior a capacidade de ação concedida ao agente, maior a consequência potencial de uma falha, de uma interpretação incorreta ou de um ataque.

Se o sistema apenas responde perguntas, um erro pode produzir uma informação incorreta. Se ele pode modificar arquivos, executar comandos, alterar registros ou chamar APIs de produção, o erro pode produzir uma consequência operacional real.

Por isso, o harness precisa fazer mais do que ampliar capacidades. Precisa também restringi-las. Identidade, autenticação, autorização, menor privilégio, isolamento, validação de ferramentas, limites de execução, logs, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps →, proteção contra prompt injection, aprovação humana para ações de maior risco e mecanismos de interrupção e reversão passam a fazer parte da arquitetura.

E existe uma camada frequentemente subestimada: avaliação. Não basta saber se o agente chegou ao resultado final. Precisamos avaliar também sua trajetória: quais ferramentas utilizou, quantas etapas executou, quanto custou, onde errou, se violou políticas, quantas vezes precisou de intervenção e se o resultado continua correto em situações diferentes.

Essa mudança também altera a forma como deveríamos comparar sistemas de IA.

Não é suficiente perguntar qual é o melhor modelo? Em aplicações agênticas, o mais importante é saber qual modelo, operando com qual contexto, quais ferramentas, qual memória, qual estado, qual ambiente, quais políticas e quais mecanismos de avaliação?

Não significa que o harness seja sempre mais importante que o modelo. Em determinadas aplicações, a capacidade do modelo continuará sendo o principal fator limitante. Mas, em sistemas agênticos complexos, o desempenho passa a emergir da interação entre modelo e arquitetura de execução. Já existem trabalhos propondo justamente avaliar essa combinação, em vez de atribuir todo o desempenho ao modelo.

Estamos deixando de construir apenas aplicações que usam modelos de IA e começando a construir sistemas de software nos quais o modelo é um componente dentro de uma máquina de execução muito maior.

O modelo fornece capacidade. O harness transforma essa capacidade em comportamento. O runtime dá persistência e operação. E a engenharia determina se tudo isso produzirá um sistema realmente útil, observável, econômico, confiável e seguro.