A conta de US$ 47.000 de um fim de semana virou a definição de 'Agent = Model + Harness'. Um componente por vez.

Em fevereiro de 2026, um time de dados subiu um agente de enriquecimento numa sexta à noite. Fechou o laptop. Foi tomar cerveja. Segunda de manhã, o painel de billing marcava US$ 47.000. Na cotação PTAX do BCB da época, isso passa dos R$ 240 mil. Um Onix zero, pagando por um fim de semana em que ninguém trabalhou.

Esse caso já rodou por todo lado, e eu mesmo já escrevi sobre ele no ângulo “quais 4 linhas de YAML teriam parado a hemorragia”. Esse artigo é outro. Aqui eu quero fazer uma coisa que não vi ninguém fazer direito em português: usar o incidente como a autópsia que deu forma à fórmula que a LangChain publicou em março do mesmo ano: Agent = Model + Harness. E fazer essa autópsia componente por componente.

O que interessa aqui é o mapa por trás do patch.

A fórmula que a comunidade demorou 2 meses pra escrever

Em 21 de março de 2026, a LangChain publicou “The Anatomy of an Agent Harness” (blog.langchain.com). O Harrison Chase, CEO da LangChain, condensou nesse post uma frase que virou o shibboleth de quem trabalha com agente hoje:

Agent = Model + Harness.

O modelo é o LLM: tokens entram, tokens saem. O harness é tudo o resto: planejamento, memória, execução de tools, feedback loops, restrições. Um modelo cru não vira agente sozinho: precisa que o harness forneça estado, execução, feedback e limites.

O post do Chase se apresenta como definição pura. Não precisa convencer ninguém. E o motivo é que os dois meses anteriores tinham produzido histórias que faziam o trabalho de convencimento sozinhas. O caso dos US$ 47.000 é a mais barulhenta.

Por que esse incidente virou a evidência definitiva

Antes desse fim de semana, “harness” era jargão de blog de framework. Depois desse fim de semana, virou linha de auditoria em reunião de arquitetura. O que mudou foi a possibilidade de responder à pergunta: “O modelo estava errado?” Todo mundo que olhou o post-mortem chegou na mesma resposta.

Não. O modelo Anthropic escolheu retry porque o system prompt dizia “garanta que o usuário receba a resposta.” A API externa devolvia 429 (rate limit). O modelo interpretou “tenta com parâmetros diferentes” e tentou. E tentou. E tentou 2,3 milhões de vezes em 52 horas.

Se o modelo não estava errado, e a instrução não estava errada, o bug morava em algum outro lugar. O incidente definiu esse “outro lugar” como o harness. E deu à LangChain, dois meses depois, o direito editorial de dizer “agora vamos formalizar” sem parecer pretensioso.

Vou seguir o mapa dos 6 componentes que a documentação da Anthropic sobre design de agentes e o post da LangChain convergem em usar, e mostrar onde cada componente falhou no incidente.

Componente 1: Contexto — o system prompt dizia “garanta”

Todo harness começa com o contexto: o system prompt, o esquema de saída, os exemplos, as regras invisíveis que o modelo lê antes de qualquer chamada.

O system prompt do agente do incidente incluía a frase “garanta que o usuário receba a resposta.” Sozinha, essa frase é razoável. Combinada com um modelo bom em raciocínio persistente, ela vira um comando implícito: desista quando?

Não havia essa cláusula. O contexto instruía “não desista”, mas não instruía “desista após N tentativas com o mesmo código de erro.” O modelo cumpriu o que leu.

Lição do componente: um contexto que fala em “garantia” sem falar em “condição de parada” é um contrato assimétrico. Todo prompt de agente hoje que use verbos absolutos (“garanta”, “sempre”, “nunca”) merece um par: até quando, até quanto, até qual limite.

Componente 2: Tools — a chamada externa não tinha rate limit interno

O agente tinha uma tool única: chamar a API externa. Simples. E foi exatamente essa simplicidade que virou arma.

A tool não implementava:

• backoff exponencial após 429
• circuit breaker por código HTTP repetido
• limite de chamadas por hora
• classificação de erros retriáveis versus não retriáveis

Todas essas coisas existiam no SDK do provedor, disponíveis em uma flag ou construtor. Ninguém tinha ligado. A tool foi desenhada como “chame o endpoint e devolva a resposta.” O modelo fez isso. 2,3 milhões de vezes.

Lição do componente: tool design é sobre o que a função se recusa a fazer, muito mais do que sobre a assinatura dela. Um circuit breaker num wrapper de tool custa 8 linhas. Um post-mortem de US$ 47.000 custa 8 linhas e um fim de semana.

Componente 3: Memória — o agente esqueceu que já tinha tentado

O modelo não é um humano que lembra “puxa, tentei isso agora há pouco e deu errado, deixa pra lá.” Cada iteração do loop começou com um contexto novo, sem histórico persistente sobre o que já tinha falhado.

O harness poderia ter oferecido essa memória. Um dicionário simples de (endpoint, código_de_erro) -> contagem_de_tentativas alimentado no contexto de cada iteração teria mostrado ao modelo, no primeiro milhão, que estava insistindo. Não estava.

