AI Agent Observability: como descobrir por que seu agente falhou em produção

A pergunta que o CTO faz depois do incidente nunca é “qual foi o BLEU score”. É: por que o agente chamou aquela tool, com aqueles argumentos, naquele tenant, àquela hora — e por que ninguém viu antes. AI Agent Observability existe para responder isso em minutos, não em war room de três dias.

O survey State of Agent Engineering da LangChain (cerca de 1.340 times) deixou o deslocamento numérico: 89% já instrumentaram alguma observabilidade; 62% têm tracing de steps e tool calls; entre quem já está em produção, 94% observam. Evals offline ficam em 52,4%; online, 37,3%. Qualidade é a barreira nº 1 para produção (32%). Tradução: o mercado aprendeu a filmar o agente. Ainda não aprendeu a julgar o filme.

O que mudou: de log de LLM para telemetria de trajetória

Logar prompt e completion era suficiente para um chatbot. Um agente é um workflow distribuído probabilístico: modelo, tools, filas, humanos, outros agentes (A2A), UI (AG-UI). A unidade não é a mensagem. É a trajetória.

Trajectory tracing

Cada run gera um trace. Cada step (planejar, chamar modelo, validar schema, policy decision, tool, espera humana, retry) é span. OpenTelemetry é a base; atributos de agente entram como dimensions: prompt_version, model, tool_name, publisher_hash, policy_decision, autonomy_level, tenant, agent_id. Você precisa reconstruir o caminho — inclusive o que foi recusado. Denies são ouro: mostram o harness funcionando ou a policy cega.

Tool-call analysis

• Taxa de tools alucinadas (nome que não existe no registry).
• Args inválidos vs schema (o modelo “quase” acertou).
• Sequências anômalas (read_all_invoices → external_webhook).
• Retries técnicos vs re-decisões semânticas (o harness deveria esconder o retry do modelo).
• Publisher e description hash vigentes no momento da call — forense de tool poisoning.

Cost attribution e budgets

Custo por tarefa, por tenant, por agente, por modelo, por tool. p50/p95/p99 de latência. Tokens. O harness do artigo-pilar já lista cost per task e budgets de steps/tokens/tempo. Observability é o que torna o budget real: quando estoura, o span marca budget_exceeded e o produto decide fallback — não “pensa mais um pouco”.

Failure clustering

Um milhão de traces não se leem. Agrupe: schema_error, policy_deny, timeout, human_timeout, wrong_tool, stale_context, injection_suspect. Clusters alimentam o backlog de engenharia. Sem clustering, o time discute casos anedóticos no Slack e chama isso de QA.

Policy violations como sinal de produto

Toda vez que o modelo tenta uma ação fora do perímetro, você tem um dado: o contexto está mal montado, a tool description está agressiva, ou um ataque está em curso. Rate de policy violations por versão de prompt/tool é regression test contínuo. No EmerAgents isso é first-class, não afterthought de SIEM.

Métricas que o harness já nomeou — e que o board entende

• Task success rate — desfecho de negócio, não “o modelo respondeu”.
• Tool success rate — execução vs erro permanente.
• Retry rate — saúde de dependências.
• Human intervention rate — autonomia real vs slide.
• Latency p95/p99 — SLO do processo, não do token.
• Cost per task — unidade que o CFO aceita.
• Policy violations — perímetro.
• Hallucinated tool calls — qualidade do registry + do pacote de contexto.
• Recovery rate — long-running: quantos runs retomam após crash.

O loop: trace → eval → fix → release

1. Produção grava trajetórias (com redaction de PII).
2. Falhas viram casos de golden set (offline eval).
3. Online eval amostra runs e pontua trajetória (não só a resposta).
4. Regressão bloqueia release de prompt, tool ou política.
5. O mesmo pipeline serve ao red team de MCP Security.

É por isso que observabilidade e evals merecem artigos irmãos neste cluster. Juntos, eles são a diferença entre “temos LangSmith/Datadog” e “temos um sistema que aprende com o próprio fracasso”.

span.setAttributes({
  "agent.id": ctx.agentId,
  "agent.trace_id": ctx.traceId,
  "tool.name": call.name,
  "tool.publisher": call.publisher,
  "tool.description_hash": call.descriptionHash,
  "policy.decision": decision, // allow | deny | require_approval
  "llm.model": ctx.model,
  "llm.prompt_version": ctx.promptVersion,
  "cost.tokens": usage.total,
});

Anti-padrões

• Só logar o texto final no app insights.
• Trace sem identity (não dá para responder “quem”).
• Amostrar 0,1% e achar que viu o incidente de exfiltração.
• Dashboard de tokens para o CFO e zero tool-call analysis para o engenheiro.
• Observar e não avaliar — a estatística de 89 vs 52.

Conclusão

Em 2026 observability de AI Agents virou infraestrutura básica pelo mesmo motivo que tracing virou básico em microserviços: o sistema é grande demais para depurar com print. A EmerSoftware trata isso como parte do Agent Harness / EmerAgents, não como um “projeto de Datadog depois do go-live”. O próximo clique, se você já filma a trajetória, é aprender a testá-la — o artigo de Evals.