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.