Ir para o conteúdo

Blog

Playbook 2.0: Por que agentes de IA precisam de arquiteturas melhores, não de prompts maiores

A maioria dos agentes de IA não falha porque o modelo é fraco. Falha porque a arquitetura em volta do modelo é frágil demais.

Uma única chamada ao LLM pode parecer impressionante em uma demo, mas conversas reais com clientes exigem memória, regras de negócio, rastreabilidade, formatação por canal, avaliação e aprendizado contínuo. O Playbook 2.0, motor cognitivo do Zap2B, foi criado para lidar com essa realidade.

O sistema organiza cada interação em um pipeline de dez etapas e separa o fluxo síncrono de resposta do ciclo assíncrono de memória, avaliação e aprendizado. Este artigo explica essa arquitetura e conecta a proposta com pesquisas sobre agentes baseados em LLM, geração aumentada por recuperação, memória de longo prazo, gestão de contexto, uso de ferramentas, avaliação automatizada, reflexão e cache semântico.

Os artigos citados aqui não descrevem o Playbook 2.0 diretamente. Eles oferecem a base técnica para os problemas que a arquitetura foi desenhada para resolver.

1. Introdução

Quando começamos a trabalhar com automação conversacional para fluxos de WhatsApp e CRM, uma coisa ficou clara muito rápido: escrever bem não é o mesmo que operar bem uma conversa.

LLMs interpretam linguagem com facilidade, mas ambientes de negócio exigem mais. O agente precisa entender a mensagem atual, recuperar o histórico relevante, respeitar a persona da empresa, seguir regras de negócio, identificar a etapa correta da jornada, responder perguntas paralelas, acionar ferramentas quando necessário, formatar a resposta para o canal e guardar informações úteis para interações futuras.

Isso coloca o problema no campo dos agentes baseados em LLM, onde o modelo deixa de ser apenas um gerador de texto e passa a fazer parte de um sistema maior, com memória, planejamento, ação e avaliação (Wang et al., 2024).

O Playbook 2.0 foi desenhado como o motor cognitivo do Zap2B para resolver exatamente esse problema. Sua função é transformar mensagens recebidas do WhatsApp ou do CRM em respostas contextuais, rastreáveis e alinhadas ao playbook de negócio de cada cliente. Em vez de depender de um prompt e de uma única chamada ao modelo, a arquitetura divide a execução em dez etapas especializadas. Isso torna o sistema mais fácil de controlar, auditar e melhorar.

Este artigo explica essa arquitetura e a conecta com pesquisas sobre agentes LLM, geração aumentada por recuperação, memória persistente, gestão de contexto, avaliação automatizada e aprendizado contínuo.

2. Por que uma única chamada ao LLM não é suficiente

Uma primeira tentativa comum de automação conversacional é simples: receber a mensagem do usuário, concatenar histórico, persona, regras de negócio e instruções em um único prompt, chamar o modelo e devolver a resposta. Funciona em protótipos. Em produção, as limitações aparecem rápido.

O primeiro problema é o inchaço de contexto. À medida que o sistema adiciona histórico, regras, dados do cliente, instruções do playbook e exemplos, o prompt cresce e fica mais difícil de controlar. Pesquisas sobre contexto longo mostram que modelos de linguagem nem sempre usam bem toda a informação disponível em entradas extensas. Em Lost in the Middle, Liu et al. (2024) mostram que o desempenho pode cair quando a informação relevante está no meio de um contexto longo, mesmo em modelos projetados para janelas maiores. A lição é simples: contexto não é só contagem de tokens. É seleção, estrutura e posicionamento.

O segundo problema é a falta de memória operacional persistente. Em conversas comerciais reais, o agente precisa lembrar preferências, dúvidas não resolvidas, entidades citadas, respostas anteriores e decisões tomadas em turns passados. Trabalhos como MemoryBank mostram por que a memória de longo prazo importa para manter representações de usuário atualizadas e sustentar interações mais longas (Zhong et al., 2024). Surveys recentes sobre memória em agentes LLM apontam na mesma direção: memória é uma capacidade central, não um detalhe (Zhang et al., 2024).

O terceiro problema é a ausência de avaliação sistemática. Em muitos chatbots, tudo o que o modelo produz é tratado como resposta final. Isso é arriscado. A literatura sobre avaliação com LLMs mostra que modelos podem atuar como juízes quando há rubricas e critérios explícitos. O trabalho G-Eval, por exemplo, usa prompts estruturados e raciocínio guiado para avaliar saídas de geração textual (Liu et al., 2023). Zheng et al. (2023) também mostram que modelos fortes podem se aproximar de preferências humanas em algumas avaliações abertas, embora ainda tragam vieses e limitações de consistência.

Por isso, o Playbook 2.0 usa uma arquitetura em pipeline, em vez de confiar em um prompt único.

3. Fundamentos conceituais da arquitetura

O Playbook 2.0 conversa com cinco linhas principais da pesquisa em IA aplicada.

3.1 Agentes baseados em LLM

Essa é a direção atual da pesquisa em agentes LLM, na qual os agentes passam a ser descritos como sistemas com módulos de percepção, memória, planejamento, ação e avaliação (Wang et al., 2024). Nessa visão, um agente não é só um modelo que escreve texto. Ele é um sistema composto por partes distintas, e esse enquadramento sustenta a decisão de separar o Playbook 2.0 em etapas com responsabilidades diferentes.

3.2 Geração aumentada por recuperação

A geração aumentada por recuperação combina a memória paramétrica do modelo com memória externa, não paramétrica (Lewis et al., 2020). Essa ideia é central aqui porque o Playbook 2.0 não depende apenas do que o modelo já sabe. Ele recupera contexto, histórico, conhecimento do playbook e aprendizados persistidos antes de produzir uma resposta.

3.3 Memória de longo prazo e memória agentic

Em Generative Agents, Park et al. (2023) mostram que agentes mais coerentes podem ser construídos quando memória, reflexão e planejamento fazem parte da arquitetura. O MemGPT propõe uma abordagem parecida com sistemas operacionais para gerenciar memória e contornar limites da janela de contexto (Packer et al., 2023). Já o A-MEM avança para uma estrutura de memória mais dinâmica, com atributos, tags e relações entre registros (Xu et al., 2025). O ponto em comum é simples: memória precisa ser estruturada, recuperável e capaz de evoluir.

3.4 Uso de ferramentas e ações externas

O ReAct mostra que raciocínio e ação podem ser intercalados, permitindo que o modelo atualize planos e interaja com fontes externas (Yao et al., 2022). O Toolformer segue na mesma direção ao demonstrar que modelos podem aprender quando chamar APIs, quais argumentos passar e como usar os resultados na geração (Schick et al., 2023). Isso importa para agentes empresariais que precisam consultar bases, registrar dados em CRM, acionar webhooks ou executar tarefas operacionais.

3.5 Avaliação, feedback e aprendizado sem atualização dos pesos

O Reflexion propõe que agentes melhorem com feedback linguístico armazenado em memória, sem retreinar o modelo a cada ajuste (Shinn et al., 2023). O Self-Refine explora refinamento iterativo com auto-feedback durante a execução (Madaan et al., 2023). No Playbook 2.0, essas ideias aparecem nos Steps 9 e 10, onde as execuções são avaliadas e podem gerar aprendizados para uso futuro.

