Sessões de agentes de IA: estado, isolamento e retomada

Sessão é uma fronteira operacional

Um cliente começa uma conversa no site, continua pelo WhatsApp e envia um documento horas depois. O agente precisa reconhecer a continuidade certa sem carregar contexto de outra pessoa, outro canal ou outro assunto.

Esse problema parece simples enquanto existe um usuário, uma janela aberta e poucas mensagens. Em produção, aparecem dispositivos diferentes, canais paralelos, tarefas em espera, permissões que mudam, atendentes que assumem casos e execuções que continuam em segundo plano.

Sessões de agentes de IA organizam a continuidade temporária entre uma identidade, um objetivo e um conjunto autorizado de estados. A sessão define quais eventos pertencem ao mesmo trabalho, o que pode ser recuperado, quando a autoridade deve ser revalidada e como o contexto será encerrado.

Sem essa fronteira, o agente pode esquecer uma pendência válida ou, pior, lembrar a pendência da pessoa errada.

Sessão, conversa, memória e execução não são sinônimos

Separar os objetos evita que um histórico de mensagens vire a única base da operação.

Conversa

É a sequência de mensagens em uma interface ou canal. Uma conversa pode conter vários assuntos e gerar mais de uma tarefa.

Sessão

É o envelope temporário que liga identidade, objetivo, escopo, estado e validade. Pode atravessar várias interações e, quando autorizado, mais de um canal.

Memória

É o conteúdo selecionado para persistir ou ser recuperado em outras execuções. Preferência, decisão, procedimento e evento podem viver além da sessão, conforme finalidade e política.

A página sobre memória de agentes de IA detalha validade, fonte, recuperação e descarte de informação persistente.

Registro de execução

É a unidade de trabalho processada pelo sistema. Uma sessão pode iniciar várias execuções, e uma execução longa pode continuar depois que a interface do usuário foi fechada.

Os agentes de IA para tarefas longas precisam de máquina de estados, checkpoints e idempotência. A sessão conecta a pessoa ao trabalho, mas não deveria substituir o registro operacional da tarefa.

Sessão de autenticação

É o vínculo de segurança que confirma a identidade do usuário em um aplicativo. Ela pode expirar antes ou depois da sessão do agente. As duas precisam se relacionar sem serem confundidas.

O contrato mínimo de uma sessão

Cada sessão deveria possuir um registro estruturado.

Campos úteis incluem:

identificador único e imprevisível;
organização, cliente ou tenant;
usuário autenticado;
canal e dispositivo, quando relevantes;
agente, versão e finalidade;
objetivo atual;
objetos e fontes autorizados;
ferramentas disponíveis;
estado resumido da tarefa;
pendências e próxima ação;
execuções vinculadas;
aprovações e concessões válidas;
horário de criação e última atividade;
expiração por inatividade e prazo máximo;
classificação dos dados;
política de retenção;
status da sessão;
motivo e evidência de encerramento.

Texto livre pode complementar esse registro. Ele não deveria ser o único estado capaz de dizer quem participa, qual trabalho está aberto e que autoridade continua válida.

Use um ciclo de vida explícito

Estados simples ajudam a bloquear transições indevidas.

Criada

A identidade foi confirmada, a finalidade foi declarada e a sessão recebeu seu escopo inicial.

Ativa

O usuário ou o processo pode enviar eventos e receber respostas. Ferramentas são liberadas conforme política.

Aguardando

Existe uma dependência conhecida: documento, aprovação, sistema externo ou resposta humana. O estado precisa indicar responsável e prazo.

Pausada

Novas ações ficam suspensas, mas o contexto necessário para uma retomada segura continua preservado.

Expirada

A validade terminou. Leitura de histórico pode continuar conforme política, porém novas ações exigem autenticação ou autorização atualizada.

Encerrada

O objetivo foi concluído, cancelado ou transferido. Recursos temporários são liberados e o resultado útil segue para o sistema oficial.

Bloqueada

Um sinal de risco, revogação ou incidente impede continuidade. Filas e execuções vinculadas precisam respeitar o bloqueio.

Cada transição deve resultar de um evento conhecido. Uma mensagem nova não deveria reabrir automaticamente uma sessão encerrada meses antes.

A chave da sessão começa pela identidade

Associar sessão somente ao número de telefone, endereço de e-mail ou cookie pode ser insuficiente.

O identificador correto depende do contexto:

pessoa autenticada em portal;
contato validado dentro de uma conta;
membro de uma organização;
atendente assumindo um caso;
dispositivo conhecido;
conversa em canal compartilhado;
processo disparado por evento interno.

Em WhatsApp, e-mail ou chat público, o canal identifica uma origem, mas pode não provar autoridade para consultar dados sensíveis. A sessão pode começar com acesso restrito e ganhar capacidades depois de uma verificação adequada.