Lição do componente: memória de operações do próprio agente entra na lista de componentes obrigatórios do harness. Sem ela, o agente vira Sísifo. E cada tentativa custa dinheiro real na sua conta.

Componente 4: Ciclo de vida — não havia parada programada

Todo agente de longa duração precisa de três coisas do ciclo de vida:

• um começo explícito
• um fim programado (por budget, por tempo, ou por objetivo alcançado)
• um watchdog externo que consegue matar o processo

O agente do incidente tinha o começo. Não tinha o fim. Não tinha o watchdog. Rodou por 52 horas porque ninguém definiu depois de quanto tempo ele deveria parar, e ninguém colocou um segundo processo capaz de olhar de fora e concluir “isso não está andando, encerra.”

Lição do componente: o ciclo de vida de um agente vai muito além do while True. Fica assim: “esse agente termina quando X ou quando Y ou quando Z, e um observador independente pode terminá-lo mesmo se ele achar que está indo bem.”

Componente 5: Feedback — as métricas chegavam com atraso

O time descobriu o incidente na segunda de manhã porque o painel de billing atualiza em batch. A conta acumulou o fim de semana inteiro sem ninguém ver.

Feedback aqui não é “log estruturado” (isso é observabilidade, componente 6). Feedback é: o próprio agente sabe, em tempo real, que está queimando dinheiro? O harness pode oferecer ao modelo, a cada iteração, uma linha do tipo “gastou US$ 320 na última hora, orçamento diário é US$ 50” e deixar o modelo decidir se continua. Não estava lá.

Lição do componente: um agente que não recebe o custo do próprio comportamento como parte do contexto não tem como se auto-regular. Isso é questão de desenho de sistema antes de ser tópico de “IA ética”.

Componente 6: Monitoramento — alertas eram para SREs, não para agentes

Havia observabilidade. Havia logs. Havia até um dashboard no Datadog. Só que os alertas eram configurados para “erro do servidor de aplicação”, não para “custo por hora acima do esperado.”

Um alerta de “gasto > US$ 100/hora” configurado no CloudWatch teria disparado às 21h de sexta. Um oncall às 22h de sexta é chato, mas custa muito menos que US$ 47.000.

Lição do componente: o monitoramento de agentes é diferente do monitoramento de servidor. Servidor você olha CPU, memória, latência. Agente você olha gasto por hora, taxa de retry, similaridade de tool calls consecutivas. Se você aplica o dashboard do time de backend no seu agente, você vai descobrir que ele estava saudável enquanto queimava seu orçamento anual.

O que a fórmula do Chase resolve, e o que ainda não

A fórmula “Agent = Model + Harness” resolve um problema editorial que a comunidade tinha desde 2024: como falar de agente sem colapsar tudo em “escolha um LLM bom.” Ela diz, com autoridade, que 6 componentes distintos existem, que cada um pode falhar sozinho, e que trocar o modelo nunca vai consertar um bug que mora no harness.

O que ela ainda não resolve é a pergunta que fica depois: quem é responsável por cada componente na sua empresa? No incidente de fevereiro:

• Contexto: escrito pelo engenheiro do agente, revisado por ninguém.
• Tools: reutilizadas do SDK, sem wrapper defensivo.
• Memória: não implementada.
• Ciclo de vida: definido implicitamente pelo while do loop.
• Feedback: nenhum.
• Monitoramento: reutilizado do stack de backend.

Cada uma dessas seis linhas tinha um dono possível diferente, e nenhuma delas foi tratada como “o dono precisa fazer isso antes do deploy.” Essa é a parte que a fórmula do Chase deixa aberta pra você resolver na sua empresa.

O que muda no seu próximo agente

Se você está montando um agente para produção nas próximas semanas, o exercício útil não é decorar a fórmula. É rodar o incidente dos US$ 47.000 nos 6 componentes do seu design. Uma checklist honesta:

1. Seu system prompt tem verbo absoluto (“garanta”, “sempre”, “nunca”) sem uma condição de parada explícita?
2. Cada tool tem um wrapper defensivo com circuit breaker e classificação de erro?
3. O agente vê o histórico das próprias últimas N ações no contexto?
4. Existe um watchdog externo capaz de matar o processo mesmo se o agente achar que está indo bem?
5. O contexto de cada iteração inclui uma linha do custo real acumulado?
6. Existe um alerta de “gasto por hora” separado dos alertas de infraestrutura?

Se três dessas respostas forem “não”, você está a um fim de semana de virar o próximo post-mortem.

Você não precisa acreditar em mim. Basta acreditar no boleto de fevereiro.

Referências

• LangChain, “The Anatomy of an Agent Harness” — blog.langchain.com
• LangChain, “Agent Frameworks, Runtimes, and Harnesses — oh my!” — langchain.com/blog
• Anthropic Engineering, “How we built our multi-agent research system” — anthropic.com/engineering
• LLMO Framework, uma leitura complementar sobre como esses 6 componentes conversam com o resto da stack de produção — llmoframework.com

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews