Chatbot não é agente: o teste dos 3 turnos que separa brinquedo de produto

Você abre a demo do chatbot da empresa, faz uma pergunta genérica e recebe uma resposta linda. Markdown bem formatado. Tom amigável. Parece mágica.

Aí você faz a segunda pergunta. E a terceira.

E o castelo desaba.

Esse é o teste dos 3 turnos — três perguntas simples sobre um produto real que qualquer cliente faria sem pensar. Se o seu "agente" não passa, ele não é agente. É um chatbot empacotado num divzinho de chat com gradiente roxo.

E o problema não é o modelo. O problema é a camada que falta em volta dele.

TL;DR

• O que é: um teste de 3 turnos (preço hoje, reviews recentes, disponibilidade no CEP) que expõe a diferença entre chatbot cru e agente real.
• Stack/Modelos: qualquer LLM moderno (Claude, GPT, Gemini, Llama) — o teste vale para todos. O que muda é o que está em volta.
• Custo/Acesso: conceitual. Você consegue rodar em qualquer playground gratuito de LLM em 2 minutos para ver quebrar.
• Conceito-chave: agent harness — a infraestrutura que transforma um modelo em sistema confiável.

O contexto — chatbot, agente, e a confusão proposital do mercado

A indústria mistura os dois nomes de propósito. Vende chatbot como agente porque "agente" cobra mais caro. Mas a Anthropic, no guia oficial sobre construção de agentes, é cirúrgica:

"Workflows são sistemas onde LLMs e ferramentas são orquestrados por caminhos de código predefinidos. Agents são sistemas onde os LLMs dirigem dinamicamente seus próprios processos e uso de ferramentas, mantendo o controle sobre como cumprem a tarefa."

E reforça:

"Agents são tipicamente apenas LLMs usando ferramentas com base no feedback do ambiente, em loop."

Repare nas duas palavras-chave: ferramentas e feedback do ambiente.

Chatbot cru não tem nenhuma das duas. Ele tem o que o modelo memorizou do treino — e o treino acabou meses atrás. É exatamente o problema que cobri no post Seu LLM não sabe o preço de nada: conhecimento congelado, respondido com a confiança de quem acabou de checar. Pior cenário possível.

Agente, na definição da casa, é um LLM que chama ferramenta, observa resultado, decide o próximo passo, repete. Estado entre turnos. Ground truth do mundo real a cada iteração. Stop condition explícita.

Sem isso, é teatro.

O teste dos 3 turnos

Pegue qualquer chatbot que se diga "agente de compras", "assistente de e-commerce", "concierge de produto". Faça as três perguntas abaixo, na ordem, sobre um produto que existe de verdade no catálogo dele.

Turno 1 — "Quanto custa o [produto X] hoje?"

O chatbot cru tem duas saídas:

1. Inventa um preço. Plausível, redondo, errado. Cliente confia, fecha pedido na cabeça, depois descobre no checkout que o real é outro. Casos como o da Air Canada cobri aqui — chargeback, processo, manchete.
2. Foge: "não tenho acesso a preços em tempo real, consulte o site". OK, sincero. Mas então você acabou de me vender um chatbot que faz menos que o Ctrl+F da página do produto.

O agente faz outra coisa: chama uma tool get_product_price(sku), recebe {"price": 4299.00, "currency": "BRL", "checked_at": "2026-04-25T16:58:42-03:00"}, e responde com base nisso. Estado: o preço passa a fazer parte do contexto da conversa.

Turno 2 — "E os reviews? Tá bom mesmo?"

Aqui o chatbot cru cai num poço mais fundo. Ele vai gerar uma resposta no padrão "muitos usuários elogiam a bateria e a câmera, alguns reclamam do peso" — uma alucinação semanticamente perfeita, fundamentada em nenhum review real.

Veja só: ele não sabe quais reviews existem. Ele sabe como reviews soam. É outra coisa.

O agente chama fetch_reviews(sku, limit=50, since="2026-01-01"), recebe os reviews recentes, passa por um sumarizador com instrução explícita ("não inferir além do que está nos textos") e responde com citações verificáveis. Bônus: rejeita reviews falsos via trust layer (assunto pra outro post da série).

Turno 3 — "Chega no CEP 04567-000 em quanto tempo?"