Evite usar nome livre ou informação produzida pelo modelo para resolver identidade. O vínculo com cliente, contrato, oportunidade ou prontuário precisa vir de fonte autenticada ou de uma confirmação controlada.

Isolamento vem antes da recuperação de contexto

A busca mais inteligente continua perigosa quando o filtro de escopo está errado.

A sessão deve isolar pelo menos:

organização ou tenant;
cliente e unidade;
usuário ou grupo autorizado;
ambiente de teste e produção;
canal, quando a travessia não foi autorizada;
finalidade da tarefa;
classe de dado;
agente e ferramentas permitidas.

A ordem importa. Primeiro aplique filtros determinísticos de identidade e escopo. Depois use relevância, similaridade ou resumo para escolher conteúdo dentro da fronteira autorizada.

Um banco vetorial não deveria descobrir sozinho a qual cliente um trecho pertence. Essa informação precisa estar registrada e validada antes da busca.

Travessia entre canais exige uma regra

Continuar no celular uma tarefa iniciada no portal pode reduzir atrito. Também pode carregar dados para uma superfície com outra identidade, retenção ou visibilidade.

Antes de unir canais, confirme:

que a mesma pessoa controla os dois acessos;
que a organização permite a travessia;
qual conteúdo pode aparecer no novo canal;
se anexos e dados sensíveis precisam ficar no portal;
quais ações exigem nova autenticação;
como o usuário encerra ou separa os assuntos;
onde o histórico oficial será mantido.

Uma alternativa segura é transferir somente um identificador e uma síntese mínima. O canal secundário informa status e próxima ação, enquanto documentos e decisões sensíveis permanecem na superfície apropriada.

Concorrência pode corromper o estado

Duas mensagens chegam quase juntas. Um atendente altera o CRM enquanto o agente prepara uma ação. O usuário abre a mesma conversa em dois dispositivos. Um worker retoma uma tarefa antiga depois de outra execução já ter concluído.

Sem controle de concorrência, o sistema pode:

responder com base em estado vencido;
sobrescrever uma correção humana;
executar a mesma ação duas vezes;
misturar dois objetivos;
fechar uma sessão ainda ativa;
enviar mensagem fora de ordem.

Use versão de estado, sequência de eventos ou bloqueio compatível com o processo. Antes de gravar, confirme que a sessão continua na versão esperada. Quando houver conflito, preserve os dois eventos e encaminhe para uma regra de reconciliação.

A página sobre controle de concorrência para agentes de IA aprofunda reservas, locks, versões e conflitos em efeitos externos.

Histórico bruto não deveria ser o estado principal

Reenviar toda a conversa em cada chamada parece uma forma simples de continuidade. O custo e o risco crescem com o tempo.

Um estado útil separa:

objetivo confirmado;
fatos com fonte;
decisões tomadas;
ações executadas;
pendências;
restrições;
objetos ativos;
próxima ação;
referências para evidência original.

O resumo precisa indicar versão e origem. Se uma inferência virou resumo, registre que ela é uma interpretação. Se uma decisão mudou, a versão atual deve prevalecer sem apagar a trilha necessária.

A engenharia de contexto para agentes de IA ajuda a montar o pacote mínimo para cada etapa, em vez de despejar todo o histórico no modelo.

Expiração precisa combinar inatividade, duração e risco

Uma única regra de “30 dias” costuma ser inadequada.

Considere três relógios.

Inatividade

Encerra ou reduz capacidades depois de um período sem evento. Uma conversa casual pode tolerar uma janela maior que uma tarefa financeira.

Duração máxima

Impede que uma sessão permaneça válida indefinidamente por receber pequenos eventos. Depois do prazo, o sistema cria nova sessão ou exige revisão.

Validade da autoridade

Permissões, aprovações e tokens podem expirar antes da sessão. O contexto pode continuar visível enquanto a capacidade de agir fica bloqueada.

Uma sessão antiga pode ser retomada para leitura e ainda exigir confirmação de identidade, atualização do estado oficial e nova autorização antes de qualquer efeito.

Retomar exige verificar o que mudou

Retomada segura vai além de carregar mensagens.

Antes de continuar:

confirme a identidade atual;
verifique status e expiração da sessão;
recupere o objetivo e a próxima ação;
consulte fontes oficiais que podem ter mudado;
revalide permissões e aprovações;
confira se outra pessoa ou execução concluiu a tarefa;
detecte alterações de versão no agente ou procedimento;
apresente ao usuário uma síntese curta quando houver ambiguidade;
crie nova execução com identificador próprio;
registre de onde a retomada partiu.

Se preço, contrato, responsável, consentimento ou estágio mudaram, o checkpoint antigo não autoriza seguir como se o tempo tivesse parado.

Delegação de acesso deve expirar dentro da sessão