4. Playbook 2.0 em visão geral

O Playbook 2.0 é uma arquitetura de execução conversacional orientada por playbooks. Seu papel é receber uma mensagem do usuário, identificar o contexto da conversa, recuperar informações relevantes, determinar a intenção, compilar instruções de negócio em comportamento conversacional, gerar uma resposta, formatá-la para o canal e alimentar sistemas de memória, avaliação e aprendizado.

A arquitetura tem dez etapas. As sete primeiras fazem parte do fluxo síncrono, o caminho necessário para produzir a resposta para o usuário. As três últimas fazem parte do fluxo assíncrono, executado em segundo plano, responsável por persistência de memória, avaliação de qualidade e armazenamento de aprendizados.

Essa separação importa. O usuário precisa de uma resposta rápida. Já a avaliação e o aprendizado podem acontecer depois que a resposta volta para o CRM. Na prática, isso mantém a experiência responsiva sem abrir mão de observabilidade ou evolução contínua.

5. O pipeline síncrono: da mensagem à resposta

O fluxo síncrono começa quando o CRM ou o WhatsApp envia uma requisição ao motor do AgentOS. A requisição inclui dados como mensagem do usuário, identificadores de tenant, agente e playbook, além do estado da sessão.

Step 1. Request Adapter

O Request Adapter normaliza a entrada. Ele extrai contexto, persona do agente, timezone e os dados essenciais para executar o fluxo. Também prevê fallback, usando o histórico de diálogo quando o payload chega incompleto. Isso importa porque, em sistemas distribuídos, o estado enviado pelo cliente pode estar parcial ou desatualizado.

Depois disso, o auto-indexing garante que o playbook esteja indexado e disponível para busca. Essa camada é importante porque o motor precisa localizar as etapas, subetapas e instruções de negócio certas para a intenção atual.

Step 2. Context Prepare

O Context Prepare classifica a mensagem recebida e recupera o histórico recente da sessão. É isso que transforma uma mensagem isolada em algo interpretável dentro de uma conversa em andamento. Em diálogos reais, frases como “quanto custa?”, “e amanhã?” ou “pode ser com ele?” só fazem sentido quando as interações anteriores estão disponíveis.

Step 3. Learning Recall

O Learning Recall recupera aprendizados armazenados anteriormente. Conceitualmente, ele se aproxima da lógica de recuperação discutida por Lewis et al. (2020), embora aqui aplicada à memória operacional de agentes conversacionais. O objetivo é evitar depender apenas da mensagem atual ou apenas da memória paramétrica do modelo.

Step 4. Intent Analyst

O Intent Analyst identifica o que o usuário quer fazer e determina qual parte do playbook deve conduzir a resposta. Isso é especialmente importante em conversas não lineares. Um usuário pode estar em uma etapa de qualificação e perguntar sobre preço. Pode estar em agendamento e levantar uma objeção. Pode responder uma pergunta anterior e introduzir uma nova solicitação ao mesmo tempo. Separar análise de intenção e geração de resposta reduz a chance de respostas genéricas ou fora da etapa correta.

Step 5. Context Compiler

O Context Compiler transforma regras e instruções do playbook em comportamento conversacional executável. Essa etapa separa as regras de negócio da forma como o agente deve agir durante a interação. Isso conversa com a literatura mais ampla sobre agentes LLM, em que o modelo é um componente dentro de uma arquitetura maior, e não a única camada decisória (Wang et al., 2024).

Step 6. Main Responder

O Main Responder gera a resposta principal a partir do contexto compilado. Ele não atua sozinho. Recebe uma estrutura de execução já organizada pelas etapas anteriores. Esse desenho reduz a carga sobre o gerador, porque análise de intenção, recuperação de memória e compilação de instruções já foram tratadas antes da geração final.

Step 7. Response Formatter

O Response Formatter adapta a resposta ao canal. Em interfaces de WhatsApp e CRM, a forma de entrega faz parte da conversa. Uma resposta pode estar correta e ainda assim parecer ruim se for longa demais ou difícil de ler no celular. O formatador divide a resposta em mensagens curtas e legíveis, preservando o conteúdo, mas ajustando a entrega ao canal.

6. Context Isolation XML: gestão estruturada de contexto

Uma das ideias centrais do Playbook 2.0 é o Context Isolation XML. A função dele é organizar o contexto enviado ao modelo em seções dedicadas, como tarefa, persona, estado do playbook, memória da conversa, contexto aprendido, instruções, contexto secundário e contrato de saída.

A premissa é simples: contexto não é apenas volume de informação. Contexto também é seleção, ordem, hierarquia e contrato de execução. Pesquisas sobre contexto longo mostram que adicionar mais informação ao prompt não garante melhor desempenho, porque o modelo pode falhar ao recuperar a parte relevante dependendo da posição e da estrutura da entrada (Liu et al., 2024). Na prática, organizar o contexto de forma explícita é uma forma de reduzir ruído e tornar a execução mais previsível.

Isso também se alinha ao MemGPT, que trata gestão de contexto como um problema de memória parecido com o que sistemas operacionais resolvem. Packer et al. (2023) argumentam que LLMs são limitados por janelas de contexto e que sistemas externos podem administrar diferentes camadas de memória para ampliar a utilidade do modelo em conversas longas e análise de documentos. No Playbook 2.0, o Context Isolation XML deixa claro qual informação entra no contexto imediato de geração e por quê.

7. Sinapses: cache semântico de comportamento conversacional

O Playbook 2.0 usa sinapses como forma de reaproveitar compilações bem-sucedidas. Quando o Context Compiler encontra uma situação nova, ele pode usar um LLM para compilar instruções específicas para aquele estado da conversa. Se o resultado se mostra útil, ele pode ser armazenado e reutilizado em casos semanticamente parecidos.

Isso se aproxima da literatura de cache semântico, mas com uma diferença importante. Em um cache tradicional, o sistema tenta reaproveitar respostas anteriores com base na similaridade entre consultas. O SCALM, por exemplo, propõe uma arquitetura de cache para serviços de chat com LLM que usa relações semânticas para melhorar a taxa de acerto e reduzir custo (Li et al., 2024). O GPT Semantic Cache e o MeanCache também estudam formas de reduzir chamadas ao LLM e diminuir latência por meio de similaridade semântica e embeddings (Regmi and Pun, 2024; Gill et al., 2024).

No Playbook 2.0, uma sinapse não é apenas uma resposta cacheada. Ela representa uma compilação de comportamento conversacional. Isso significa que o sistema reaproveita uma forma operacional de agir em determinado estado, e não necessariamente a frase final. Isso importa porque a resposta continua se adaptando ao usuário e à conversa, enquanto a lógica de execução pode ser reaproveitada.

Essa ideia também se conecta às bibliotecas de habilidades em sistemas de agentes. O Voyager, por exemplo, usa uma biblioteca crescente de habilidades executáveis para armazenar e recuperar comportamentos aprendidos em um ambiente de aprendizado contínuo (Wang et al., 2023). O domínio é diferente, mas o princípio arquitetural é parecido: comportamentos úteis podem ser armazenados, recuperados e recombinados depois.

