Seu agente IA quebra em produção (sem testing)

Seu agente IA quebra em produção (sem testing)

Você tem SaaS.

Seu SaaS: agente IA pra atendimento/vendas.

Você lança agente (beta).

Agente funciona bem (em dev environment):

• Entende pergunta do cliente
• Busca resposta no database
• Responde rápido
• Cliente feliz

Você lança agente em produção.

MAS:

2 dias depois:

Cliente 1 diz:

"Seu agente respondeu errado.

Eu perguntei: 'Qual é o prazo de entrega?'

Agente respondeu: 'Seu pedido foi cancelado.' (WTF?)

Eu não queria cancelar pedido!

Seu agente é broken."

Cliente 2 diz:

"Seu agente mandou email pra pessoa errada.

Eu perguntei: 'Avise meu cliente X'

Agente avistou meu cliente Y (wrong customer).

Agora cliente Y está puto comigo.

Seu agente is a disaster."

Cliente 3 diz:

"Seu agente travou no meio da conversa.

Eu tive que reabrir conversa do zero.

A primeira conversa ficou incompleta.

Seu agente is unreliable."

Você:

"WTF? Agente funcionava bem em dev!

O que aconteceu?"

Resposta:

Seu agente NÃO FOI TESTADO antes de produção.

---

Por que agente sem testing quebra (e breaks customer trust)

Agentes são não-determinísticos (output é imprevisível)

DIFERENÇA: Software tradicional vs Agente IA

---

SOFTWARE TRADICIONAL:

Input: 5 Code: function add(x) { return x + 5; } Output: 10

Tested:

• Input 5 → Output 10 ✓
• Input 3 → Output 8 ✓
• Input 0 → Output 5 ✓

Result: DETERMINÍSTICO (same input = same output, always)

Production: confiável (código não muda behavior)

---

AGENTE IA:

Input: "Qual é o prazo de entrega?" Agente:

• Step 1: Entender pergunta (use LLM para interpretar)
• Step 2: Buscar resposta (chamar tool/API)
• Step 3: Formatar resposta (LLM gera resposta)

Output: depende de LLM (language model)

Problem:

• LLMs são não-determinísticos
• Same input = different output (sometimes)
• Agente output é imprevisível

Exemplos:

1ª chamada: Input: "Qual é o prazo de entrega?" Output: "Seu pedido chega em 3 dias" ✓ (correto)

2ª chamada (mesma pergunta): Input: "Qual é o prazo de entrega?" Output: "Seu pedido foi cancelado" ✗ (ERRADO)

Por quê?

• LLM é probabilístico (sampling, temperature, etc)
• Agente comportamento é imprevisível
• Agente pode fazer coisa diferente com input idêntico

Result: NÃO-DETERMINÍSTICO (same input ≠ same output, sometimes wrong)

Production: UNRELIABLE (agente pode fazer qualquer coisa)

---

COMPARAÇÃO:

Software tradicional:

• Determinístico (same input = same output)
• Testável (unit test, integration test, etc)
• Confiável em produção (comportamento previsível)

Agente IA:

• Não-determinístico (same input ≠ same output, sometimes)
• Difícil de testar (não é unit-testable)
• Unreliable em produção (comportamento imprevisível)

---

IMPLICAÇÃO:

Agente sem testing = roulette wheel (agente pode fazer qualquer coisa). Cliente usa agente = Russian roulette (quando agente vai quebrar?). Cliente descobre = customer loss (agente unreliable = cancel contract).

Agentes são multi-step (erro em step 1 cascata pra step 10)

COMPLEXIDADE: Single-step vs Multi-step agent

---

SINGLE-STEP (simples):

Input: "Qual é o preço?" ↓ Step 1: Buscar preço (query database) ↓ Output: "Preço é R$ 100"

Testing: fácil

• Teste se Step 1 funciona (query database works)
• Done

Risk: baixo

• Se Step 1 quebra, output é errado
• Mas apenas 1 ponto de failure

---

MULTI-STEP (complexo):

Input: "Quero devolver meu pedido e receber refund" ↓ Step 1: Entender pergunta (LLM interpreta) ↓ Step 2: Buscar pedido (chamar API) ↓ Step 3: Verificar políticas (chamar database) ↓ Step 4: Decidir se refund é válido (LLM decide) ↓ Step 5: Processar refund (chamar payment API) ↓ Step 6: Enviar email confirmação (chamar email API) ↓ Output: "Refund processado, você receberá em 2-3 dias"

Testing: MUITO DIFÍCIL

• Teste Step 1 (LLM interpreta corretamente) - hard
• Teste Step 2 (API retorna dado correto) - medium
• Teste Step 3 (database válido) - easy
• Teste Step 4 (LLM decide corretamente) - VERY HARD
• Teste Step 5 (payment API funciona) - medium
• Teste Step 6 (email API funciona) - medium

Result: 6 pontos onde pode quebrar

Cascata (erro em Step N afeta Step N+1):

• Se Step 1 falha (LLM interpreta errado): Step 2-6 usa interpretação errada
• Se Step 2 falha (API retorna nada): Step 3-6 não tem dado
• Se Step 4 falha (LLM decide errado): Step 5 processa refund errado
• Se Step 5 falha (payment API down): Step 6 manda email de failure

Risk: MUITO ALTO

• 6 pontos de failure
• Cada ponto pode quebrar tudo
• Cascata de erros (erro antigo afeta downstream)

---

EXEMPLO DE CASCATA:

Scenario: Cliente devolvendo pedido

Step 1: LLM interpreta

• Input: "Quero devolver porque produto chegou quebrado"
• LLM interpreta: "Cliente quer devolver porque produto NÃO é compatível" (WRONG)
• Nota: LLM alucinando (hallucinating)

Step 2: Busca pedido (usa interpretação errada)

• Busca por: "incompatibilidade" (em lugar de "produto quebrado")
• Resultado: encontra pedido errado (ou nenhum pedido)

Step 3: Verifica política

• Pedido errado = política errada aplicada
• Resultado: política de "incompatibilidade" (não "produto quebrado")

Step 4: Decide refund

• Política de incompatibilidade: refund não é válido (cliente responsável)
• Resultado: Nega refund (ERRADO)

Step 5: Informa cliente

• "Seu refund foi negado. Produto não é compatível, você não pode devolver."
• Resultado: Cliente PUTO (pedido chegou quebrado, e nós negamos refund!)

Result:

• Error in Step 1 (LLM hallucination) cascata através Steps 2-5
• Cliente perde refund (wrongly denied)
• Cliente é FURIOUS (agente is broken)
• Customer cancels contract (agente é unreliable)

---

MORAL:

Multi-step agentes = muitos pontos onde quebram. Cascata = erro antigo quebra tudo downstream. Sem testing = você não sabe onde agente quebra. Cliente descobre = você morre.

Agentes fazem tool calls (1 tool call ruim = tudo ruim)

TOOL CALLS: quando agente chama externa API/service

---

EXEMPLO:

Cliente: "Quero reembolso"

Agente precisa:

1. Chamar tool: "buscar_pedido(customer_id)" → retorna pedido do cliente
2. Chamar tool: "verificar_politica_refund(pedido)" → retorna se refund é válido
3. Chamar tool: "processar_refund(pedido)" → processa refund
4. Chamar tool: "enviar_email(customer, 'refund processado')" → manda email

Problema: Se 1 tool call quebra:

Scenario 1: Tool 1 retorna dado errado

• "buscar_pedido" retorna pedido do cliente ERRADO
• Tools 2-4 usam pedido errado
• Refund processado pra pedido errado
• Resultado: cliente X recebe refund de cliente Y (NIGHTMARE)

Scenario 2: Tool 3 não processa refund

• "processar_refund" chama payment API
• Payment API está down (maintenance, bug, etc)
• Tool 3 falha (não processa refund)
• Agent continua (assume refund foi processado)
• Tool 4 manda email: "Refund processado"
• Cliente recebe email ("refund processado")
• Mas refund NÃO foi processado (payment API down)
• Cliente espera 2-3 dias por dinheiro
• Dinheiro não chega (payment API nunca processou)
• Cliente FURIOUS (agente mentiu)
• Customer cancels (agente unreliable)

Scenario 3: Agent chama tool errado

• Agente precisa chamar: "processar_refund(pedido_id_123)"
• Agente chama: "cancelar_pedido(pedido_id_123)" (WRONG TOOL)
• Pedido é cancelado (em lugar de refund processado)
• Cliente recebe email: "Seu refund foi processado"
• Mas pedido foi cancelado (não refund)
• Cliente é confused (agente fez coisa errada)

---

MORAL:

Agent faz muitas tool calls. Cada tool call pode quebrar (API down, wrong data, wrong tool). Sem testing = você não sabe qual tool call é broken. Cliente descobre = você morre.

Como testar agente (antes de produção quebrar)

Problema: agentes são difíceis de testar (não é unit testable)

POR QUE AGENTES SÃO DIFÍCEIS DE TESTAR?

1. NÃO-DETERMINISMO

   • LLM output é probabilístico
   • Same input ≠ same output
   • Teste falhará intermitentemente (sometimes pass, sometimes fail)
   • Resultado: testes não são confiáveis

2. COMPLEXIDADE MULTI-STEP

   • Agente tem 6-10 steps
   • Cada step pode quebrar
   • Testar todas as combinações (6^2 = 36 scenarios, 10^2 = 100 scenarios)
   • Unit tests não são suficientes (need integration tests)
   • Resultado: testes são caros e lentos

3. DEPENDÊNCIA EXTERNA (APIs)

   • Agente chama APIs externas (payment, email, database)
   • APIs podem estar down, retornar erro, retornar dado errado
   • Você pode't mock todas as APIs (too many)
   • Resultado: precisas testar com APIs reais (slow, expensive)

4. HALLUCINATIONS (LLM alucinações)

   • LLM pode inventar informação (hallucinate)
   • "Seu pedido chegará em 3 dias" (agente inventou, não tem dado)
   • Impossível testar sem avaliar semantic correctness
   • Resultado: testes precisam de human review (expensive)

---

TRADICIONAL TESTING INADEQUATE:

Unit tests:

• function add(5) → 10 ✓ (works pra traditional software)
• agent("refund?") → "refund processado" ? (maybe, maybe not—non-deterministic)

Integration tests:

• Works pra traditional software (if A works and B works, A+B works)
• Doesn't work pra agentes (A works + B works ≠ agente works)
  • Because LLM output is probabilistic
  • Because cascata of errors
  • Because hallucinations

End-to-end tests:

• Too slow (agente takes 5-10 seconds per test)
• Too expensive (APIs calls cost money)
• Too hard to scale (can't test all scenarios)

---

RESULT:

Traditional testing doesn't work for agents. You need agent-specific evaluation framework. Enter: LangSmith (or similar).

Solução: LangSmith (evaluating agentes systematically)

LANGSMITH: Framework pra validar agente behavior

---

O QUE FALTA EM AGENTES:

1. You can't do unit testing (agentes são não-determinísticos)
2. You can't do integration testing (cascata de erros)
3. You need systematic evaluation (on multiple dimensions)

O QUE LANGSMITH FAZ:

1. TRACES: registra cada step do agente

   • Step 1 output
   • Step 2 input/output
   • Step 3 input/output
   • Etc
   • Result: você vê exatamente onde agente quebrou

2. DATASETS: cria test dataset (múltiplos scenarios)

   • Scenario 1: "Refund request (valid)"
   • Scenario 2: "Refund request (invalid policy)"
   • Scenario 3: "Refund request (wrong pedido)"
   • Scenario 4: "Refund + complaint (multi-intent)"
   • Result: você testa agente em múltiplos cases

3. EVALUATORS: avalia output (semantic correctness)

   • Evaluator 1: "Did agente understand correctly?"
   • Evaluator 2: "Did agente call right tool?"
   • Evaluator 3: "Is refund amount correct?"
   • Evaluator 4: "Did agente maintain context?"
   • Result: você sabe se agente output é correto (not just syntactically, semantically)

4. METRICS: agregha dados (pass rate, latency, cost)

   • Pass rate: 95% (agente acerta 95% dos casos)
   • Fail rate: 5% (agente erra 5% dos casos)
   • Latency: 2.3 segundos (agente leva 2.3s pra responder)
   • Cost: R$ 0.15 por request (custo de inference)
   • Result: você vê health of your agente (overall)

---

COMO USA LANGSMITH:

1. Create dataset (write test scenarios)

   • "Refund request (valid)"
   • "Refund request (invalid)"
   • Etc (10-100 scenarios)

2. Run agente against dataset

   • LangSmith executa agente com cada scenario
   • LangSmith registra cada step (trace)
   • LangSmith coleta output

3. Evaluate results

   • LangSmith run evaluators (semantic correctness)
   • LangSmith agrega métricas (pass rate, latency, cost)

4. Analyze failures

   • LangSmith mostra onde agente falhou (step 4, tool 3, etc)
   • LangSmith mostra por que falhou (wrong tool, hallucination, etc)
   • Result: você sabe exatamente o que arrumar

5. Iterate

   • Arrumar agente (change prompt, fix tool call, etc)
   • Run LangSmith again (test improvements)
   • Repeat (until pass rate é alto, failures são low)

---

RESULT:

Before LangSmith:

• You deploy agente to production
• Agente quebra
• Customers descobrem
• You lose customers

With LangSmith:

• You test agente with LangSmith (before production)
• You find failures (step 4 quebra, tool 3 não funciona)
• You fix agente (before production)
• You deploy agente to production (confident, tested)
• Agente não quebra (porque você testou)
• Customers happy (agente é reliable)

3 tipos de testing pra agente (antes que cliente descobre erro)

Testing Type 1: Correctness (agente entende pergunta corretamente?)

QUESTÃO:

"Seu agente está entendendo o que cliente pedindo?"

TESTE:

Input scenarios:

1. "Quero refund" → agente entende: refund request ✓
2. "Devolva meu produto" → agente entende: return/refund request ✓
3. "Não gostei do produto" → agente entende: refund request (satisfaction issue) ✓
4. "Produto chegou quebrado" → agente entende: refund request (defective) ✓
5. "Qual é o prazo?" → agente entende: delivery status inquiry (NOT refund) ✓

Metric: Correctness (does agente understand correctly?)

• Pass: 5/5 (100%)

RESULTADO:

Se correctness é 100%:

• Agente entende corretamente
• Agente leva caminhos corretos

Se correctness é 70%:

• Agente entende errado em 30% dos casos
• Agente leva caminhos errados (cascata)
• RISK: alto (cliente recebe respostas erradas)

Testing Type 2: Reliability (agente faz tool calls corretamente?)

QUESTÃO:

"Seu agente está chamando as tools corretas?

E as tools estão retornando dados corretos?"

TESTE:

Scenarios (com tool mocking):

1. Agente chama: "buscar_pedido(customer_id_123)" → mock retorna pedido_id_456

   • Agente usa pedido_id_456 (correto) ✓

2. Agente chama: "verificar_politica_refund(pedido_id_456)" → mock retorna "refund válido"

   • Agente processa refund (correto) ✓

3. Agente chama: "processar_refund(pedido_id_456, amount)" → mock retorna "success"

   • Agente envia email confirmação (correto) ✓

4. Agente chama: "processar_refund(pedido_id_456, amount)" → mock retorna "error"

   • Agente trata erro (envia email de failure) ✓

Metric: Reliability (does agente call right tool, handle errors)

• Pass: 4/4 (100%)

RESULTADO:

Se reliability é 100%:

• Agente chama tools corretos
• Agente trata erros (se tool falha, agente não cascata)

Se reliability é 60%:

• Agente chama tool errado em 40% dos casos
• Agente não trata erros em 40% dos casos
• RISK: MUITO ALTO (tool call wrong = customer data corrupted)

Testing Type 3: Robustness (agente quebra quando APIs estão down?)

QUESTÃO:

"Seu agente é robusto quando APIs externas estão down/lenta?"

TESTE:

Scenarios (com API failures):

1. Payment API down

   • Agente chama: "processar_refund"
   • API retorna: timeout/error
   • Agente deve: retry, ou return error gracefully
   • Agente não deve: cascade error, ou assume success

2. Database down

   • Agente chama: "buscar_pedido"
   • Database retorna: connection refused
   • Agente deve: retry, ou inform customer
   • Agente não deve: hallucinate pedido data

3. Email API slow

   • Agente chama: "enviar_email"
   • Email API takes 10 segundos (normal é 1s)
   • Agente deve: timeout gracefully
   • Agente não deve: block everything

Metric: Robustness (does agente handle failures)

• Pass: 3/3 (100%)

RESULTADO:

Se robustness é 100%:

• Agente gracefully trata API failures
• Customer recebe feedback ("API down, will retry later")
• Agente não quebra (quando API quebra)

Se robustness é 30%:

• Agente cascata erros (quando API quebra, tudo quebra)
• Customer recebe confusing message ("refund processed" mas payment failed)
• RISK: CRÍTICO (customer data inconsistency)

Conclusão: Test agente before produção (ou cliente vai descobrir erro)

**O que você precisa saber:

1. Agentes são não-determinísticos + multi-step + fazem tool calls

   • Determinístico software: same input = same output (testável)
   • Agente: same input ≠ same output, sometimes quebra (hard to test)
   • Agente multi-step: erro em step 1 cascata pra step 10
   • Agente tool calls: 1 tool call wrong = tudo errado

2. Quando você não testa agente:

   • Agente quebra em produção (você só descobre quando cliente complains)
   • Cliente descobre agente é unreliable ("agente mentiu pra mim")
   • Customer cancels (agente unreliable = contract termination)
   • Você lose revenue (customer gone)
   • Você lose reputation (customer spread word: "agente is broken")

3. Traditional testing doesn't work:

   • Unit tests: agente é non-deterministic (testes falham sometimes)
   • Integration tests: agente cascata errors (A + B ≠ A+B)
   • End-to-end tests: slow + expensive + doesn't scale
   • Result: você need agent-specific evaluation framework

4. LangSmith (ou similar) solve agente testing:

   • TRACES: mostra exatamente onde agente quebrou
   • DATASETS: testa múltiplos scenarios
   • EVALUATORS: avalia semantic correctness (not just syntax)
   • METRICS: mostra overall health (pass rate, latency, cost)

5. 3 tipos de testing pra agente:

   • Correctness: agente entende pergunta corretamente?
   • Reliability: agente chama tools corretos + trata erros?
   • Robustness: agente quebra quando APIs down/slow?
   • Sua goal: Correctness ≥ 95%, Reliability ≥ 95%, Robustness ≥ 90%

6. Timeline (quando você precisa testar):

   • Week 1-2: Build agente (MVP)
   • Week 3-4: Create LangSmith dataset (10-50 test scenarios)
   • Week 5: Run LangSmith evaluation (identify failures)
   • Week 6: Fix agente (based on LangSmith feedback)
   • Week 7: Re-run LangSmith (verify fixes)
   • Week 8: Deploy to production (confident, tested)
   • Result: Agente é reliable em produção (customer happy)

Na OpenClaw, ajudamos startup de agente IA a:

• ASSESS agente reliability (é realmente confiável pra produção?)
• IDENTIFY failure modes (onde agente quebra? Correctness? Reliability? Robustness?)
• BUILD test dataset (create comprehensive test scenarios)
• EVALUATE com LangSmith (ou similar framework)
• ITERATE agente (fix failures, improve metrics)
• DEPLOY com confiança (knowing agente é tested, reliable)
• MONITOR em produção (catch new failure modes early)

Resultado: Seu agente é reliable em produção (customer happy, customer doesn't cancel, revenue grows).

Audite sua agente reliability →

Seu agente foi testado antes de produção?

Ou você descobrir erro quando cliente reclama?