Agente de IA vs chatbot: qual construir

A versão honesta desta comparação começa com uma confissão: para muitos casos de uso o chatbot continua sendo a resposta certa, e o mercado passou dois anos fingindo o contrário.

Então vai a diferença, e depois a parte em que dizemos quando não construir o agente.

A diferença real

Um chatbot segue um caminho que uma pessoa escreveu. Alguém desenhou a árvore: se o cliente tocar em "Rastrear meu pedido", pedir o número, chamar o endpoint de rastreio, mostrar o resultado. Cada ramificação existe porque uma pessoa colocou ali.

Um agente decide. Ele recebe um objetivo, um conjunto de tools e permissão para escolher. Ninguém escreveu o caminho, porque o caminho é diferente toda vez.

Essa é a distinção inteira. Não é inteligência, não é o modelo, não é se ele "entende linguagem natural" (chatbots lidam com linguagem natural há anos). A pergunta é: quem escolheu o que acontece em seguida, uma pessoa no momento do design ou o modelo no momento da execução.

O mesmo pedido, dos dois jeitos

Um cliente escreve: "oi comprei uma coisa semana passada pro aniversário da minha mãe e até agora não chegou, o aniversário é sábado, dá pra verificar?"

O chatbot:

Não entendi. Escolha uma opção:
1. Rastrear um pedido
2. Trocas e devoluções
3. Falar com um atendente

Ele não falhou. Fez exatamente o que foi construído para fazer. A mensagem não bateu com nenhuma ramificação, então caiu no default.

O agente:

turno 1  não há número de pedido na mensagem
         chama: find_orders(customerPhone) -> um pedido, de 4 de agosto
turno 2  chama: lookup_order("4471") -> in_transit, eta 14 de agosto
turno 3  responde

"Achei seu pedido de 4 de agosto. Está a caminho e a transportadora estima o dia 14, que é depois de sábado. Posso pedir para agilizarem ou abrir um reembolso. O que você prefere?"

Duas coisas aconteceram que nenhuma ramificação daria conta: ele deduziu que o número do pedido que faltava dava para achar pelo telefone, e percebeu que a data de entrega cai depois do aniversário que o cliente mencionou de passagem. Ninguém escreveu um script para "comparar a ETA com uma data que o cliente citou casualmente".

Esse é o argumento a favor dos agentes, dito com toda a força que ele merece.

Agora o argumento contra

Chatbots são previsíveis, e previsibilidade tem valor real. Você consegue enumerar tudo o que um chatbot algum dia vai dizer. Com um agente, não. Em contexto regulado isso não é preferência, é requisito.

Chatbots são mais baratos. Tocar um botão não custa nada. Um turno de agente é uma chamada ao modelo carregando a conversa inteira, e pedidos complexos levam vários.

Chatbots são mais rápidos. Sem modelo no caminho, a resposta é instantânea. Um agente que chama duas tools leva alguns segundos, o que no WhatsApp está de bom tamanho e numa ligação não está.

Chatbots falham de forma visível. Quando um chatbot quebra, você vê um menu quebrado. Quando um agente quebra, ele produz uma resposta fluente, confiante e errada, e você descobre por um cliente.

A decisão

Sua situação	Construa
Cinco opções, e 90 por cento das pessoas quer uma delas	Chatbot
As respostas precisam ser aprovadas palavra por palavra (jurídico, saúde, financeiro)	Chatbot
Os pedidos são abertos e chegam com as palavras do próprio cliente	Agente
Responder exige consultar duas ou três coisas e combinar	Agente
Seu knowledge base muda toda semana e ninguém quer redesenhar uma árvore	Agente
Você está numa ligação com orçamento de latência de um segundo	Agente, com tools muito rápidas
A ação é irreversível e cara se der errado	Qualquer um dos dois, com um humano aprovando
Você não tem tools para dar a ele	Nenhum. Você quer busca sobre os seus documentos

A última linha pega mais times do que se imagina. Um agente sem tools é um FAQ bem falante, e montar infraestrutura de agentes para chegar nisso é muito trabalho para algo que uma caixa de busca resolve.

O que realmente vai para produção: os dois

