A diferença está no que vem depois da resposta

Um chatbot recebe uma pergunta e devolve texto. Um agente recebe um objetivo, decide que precisa de uma informação que não tem, chama uma ferramenta para buscá-la, lê o resultado e só então responde — ou executa a ação que resolve o pedido.

Na prática, o agente é um laço: observar, decidir, agir, observar de novo. Ele repete esse ciclo até concluir a tarefa, esbarrar num limite que você definiu ou decidir que precisa de um humano. É essa capacidade de agir que separa uma demonstração bonita de algo que tira trabalho da fila do seu time.

Se o resultado do seu projeto de IA é sempre um texto que alguém ainda vai precisar transcrever para outro sistema, você não construiu um agente — construiu um gerador de rascunho.

As quatro peças de um agente que funciona

1. O modelo

É a parte que menos importa na decisão inicial, e a que mais rouba a discussão. Claude, GPT, Gemini e modelos abertos resolvem a grande maioria dos casos corporativos, e a escolha certa costuma ser a que sai mais barata para a qualidade que o caso exige. O que importa é a arquitetura permitir trocar de modelo sem reescrever o sistema.

2. As ferramentas

São funções que você define e autoriza: consultar pedido no ERP, verificar saldo, abrir chamado, agendar visita, emitir segunda via. Cada uma com contrato claro de entrada e saída, e com regra de quando pode ser usada.

Aqui está a maior parte do trabalho de engenharia de um projeto de agente — e é também onde eles morrem. O sistema legado não tem API, o cadastro do cliente está duplicado em três lugares, ninguém sabe qual campo é a fonte da verdade. Nada disso é problema de IA, mas tudo isso impede o agente de existir.

3. O contexto

O modelo não conhece o seu contrato, a sua política de troca nem o pedido de ontem. O conhecimento estável entra por RAG — recuperar os trechos relevantes do seu acervo e entregá-los junto com a pergunta. O dado que muda entra por consulta ao sistema no momento da conversa. Confundir os dois é a causa mais comum de agente que responde com informação desatualizada.

4. Os limites

Um agente que pode fazer qualquer coisa é um incidente esperando data. Os limites são camadas: escopo de assunto, validação da saída antes de entregar, permissão verificada no momento de executar a ação, faixa de valor que exige aprovação humana, e log de tudo que foi decidido.

Vale inverter a pergunta de projeto: em vez de "o que o agente consegue fazer?", pergunte "o que acontece quando ele erra?". Se a resposta for cara demais, essa ação não é candidata a automação total — é candidata a sugestão com aprovação.

Onde o agente paga a conta primeiro

Três características tornam um processo bom candidato, e elas precisam aparecer juntas:

• Volume repetitivo. A mesma pergunta escrita de mil formas diferentes. Status de pedido, segunda via, prazo, disponibilidade, procedimento interno.
• Resposta que já existe em algum sistema. Se nem um humano conseguiria responder sem inventar, o agente também não vai.
• Erro barato ou detectável. Processo em que uma resposta errada é corrigida na conversa seguinte, e não vira prejuízo irreversível.

O padrão que mais aparece: atendimento pós-venda no WhatsApp, triagem de chamado interno, consulta a norma e procedimento, extração de dado de documento que hoje alguém digita à mão.

Como não começar

Os três erros que mais fazem projeto de agente morrer antes de entrar em produção:

• Escopo largo demais. "Um agente que atende tudo" leva seis meses e não entra no ar. Um agente que resolve o assunto mais repetido da sua fila entra em semanas e ganha o direito de crescer.
• Nenhuma métrica combinada antes. Sem saber a taxa de resolução sem humano de hoje, não há como afirmar que melhorou. A conversa vira opinião.
• Piloto que nunca vira operação. Demonstração impressiona a diretoria e morre porque ninguém definiu quem opera, quem revisa e quem responde quando quebra às três da manhã.

O que medir depois do go-live

Quatro números bastam para saber se o agente está ajudando:

• Taxa de resolução sem humano — a métrica principal, e a única que justifica o investimento.
• Motivo de transbordo — cada transferência para humano é um item da lista de melhoria do mês seguinte.
• Custo por conversa — consumo de modelo mais canal, para a conta não surpreender no fim do mês.
• Reclamação sobre a resposta — o sinal de que os limites estão frouxos em algum lugar.

Por onde começar de verdade