8. O pipeline assíncrono: memória, avaliação e aprendizado

Depois que a resposta volta para o CRM, o Playbook 2.0 executa três etapas assíncronas. Essa separação permite que o usuário receba a resposta sem esperar pelos processos de avaliação e escrita de memória.

Step 8. Context Memory

O Context Memory registra o estado da execução no histórico da conversa. Ele persiste itens como resumo, tags, entidades, variáveis atualizadas e outros sinais relevantes da interação. Isso se conecta às pesquisas sobre memória em agentes, nas quais registros persistentes tornam possível recuperar informações futuras e manter continuidade conversacional (Zhang et al., 2024; Zhong et al., 2024).

Step 9. Eval Judge V2

O Eval Judge V2 avalia a qualidade da execução. Ele compara o que deveria ter acontecido, com base nas instruções compiladas, com o que foi realmente produzido. A avaliação pode considerar critérios como aderência à intenção, execução do playbook, uso de ferramentas e respeito às restrições.

O uso de LLMs como juízes já foi explorado em trabalhos como G-Eval e LLM-as-a-Judge. Liu et al. (2023) propõem avaliação estruturada por modelo de linguagem, com formulário e critérios explícitos. Zheng et al. (2023) mostram que modelos fortes podem se aproximar de preferências humanas em avaliações abertas, embora também exponham vieses como preferência por respostas mais longas, efeito de posição e limitações de raciocínio.

Step 10. Learning Writer

O Learning Writer armazena aprendizados de longo prazo em stores especializadas. Isso fecha o ciclo de aprendizado: uma interação gera uma resposta, a resposta é avaliada e a avaliação pode produzir conhecimento reutilizável.

Isso se aproxima da lógica do Reflexion, em que agentes aprendem com feedback linguístico armazenado em memória, em vez de atualizar diretamente os pesos do modelo (Shinn et al., 2023). Também se relaciona ao Self-Refine, que usa feedback e refinamento iterativo como mecanismo de melhoria em runtime (Madaan et al., 2023).

9. Learning stores como memória operacional especializada

O Playbook 2.0 organiza os aprendizados em stores diferentes, como contexto de sessão, perfil do usuário, memória do usuário, memória de entidades, conhecimento aprendido e logs de decisão. Essa separação existe porque nem toda memória tem a mesma finalidade ou o mesmo grau de confiança.

Memórias de sessão ajudam na continuidade imediata. O perfil do usuário orienta personalização. A memória de entidades guarda fatos sobre empresas, pessoas, serviços ou objetos citados na conversa. Logs de decisão aumentam a rastreabilidade. Já conhecimentos aprendidos podem capturar padrões recorrentes, mas precisam de mais controle antes de serem tratados como regra ativa.

Essa organização tem paralelo em pesquisas recentes sobre memória agentic. O A-MEM propõe um sistema de memória para agentes LLM que organiza registros por meio de descrições contextuais, palavras-chave, tags e conexões dinâmicas entre entradas (Xu et al., 2025). A mensagem principal é clara: memória deve ser tratada como uma estrutura em evolução, não como um despejo cronológico de mensagens.

A curadoria humana continua necessária para certos aprendizados. Mesmo quando a avaliação automatizada gera sinais úteis, a literatura sobre LLM-as-a-Judge alerta para limitações e vieses dos modelos avaliadores (Zheng et al., 2023). Por isso, aprendizados que alteram o comportamento do agente devem ser armazenados com níveis de confiança, status e, quando necessário, aprovação humana.

10. Separação de responsabilidades: regra de negócio, persona, execução e entrega

Uma das contribuições mais práticas do Playbook 2.0 está na separação entre o que o negócio define e o que o sistema executa.

O responsável pelo playbook define regras de negócio, como valor de consulta, políticas de atendimento, perguntas de qualificação ou instruções de agendamento. O motor cognitivo transforma essas regras em comportamento conversacional.

Isso evita que times não técnicos precisem escrever prompts complexos. Em vez disso, o sistema assume a responsabilidade de compilar contexto, respeitar a persona, produzir a resposta e formatá-la para o canal. O padrão é coerente com a literatura sobre agentes LLM em geral, em que diferentes módulos contribuem para percepção, decisão, ação e avaliação (Wang et al., 2024).

Isso também reduz risco operacional. Se o mesmo LLM tivesse de identificar intenção, escolher a etapa do playbook, interpretar regras, gerar resposta, formatar a mensagem e avaliar a qualidade ao mesmo tempo, o sistema seria muito mais difícil de auditar. Ao dividir responsabilidades, o Playbook 2.0 cria pontos de observabilidade ao longo de todo o pipeline.

11. Discussão: o que o Playbook 2.0 entrega

A principal contribuição do Playbook 2.0 não é um novo modelo de linguagem. É uma arquitetura prática que combina ideias conhecidas da pesquisa em um sistema funcional para agentes conversacionais empresariais.

A proposta reúne recuperação de contexto, memória persistente, roteamento de intenção, compilação de instruções, geração assistida por LLM, formatação por canal, avaliação automatizada e aprendizado contínuo.

Isso resolve um problema muito concreto: empresas precisam de agentes que sigam regras, mantenham coerência entre interações, sejam auditáveis e melhorem com o tempo. Em atendimento e vendas, uma resposta não pode ser apenas fluente. Ela precisa estar correta, sair no momento certo da jornada, respeitar a persona e caber no canal.

A arquitetura também mostra uma mudança importante no uso de LLMs. O modelo deixa de ser o produto inteiro e passa a ser um componente dentro de um sistema cognitivo maior. Isso está em linha com pesquisas sobre agentes, memória, uso de ferramentas e avaliação automatizada. O desempenho do agente passa a depender não só do modelo, mas da qualidade da arquitetura ao redor dele.

12. Limitações e cuidados

Mesmo com potencial claro, a arquitetura exige cuidados. Avaliações com LLM não devem ser tratadas como verdade absoluta. Estudos sobre LLM-as-a-Judge mostram resultados promissores, mas também destacam vieses e problemas de consistência (Zheng et al., 2023). Rubricas, logs, validação humana e critérios claros para ativação de aprendizados continuam importantes.

Outro ponto crítico é a qualidade da memória. Memórias incorretas, desatualizadas ou mal classificadas podem degradar respostas futuras. Pesquisas sobre memória em agentes LLM mostram que armazenamento, recuperação, atualização e esquecimento são desafios centrais em interações prolongadas (Zhang et al., 2024; Zhong et al., 2024). Isso significa que os stores de memória precisam de políticas claras de escrita, recuperação, expiração e curadoria.

Sinapses e cache semântico também exigem cuidado. Embora ajudem a reduzir custo e latência, falsos positivos podem reutilizar comportamento no contexto errado. O MeanCache, por exemplo, destaca a diferença entre similaridade semântica e equivalência operacional (Gill et al., 2024). No Playbook 2.0, isso reforça a necessidade de limiares, avaliação posterior e possibilidade de desativar sinapses de baixa performance.

13. Conclusão

O Playbook 2.0 é uma arquitetura aplicada para agentes conversacionais orientados por playbooks em ambientes de negócio. Sua estrutura em dez etapas foi pensada para resolver limites comuns de chatbots baseados em uma única chamada ao LLM: inchaço de contexto, perda de memória, baixa rastreabilidade, falta de avaliação e dificuldade de aprendizado contínuo.