Uma sessão pode preservar contexto sem preservar toda a autoridade recebida no início.

Quando um agente age em nome da pessoa, a concessão precisa indicar ação, objeto, validade e uso permitido. Ao pausar, trocar de canal ou retomar depois do prazo, revalide a delegação.

O guia sobre delegação de acesso para agentes de IA mostra como separar principal, ator automatizado, identidade técnica e efeito confirmado.

Essa separação impede que “sessão ativa” vire permissão ampla para qualquer ferramenta disponível.

Encerramento precisa liberar recursos e preservar o resultado certo

Fechar a janela do chat não encerra necessariamente a sessão. Da mesma forma, encerrar a sessão não deveria apagar o registro oficial produzido pelo processo.

Um procedimento de encerramento pode:

impedir novos eventos;
cancelar ou transferir execuções abertas;
revogar tokens temporários;
liberar locks e recursos de sandbox;
resolver aprovações pendentes;
gravar resultado no sistema oficial;
preservar evidência mínima;
descartar anexos e buffers temporários;
aplicar retenção ao histórico;
informar o usuário quando necessário;
registrar motivo, horário e responsável.

A política de retenção de dados em agentes de IA deve definir quais objetos permanecem, por qual finalidade e até quando.

Handoff humano deve carregar estado útil

Quando uma pessoa assume o caso, ela precisa receber um pacote decisório:

identidade e escopo da sessão;
objetivo atual;
fatos confirmados e fontes;
ações já realizadas;
estado dos sistemas;
pendências;
motivo do handoff;
decisão necessária;
prazo;
restrições de comunicação ou acesso.

Transferir somente a conversa bruta devolve o trabalho de interpretação para a equipe. O handoff entre agente e humano ajuda a estruturar responsabilidade, evidência e próxima ação.

Como testar sessões de agentes de IA

Inclua cenários de isolamento, ordem e encerramento:

dois usuários com nomes iguais em organizações diferentes;
mesma pessoa com dois assuntos simultâneos;
mensagem duplicada ou recebida fora de ordem;
troca de canal sem identidade confirmada;
sessão expirada com contexto ainda armazenado;
permissão revogada durante uma espera;
retomada depois de mudança no CRM;
dois workers tentando avançar a mesma etapa;
atendente humano corrigindo o estado;
arquivo enviado à sessão errada;
versão nova do agente lendo resumo antigo;
encerramento com execução ainda enfileirada;
solicitação de exclusão ou correção de dado;
incidente que exige bloquear várias sessões relacionadas.

Teste a consequência, não somente a resposta do chat. Verifique ferramenta chamada, objeto alcançado, estado final, descarte e evidência.

Métricas para operar sessões

sessões ativas, aguardando, expiradas e bloqueadas;
sessões sem dono ou objetivo definido;
retomadas bem-sucedidas;
reautenticações e reautorizações exigidas;
conflitos de concorrência;
mensagens duplicadas ou fora de ordem;
casos misturados entre usuários, clientes ou assuntos;
tempo parado aguardando pessoa ou sistema;
sessões encerradas com execução aberta;
contexto recuperado sem uso;
custo por sessão concluída;
handoffs e reconstrução manual de contexto;
falhas de descarte;
incidentes de isolamento.

Contar sessões abertas mede atividade. A métrica de negócio precisa mostrar se a continuidade reduziu repetição, espera, retrabalho ou abandono sem ampliar risco.

Checklist para gestão de sessões

Sessão, conversa, memória e execução possuem identificadores próprios?
A identidade é confirmada antes de recuperar dados sensíveis?
Tenant, usuário, canal e finalidade estão explícitos?
Filtros determinísticos são aplicados antes da busca por relevância?
O estado útil está estruturado fora do histórico bruto?
Transições de ciclo de vida possuem eventos conhecidos?
Inatividade, duração máxima e validade de autoridade são separadas?
Concorrência usa versão, sequência ou bloqueio?
Retomada consulta fontes que podem ter mudado?
Delegações e aprovações são revalidadas?
Handoff humano leva fatos, ações, pendências e decisão?
Encerramento cancela trabalho e libera recursos?
Retenção e descarte foram definidos por objeto?
Testes cobrem mistura, duplicidade, expiração e revogação?

Continuidade útil depende de fronteiras claras

Uma boa sessão permite que o agente continue o trabalho sem pedir tudo novamente. Essa continuidade só gera confiança quando identidade, objetivo, escopo e validade permanecem visíveis.

A arquitetura precisa preservar estado suficiente para retomar, consultar o que pode ter mudado e descartar o que perdeu finalidade. Também precisa separar pessoas, organizações, assuntos e canais antes de qualquer recuperação inteligente.

Sessão madura reduz repetição sem transformar histórico em autoridade permanente. Ela sabe quando continuar, quando confirmar, quando abrir um novo trabalho e quando encerrar.