Agente IA não cai por LLM ruim. Cai por function calling mal feito.
Você troca o modelo do GPT-4 pro Claude, depois pro Gemini, e o agente continua rodando em loop, chamando tool errada, ou estourando timeout. O LLM não é o problema. O problema é a camada de tools: schemas frouxos, validação ausente, retry mal calibrado, observabilidade zero. Quem opera agente em produção sabe — quem ainda não opera, vai aprender da pior forma.
Por que function calling quebra em produção?
Function calling (ou tool use) é o mecanismo onde o LLM decide qual função sua chamar e com quais argumentos. Guias práticos de 2026 destacam 4 falhas recorrentes: argumentos malformados, função inexistente, timeouts em chamadas externas e loops infinitos quando o LLM insiste em chamar tool errada.
Cada uma dessas falhas é silenciosa em dev, com 3-5 conversas/dia. Em produção, com 1.000-10.000 conversas/dia, viram incidentes diários. O custo também escala: definição de tool consome tokens, e cada loop multiplica chamadas API. Sem observabilidade fina, você descobre o estrago no boleto da OpenAI no fim do mês.
Dado-chave: em agentes de produção, 60-70% dos incidentes não vêm do LLM. Vêm da camada de orquestração — schemas mal definidos, retry sem cap e ausência de fallback.
O ângulo contrário: você não escala "deixando o LLM decidir tudo"
O sonho é "agente autônomo decide qual tool usar, com quais argumentos, em qual ordem". É factível pra demo. Em produção, agente robusto é agente com guardrails. O LLM propõe, o seu código dispõe. Quem inverte essa hierarquia paga em uptime.
Outro ponto: tool não é só REST. Tool é qualquer função que extende o agente — query SQL, leitura de planilha, chamada de webhook, busca em knowledge base. Quanto mais tools, mais decisão errada. A solução não é menos tools — é tools melhor descritas e agrupadas por domínio.
Os 5 padrões que salvam seu agente
1. Schema rígido com validação antes de executar
Defina cada tool com JSON Schema completo: tipos, required, enums, ranges. Antes de executar, valide com Pydantic ou Zod. Argumento fora do schema = retorna erro pro LLM (não pro código), e o agente ajusta:
{
"name": "buscar_imovel",
"parameters": {
"type": "object",
"properties": {
"bairro": { "type": "string", "minLength": 2 },
"valor_max": { "type": "number", "minimum": 50000 },
"tipo": { "enum": ["apartamento", "casa", "comercial"] }
},
"required": ["bairro", "tipo"]
}
}Schema frouxo é a fonte #1 de bug.
2. Paralelismo onde for independente
Se o usuário perguntar "tem disponibilidade pra terça e quinta?", o agente deve chamar checar_disponibilidade duas vezes em paralelo, não duas idas-e-voltas. LLMs modernos suportam multiple tool calls num único turno. Bibliotecas que serializam matam UX por inércia.
3. Retry com cap e timeout específico por tool
Tool externa falha. Sempre. Implemente:
- Timeout específico: 2s para webhook interno, 10s para integração com CRM externo
- Retry máximo: 2 tentativas com backoff exponencial
- Cap global: agente nunca chama a mesma tool 3+ vezes na mesma conversa sem mensagem do usuário entre as chamadas
Sem cap, você descobre que um agente entrou em loop com 1.400 chamadas no dia depois — e o boleto chega.
4. Observabilidade granular por tool
Logue cada chamada com: tool name, argumentos, latência, resultado, custo de tokens. Métricas que importam:
- Taxa de sucesso por tool (qualquer abaixo de 95% = problema)
- Latência p95 por tool (>2s no WhatsApp = ruim)
- Tokens médios por chamada (alto = schema gordo demais)
- Tools mais chamadas vs tools nunca chamadas (sinaliza prompt mal calibrado)
5. Agrupamento por domínio + tool router
Quando seu agente tem 15+ tools, qualidade cai. LLM erra a escolha. Solução: agrupe tools por domínio (vendas, suporte, agendamento) e use um agente roteador que decide qual sub-agente chamar. Cada sub-agente carrega só 3-5 tools relacionadas. Ganho duplo: prompt mais curto + decisão mais precisa.
Como a Verboo entrega isso nativamente
| Padrão | Sem plataforma | Verboo |
|---|---|---|
| Schema rígido + validação | Pydantic + parser custom | Painel define schema; validação automática |
| Paralelismo | Configurar no framework | Nativo no runtime |
| Retry com cap + timeout | Lógica custom + bibliotecas | Configurável por gatilho |
| Observabilidade por tool | OpenTelemetry + dashboard | Histórico nativo de chamadas |
| Tool router (multi-agente) | Orquestrador próprio | Múltiplos assistentes + Fluxo AI roteador |
O que isso significa em produção
A Verboo opera 1.284 agentes ativos com 27MM+ mensagens processadas. Latência média sub-500ms, incluindo function calling. A camada que separa agente de demo de agente sério é exatamente esses 5 padrões — e fazer cada um na mão custa 2-4 semanas de engenharia. Conheça a plataforma.
Próximo passo
Pegue um dos seus agentes em dev, conte quantas tools tem e quantas falham silenciosamente sob carga. Provavelmente 2-3. Os 5 padrões acima resolvem 90% disso. Veja os planos da Verboo pra rodar com gatilhos prontos.
Fonte: guia de implementação de function calling 2026 · Fonte: Martin Fowler sobre function calling com LLMs