Ao separar o fluxo síncrono de resposta do fluxo assíncrono de memória e aprendizado, a arquitetura preserva a experiência do usuário sem abrir mão de observabilidade e evolução. Ao usar o Context Isolation XML, ela organiza o contexto de forma explícita e hierárquica. Ao empregar sinapses, reaproveita compilações de comportamento já validadas. Ao incorporar o Eval Judge e o Learning Writer, transforma cada interação em oportunidade de avaliação e melhoria.

A literatura científica atual não descreve o Playbook 2.0 como um produto específico, mas oferece uma base sólida para seus principais componentes. Pesquisas sobre agentes LLM, RAG, memória, gestão de contexto, uso de ferramentas, avaliação por LLM, reflexão e cache semântico apontam para a mesma direção: sistemas conversacionais robustos dependem de arquitetura, não apenas de modelos maiores.

Nesse sentido, o Playbook 2.0 pode ser entendido como uma camada cognitiva entre o CRM, os playbooks de negócio e os modelos de linguagem. O objetivo é transformar mensagens em respostas inteligentes, contextuais e capazes de melhorar com o uso real.

Referências

GILL, Waris et al. MeanCache: User-Centric Semantic Cache for Large Language Model Based Web Services. arXiv, 2024.

LEWIS, Patrick et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems, 2020.

LI, Jiaxing et al. SCALM: Towards Semantic Caching for Automated Chat Services with Large Language Models. arXiv, 2024.

LIU, Nelson F. et al. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 2024.

LIU, Yang et al. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. Proceedings of EMNLP 2023, 2023.

MADAAN, Aman et al. Self-Refine: Iterative Refinement with Self-Feedback. arXiv, 2023.

PACKER, Charles et al. MemGPT: Towards LLMs as Operating Systems. arXiv, 2023.

PARK, Joon Sung et al. Generative Agents: Interactive Simulacra of Human Behavior. Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology, 2023.

REGMI, Sajal; PUN, Chetan Phakami. GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching. arXiv, 2024.

SCHICK, Timo et al. Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv, 2023.

SHINN, Noah et al. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv, 2023.

WANG, Guanzhi et al. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv, 2023.

WANG, Lei et al. A Survey on Large Language Model based Autonomous Agents. Frontiers of Computer Science, 2024.

XU, Wujiang et al. A-MEM: Agentic Memory for LLM Agents. arXiv, 2025.

YAO, Shunyu et al. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv, 2022.

ZHANG, Zeyu et al. A Survey on the Memory Mechanism of Large Language Model based Agents. arXiv, 2024.

ZHENG, Lianmin et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv, 2023.

Eval Judge: por que agentes de IA precisam ser avaliados como produtos, não como respostas

Um agente de IA não deve ser avaliado apenas pela fluidez da resposta. Em produção, o que importa é saber se ele roteou corretamente a intenção, seguiu as instruções certas, usou ferramentas no momento adequado e respeitou os limites de escopo e identidade.

No caso do Playbook 2.0, por exemplo, o agente pode acertar o roteamento para a etapa inicial, mas ainda falhar se não executar a saudação institucional pela ferramenta obrigatória. O Eval Judge existe para isso: transformar cada execução em um sinal objetivo de qualidade.

A maioria dos times começa tentando melhorar agentes de IA pelo prompt. Os melhores times começam medindo comportamento.

Este artigo explica o Eval Judge, o módulo de avaliação do Playbook 2.0, e mostra por que ele é necessário para agentes em produção. Também conecta a proposta com pesquisas sobre LLM-as-a-Judge, avaliação fine-grained e aprendizado contínuo.

Os artigos citados aqui não descrevem o Eval Judge diretamente. Eles oferecem a base técnica para os problemas que o sistema foi desenhado para resolver.

1. O problema de confiar só na resposta

Em uma demonstração, um agente de IA parece bom quando produz uma resposta fluida, coerente e educada. O problema é que produção não é demo.

Em produção, o agente opera em um ambiente com regras de negócio, identidade de marca, protocolos de etapa, ferramentas obrigatórias e canais com restrições de formato. Responder bem não é o suficiente. É preciso responder certo — na etapa certa, com a ferramenta certa, dentro do escopo certo.

Considere o caso de um agente configurado para atendimento comercial no WhatsApp. Ele recebe uma saudação como "Boa noite". O roteamento funciona: o sistema identifica corretamente a intenção inicial e direciona para a etapa de abertura. O agente responde "Como podemos te ajudar hoje?" de forma educada e contextual. Tudo parece correto.

Mas a execução foi incompleta. O playbook determinava que, na abertura, o agente deveria usar uma ferramenta obrigatória de saudação institucional — e ele não usou. A resposta estava correta no conteúdo, mas falhou no protocolo operacional.

Esse caso ilustra um ponto central deste artigo: um agente pode responder certo e ainda assim executar errado.

Sem um sistema de avaliação estruturada, esse tipo de falha passa despercebido. O time vê uma resposta fluida e assume que está tudo bem. O diagnóstico só aparece quando um cliente reclama ou quando o funil de vendas começa a cair sem explicação.

É por isso que, em produção, a pergunta certa não é "respondeu bem?", mas "fez o que devia, no momento certo, do jeito certo?".

2. Demo versus produção: por que a avaliação é ignorada

Muitos times de produto ignoram a avaliação sistemática porque o problema não é visível no curto prazo. Durante o desenvolvimento, o agente é testado com cenários controlados. A resposta parece boa. O teste passa. O time avança.

Em produção, porém, o agente enfrenta:

  • Variabilidade de entrada: usuários reais escrevem de formas imprevisíveis.
  • Mudanças no playbook: regras de negócio mudam e nem sempre são refletidas no comportamento do agente a tempo.
  • Deriva de comportamento: atualizações no modelo de linguagem podem alterar respostas sem aviso.
  • Ferramentas instáveis: APIs externas falham, mudam de contrato ou ficam lentas.
  • Canais assimétricos: o que funciona no CMS pode não funcionar no WhatsApp.

Nenhum desses problemas é detectado por um teste unitário ou por uma inspeção manual de algumas respostas. Eles só aparecem quando cada execução é avaliada de forma sistemática contra as instruções que o agente recebeu.

A literatura sobre LLM-as-a-Judge confirma que a avaliação automatizada é viável, mas exige rubricas claras e mitigação de vieses. Zheng et al. (2023) mostram que modelos fortes podem se aproximar de preferências humanas em avaliações abertas, mas também expõem problemas como position bias, verbosity bias e self-enhancement bias. Gu et al. (2025) propõem um framework de confiabilidade que combina consistência, mitigação de viés e adaptação a cenários diversos — exatamente o que um judge operacional precisa considerar.

O Eval Judge foi desenhado a partir dessas premissas. Ele não tenta substituir o julgamento humano, mas criar uma camada sistemática de avaliação que transforme cada execução em um dado objetivo.

3. O que o Eval Judge realmente avalia

O Eval Judge tem um escopo deliberadamente restrito: ele avalia uma execução isolada do agente contra as instruções compiladas que o agente recebeu para aquela interação.

Isso é diferente de avaliar o diálogo inteiro ou a satisfação do usuário. O judge não pergunta "o usuário ficou satisfeito?". Ele pergunta "o agente fez o que deveria fazer nesta execução?".

Essa restrição de escopo é intencional e tem implicações práticas importantes:

  • Foco operacional: a avaliação mede aderência a instruções, não qualidade percebida. Isso torna o resultado mais objetivo e acionável.
  • Granularidade: cada execução gera um score individual. Se um agente erra uma ferramenta em uma etapa, o judge detecta, independentemente de o restante do diálogo estar correto.
  • Comparabilidade: como o judge segue a mesma rubrica para todas as execuções do mesmo playbook, os scores são comparáveis entre sessões e ao longo do tempo.

O processo é assíncrono e fire-and-forget. Isso significa que o judge é executado em segundo plano, depois que a resposta já foi entregue ao usuário. A avaliação não bloqueia o fluxo síncrono de resposta. O usuário recebe a resposta rapidamente, e a avaliação acontece depois, alimentando métricas, logs e oportunidades de aprendizado.

Na prática, a execução do Eval Judge consome cerca de 5,2 segundos de runtime e utiliza aproximadamente 5.765 tokens de entrada e 557 tokens de saída por avaliação — um custo operacional baixo comparado ao valor do diagnóstico gerado.

4. Os quatro critérios da rubrica

O Eval Judge organiza a avaliação em quatro critérios fixos. Cada critério recebe um score individual de 0 a 10, além de um campo de evidência e uma ação sugerida.

4.1 Intent Analysis (Análise de Intenção)

O primeiro critério verifica se o agente identificou corretamente a intenção do usuário. Ele responde: "O agente entendeu o que o usuário queria fazer?"

Esse critério não avalia o conteúdo da resposta. Ele avalia se o roteamento de intenção estava correto. Se o usuário pergunta sobre preço e o agente roteia para uma etapa de cadastro, a análise de intenção falha, mesmo que a resposta individual seja educada.

Na prática, esse critério depende do classificador de intenção do Playbook 2.0 (Step 4 — Intent Analyst) e da confiança do roteamento. Scores baixos aqui indicam que o agente não entendeu o que o usuário queria — um problema diferente de não saber responder.

4.2 Execution (Execução)

O segundo critério verifica se o agente seguiu as instruções do playbook para aquela etapa. Ele responde: "O agente executou o protocolo correto para esta intenção?"

A execução inclui aspectos como cumprimento do roteiro da etapa, respeito à ordem das subetapas, conclusão de ações obrigatórias e alinhamento com a persona configurada. Uma resposta pode ser fluente e ainda assim falhar na execução se ignorar uma instrução do playbook.

4.3 Tools (Uso de Ferramentas)

O terceiro critério verifica se o agente usou as ferramentas certas no momento certo. Ele responde: "O agente acionou as ferramentas obrigatórias e não acionou ferramentas proibidas?"

Esse critério é especialmente importante em fluxos operacionais. Um agente de vendas pode precisar consultar o estoque, registrar um lead no CRM ou acionar um webhook de agendamento. Ferramentas obrigatórias que não são chamadas representam falha operacional, assim como ferramentas chamadas no contexto errado.

4.4 Guardrails (Limites de Escopo)

O quarto critério verifica se o agente respeitou os limites de escopo, identidade e segurança. Ele responde: "O agente se manteve dentro dos limites definidos?"

Guardrails incluem não se passar por humano, não inventar informações, não executar ações fora do escopo autorizado, não compartilhar dados sensíveis e não fazer promessas que o sistema não pode cumprir. Esse critério é o mais sensível e, na prática, costuma ter o threshold mais rigoroso.

4.5 Score composto e ação sugerida

Cada critério gera três saídas:

  • Score: valor numérico de 0 a 10.
  • Evidence: explicação textual do que foi observado, justificando o score.
  • Suggested Action: recomendação operacional, como "revisar ferramenta obrigatória", "atualizar playbook" ou "monitorar execução".

O score geral não é uma média simples. Ele pode ser ponderado por critério, e o threshold de aprovação é configurável por playbook. Um resultado abaixo do threshold gera um alerta e, em casos de falha recorrente, pode disparar a criação de um learning candidate.

5. O caso real: quando a execução falha apesar da resposta correta

O exemplo de abertura deste artigo merece ser examinado em detalhes porque ele revela o valor real do Eval Judge.

Cenário: Um agente configurado para atendimento comercial recebe a mensagem "Boa noite". O sistema identifica a intenção como IDENTIFICAR_INTENCAO_INICIAL com confiança de 0,95. A sinapse encontrada é IDENTIFICAR_INTENCAO_INICIAL_OPENING. O agente responde "Como podemos te ajudar hoje?".

Avaliação do Eval Judge:

Critério Score Análise
Intent Analysis 10 A intenção foi corretamente identificada
Execution 5 A saudação foi verbal, mas não passou pela ferramenta obrigatória
Tools 1 Nenhuma tool foi chamada, contrariando o protocolo
Guardrails 10 A resposta respeitou escopo e identidade

Resultado: Score geral 6,5 (threshold 7,0). Outcome: partial (alerta).

Diagnóstico: O agente entendeu a intenção. Acertou a persona. Acertou o tom. Mas falhou na execução operacional porque ignorou a obrigatoriedade da ferramenta de saudação institucional.

Learning candidate gerado: Reforçar a obrigatoriedade de uso da ferramenta de saudação em aberturas de duas etapas, com validação antes da entrega da resposta.

Esse caso mostra algo que a maioria dos sistemas de avaliação ignora: o problema não foi "entender o que fazer", mas "cumprir o protocolo do playbook".

Em um sistema sem Eval Judge, essa execução passaria despercebida. A resposta é educada. O usuário não reclamou. O time não tem evidência de que algo errado aconteceu. Mas o lead não foi registrado pela ferramenta obrigatória. A informação foi perdida. O funil silenciosamente deixa de funcionar.

O valor do Eval Judge aqui não é gerar uma nota. É separar claramente:

  • Roteamento certo (intent analysis = 10)
  • Execução incompleta (execution = 5)
  • Falta de ferramenta obrigatória (tools = 1)
  • Guardrails preservados (guardrails = 10)

Isso mostra maturidade de produto. O time deixa de tratar tudo como "resposta ruim" e passa a diagnosticar o tipo exato de falha.

6. Como a avaliação alimenta melhoria contínua

O Eval Judge não existe isoladamente. Ele é parte do ciclo assíncrono do Playbook 2.0, junto com o Context Memory e o Learning Writer.

O fluxo é:

  1. O agente executa uma interação e produz uma resposta.
  2. A resposta é entregue ao usuário (fluxo síncrono).
  3. Em paralelo, o Eval Judge avalia a execução contra as instruções compiladas.
  4. Se o score fica abaixo do threshold, o resultado é registrado com diagnóstico.
  5. Se há falha recorrente no mesmo padrão, o sistema gera um learning candidate.
  6. O learning candidate é armazenado em uma learning store especializada.
  7. Em execuções futuras, o Learning Recall (Step 3) recupera aprendizados relevantes e ajusta o comportamento do agente.

Esse ciclo se alinha com pesquisas sobre aprendizado contínuo em agentes. O Reflexion propõe que agentes melhorem com feedback linguístico armazenado em memória, sem retreinar o modelo a cada ajuste (Shinn et al., 2023). A diferença no Eval Judge é que o feedback não é auto-gerado pelo agente, mas produzido por um judge dedicado, com uma rubrica fixa e explícita.

O Self-Refine explora refinamento iterativo com auto-feedback durante a execução (Madaan et al., 2023). No Eval Judge, o refinamento acontece entre execuções, não durante — o que é mais realista para ambientes de produção onde latência é crítica.

A separação entre execução e avaliação também permite que diferentes pessoas participem do ciclo. O time de produto pode revisar learning candidates e aprovar mudanças no playbook. O time de engenharia pode ajustar rubricas e thresholds. O time de operações pode monitorar scores ao longo do tempo.

Isso conversa com o framework de confiabilidade de Gu et al. (2025), que defende que avaliação automatizada precisa vir acompanhada de governança e intervenção humana quando necessário.

7. Score com significado operacional

Um score de avaliação só tem valor se ele orienta uma decisão. O Eval Judge foi desenhado com essa premissa.

O score geral e os scores por critério alimentam diferentes tipos de decisão:

  • Operacional imediato: scores baixos em ferramentas ou execução podem gerar alertas em tempo real para o time de operações.
  • Tático (aprendizado): padrões de falha recorrentes geram learning candidates que alteram o comportamento futuro do agente.
  • Estratégico (produto): a distribuição de scores ao longo do tempo mostra se o sistema está melhorando, estabilizando ou degradando.

Sem um judge, toda melhora vira opinião. O time ajusta o prompt, testa com alguns exemplos e decide se ficou melhor com base em impressão subjetiva. Com o Eval Judge, o time tem uma base objetiva para comparar versões, testar hipóteses e decidir se uma mudança realmente melhorou a execução.

Isso está alinhado com a abordagem de score rubrics customizados proposta pelo PROMETHEUS (Kim et al., 2024). Os autores mostram que rubricas explícitas e fine-grained produzem avaliações mais alinhadas com juízes humanos do que preferências genéricas. O Eval Judge aplica esse princípio em escala operacional, com uma rubrica fixa de quatro critérios que cobre os aspectos mais críticos da execução de agentes conversacionais.

O trabalho de Saha et al. (2025) no EvalPlanner também reforça a importância de separar o planejamento da avaliação da execução da avaliação. No Eval Judge, essa separação aparece na estrutura do output: primeiro o plano de avaliação (rubrica), depois a execução (scores e evidências), depois o veredito final (ação sugerida).

8. Limites e cuidados

O Eval Judge não é verdade absoluta. É uma camada de avaliação automatizada que precisa de governança e calibração contínua.

Viés de judge. Estudos sobre LLM-as-a-Judge identificam múltiplos vieses que afetam a confiabilidade das avaliações. Zheng et al. (2023) documentam position bias (preferência pela primeira ou última resposta), verbosity bias (preferência por respostas mais longas) e self-enhancement bias (preferência por textos gerados pelo mesmo modelo). Zhu et al. (2025) adicionam knowledge bias e format bias no contexto de fine-tuning de judges.

O Eval Judge mitiga alguns desses vieses pelo design: como avalia uma única execução contra instruções fixas, não há posição de resposta para influenciar o resultado. A rubrica explícita reduz o espaço para preferências arbitrárias. Mesmo assim, o viés do modelo subjacente ao judge não é eliminado — apenas atenuado.

Rubrica não cobre tudo. Quatro critérios não capturam a complexidade total de uma interação conversacional. Aspectos como tom emocional, adequação cultural e criatividade ficam de fora. O Eval Judge cobre o que pode ser verificado contra instruções compiladas. O restante permanece como responsabilidade do design do playbook e da supervisão humana.

Threshold arbitrário. O threshold de 7,0 usado no exemplo é configurável, mas ainda assim arbitrário. Um score 6,5 pode ser aceitável em alguns contextos e crítico em outros. A definição de thresholds por playbook e por critério é uma decisão de produto que precisa ser revisada regularmente.

Custo de avaliação. Embora o custo por avaliação seja baixo (cerca de 5,2 segundos e 6.300 tokens), ele se acumula em escala. Para milhares de execuções por dia, o custo operacional do judge precisa ser monitorado e otimizado. Técnicas como amostragem seletiva (avaliar apenas execuções com baixa confiança) podem reduzir o custo sem perder cobertura.

Aprendizado requer curadoria. Learning candidates gerados automaticamente precisam de revisão antes de alterar o comportamento do agente. A literatura sobre LLM-as-a-Judge recomenda validação humana periódica para calibrar e corrigir desvios (Gu et al., 2025). No Eval Judge, isso é tratado por níveis de confiança, status de aprovação e logs de decisão.

Whitehouse et al. (2025) mostram que é possível treinar judges com RL (GRPO) para desenvolver estratégias sistemáticas de avaliação, incluindo geração dinâmica de critérios e autocorreção iterativa. Essa é uma direção futura promissora para o Eval Judge, mas a versão atual prioriza simplicidade, previsibilidade e baixo custo operacional.

9. Conclusão

O Eval Judge não resolve todos os problemas de avaliação de agentes de IA. Ele resolve o problema mais imediato: criar uma camada sistemática de avaliação que transforme cada execução em um sinal objetivo de qualidade.

A proposta é simples: antes de otimizar um agente, é preciso medir se ele fez o que devia. E medir não significa ler algumas respostas e dar um palpite. Significa comparar cada execução contra instruções compiladas, usando critérios explícitos, gerando scores, evidências e ações sugeridas.

O que diferencia o Eval Judge de abordagens genéricas é o escopo restrito (uma execução, não o diálogo inteiro), a rubrica fixa de quatro critérios, a execução assíncrona e a conexão direta com o ciclo de aprendizado do Playbook 2.0.

Em produtos que usam IA conversacional em produção, a pergunta não é "o modelo é bom?". A pergunta é "cada execução está correta?". O Eval Judge foi construído para responder a segunda pergunta — e, a partir dela, melhorar a primeira.

A literatura científica atual oferece base sólida para essa abordagem. Pesquisas sobre LLM-as-a-Judge, score rubrics, separação entre planejamento e execução de avaliação, e aprendizado por reforço para judges apontam na mesma direção: avaliação sistemática não é um luxo — é um requisito de produção.

Se você quer agentes melhores, comece pelo que quase ninguém mede: a qualidade de cada execução.

Referências

GU, Jiawei et al. A Survey on LLM-as-a-Judge. arXiv:2411.15594v6, 2025.

KIM, Seungone et al. PROMETHEUS: Inducing Fine-Grained Evaluation Capability in Language Models. arXiv:2310.08491v2, 2024.

LIU, Yang et al. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. Proceedings of EMNLP 2023, 2023.

MADAAN, Aman et al. Self-Refine: Iterative Refinement with Self-Feedback. arXiv:2303.17651, 2023.

SAHA, Swarnadeep et al. Learning to Plan & Reason for Evaluation with Thinking-LLM-as-a-Judge. arXiv:2501.18099v2, 2025.

SHINN, Noah et al. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366, 2023.

WANG, Lei et al. A Survey on Large Language Model based Autonomous Agents. Frontiers of Computer Science, 2024.

WHITEHOUSE, Chen et al. J1: Incentivizing Thinking in LLM-as-a-Judge via Reinforcement Learning. arXiv:2505.10320v3, 2025.

ZHENG, Lianmin et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. arXiv:2306.05685v4, 2023.

ZHU, Liang et al. JudgeLM: Fine-Tuned Large Language Models Are Scalable Judges. ICLR 2025. arXiv:2310.17631v2, 2025.

Playbooks Agênticos: a metodologia que transforma processos complexos em operações estruturadas de IA

Processos reais de atendimento e operação não falham por falta de conversa. Falham por falta de estrutura para lidar com regras, exceções, integrações e continuidade operacional.

Essa constatação está na origem da metodologia de playbooks agênticos do Zap2B. Ela não nasceu de uma teoria, mas da observação de um padrão recorrente: empresas adotam agentes de IA, os agentes respondem bem em interações simples, mas quando o processo exige sequência lógica, manutenção de contexto e execução orientada a objetivo, a operação se torna frágil.

O problema não é o modelo. É a falta de uma estrutura operacional que transforme intenção em execução confiável.

Este artigo apresenta a metodologia que criamos para resolver esse problema. Explica o conceito de playbooks agênticos, detalha os quatro tipos de fluxo que organizam a operação e mostra, por meio de um caso real de uso, como essa estrutura sustenta processos complexos com previsibilidade, controle e escala.

1. O problema real: por que prompts não bastam

Grande parte das soluções de IA conversacional disponíveis hoje compartilha uma mesma arquitetura simplificada: um prompt bem escrito, algumas instruções de persona, uma chamada ao modelo e uma resposta devolvida ao usuário.

Isso funciona para interações pontuais. Um cliente pergunta o horário de funcionamento, o agente responde. Um visitante pede informações sobre um produto, o agente entrega. São cenários de pergunta e resposta, sem estado, sem sequência, sem dependência entre etapas.

O problema surge quando o processo é complexo.

Um processo complexo de atendimento não é uma lista de perguntas que o agente precisa responder. É uma sequência lógica de etapas com dependência entre si, onde cada passo depende do resultado do anterior, onde existem regras de negócio que precisam ser respeitadas, onde o contexto precisa ser mantido mesmo quando o usuário faz perguntas fora da sequência, onde exceções precisam ser tratadas sem interromper o fluxo, onde ferramentas externas precisam ser acionadas no momento certo, onde a equipe humana precisa ser envolvida sem ruptura da experiência.

Nenhum prompt, por melhor que seja, sustenta sozinho esse nível de complexidade operacional.

A literatura sobre agentes baseados em LLM aponta na mesma direção: agentes não são apenas geradores de texto. Eles são sistemas compostos por módulos de percepção, memória, planejamento, ação e avaliação (Wang et al., 2024). Um prompt pode iniciar uma conversa, mas não pode substituir uma arquitetura operacional.

2. O limite das abordagens atuais

Antes de chegar à metodologia de playbooks, é importante reconhecer por que as abordagens mais comuns do mercado não resolvem o problema.

Prompt engineering isolado. Muitas equipes tentam resolver a complexidade operacional aumentando o prompt. Adicionam regras, exemplos, restrições e histórico. O resultado é um prompt inchado, frágil e difícil de manter. Pequenas mudanças no processo exigem reescrever partes inteiras da instrução. Além disso, prompts longos introduzem problemas de perda de contexto e posicionamento da informação (Liu et al., 2024).

Automação rígida baseada em fluxos fixos. Outra abordagem comum é construir árvores de decisão ou fluxos fixos onde cada pergunta do usuário mapeia para uma resposta pré-definida. Isso funciona para processos muito estáveis, mas quebra na primeira exceção. Usuários reais não seguem roteiros lineares. Eles fazem perguntas fora de ordem, mudam de assunto, voltam atrás em decisões. Fluxos fixos não acomodam essa imprevisibilidade.

RAG sem coordenação de processo. A geração aumentada por recuperação (RAG) melhora a qualidade das respostas ao buscar informações em bases externas (Lewis et al., 2020). Mas RAG resolve o problema de informação, não o problema de operação. Saber qual é o preço de um produto é diferente de conduzir uma negociação com múltiplas etapas, validações e integrações.

O ponto comum entre essas abordagens é que todas tratam o agente como um respondedor, não como um executor operacional. Elas se concentram na qualidade da resposta individual, não na integridade do processo como um todo.

3. O que é um playbook agêntico

Um playbook agêntico é uma estrutura operacional que organiza como um agente de IA deve conduzir um processo complexo do início ao fim.

Diferente de um prompt, que é uma instrução textual para o modelo, um playbook é um conjunto organizado de fluxos que definem:

  • qual é o objetivo do processo
  • quais são as etapas para atingir esse objetivo
  • como cada etapa deve ser conduzida
  • o que fazer quando algo foge do esperado
  • quando e como acionar ferramentas, sistemas ou pessoas

O playbook não diz ao modelo como escrever. Ele diz ao agente o que fazer e em que ordem.

Essa distinção é sutil, mas fundamental. Em um prompt, instrução e execução estão misturadas. Em um playbook, a lógica operacional é separada da geração de texto. O modelo continua sendo o responsável por produzir linguagem natural, mas a estrutura do processo é definida pelo playbook.

É essa separação que torna o agente capaz de operar processos complexos sem depender de um prompt que tenta prever todas as variações possíveis de uma conversa real.

4. A metodologia: quatro tipos de fluxo

A metodologia do Zap2B organiza os playbooks agênticos em quatro categorias de fluxo. Cada uma tem uma função específica dentro da operação.

4.1 Fluxos principais

Os fluxos principais representam a progressão central do processo. Eles formam a sequência padrão de eventos esperados para a concretização do objetivo principal.

Em um processo de agendamento de consulta, por exemplo, os fluxos principais podem ser: atendimento inicial, triagem, proposta de horários, agendamento e conclusão. Cada um representa um estado macro da execução, e a transição entre eles é controlada pelo cumprimento dos critérios de cada etapa.

Os fluxos principais são sequenciais por natureza. O agente não pode pular etapas ou retroceder sem um motivo operacional válido. É essa sequência que garante que o processo avance de forma consistente, sem lacunas ou repetições desnecessárias.

4.2 Fluxos secundários

Os fluxos secundários são fluxos de apoio que podem ser acionados durante a execução de um fluxo principal sem alterar o objetivo macro da jornada.

Eles existem porque, em conversas reais, o usuário raramente segue um roteiro linear. Durante um processo de agendamento, o paciente pode perguntar sobre convênios aceitos, valores de consulta ou procedimentos específicos. Essas perguntas não fazem parte da sequência principal, mas precisam ser respondidas sem interromper o progresso do agendamento.

O fluxo secundário permite que o agente responda à pergunta, registre o contexto e retorne exatamente ao ponto onde estava no fluxo principal. A continuidade é preservada porque o estado da execução principal não é perdido quando um fluxo secundário é acionado.

Esse mecanismo resolve um dos problemas mais comuns em agentes conversacionais: a incapacidade de manter o contexto quando o usuário faz perguntas fora da sequência principal.

4.3 Fluxos excepcionais