O padrão que sobrevive não é um ou outro. É um flow com script no caminho que você já conhece, e um agente em todo o resto.

O opt-out é o exemplo mais claro. Quando alguém escreve SAIR, você não quer um modelo decidindo. Quer uma ramificação determinística que descadastre a pessoa, sempre, em menos de um segundo. Mesma coisa para "quero falar com uma pessoa": sem interpretação, só o handoff.

Tudo o que não está na lista de caminhos conhecidos vai para o agente.

Na Zavu isso mapeia direto. Os flows cuidam dos caminhos determinísticos com triggers por palavra-chave. O agente cuida do resto, com tools para o que ele precisa fazer e uma tool transfer_to_human para o que ele não deveria.

Essa divisão você descreve, não programa. Instale as skills e o CLI uma vez (npx skills add zavudev/zavu-skills e npx zavudev@latest login), e então entregue a política ao seu coding agent:

> Mantenha os nossos flows de palavra-chave SAIR e "falar com uma pessoa" exatamente como estão. Adicione um agente para todo o resto. Dê a ele uma tool transfer_to_human que faz POST no nosso webhook de plantão, e faça ele usar essa tool para reembolsos acima de USD 200 em vez de decidir sozinho.

O que volta:

TypeScript
import { defineAgent, defineTool } from "@zavudev/functions"

defineAgent({
  senderId: process.env.SENDER_ID!,
  name: "Suporte",
  provider: "zavu",
  model: "openai/gpt-4o-mini",
  prompt: Você é o suporte de uma loja online.
Nunca prometa uma data de entrega que a transportadora não tenha dado.
Para reembolsos acima de USD 200, use transfer_to_human em vez de decidir.,
})

defineTool({
  name: "transfer_to_human",
  description:
    "Hand the conversation to a person. Use for refunds over $200, complaints about damage, or any time the customer asks for a human.",
  parameters: {
    type: "object",
    properties: { reason: { type: "string" } },
    required: ["reason"],
  },
  handler: async ({ reason }, ctx) => {
    await notifyOnCall({ conversation: ctx.sessionId, reason })
    return { transferred: true }
  },
})

Confira uma coisa nesse diff antes de subir: a regra de escalada mora em dois lugares de propósito. No prompt, para o modelo conhecer a política, e na descrição da tool, para ele reconhecer o momento. Prompt declara política. Descrição de tool dispara comportamento. Colocar em só um dos dois é o motivo mais comum de um agente que "sabe" que deveria escalar nunca escalar, e é o que um coding agent deixa pela metade com mais frequência.

Como saber qual você já tem

Se um fornecedor te vende um "agente de IA", três perguntas resolvem:

Quais tools ele consegue chamar? Se a resposta for uma lista de intents em vez de funções, é um chatbot com um modelo de linguagem na frente.

Ele consegue chamar duas tools na mesma conversa e usar o resultado da primeira para decidir a segunda? Isso é o loop. Se não consegue, não existe loop.

O que ele faz quando não sabe? Uma resposta de verdade aqui ("ele escala, e o log é este") significa que alguém desenhou para a falha. Sem resposta, você vai descobrir em produção.

Migrar de um para o outro

Você não precisa jogar o chatbot fora. O caminho que funciona:

Deixe os flows principais exatamente como estão. Funcionam e são baratos.

Aponte o default de "não entendi" para um agente em vez de para um menu. Essa ramificação padrão é onde você está perdendo gente hoje, e é o lugar de maior valor para colocar um modelo.

Dê ao agente as tools que os seus flows já chamam. Elas existem e estão testadas.

Acompanhe a taxa de escalada. Quando cair, mova outro flow para o agente. Quando subir, você moveu um a mais.

Começar pelo fallback significa que o agente só atende conversas que já estavam falhando, então o downside fica limitado desde o primeiro dia.

Continue lendo

O que é um agente de IA: a definição e as quatro partes.
Como criar um agente de IA: o loop do zero e depois deployado num canal.
Como criar um chatbot para WhatsApp: se a tabela de decisão te trouxe até aqui.
Frameworks de agentes de IA comparados: depois que você decidiu pelo agente.

Agente de IA vs chatbot: a diferença, e quando o chatbot ganha