A harness é o produto, não o modelo

Existe uma ideia muito popular de que construir um agente de IA é basicamente configurar um prompt e chamar uma API. Você escreve um system prompt caprichado, conecta ao modelo e o sistema está pronto. Não está.

O que eu vejo acontecer quando essa ideia é levada a sério em produção é sempre a mesma coisa: o sistema funciona no teste, quebra no pico de acesso, perde mensagens silenciosamente, acumula contexto que polui as respostas, vaza informação entre conversas. Nenhum desses problemas é do modelo. São problemas de arquitetura ao redor do modelo.

O que separa um agente de produção de um protótipo

Harness é o conjunto de responsabilidades que o modelo não tem como assumir por conta própria. O modelo recebe contexto e gera texto. Tudo que acontece antes e depois disso é problema de engenharia.

Numa solução de WhatsApp, isso se torna especialmente evidente porque o canal impõe restrições que a maioria dos frameworks de agente não considera. Não existe o botão "novo chat". Toda conversa fica numa thread vinculada ao número do usuário. Você não pode simplesmente deixar o contexto crescer indefinidamente porque o modelo começa a se confundir com informações antigas que não são mais relevantes. E se você comprimir mal o contexto, perde informação que importava.

As camadas que o modelo não gerencia

O primeiro problema de qualquer sistema de mensagem assíncrona é a ingestão: garantir que nenhuma mensagem se perde. O WhatsApp Business API espera uma confirmação rápida de recebimento. Se você não responder dentro do tempo esperado, a mensagem pode ser descartada. Isso significa que o processo que recebe a mensagem tem que ser separado do processo que pensa sobre ela.

Quando eu construí o pipeline de processamento do Nexus ZDT, que atende múltiplos clientes com automação de rotinas de RH no Protheus, um dos aprendizados que levei foi exatamente esse: a borda de recebimento tem que ser rápida e dura. Recebe, valida, enfileira, confirma. Nada de processamento pesado ali. O trabalho pesado acontece em outro lugar, de forma assíncrona, com controle de retentativas quando algo falha.

Para WhatsApp isso é ainda mais crítico porque o usuário pode mandar três mensagens em sequência em segundos. Se o sistema tentar processar cada uma imediatamente, o modelo vai receber a primeira sem ter visto a segunda e a terceira. O resultado é uma resposta que parece ignorar parte do que o usuário disse. Uma fila com debouncing, que aguarda um intervalo de silêncio antes de processar, resolve isso de forma elegante.

Contexto é o recurso mais crítico

Depois da ingestão, o próximo desafio é o gerenciamento de contexto. O histórico da conversa precisa ser passado para o modelo em cada mensagem, mas há um limite de quanto contexto o modelo processa bem antes de começar a perder atenção para os turnos mais antigos.

A solução é sumarização automática. Quando o histórico ultrapassa um threshold, um processo de compactação resume os turnos mais antigos em um bloco menor que preserva o essencial. Isso é exatamente o que o Claude Code faz com seus logs de sessão quando o contexto chega perto do limite.

Mas há um problema com sumarização: informação factual específica pode se perder no resumo. Se o usuário disse lá atrás que tem alergia a amendoim e isso não sobreviveu à compactação, o agente vai agir como se nunca soubesse.

A resposta para isso é uma camada separada de memória semântica. Fatos relevantes sobre o usuário são extraídos e armazenados de forma indexável, fora do histórico de conversa. Quando uma nova mensagem chega, o sistema busca os fatos relevantes e os injeta no contexto antes de chamar o modelo. Dessa forma o histórico pode ser compactado sem perder o que importa sobre aquela pessoa específica.

Observabilidade como prática de engenharia

O componente que mais diferencia um sistema amadurecido de um protótipo expandido é a observabilidade. Quando uma mensagem falha, você precisa saber exatamente onde falhou, com que erro, quantas vezes foi tentada e o que estava no contexto quando falhou.

Sem isso, você opera no escuro. O usuário reclama que o bot não respondeu e você não tem como saber se foi a ingestão, o processamento, a chamada ao modelo ou o envio da resposta que quebrou.

No GITFLOW, a plataforma que automatizou dezenas de processos de BPM na Guaraves, o painel de observabilidade foi o que permitiu que times diferentes conseguissem acompanhar o estado de cada processo sem precisar me consultar. Cada etapa tinha um log estruturado, cada falha tinha rastreabilidade. Isso não é luxo. É o que torna o sistema operável por quem não construiu ele.

O que muda quando você pensa em harness primeiro

Quando você começa pelo modelo, você tem um protótipo que funciona em condições ideais. Quando você começa pensando nas responsabilidades ao redor do modelo, você tem um sistema.

A harness define a confiabilidade. O modelo define a qualidade da resposta. Os dois importam, mas em produção, a confiabilidade que quebra primeiro.

O que você colocaria como primeira responsabilidade num agente de WhatsApp que vai atender 500 usuários simultâneos?