Aproveitando, Loop e Grafo: O Que Aprendi Construindo o Mesmo Agente de IA de Três Maneiras Diferentes

Quero começar com uma admissão. Seis semanas atrás, se você tivesse me perguntado para explicar a diferença entre "engenharia de harness de agente" e "engenharia de loop", eu teria te dado uma resposta confiante, mas ligeiramente errada. Eu tinha lido as frases suficientes vezes no Twitter e em posts do Medium para que elas parecessem familiares, e a familiaridade me enganou, fazendo-me pensar que as entendia. Eu não entendia.

O que quebrou a ilusão foi uma pequena e embaraçosa falha. Eu estava construindo um agente de pesquisa que puxava artigos do arXiv, os resumia e escrevia um digest semanal. Funcionou lindamente nas minhas três primeiras execuções de teste e então começou a alucinar resumos para artigos que nunca havia realmente aberto, porque uma chamada de API com limite de taxa falhou silenciosamente e nada no meu código percebeu. O modelo não era o problema. Meu prompt estava bom. A infraestrutura ao redor do modelo não tinha como distinguir "Eu li este artigo com sucesso" de "Eu inventei algo que soa como se eu tivesse lido este artigo." Essa lacuna, eu aprendi eventualmente, tem um nome, e não é um problema de prompting.

Então eu fiz o que costumo fazer quando me queimo: fui ler tudo que consegui encontrar, então reconstruí o mesmo agente três vezes, uma vez otimizando puramente para design de ambiente, uma vez para loops de feedback, e uma vez para controle de fluxo explícito. Este artigo é o que saiu desse processo. Ele é longo de propósito, porque o tópico merece mais do que uma lista, e porque eu continuei descobrindo que as explicações populares por aí (incluindo aquela que me enviou por esse caminho em primeiro lugar) descrevem a forma dessas três ideias sem nunca mostrar o que elas custam para construir ou onde elas quebram.

Não vou fingir que esses três termos são um vocabulário perfeitamente estabelecido. O campo tem talvez dezoito meses na sua forma atual e as pessoas ainda estão discutindo sobre nomes. Mas as distinções subjacentes são reais, elas se mapeiam para decisões de engenharia reais, e ao final deste texto você deve ser capaz de olhar para um agente quebrado e saber qual das três camadas consertar primeiro.

Por que o modelo nunca foi toda a história

Um modelo de linguagem, por si só, é uma função que transforma texto em texto. Ele não tem memória entre chamadas, a menos que você lhe dê uma. Ele não pode abrir um arquivo, executar um comando de shell, ou acessar uma API a menos que você construa a infraestrutura que permita isso. Ele não pode dizer se sua própria saída está correta a menos que algo fora do modelo verifique. Todos que estão construindo agentes em 2024 descobriram isso da maneira mais difícil, geralmente assistindo a uma demonstração funcionar perfeitamente e depois desmoronar no momento em que um usuário real fez algo inesperado.

A resposta da indústria tem sido parar de tratar "o agente" como um único artefato e começar a tratá-lo como três problemas de engenharia separáveis empilhados sobre o modelo:

LAYER QUESTION IT ANSWERS FAILS AS
----------------------------------------------------------------------
Harness O que o agente pode ver e tocar? Ferramentas faltando,
                   (ambiente, ferramentas, memória, estado perdido, permissões
                   estouradas, limites de execução) orçamentos, vazamentos
----------------------------------------------------------------------
Loop Como uma tentativa se torna uma resposta Confiante errada
                   correta? (tentar novamente, verificar, parar) respostas, girando
                                                                infinitamente, falha
                                                                silenciosa
----------------------------------------------------------------------
Graph Qual é a forma real do trabalho? Ordem de passo errada,
                   (sequência, ramificações, caminhos paralelos, nenhum caminho de recuperação,
                   pontos de verificação humanos) sem visibilidade
----------------------------------------------------------------------

Vou passar por cada um da maneira como realmente aprendi: construindo a menor versão possível, quebrando-a, e então lendo a pesquisa e a documentação do framework para entender por que quebrou.

Camada 1: o harness, ou "o que o agente realmente pode fazer"

