Um resumo de histórico para chatbot deve funcionar como um estado de trabalho: registrar o objetivo atual, os fatos confirmados, os compromissos assumidos, as pendências e as correções feitas pelo usuário. Uma narrativa curta da conversa ajuda a leitura, mas não basta para decidir o que o sistema pode fazer no próximo turno.
A abordagem proposta aqui combina mensagens recentes, um registro estruturado atualizado por eventos e referências às mensagens que sustentam cada informação. O resumo é uma interpretação revisável. Quando houver divergência, a aplicação deve conseguir voltar à origem, corrigir o estado e impedir que uma promessa antiga reapareça como tarefa ainda válida.
Resumo rápido
- Separe fatos, preferências, pedidos e compromissos em campos distintos.
- Registre a origem de cada informação que influencia uma decisão.
- Uma correção deve substituir o valor vigente e preservar sua relação com o anterior.
- Atualize o estado com controle de versão para evitar disputas entre respostas simultâneas.
- Teste mudanças de intenção, recusas, cancelamentos e retomadas de atendimento.
1. Defina o que precisa sobreviver a cada resumo
Imagine uma conversa que começou com uma cotação e terminou com um pedido de cancelamento. “Cliente interessado no serviço” pode descrever parte do histórico, mas é uma representação ruim do que a equipe deve fazer agora. O resumo precisa registrar o cancelamento, o que ele afeta e quais providências ainda estão pendentes.
Faça uma lista das decisões que o próximo turno pode exigir. Para atendimento comercial, ela pode incluir produto, quantidade, local, orçamento informado, dúvidas abertas e autorização para contato. Para suporte, pode incluir sintomas, testes já realizados, resultado observado e encaminhamento solicitado. Inclua apenas campos com função clara no atendimento.
Organize três camadas. As mensagens originais fornecem evidência. O estado estruturado reúne o que está vigente. Um texto breve explica o contexto para a pessoa ou para o modelo. Evite manter duas versões concorrentes da verdade: quando o texto e o campo estruturado divergem, o fluxo deve detectar o conflito e reconstruir a projeção.
As ferramentas de function calling e saídas estruturadas ajudam a obter formatos verificáveis. Mesmo assim, um objeto bem formado pode conter uma interpretação errada. Validar o formato é uma etapa; conferir se cada mudança corresponde à conversa é outra.
2. Escolha campos que distingam intenção e compromisso
Um campo chamado “observações” costuma misturar tudo. Prefira categorias explícitas, com estados limitados e origem registrada. O quadro abaixo é uma sugestão de desenho para sua aplicação, não uma estrutura obrigatória de qualquer fornecedor.
| Campo | Conteúdo adequado | Confusão a evitar |
|---|---|---|
| Objetivo atual | Solicitar remarcação de visita | Preservar o objetivo antigo após cancelamento |
| Fato informado | Usuário declarou endereço X | Tratar declaração como verificação externa |
| Preferência | Contato pela manhã | Transformar preferência em autorização de envio |
| Compromisso | Equipe prometeu retornar após análise | Registrar uma sugestão como promessa |
| Pendência | Aguardar confirmação da data | Marcar concluído porque o modelo escreveu uma resposta |
| Correção | Endereço novo substitui o anterior | Manter os dois endereços como igualmente vigentes |
Para compromissos, guarde identificador, responsável, descrição, prazo quando existir, status e mensagem de origem. “Vou verificar” exige uma classificação diferente de “a visita está confirmada”. O modelo não deve transformar linguagem cortês ou uma hipótese em execução concluída.
Para fatos, mantenha o tipo de fonte. “Informado pelo usuário”, “consultado no cadastro” e “inferido pelo assistente” têm pesos diferentes. Caso a aplicação não permita inferências na memória operacional, rejeite esse tipo de atualização. Se permitir, mantenha a incerteza explícita e peça confirmação antes de usar a informação numa ação relevante.
JSON Schema documenta propriedades obrigatórias e o tratamento de propriedades adicionais. Use esses recursos para limitar campos desconhecidos e exigir a origem de alterações. As regras de negócio, como impedir que uma preferência autorize um envio, continuam sob responsabilidade da aplicação.
3. Atualize o estado a partir dos turnos novos
Em vez de pedir “reescreva todo o histórico de forma resumida”, peça uma proposta de alterações sobre o estado atual. Envie as mensagens novas, os campos vigentes e as regras de atualização. Exija que cada inclusão, substituição ou conclusão cite uma mensagem existente. Esse desenho deixa as mudanças mais fáceis de revisar e auditar.
{
"state_version": 12,
"through_message": "msg-48",
"current_goal": "remarcar visita",
"facts": {
"bairro": {"value": "Tijuca", "source": "msg-45"}
},
"commitments": [
{"id": "c-3", "task": "consultar agenda",
"owner": "equipe", "status": "pendente", "source": "msg-48"}
]
}O objeto é ilustrativo. Num sistema real, inclua os identificadores do atendimento e da organização no contexto de armazenamento e autorização. Um identificador de conversa recebido do navegador não deve permitir consultar o estado de outra pessoa.
Processe a proposta em etapas: valide o esquema, confira referências, aplique regras de transição e grave a nova versão. Atualize também o marcador da última mensagem incorporada. Se uma requisição for repetida após uma falha de rede, o sistema deve reconhecer o evento já processado e evitar duplicar o compromisso.
Não marque uma tarefa como concluída apenas porque o assistente pediu sua execução. A conclusão deve vir da confirmação adequada ao processo: resultado da ferramenta, registro operacional ou manifestação de quem executou. Diferencie “solicitado”, “em execução”, “concluído” e “falhou” quando esses estados forem úteis à equipe.
4. Corrija a memória sem perder a rastreabilidade
Quando o usuário disser “corrigindo, a entrega é na filial de Santos”, o sistema precisa identificar qual entrega e qual campo foram afetados. A correção mais recente da mesma pessoa pode substituir uma informação anterior, mas não resolve automaticamente conflito com um cadastro validado ou com outra pessoa autorizada. Defina a política de precedência por campo.
Guarde o valor vigente e um evento de correção ligado ao valor anterior. Se houver ambiguidade, mantenha a pendência em vez de escolher uma interpretação. “Não é para amanhã” cancela aquela referência de data, mas não informa uma nova data. O próximo resumo deve representar esse vazio corretamente.
Uma proposta de alteração pode usar operações inspiradas em JSON Patch. A RFC 6902 define operações como adicionar, remover, substituir e testar valores em documentos JSON. Ela não decide quem tem autorização para corrigir um dado. Faça essa verificação no código antes de aplicar a mudança.
Use uma versão esperada na gravação. Se dois processos leram a versão 12 e um deles gravou a 13, o segundo precisa reler e reconciliar a alteração. Sobrescrever toda a memória com a cópia antiga pode ressuscitar o endereço corrigido ou apagar o cancelamento feito no outro canal.
Registre também correções em cascata. Trocar a unidade de atendimento pode invalidar horário, responsável e orçamento. Faça as dependências voltarem a “precisa confirmar” quando necessário. Preservar todos os campos antigos depois de uma mudança central pode criar um estado formalmente válido e operacionalmente incoerente.
5. Reconstrua e teste o resumo como parte do atendimento
Um resumo de outro resumo pode carregar uma omissão por muitas interações. Para reduzir essa propagação, permita reconstruir o estado usando as mensagens e os eventos autorizados disponíveis. A política de retenção deve definir por quanto tempo essa reconstrução será possível. Não prometa recuperar conteúdo que o sistema já eliminou.
A documentação do LangGraph apresenta memória de curto prazo associada ao estado da conversa e persistência por checkpoints. Esses mecanismos ajudam a guardar e retomar estados. A escolha de campos, a validade das promessas e a resolução de correções continuam exigindo regras do produto. Persistir um resumo errado apenas torna o erro durável.
Monte conversas de teste com respostas esperadas sobre o estado, além da resposta textual ao usuário. Inclua uma promessa seguida de cancelamento, duas unidades com nomes parecidos, uma correção sem novo valor, mudança de objetivo e retorno depois de intervenção humana. Para cada caso, indique quais campos devem mudar e quais devem permanecer.
Observe omissões de compromissos, tarefas indevidamente reabertas, fatos sem origem e atualizações perdidas por concorrência. Conte também quantas vezes o atendente precisa voltar ao histórico para entender uma pendência. Esses indicadores devem ser medidos no seu fluxo; não há ganho numérico presumido por adotar resumo estruturado.
Reveja a informação enviada ao modelo e o acesso aos registros com base no projeto. O guia de segurança e LGPD para IA ajuda a organizar essa discussão. Memória de atendimento não deve virar automaticamente um perfil permanente que circula entre todos os canais.
Exemplo: uma assistência técnica em Recife
Considere uma assistência de eletrodomésticos em Recife. O cenário é ilustrativo. Uma cliente pede visita no bairro Boa Viagem e informa preferência pela manhã. O atendente responde que consultará a agenda. Até aqui, há uma preferência e um compromisso de consulta, sem horário confirmado.
Depois a cliente escreve: “O aparelho está na casa da minha mãe, na Madalena. E pode ser à tarde”. O estado deve substituir o bairro e a preferência, mantendo referências às mensagens que trouxeram a correção. A pendência de consultar disponibilidade continua aberta. O sistema não pode apresentar uma visita em Boa Viagem apenas porque essa localização apareceu mais vezes.
O técnico informa uma opção de horário, e a cliente responde “não confirme ainda, vou falar com ela”. Registre a opção como proposta e a confirmação como pendente. Se o resumo disser apenas “visita à tarde na Madalena”, o próximo atendente pode interpretar a frase como agendamento fechado.
Ao retomar, o chatbot deveria dizer que existe uma opção apresentada e que aguarda confirmação. Quando a cliente confirma, a aplicação verifica a disponibilidade no sistema operacional antes de anunciar sucesso. Se a opção deixou de existir, atualiza a pendência e explica a situação. A memória preserva o contexto sem substituir a agenda da empresa.
Erros comuns
- Resumir apenas por temas: “conversa sobre entrega” não informa qual obrigação permanece aberta.
- Guardar inferência como declaração: uma dedução do modelo precisa de tratamento diferente de um dado informado.
- Concluir promessa por linguagem: “vou enviar” não comprova que o envio ocorreu.
- Ignorar concorrência: atualizações simultâneas podem apagar correções já aceitas.
- Misturar instruções e conteúdo: uma frase do cliente armazenada na memória não ganha autoridade para alterar regras da aplicação.
- Acumular tudo para sempre: defina retenção, escopo de acesso e retirada dos dados conforme a finalidade do atendimento.
Perguntas frequentes
Devo substituir todo o histórico pelo resumo?
Não é uma regra geral. Preserve mensagens recentes e referências suficientes para conferir decisões, conforme sua política de retenção. O resumo serve à continuidade; o registro original, quando disponível e autorizado, permite auditar interpretações.
Com que frequência devo atualizar?
Atualize quando houver mudança operacional relevante, como correção, compromisso ou cancelamento. O gatilho pode combinar eventos e limites definidos pela equipe. Teste a política com conversas reais autorizadas antes de adotá-la amplamente.
Quem decide entre duas informações conflitantes?
A política do campo deve indicar a fonte competente e quando pedir confirmação. A mensagem mais recente não é uma regra universal de autoridade. Em caso de dúvida, represente o conflito e mantenha a ação dependente em espera.
Checkpoints resolvem o problema da memória?
Eles ajudam a persistir e recuperar estados, mas não garantem que o conteúdo esteja correto. Você ainda precisa validar transições, controlar acesso, interpretar correções e testar se compromissos sobrevivem às atualizações.
