---
title: Agente de IA vs chatbot: a diferença, e quando o chatbot ganha
description: Um chatbot segue ramificações que uma pessoa escreveu. Um agente decide e chama tools. A diferença real, o mesmo pedido resolvido dos dois jeitos, e os casos em que o chatbot ainda é a escolha certa.
date: 2026-08-11
author: Victor Villalobos
locale: pt
source: https://www.zavu.dev/pt/blog/ai-agent-vs-chatbot
tags: AI Agents, Guia, WhatsApp
---

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

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:

```ts
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:

1. **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.
2. **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.
3. **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:

1. Deixe os flows principais exatamente como estão. Funcionam e são baratos.
2. 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.
3. Dê ao agente as tools que os seus flows já chamam. Elas existem e estão testadas.
4. 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](/pt/blog/what-is-an-ai-agent): a definição e as quatro partes.
- [Como criar um agente de IA](/pt/blog/how-to-build-an-ai-agent): o loop do zero e depois deployado num canal.
- [Como criar um chatbot para WhatsApp](/pt/blog/como-crear-chatbot-whatsapp): se a tabela de decisão te trouxe até aqui.
- [Frameworks de agentes de IA comparados](/pt/blog/ai-agent-frameworks): depois que você decidiu pelo agente.