A definição clara em uma linha que encontrei, e agora acho que é a correta, vem de uma nota de engenharia do LangChain que reduz toda a ideia a uma equação: agente = modelo + harness. O modelo fornece raciocínio. O harness fornece tudo o que o raciocínio precisa para tocar o mundo real: ferramentas, memória, contexto, permissões e as barreiras que o impedem de fazer algo caro ou perigoso.

Antes de entender isso, meu modelo mental de "dar ferramentas a um agente" era basicamente "escrever algumas funções em Python e descrevê-las no prompt do sistema." Isso funciona para uma demonstração. Não sobrevive ao contato com uma tarefa que leva mais do que uma janela de contexto, ou uma chamada de ferramenta que falha às 2 da manhã com ninguém assistindo.

O que um harness realmente precisa gerenciar

Através de tentativa e erro (principalmente erro), descobri que o harness é responsável por seis coisas:

Injeção de contexto. Decidir o que o modelo vê antes de cada passo de raciocínio. Não apenas a mensagem do usuário, mas documentos recuperados, conversa anterior, estado do projeto e política organizacional. Eu corrigi isso em excesso no início, despejando toda a minha árvore de arquivos e log do git em cada chamada, e assisti a precisão do modelo degradar porque ele estava se afogando em tokens irrelevantes. Menos contexto, curado, consistentemente superou mais contexto, bruto.

Superfícies de ação. O mecanismo real pelo qual a decisão do modelo se torna um efeito no mundo real: uma chamada de API, um comando de shell, uma gravação em banco de dados, um clique no navegador. É aqui que vive o Protocolo de Contexto do Modelo (MCP), e vale a pena pausar nisso porque mudou significativamente este ano. O MCP começou no final de 2024 como uma forma de padronizar como um agente descobre e chama ferramentas, para que você não precisasse escrever uma integração sob medida para cada API. A partir da especificação de julho de 2026, o MCP mudou para um núcleo sem estado que roda atrás de balanceadores de carga comuns em vez de exigir sessões fixas, adicionou uma extensão de Tarefas (contribuída pela AWS) para trabalhos de longa duração que sobrevivem a uma única solicitação, e apertou seu modelo de autorização em torno de fluxos padrão de OAuth e OpenID Connect. Agora existem mais de dez mil servidores MCP públicos rodando em produção, e os downloads mensais de SDK ultrapassam 97 milhões. Se você está projetando um harness hoje e não está construindo sua camada de ferramentas em cima do MCP ou algo com garantias equivalentes, você provavelmente está reinventando uma versão pior disso.

Persistência. Qualquer coisa que o agente precise para sobreviver a uma reinicialização, uma falha ou simplesmente o fim de uma janela de contexto: pontos de verificação, estado de sessão, memória vetorial, histórico do git. Meu agente de pesquisa não tinha nada disso em sua primeira versão, o que significava que uma conexão perdida no meio da execução silenciosamente jogava fora quarenta minutos de trabalho. Adicionar um simples ponto de verificação JSON após cada subtarefa concluída resolveu mais problemas de confiabilidade do que qualquer mudança de prompt que tentei.

Controle de execução. Política de repetição, timeouts, orçamentos de tokens e custos, roteamento de modelos, quantos sub-agentes podem surgir, e onde um humano precisa aprovar antes que o agente prossiga. Esta é a camada que impede que um agente transforme uma tarefa de $2 em uma de $200 porque ficou preso em um ciclo de chamada e falha durante a noite.

Segurança e governança. Acesso a ferramentas de menor privilégio, manuseio de segredos, sandboxing, logs de auditoria, listas de permissão. Eu coloco em sandbox qualquer coisa que execute código que o modelo escreveu, sem exceções, porque pessoalmente assisti a um agente de codificação tentar rm -rf um diretório que identificou erroneamente como um artefato de construção. Não era malicioso. Era apenas errado, e tinha permissão para estar errado de forma destrutiva.

Observabilidade. Rastros, logs de chamadas de ferramentas, uso de tokens, latência e resultados de avaliação. Este parece chato até o dia em que seu a