Observabilidade É a Única Superfície de Controle de Agentes de Produto

TV
Thiago Victorino
6 min de leitura
Observabilidade É a Única Superfície de Controle de Agentes de Produto

A maior parte do que já escrevemos sobre observabilidade de agentes vive dentro do loop de engenharia. Um agente roda no CI, um humano acompanha a execução, um revisor lê o diff. O agente opera sob supervisão, e o trace é uma conveniência.

Existe um caso mais difícil. O agente de produto que roda milhares de vezes por dia, sem nenhum humano no loop, atendendo clientes enquanto você dorme. Para esse agente, o trace não é conveniência. É o único lugar onde você enxerga o que aconteceu, e o único lugar onde você muda o que vai acontecer em seguida.

IndyDevDan foi direto numa demonstração recente do seu agente de código Pi: “Se você não mede seus agentes, você não está fazendo engenharia. Você está apostando com tokens.” A frase mira quem constrói, mas pesa mais sobre quem opera. Um agente de produto em escala é uma frota de pequenos trabalhadores autônomos gastando seu dinheiro a cada requisição. Sem o trace, você não comanda essa frota. Você torce.

A sala de controle que você não vê

Uma API tradicional tem um contrato. Você envia uma requisição, recebe uma resposta, sabe mais ou menos quanto custou. Um agente de produto não tem esse contrato. Entre a requisição e a resposta há um número desconhecido de chamadas de ferramenta, uma contagem de tokens desconhecida, e um system prompt montado no boot a partir de um contexto que talvez você nunca tenha lido.

IndyDevDan mostra isso na prática. Ele manda a mesma instrução para duas versões do agente, uma alimentada com uma spec em markdown, outra com a mesma spec em HTML. Mesma tarefa, mesma intenção. Numa das execuções, o agente com markdown queimou mais tokens que o com HTML: cerca de 170 eventos contra 100. Mesmo prompt, formato de spec diferente, quase o dobro de trabalho. Nada na resposta diria isso a você. Só o trace mostra.

É aqui que quem opera tropeça. A saída parecia correta nos dois casos. O cliente recebeu uma resposta. A diferença morava inteira no caminho de execução, invisível para qualquer um que lesse o resultado. Multiplique uma duplicação silenciosa dessas por milhares de execuções diárias e você tem uma linha de custo que ninguém consegue explicar no fechamento do mês.

A conta escondida no contexto inicializado

O segundo achado é pior, porque se esconde dentro de algo que a maioria trata como gratuito. IndyDevDan observa que um simples “olá” pelo Claude Code custou a ele cerca de vinte centavos. Não vinte centavos por sessão. Vinte centavos para dizer olá, uma vez.

A razão é o contexto inicializado por completo. Quando o agente sobe, ele carrega instruções de sistema, definições de ferramentas, memória, arquivos do projeto e convenções antes de processar uma única palavra do usuário. Esse pacote é cobrado a cada turno. A mensagem mais barata possível ainda arrasta todo o peso do boot atrás de si. Os próprios logs da Tailscale, do gateway Aperture, corroboram o padrão de forma independente: o contexto de enquadramento, não as palavras do usuário, domina a conta.

Para um agente de produto, esse é o jogo inteiro. Você não está pagando pela resposta inteligente. Você está pagando, de novo e de novo, pelo contexto com que o inicializou. Se você não consegue ver esse contexto no trace, o system prompt completo, cada arquivo injetado, cada schema de ferramenta, você não consegue cortar a conta. Você só consegue assistir a ela crescer.

Por que isso vem antes da economia unitária

Há uma cadeia de valor por baixo de todo produto baseado em agente. Você gasta tokens, gera valor a partir desses tokens, captura receita a partir do valor. IndyDevDan descreve como subir a cadeia: usar tokens, criar valor, capturar o resultado. A maioria dos times empaca no primeiro passo. Gasta tokens e nunca descobre se algum valor saiu disso.

A observabilidade é o que move você para cima nessa cadeia. O trace conta o custo por resultado, não o custo no abstrato. Conta quais chamadas de ferramenta se pagaram e quais rodaram à toa. Conta que a spec em markdown custa 70% mais pelo mesmo resultado, então você troca o formato e embolsa a diferença em cada execução futura.

Sem isso, um agente de produto é centro de custo. Tokens entram, respostas saem, e a relação entre os dois é um mistério. Com isso, o mesmo agente vira algo que você consegue precificar, ajustar e defender. O trace é o instrumento que transforma gasto em economia.

Isso recoloca o comprador. Observabilidade de agente de engenharia é ferramenta de desenvolvedor: ajuda quem acompanha a execução. Observabilidade de agente de produto é controle de negócio: ajuda quem responde pela margem. Os dashboards podem parecer iguais. O que está em jogo não é. Um pega um diff ruim. O outro decide se o produto dá lucro em volume.

A armadilha da metodologia

Uma ressalva justa sobre a fonte. É um único criador, trabalhando a partir de demos, com opiniões fortes. O achado sobre formato de spec é um caso isolado de uma execução, não um benchmark. Markdown nem sempre vai custar 70% mais que HTML, e quem citar esse número como lei perdeu o ponto.

O ponto não é o número. O ponto é que o número existia e era invisível até o trace trazê-lo à tona. A lição vale mesmo quando o valor específico não vale. Seu agente de produto tem suas próprias duplicações silenciosas, seus próprios olás de vinte centavos, seu próprio peso de boot que ninguém leu. Você não vai achar isso na saída. Vai achar no trace, ou não vai achar em lugar nenhum.

Faça isto agora

Escolha o seu agente de produto de maior volume. Puxe um trace completo, do início ao fim: cada chamada de ferramenta, a contagem de tokens por turno, o custo, e o system prompt inicializado inteiro, exatamente como o modelo o recebeu. Leia o system prompt em voz alta. A maioria dos times nunca o viu por completo. Depois faça uma pergunta a cada linha: isto está se pagando em escala, ou é parte de um olá que custa vinte centavos?

Faça isso uma vez e você para de apostar. Você começa a operar.


Fontes

A Victorino ajuda equipes a instrumentar agentes de produto para manter custo e qualidade visíveis em escala: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa