Agentes de IA falham em silêncio: por que o dashboard verde engana

O painel está verde, mas o agente está falhando

Imagine o cenário: uma revisão de segurança aperta as permissões de uma função de execução numa terça-feira. Nada dispara alerta. Cada chamada de ferramenta continua retornando HTTP 200, mas os payloads chegam vazios. O agente, então, responde — com educação e fluência — que não encontrou nada para fazer.

Taxa de erro: estável. Latência: inalterada. Gasto de tokens: normal. A qualidade das resoluções, porém, degrada em silêncio até que um cliente perceba, dias depois. Os seus dashboards não viram nada disso, porque a maioria das ferramentas de monitoramento de agentes de IA observa a unidade errada.

O cenário acima é composto, mas apenas por pouco. Engenheiros da AWS documentaram um incidente quase idêntico em um agente de reservas aéreas em produção: uma permissão de invocação de modelo ausente produzia saídas em branco enquanto todas as métricas de infraestrutura permaneciam verdes. Descobrir a causa raiz exigiu uma correlação manual entre políticas IAM, logs de invocação e rastros de orquestração — algo que a equipe estimou em 30 a 60 minutos, mesmo com conhecimento profundo da arquitetura.

A unidade de saúde é a resolução, não a requisição

Uma resolução é uma meta entrando no loop do agente e um resultado verificado saindo dele. “Reserve a viagem com múltiplas escalas e aplique o certificado de acompanhante” é uma única resolução — que atravessa dezenas de requisições: chamadas de modelo, invocações de ferramentas, retries, transferências entre especialistas e estado persistente que muda a cada passo.

O problema é que os “sinais de ouro” da observabilidade clássica — taxa, erros, duração e saturação — foram escritos para serviços orientados a requisição. Nenhuma requisição individual sabe que uma meta existe. Por isso, a taxa de erro, a latência e o volume de tokens podem permanecer dentro da normalidade enquanto as resoluções falham: eles medem a mecânica do loop, não a qualidade do resultado.

Duas consequências seguem disso. Primeiro, observar um agente rodando e saber que ele resolveu corretamente são problemas de engenharia diferentes, com sinais diferentes. Segundo, sistemas multiagente ampliam a distância, porque não existe um grafo de chamadas fixo para servir de linha de base — o trabalho é roteado dinamicamente entre especialistas.

As cinco falhas que os dashboards não enxergam

Três mecanismos merecem atenção. A deriva de permissão falha educadamente: a ferramenta não passa a devolver 403, continua respondendo 200 com nada útil dentro — o sintoma e a causa vivem em sistemas diferentes, a dias de distância. As regressões de contrato perdem dados sem quebrar nada: um campo renomeado flui como se tudo estivesse bem, e o modelo raciocina sobre um buraco. E os loops de retry são feitos de requisições saudáveis: o backoff exponencial é a postura correta, mas não elimina travamentos — apenas os espaça.

O que instrumentar em cada etapa do ciclo de vida

Nada disso exige adotar um novo fornecedor de monitoramento. As convenções semânticas OpenTelemetry GenAI — incluindo as definições de spans de agentes — estão em desenvolvimento ativo em status de incubação, o que significa que o tracing de agentes pode estender o coletor e o backend que você já usa. A decisão arquitetural que importa vem antes de qualquer nome de atributo: ancore o contexto de trace na resolução, não na requisição individual.

• Dispatch: crie um ID de resolução e a raiz do trace no instante em que a meta entra no loop, registrando a meta estruturada, a identidade do chamador, o tipo de tarefa e os orçamentos (passos, tempo, custo).
• Chamadas de ferramenta: registre a versão do schema do contrato, se a resposta validou contra ele e se o payload estava materialmente vazio. O vazio precisa ser campo de primeira classe, porque é ali que a deriva de permissão se anuncia.
• Verificação: toda resolução deve terminar com um evento de verificação registrado — qual verificador rodou (checagem determinística, regra, humano ou juiz baseado em modelo) e o que concluiu.
• Handoff: em cada fronteira entre agentes, emita um snapshot de estado e compare com o que o sistema realmente reporta, registrando a divergência.

Métricas de resolução e SLOs de resultado

As métricas de resolução respondem a uma pergunta diferente das métricas de requisição. Defina um conjunto pequeno e pendure os SLOs nele: resoluções verificadas por meta, taxa de aprovação de verificação, custo por resolução (somando todos os retries), taxa de escalonamento (quantas vezes o loop desistiu e roteou para um humano) e tentativas e passos por resolução como distribuição. Um SLO de resultado amarra um resultado verificado a um orçamento: “95% das metas de reserva alcançam resolução verificada em 15 minutos e 30 passos”.

Um rollout de cinco sinais, na pilha que você já tem

1. Reancore o tracing na resolução — plumbing puro, sem fornecedor novo.
2. Taxas de validade e vazio de payload por ferramenta — captura deriva de permissão em menos de uma hora.
3. Contadores e orçamentos de tentativas por resolução — torna loops travados “pagáveis” em vez de apenas lentos.
4. Resultados de verificação, amostrados primeiro.
5. Snapshots de handoff, para sistemas multiagente.

Três armadilhas conhecidas: cardinalidade de métricas (rotule por ferramenta e resultado, nunca por ID de resolução), amostragem de trace (amostre por resultado de resolução, mantendo toda resolução falha em fidelidade total) e fadiga de alerta por vazio (uma busca que não encontra nada é comportamento correto — alerte sobre desvio da linha de base, não sobre um limiar absoluto).

Por que isso importa agora

À medida que agentes deixam de ser demos e viram funções de produção — atendimento, reservas, suporte técnico — a diferença entre “o loop rodou” e “a meta foi atingida” vira a diferença entre confiança e prejuízo silencioso. Para times brasileiros que estão colocando agentes em produção, a lição prática é direta: sinais de processo provam que o loop está vivo; sinais de resultado provam que a meta foi cumprida. E o SLO pertence ao segundo tipo.