Antes de escolher plataforma ou modelo, faça o trabalho chato: pegue o histórico real do último mês de atendimento ou de chamados e separe o que é repetição resolvível do que exige julgamento humano. Esse recorte define o escopo, o ganho esperado e o tamanho do projeto — com número, não com estimativa de fornecedor.

Com isso em mãos, o primeiro agente costuma levar semanas, não meses. E, mais importante, ele entra em produção com um critério objetivo de sucesso combinado antes de a primeira linha de código existir.

Primeira decisão: API oficial ou não

Existem bibliotecas que conectam um número comum de WhatsApp a um sistema sem passar pela API oficial da Meta. Funcionam, são baratas e aparecem em muita proposta.

Também violam os termos de uso, e o risco é concreto: número banido sem aviso, sem recurso e sem histórico. Perder o número que a sua base inteira tem salvo é um prejuízo que nenhuma economia de mensalidade paga.

A WhatsApp Business API — a oficial, contratada via provedor — traz número verificado, múltiplos atendentes no mesmo número, histórico centralizado e previsibilidade. É o caminho para qualquer operação que dependa do canal.

Se a proposta que você recebeu não menciona a API oficial e o custo de conversa da Meta, ela está incompleta — não mais barata.

A arquitetura, em quatro camadas

Canal

A conexão com a API oficial, via provedor. Cuida de entrega, mídia, template de mensagem ativa e janela de atendimento de 24 horas.

Orquestrador

O cérebro: recebe a mensagem, entende a intenção, decide se responde direto, se consulta um sistema, se executa uma ação ou se transfere para humano. É aqui que vivem o prompt, as regras e os limites.

Conhecimento

O conteúdo oficial da empresa — catálogo, política de troca, tabela de preço, manual, FAQ — indexado para recuperação. É o que impede o agente de responder com o que o modelo "acha".

Integrações

ERP, CRM, plataforma de e-commerce, agenda. É a camada que transforma "vou verificar e retorno" em resposta pronta. Sem ela, o agente é um FAQ com aparência de conversa.

O que realmente dá para automatizar

Numa operação típica de varejo ou serviço, a fila é dominada por poucos assuntos:

• Status de pedido, prazo e código de rastreio.
• Troca, devolução e primeira etapa de garantia.
• Segunda via de boleto e nota, e confirmação de pagamento.
• Disponibilidade, preço de tabela e ficha técnica de produto.
• Agendamento, remarcação e confirmação.
• Qualificação de lead antes de passar para o vendedor.

Repare que quase tudo depende de consultar um sistema. É por isso que a integração — e não a escolha do modelo — decide o resultado do projeto.

Os erros que fazem o cliente pedir atendente na segunda mensagem

• Menu numerado disfarçado. Se a primeira mensagem do agente é "digite 1 para financeiro", nada mudou além do custo.
• Agente que não sabe quem está falando. Sem identificar o cliente pelo número e puxar o histórico, cada conversa começa do zero.
• Transbordo sem contexto. Passar para o humano e fazer o cliente repetir tudo é pior do que não ter automatizado.
• Assunto sensível solto na IA. Cancelamento, negociação de dívida, reclamação grave e qualquer coisa jurídica devem sair por regra fixa ou ir direto para gente.
• Nenhuma saída para humano. Precisa existir e ser óbvia. Prender o cliente num loop é o jeito mais rápido de queimar o canal.

Quanto custa, na real

Três linhas somam o custo de operação:

• Conversa da Meta. Cobrada por janela de atendimento, com preço diferente para conversa iniciada pela empresa e pelo cliente. Em volume alto, costuma ser o maior item da conta — maior que a IA.
• Consumo de modelo. Centavos por conversa quando o prompt é enxuto e o contexto é recuperado com critério; múltiplos disso quando se manda o manual inteiro a cada mensagem.
• Manutenção. A linha que some das propostas e aparece no terceiro mês. Base desatualizada e integração quebrada derrubam a taxa de resolução em semanas.

O caminho que funciona

1. Ler a fila real. Uma semana no histórico de conversas para separar repetição resolvível de julgamento humano. O escopo sai daí.
2. Integrar antes de conversar. Conectar os sistemas que guardam a resposta é o caminho crítico do projeto.
3. Piloto em número de teste. Com conversas reais do próprio time, ajustando tom, limites e transbordo antes de qualquer cliente ver.
4. Go-live por assunto. Um tema ou uma faixa de horário primeiro. Confirmada a taxa de resolução, abre o resto.
5. Revisão mensal. Cada conversa não resolvida vira melhoria de base, integração nova ou regra de negócio.

