Agentes de IA em produção: lições de quem já quebrou a cara

Se você acompanhou o hype de agentes de IA no último ano, deve ter visto demos incríveis: um agente que consulta APIs, faz processamento paralelo, recupera informações de uma base de dados vetorial e entrega uma resposta em tempo real. Lindíssimo.

Agora tira os agentes do Jupyter e coloca em produção servindo milhares de requests por hora. É aqui que a diversão começa.

A gente já viu (e passou por) praticamente tudo que pode dar errado com agentes em produção. Este post é um debriefing honesto sobre o que realmente importa.

O abismo entre demo e produção

Demos funcionam porque operam em condições controladas. Input perfeito, latência não importa, falhas são features para aprender. Produção não é assim.

Num agente em produção, a gente está lidando com:

• Requisições com dados malformados ou inesperados
• Chamadas a APIs externas que podem estar lentas, com rate limits ou indisponíveis
• LLM calls que geram outputs inúteis ou tóxicos em 3% dos casos (e esse 3% de 10 mil é 300 problemas)
• Latência importa demais — uma decision loop de 5 segundos multiplica rápido
• Custo explodindo porque ninguém olhou pro token budget

A diferença é brutal. A primeira coisa que a gente faz é parar de pensar em "perfeição" e começar a pensar em "degradação elegante".

Idempotência, retries e circuit breakers

Quando um agente chama uma ação (paga uma conta, cria um registro, envia um email), precisa garantir que falhas de rede não causem duplicação.

Um agente que tenta recarregar um saldo de conta 3 vezes por causa de timeout gera 3 transações. Agora a gente tem um problema de observabilidade que ninguém vai descobrir até o cliente ligar furioso.

A solução é idempotência: toda ação precisa ter uma chave única, um request ID. Se o agente tenta pagar novamente, o sistema recogniza que é a mesma transação.

Retries precisam de jitter e backoff exponencial. Ficar tentando 100 vezes em 1 segundo é fútil. A gente usa algo como:

tentativa 1: sem espera
tentativa 2: espera 100ms + random(0-50ms)
tentativa 3: espera 200ms + random(0-100ms)
tentativa 4: espera 400ms + random(0-200ms)
...
máximo de tentativas: 5

Circuit breakers impedem que um agente fique martelando um serviço que está offline. Se uma API retorna erro em 50% das últimas 10 requisições, o circuito "abre" — o agente para de tentar por X segundos. Volta a tentar depois, devagar.

Observabilidade: logs estruturados e traces de LLM calls

Sem observabilidade, você só descobre que algo quebrou quando o usuário reclama. Ou pior, quando não reclama e silenciosamente o agente começou a retornar lixo.

Logs estruturados (JSON, não strings livres) salvam vidas:

{
  "timestamp": "2026-04-21T14:32:00Z",
  "agent_id": "content_classifier_v2",
  "request_id": "req_7f4a2c9e",
  "action": "classify_content",
  "input_length": 2847,
  "llm_model": "gpt-4o-mini",
  "tokens_in": 450,
  "tokens_out": 12,
  "latency_ms": 680,
  "success": true,
  "classification": "urgent",
  "confidence": 0.92
}

Com isso, você consegue:

• Alertar se latência de um agente subiu de 200ms para 3s
• Correlacionar custos de token com volume de requests
• Descobrir que um modelo começou a retornar outputs truncados após um update

Ferramentas como LangSmith e LangFuse são feitas pra isso. Elas rastreiam cada LLM call dentro de um agente, mostram onde o tempo está sendo gasto, e permitem debug de uma conversa específica em segundos.

Custo fora de controle: tokens e caching

Token budget é a realidade que ninguém quer conversar em demo. Mas em produção, custa dinheiro de verdade.

Um agente que faz RAG precisa passar documentos para o LLM a cada chamada. Se cada documento é 500 tokens e você tem 10 documentos como contexto, são 5 mil tokens só de input pra responder uma pergunta simples. Multiplica por 10 mil usuarios/dia e você está queimando 50 milhões de tokens por dia.

Estratégias que funcionam:

• Prompt caching: LLMs modernos (GPT-4o, Claude 3.5) suportam cache de contexto. Os primeiros 1024 tokens de sistema + documentos são cacheados. Requisição seguinte reutiliza, economiza 90% dos tokens.
• Chunks menores: RAG com chunks de 200 tokens vs 1000 tokens faz diferença. Menos contexto desnecessário.
• SLM para filtros: Antes de chamar um GPT-4o caríssimo, um Llama 3.1 8B (ou Phi-3) classifica se a query merece a chamada cara. Economiza fortune.

Loops infinitos e guardrails

Agentes que raciocinam demais (ou que têm prompts ruins) conseguem entrar em loops:

Agent: "Preciso buscar informações" Agent: "Estou buscando informações" Agent: "Ainda estou buscando" ... (30 iterações depois)

A solução:

1. Max iterations limit: Um agente não pode rodar mais de N steps. 5, 10, 20 — depende do caso.
2. Timeout global: Se o agente passa de X segundos, para.
3. Detecção de repeated actions: Se o agente tenta a mesma ação 3 vezes, para e escala pra human.

Guardrails também protegem contra outputs ruins:

• Rejeitar respostas que contenham dados sensíveis (SSN, senha)
• Validar formato esperado (JSON bem-formado, campos obrigatórios)
• Rejeitar confiança baixa (se o LLM retorna confidence < 0.6, escalona)

Human-in-the-loop: quando o agente não sabe

O agente mais inteligente do mundo não sabe tudo. E tentar bluffar em produção é caro.

A arquitetura que funciona:

1. Agente tenta resolver
2. Se confiança < threshold OU ação é crítica (refund, demissão de funcionário), escalona para human
3. Human revisa, aprova ou corrige
4. Agente aprende do feedback (opcional, mas valioso)

Isso requer uma fila bem pensada, notificação para o time certo, SLA de resposta. Mas é o que transforma "agente que acha que tudo está certo" em "agente que sabe os próprios limites".

Checklist: antes de dar deploy

[ ] Idempotência implementada — toda ação tem request ID único
[ ] Retries com exponential backoff + circuit breakers rodando
[ ] Logs estruturados em JSON em stdout
[ ] LangSmith/LangFuse conectado para traces
[ ] Max iterations limit: 10
[ ] Timeout global: 30s
[ ] Monitoring de tokens/custo por request
[ ] Prompt caching habilitado (se aplicável)
[ ] SLM implementado pra pré-filtros
[ ] Fallback para human definido
[ ] Testes de observabilidade: você consegue debugar uma falha em 5 min?
[ ] Load test com 10% do tráfego esperado
[ ] Plano de rollback: você consegue voltar em 5 minutos?

A verdade sobre produção

Agentes em produção não são mágica. São um monte de engenharia chata (logging, retries, fallbacks) servindo um modelo que erra 3% das vezes, dentro de um sistema que precisa escalar.

A gente na Alienhub passou por isso. Vimos agentes que funcionavam no notebook e quebravam no primeiro pico de traffic. Vimos custos dispararem porque ninguém estava olhando. E vimos sistemas que ficaram super confiáveis depois que paramos de tentar ser perfeitos e começamos a ser observáveis.

Se você tem um agente de IA que precisa ser robusto e observável em produção, a gente sabe o caminho. Já fomos para o poço, mapeamos tudo e deixamos a ladder na parede.