Esse é o turno que mata 100% dos chatbots crus. Não tem como inventar prazo de frete sem conexão com transportadora. Modelo nenhum, por melhor que seja, sabe a malha logística da Total Express às 16h59 de uma sexta.

O agente chama check_shipping(sku, zip="04567-000"). Recebe {"available": true, "deadline_days": 3, "carrier": "TotalExpress", "cost": 24.90}. Responde com número e fonte.

E é aqui que a conversa muda de "demo bonita" para "produto que vende".

Três turnos. Três tool calls. Três pedaços de ground truth. Esse é o teste.

Por que o chatbot cru quebra (e o agente não)

A diferença entre os dois não é o modelo. É a camada em volta — o que a Anthropic, num outro artigo de engenharia, chama de agent harness:

"O Claude Agent SDK é um agent harness poderoso e de propósito geral, capaz de codar, assim como outras tarefas que exigem que o modelo use ferramentas para coletar contexto, planejar e executar."

Ou, na descrição mais técnica do Parallel Web Systems:

"Um agent harness é a infraestrutura completa que envolve um LLM para torná-lo um agente funcional — onde o modelo fornece a inteligência e o harness fornece mãos, olhos, memória e fronteiras de segurança."

O LLM é o cérebro. O harness é o resto do corpo.

Sem o resto do corpo, o cérebro só consegue falar sobre o problema. Nunca tocar nele.

Anatomia mínima de um harness que passa nos 3 turnos

Não é arquitetura de NASA. São cinco componentes que precisam existir.

1. Roteador de ferramentas (tool router)

Um catálogo de ferramentas com nome, descrição e schema JSON. O modelo vê esse catálogo no system prompt e decide qual chamar. Quando chama, o harness intercepta, executa a função real (HTTP, banco, fila) e devolve o resultado pro modelo.

tools = [
    {
        "name": "get_product_price",
        "description": "Retorna o preço atual de um SKU no catálogo. "
                       "Use sempre que o usuário perguntar valor.",
        "input_schema": {
            "type": "object",
            "properties": {"sku": {"type": "string"}},
            "required": ["sku"]
        }
    },
    # fetch_reviews, check_shipping, etc.
]

A tool mal descrita é o motivo nº1 de agente que ignora a tool e alucina mesmo com ela disponível. Volto nesse ponto em outro post da série.

2. Loop de raciocínio (ReAct)

O padrão clássico — descrito em quase todo harness sério hoje:

"O modelo recebe o estado atual, raciocina sobre o que fazer, executa uma ação via tool call, observa o resultado, e repete continuamente até atingir uma condição estrita de parada."

Pseudocódigo do loop:

def agent_loop(user_message, max_iterations=10):
    messages = [{"role": "user", "content": user_message}]
    for _ in range(max_iterations):
        response = llm.complete(messages, tools=tools)
        if response.stop_reason == "end_turn":
            return response.text
        if response.stop_reason == "tool_use":
            tool_result = execute_tool(response.tool_call)
            messages.append({"role": "assistant", "content": response})
            messages.append({"role": "tool", "content": tool_result})
    raise AgentBudgetExceeded("loop nao convergiu")

Sem max_iterations o agente entra em loop infinito quando uma tool falha. Com ele, você tem stop condition — o que a Anthropic recomenda explicitamente.

3. Estado entre turnos

A resposta do turno 1 (preço) precisa estar no contexto do turno 2 (reviews). Senão o usuário pergunta "vale o preço?" e o agente não sabe nem qual preço. Histórico de mensagens é a forma mais simples — para conversas longas, sumarização e memória vetorizada entram em cena.

4. Validação de I/O

Toda saída de tool passa por um validador antes de virar contexto. Se a API retornar null no preço, o harness não pode deixar o modelo "completar" o número. Tem que quebrar e seguir um caminho seguro: "não consegui consultar o preço agora, pode tentar de novo?".

5. Limites de segurança (guardrails)

Orçamento de tokens, orçamento de custo, lista de tools permitidas por contexto, sanitização de conteúdo externo (HTML raspado da web vem com prompt injection escondida — outro post da série). O harness é o ponto onde isso vive. Não no prompt do modelo.