É devagar no começo e rápido depois — o inverso do projeto que promete atender tudo no primeiro dia e nunca sai do piloto.

Decisão 1: de onde vem o conhecimento

Essa é a bifurcação que mais gera desperdício em projeto de empresa.

RAG — recuperar trechos do seu acervo e entregá-los ao modelo junto com a pergunta — é o padrão para conhecimento que muda. A resposta se apoia em documento seu, dá para citar a fonte, e atualizar é reindexar um arquivo.

Fine-tuning ajusta a forma da saída: tom, formato, padrão de classificação. Ele não é o caminho para "ensinar os meus documentos ao modelo" — o conhecimento entra diluído nos pesos, sem fonte citável, e qualquer atualização exige treinar de novo.

A regra prática: conhecimento que muda vai para RAG; comportamento que se repete pode ir para fine-tuning. Na maioria dos casos, prompt bem escrito e RAG resolvem antes de o fine-tuning virar necessário.

Decisão 2: o que o modelo pode chamar

Um chatbot que só recupera texto responde sobre política e procedimento. Para responder sobre o seu pedido, ele precisa de ferramentas: funções que consultam o ERP, o CRM, a agenda, o sistema de estoque.

Cada ferramenta precisa de três coisas antes de existir: contrato de entrada e saída, regra de quem pode acioná-la, e log do que foi feito. Ferramenta de escrita — que altera algo no mundo real — pede ainda idempotência, para que um reprocesso não duplique lançamento.

Decisão 3: como a resposta é ancorada

O modelo gera a continuação mais provável do texto. Diante de uma pergunta cuja resposta não está no contexto, ele completa com o que soa plausível — com a mesma confiança de uma resposta correta.

A defesa é de sistema, não de modelo:

• Nenhum trecho recuperado acima do limite de similaridade? A resposta é "não encontrei", não texto livre.
• Valor, prazo e disponibilidade sempre vêm de consulta, nunca de geração.
• Toda resposta de base carrega a citação do documento e do trecho.
• Assunto sensível sai por resposta fixa ou vai para humano.

Não existe modelo que não alucine. Existe sistema em que a alucinação tem pouco espaço para acontecer e é detectada quando acontece.

Decisão 4: como você sabe que está bom

Esta é a etapa que quase todo protótipo pula e que quase todo sistema em produção precisa ter.

Monte um conjunto de perguntas com gabarito escrito pelo time que conhece o assunto — cinquenta já mudam a conversa, duzentas dão segurança. Ele roda a cada mudança de prompt, de modelo ou de índice, medindo acerto da resposta e acerto da citação.

Sem isso, toda alteração é aposta: melhora um caso, piora três, e ninguém percebe até o cliente reclamar.

Decisão 5: qual modelo, e por quanto tempo

A escolha do modelo deve ser configuração, não arquitetura. Coloque o modelo atrás de uma camada de abstração e a decisão vira reversível — importante porque preço, limite e qualidade mudam várias vezes por ano.

Vale também usar modelos diferentes por etapa: um modelo pequeno e barato classifica a intenção e extrai dado estruturado; o modelo maior entra só onde a redação importa. Em volume, essa separação corta uma fatia grande do custo sem mudar o que o usuário percebe.

Decisão 6: o que acontece depois do deploy

Sistema com LLM tem uma característica incômoda: pode piorar sem que nada no seu código mude. O fornecedor atualiza o modelo, o perfil das perguntas muda, o acervo cresce.

O mínimo de operação que um chatbot em produção precisa:

• Prompt versionado em repositório, com histórico e revisão — não colado numa tela de configuração.
• Log de entrada, saída e versão em toda chamada, para auditar decisão automatizada.
• Métrica de custo e latência por rota, com alerta.
• Conjunto de avaliação rodando antes de qualquer mudança ir para produção.
• Caminho de rollback que alguém já testou.

O erro estrutural mais comum

Começar pela ferramenta. A pergunta "qual plataforma de chatbot usar" chega antes de "qual pergunta da minha fila eu quero eliminar", e o projeto passa a ser moldado pelo que a plataforma faz — não pelo que a operação precisa.

Invertido, funciona melhor: escolha um assunto de alto volume, mapeie onde está a resposta, construa o caminho completo até o sistema de origem e só então decida o que comprar e o que construir. O escopo fica menor, entra em produção mais rápido, e o que vier depois já nasce em cima de algo que funciona.