Os fluxos excepcionais tratam situações que fogem às regras do fluxo principal. Eles são acionados quando uma condição de negócio, risco, elegibilidade ou impedimento exige um desvio controlado da rota padrão.

Exemplos incluem situações de urgência médica, indisponibilidade de horários, direcionamento para outro canal de atendimento ou desistência do cliente. Cada uma dessas situações exige um tratamento específico, com regras próprias e desfechos definidos.

Diferente dos fluxos secundários, os fluxos excepcionais alteram temporária ou definitivamente o objetivo da execução. Em alguns casos, o agente retorna ao fluxo principal depois de tratar a exceção. Em outros, a exceção redefine completamente a rota, encerrando o processo original e iniciando um novo.

A existência de fluxos excepcionais bem definidos é o que diferencia um agente robusto de um agente frágil. Sem eles, qualquer situação fora do padrão faz o agente alucinar, se perder ou interromper o atendimento.

4.4 Fluxos operacionais

Os fluxos operacionais sustentam a operação do playbook sem fazer parte da jornada visível do usuário. Eles incluem integrações com sistemas externos (CRM, agenda), registro de memória e contexto, comunicação com a equipe humana e execução de processos internos.

Esses fluxos existem porque um agente operacional não se limita a conversar. Ele precisa registrar o lead no CRM, atualizar o status do atendimento, notificar a equipe sobre uma pendência, consultar a disponibilidade na agenda, criar um ticket de acompanhamento.

Os fluxos operacionais separam as instruções de atendimento das instruções de execução interna. Isso mantém o playbook mais organizado, mais legível e mais reutilizável, além de permitir que diferentes times — produto, operações, engenharia — atuem sobre camadas distintas do processo.

5. Como a metodologia sustenta processos complexos na prática

Para ilustrar como esses quatro tipos de fluxo operam juntos, considere o caso de um processo de agendamento de consulta em uma clínica.

O agente recebe o primeiro contato do paciente. O fluxo principal de atendimento inicial é ativado. O agente identifica a intenção de agendar e conduz para a triagem.

Durante a triagem, o paciente pergunta sobre os convênios aceitos. O agente aciona o fluxo secundário de perguntas sobre consultas, responde de forma objetiva e retorna exatamente ao ponto onde parou na triagem, sem perder o progresso.

Em outra etapa, o paciente menciona um sintoma que pode indicar urgência. O agente aciona o fluxo excepcional de urgência médica, que interrompe o agendamento, orienta o paciente sobre os procedimentos corretos e, se necessário, aciona a equipe humana.

Quando o horário é confirmado, o fluxo operacional de integração com o CRM e a agenda registra o agendamento, atualiza o status do lead e prepara a confirmação final.

Em cada um desses momentos, o agente sabe exatamente:

  • em que etapa da operação está
  • qual objetivo precisa cumprir naquele momento
  • quando deve seguir para a próxima etapa
  • quando precisa tratar uma exceção
  • quando deve acionar ferramentas ou sistemas
  • quando precisa envolver uma pessoa da equipe

A metodologia não trata o agente como um respondedor de perguntas. Ela o trata como um executor operacional orientado por processo.

6. O que muda com essa estrutura

A adoção da metodologia de playbooks agênticos produz mudanças concretas na operação.

Previsibilidade. O processo tem um caminho claro, com etapas definidas e transições controladas. O time sabe o que o agente vai fazer em cada situação porque o playbook descreve o comportamento esperado.

Continuidade. O agente mantém o estado da execução mesmo quando ocorrem interrupções contextuais — perguntas paralelas, exceções, pausas. O paciente não precisa recomeçar o processo porque fez uma pergunta fora de hora.

Tratamento de exceções. Situações fora do padrão são tratadas de forma controlada, com regras próprias e desfechos definidos. O agente não alucina nem interrompe o atendimento diante do inesperado.

Integração agente-equipe. A equipe humana pode ser acionada sem ruptura da experiência. O agente registra o contexto, comunica a pendência e retoma a execução quando a equipe responde. Não há perda de informação nem retrabalho.

Escalabilidade. Como a lógica operacional está no playbook e não no prompt, novos processos podem ser modelados com a mesma estrutura. A metodologia é replicável porque não depende do conteúdo específico de cada atendimento, mas da forma como o processo é organizado.

Governança. A separação entre fluxos de negócio, fluxos de exceção e fluxos operacionais permite que diferentes responsáveis atuem sobre o playbook. O time de produto define as regras de negócio. O time de operações acompanha as exceções. A engenharia mantém as integrações.

7. Limitações e cuidados

Nenhuma metodologia elimina todos os riscos. A abordagem de playbooks agênticos exige cuidados que precisam ser reconhecidos.

Modelagem custa tempo. Criar um playbook bem estruturado exige análise do processo, identificação de fluxos, mapeamento de exceções e definição de regras. Para processos muito simples, o custo da modelagem pode não se justificar.

Exceções não mapeadas. Por melhor que seja a modelagem, sempre existirão situações que não foram previstas. A metodologia reduz o impacto dessas exceções, mas não as elimina. É importante que o playbook inclua mecanismos de fallback — como escalonamento para equipe humana — para os casos não mapeados.

Qualidade do playbook determina a qualidade da operação. Um playbook mal estruturado produz um agente inconsistente, independentemente da qualidade do modelo de linguagem. A metodologia transfere parte da responsabilidade do modelo para o desenho do processo.

Supervisão humana continua necessária. Nem todas as decisões podem ser delegadas ao agente. Fluxos operacionais que envolvem validação humana, decisões críticas ou situações de risco devem manter a supervisão como parte do desenho, não como exceção.

A metodologia não elimina a necessidade de boa curadoria de dados. Fluxos que dependem de integração com sistemas externos estão sujeitos à qualidade e disponibilidade desses sistemas. Um CRM desatualizado ou uma agenda offline comprometem a operação, independentemente da estrutura do playbook.

8. Conclusão

A metodologia de playbooks agênticos representa uma mudança de paradigma na forma como agentes de IA são projetados para operar processos complexos.

Ela parte de uma premissa simples: o problema não é fazer o modelo responder melhor. O problema é dar a ele uma estrutura operacional que transforme intenção em execução confiável.

Ao organizar a operação em quatro tipos de fluxo — principais, secundários, excepcionais e operacionais — a metodologia cria uma camada de lógica de processo que separa o que fazer do como escrever. O agente deixa de ser um respondedor e passa a ser um executor operacional orientado por processo, capaz de conduzir jornadas, tratar desvios, acionar sistemas e integrar equipes.

Essa abordagem não elimina a importância dos modelos de linguagem. Ela reposiciona o modelo como um componente dentro de um sistema operacional maior. A qualidade do agente passa a depender não apenas do modelo, mas da qualidade da estrutura que organiza sua execução.

Em um mercado onde a maioria das soluções ainda trata agentes de IA como chatbots melhorados, a diferença competitiva estará cada vez mais na capacidade de estruturar operações, não na capacidade de gerar respostas.

Referências

LEWIS, Patrick et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems, 2020.

LIU, Nelson F. et al. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 2024.

WANG, Lei et al. A Survey on Large Language Model based Autonomous Agents. Frontiers of Computer Science, 2024.