Hands-on de 30 segundos: por que o teste falha sem harness

Quer ver com seus olhos? Abra o console do Claude, o ChatGPT, qualquer um. Sem ativar nenhuma tool nativa.

Pergunte:

Quanto custa hoje o iPhone 16 Pro 256GB no Mercado Livre?

Você vai receber uma das duas: faixa de preço inventada ou recusa honesta. Se vier número, abra o Mercado Livre e compare. Vai estar errado, ou estranhamente "redondo demais".

Agora ative a busca na web (ferramenta nativa) e refaça. A resposta muda de qualidade. Você acabou de ligar uma tool. O modelo não ficou mais inteligente — ele ganhou olhos.

É exatamente isso que um harness faz, só que para as ferramentas que fazem sentido pro seu produto: seu catálogo, seu ERP, sua transportadora, sua trust layer de reviews.

Limitações e armadilhas

Construir harness não é livre.

• Latência sobe. Cada tool call adiciona tempo. Um turno com 3 tool calls vira 3–5 segundos fácil. UX precisa cobrir com streaming, skeleton, ou resposta parcial.
• Custo sobe. Mais tokens entrando, mais tokens saindo, mais reasoning. Pré-cálculo de orçamento por sessão é obrigatório acima de qualquer escala.
• Modos de falha novos aparecem. A Anthropic mapeia quatro principais em harnesses longos: declaração prematura de vitória, degradação do ambiente, teste incompleto de feature, confusão de setup. Todos exigem instrumentação dedicada (logs, evals, observabilidade).
• Tool mal desenhada vira veneno. Descrição vaga, schema permissivo, retorno inconsistente — o modelo passa a ignorar a tool e voltar a alucinar. Engenharia de tool é metade do jogo.

Nenhum desses pontos invalida o harness. Eles dizem que harness é engenharia, não prompt.

CTA

Se você está construindo (ou herdou) um chatbot que se chama de agente, faça o teste dos 3 turnos hoje. Se ele quebrar — e vai — você ganhou um diagnóstico claro do que falta.

E se quer aprender a montar o harness completo (tool design, retrieval híbrido, reranking, evals, memória, trust layer e UI que converte) construindo um agente de ofertas do zero, é exatamente isso que estamos cobrindo no Clã Beer & Code nas próximas semanas. Discord ativo, código rodando, dúvida sendo tirada com gente que está no campo.

FAQ rápido

Posso "fingir" agente embrulhando um chatbot com if/else no backend?

Pode. Vai funcionar para 5 perguntas previstas. Quebra na sexta. A graça do agente é decidir dinamicamente qual ferramenta usar — if/else é workflow, não agente. A própria Anthropic separa os dois e diz: workflow é melhor quando a tarefa é previsível. Use o nome certo.

Qual modelo é "obrigatório" pra rodar harness sério?

Nenhum. Claude, GPT, Gemini, Llama — todos suportam tool use estruturado hoje. O modelo afeta qualidade do raciocínio e custo. O harness afeta se o produto funciona.

MCP resolve isso?

MCP é o protocolo padrão para expor tools de forma reutilizável. Resolve a parte de integração, não substitui o harness — o loop, o estado, a validação e os guardrails continuam sendo seu trabalho. MCP só padroniza a interface.

Quando o chatbot puro ainda faz sentido?

Quando a resposta certa cabe inteira no que o modelo já sabe e não muda com o tempo. FAQ de produto institucional, glossário, onboarding conceitual. Tudo que envolve dado vivo (preço, estoque, prazo, status de pedido) precisa de agente.

Conclusão

Chatbot e agente parecem a mesma coisa por fora. Por dentro, são dois animais diferentes. Um responde com texto. O outro age sobre o mundo, observa o resultado, e decide o próximo passo.

O teste dos 3 turnos é só o sintoma visível. A causa raiz é o harness — ou a ausência dele.

Os próximos posts da série vão abrir esse harness peça por peça: design de tools, retrieval híbrido, reranker, evals automatizadas, memória de usuário e a parte que ninguém mostra na demo (renderização que converte e segurança contra prompt injection vinda do site raspado).

Se chegou até aqui, você já entendeu o suficiente pra parar de chamar chatbot de agente. Agora é construir o agente de verdade.