A palavra "agente" foi pra balada
Hoje virtualmente qualquer interface conversacional vira "agente" no deck do vendor. Chatbot de FAQ é agente. Assistente que responde uma pergunta de cada vez é agente. Wrapper de OpenAI com 4 prompts encadeados é agente.
Não é. E essa confusão custa caro: empresas contratam "agente" achando que vão pro próximo nível e recebem um chatbot ligeiramente mais simpático. O upgrade técnico não vem.
Aqui vai a régua que uso pra separar o que é agente do que é chatbot maquiado.
Os quatro testes do agente real
1. Tool use de verdade — não citação
Chatbot fala. Agente opera.
Um agente real chama ferramentas externas para mudar o estado do mundo: bate em API, cria registro no CRM, envia mensagem no WhatsApp, abre ticket, marca reunião. Não é "te dei o link" — é "abri a reunião e te coloquei no convite".
Teste prático: peça pro vendor mostrar a definição das tools. Se ele tem 12 tools com schemas tipados (entrada/saída), checagem de side-effect, e tratamento de erro por ferramenta — é agente. Se tem 1 tool genérica chamada do_anything que recebe string e retorna string — é chatbot.
2. Planejamento e revisão
Agente decide a ordem das ações em tempo de execução, não em tempo de design.
Numa conversa típica de atendimento: "preciso de uma fatura de outubro do CPF X". O chatbot vai responder com FAQ ou pedir mais informação. O agente vai:
- Buscar o CPF no sistema interno.
- Verificar se o cliente tem permissão pra essa fatura.
- Consultar o financeiro.
- Gerar PDF.
- Anexar à conversa.
- Registrar audit log.
E mais: se algum passo falha, o agente decide o que fazer (tentar de novo? pedir confirmação? escalar pra humano?). Isso é planejamento. Chatbot não planeja — ele responde.
3. Memória que importa
Memória de agente não é "histórico da conversa". É:
- Contexto persistente do usuário (preferências, transações passadas, status atual).
- Estado da tarefa em andamento (já confirmou identidade? já buscou a fatura? aguarda anexo do cliente?).
- Aprendizado entre conversas (esse usuário sempre precisa de assistência adicional ou esse pedido é recorrente).
Sem memória estruturada, o "agente" trata cada turno como se fosse o primeiro. Isso é o pior dos dois mundos: a fricção do chatbot com a complexidade do agente, sem os ganhos.
4. Observability como cidadã de primeira classe
Esse é o que mais separa agente de chatbot na prática.
Em agente real, cada chamada deixa rastro: input completo, prompt resolvido, ferramenta invocada, parâmetros, retorno, custo, latência, modelo, versão. Quando dá ruim (e vai dar), você consegue voltar ao replay exato do que aconteceu.
Pergunte: "quanto custou meu agente atender 1000 conversas mês passado?". Se a resposta envolver "a gente estima mais ou menos", é chatbot. Se for "R$ X.XXX, e o top consumer foi a tool Y respondendo a sazonalidade Z", é agente.
Padrões de orquestração que aguentam produção
Pra quem vai construir e não só comprar, dois padrões valem o tempo de internalizar:
- Function calling + tool use estruturado (Anthropic, OpenAI). O modelo decide qual ferramenta chamar e com que argumentos, o orquestrador executa, devolve resultado, modelo continua. Simples, robusto, debugável.
- Agentes com planner explícito (Anthropic SWE-agent-style, Claude Code). O modelo gera um plano antes de agir, executa em ciclos, revisa, ajusta. Mais poderoso, mais caro, mais difícil de observar.
Pra 80% dos casos que vejo em empresa, function calling resolve. Planner explícito vira overkill que estoura custo sem entregar valor proporcional.
A pergunta certa pro vendor
Em vez de "vocês têm agente?", pergunte:
Me mostra um run real. Mostra o trace. Mostra o custo. Mostra o que aconteceu quando deu errado.
Se a resposta for "isso é confidencial" ou "preciso preparar", você sabe a resposta. Agente real tem run pra mostrar. Tem trace. Tem incidentes documentados. Tem post-mortems.
Chatbot maquiado, não.
