Janela de contexto: o que uma conversa longa exige do seu agente

Separe contexto, conhecimento e histórico

No funcionamento de um modelo, instruções, mensagens e informações fornecidas por documentos ou ferramentas podem participar do contexto de uma resposta. A capacidade é medida em tokens, unidades de texto que não correspondem necessariamente a palavras inteiras.

Uma base de conhecimento mantém fontes para consulta; o histórico disponível para revisão registra uma execução. Nenhum desses conceitos, sozinho, garante que todos os registros anteriores estejam presentes em uma nova chamada.

Mantenha as instruções relevantes à tarefa

Defina o objetivo, as perguntas necessárias e o uso das ferramentas com clareza. Elimine regras duplicadas ou contraditórias que dificultem identificar o que fazer em uma situação específica.

Selecione fontes pertinentes ao atendimento. Não copie um acervo inteiro nas instruções para tentar garantir acesso a cada informação. Teste a consulta aos documentos associados e use ferramentas para dados atuais do sistema responsável.

Teste detalhes corrigidos perto do fim

Prepare um roteiro em que a pessoa informe uma unidade, faça outras perguntas e depois corrija a unidade antes da consulta final. Observe os parâmetros usados pela ferramenta e o que o agente confirma.

Inclua troca de objetivo e retomada de uma pergunta anterior. O teste deve verificar o valor efetivamente utilizado, além da fluidez da resposta. Um agente pode falar de forma coerente e ainda executar uma consulta com um dado antigo.

Não transforme capacidade em promessa de memória

O Tigy mantém o modelo do agente como serviço gerenciado. Este roteiro não depende de escolher um provedor ou configurar um tamanho de janela na interface. Avalie o comportamento nas tarefas e durações permitidas pela sua operação.

Se a continuidade entre chamadas exigir dados de um atendimento anterior, desenhe uma consulta autorizada ao sistema externo. Defina os dados necessários e confirme informações que possam ter mudado; não presuma recuperação automática apenas porque existe histórico para revisão.

Contexto, base de conhecimento e histórico são a mesma coisa?

Contexto é o material disponível para a resposta atual. A base de conhecimento mantém documentos para consulta. Histórico registra uma execução para investigação pela equipe. A existência de uma transcrição não comprova que seu conteúdo entra automaticamente na próxima chamada.

Se uma tarefa depende de um atendimento anterior, defina uma consulta autorizada ao sistema que conserva os dados necessários. Confirme informações que podem ter mudado. Um teste útil compara duas chamadas com registros sintéticos e verifica como a segunda obteve cada dado, em vez de deduzir memória pela fluidez da conversa.

Entenda o que participa de uma resposta

Uma conversa depende de fontes com papéis diferentes. As instruções definem o comportamento esperado. O histórico informa o que foi dito. Um documento sustenta uma regra. Uma ferramenta retorna o estado de um sistema. A proximidade de uma frase na conversa não transforma essa frase em autoridade.

Em um exemplo fictício, o interlocutor afirma que uma taxa não existe mais. O agente não deve incorporar essa afirmação como política. Pode reconhecer a dúvida e consultar a fonte aprovada. Se ela não resolve o conflito, a resposta precisa preservar a incerteza e orientar um próximo passo possível.

Ao mesmo tempo, correções sobre a própria preferência da pessoa têm outro papel. Se ela muda a data desejada, a consulta seguinte precisa usar o valor atualizado. O agente deve distinguir essa mudança de uma tentativa de alterar uma regra da organização.

Organize instruções para explicar essas diferenças em linguagem direta. Evite despejar todo o manual no prompt quando a tarefa usa apenas parte dele. A quantidade de texto disponível não garante que cada detalhe será utilizado corretamente.

Mantenha o pedido atual claro após uma correção

Em um exemplo fictício, uma pessoa pede manutenção na terça, pergunta sobre documentos e depois troca para quinta. O teste não termina quando o agente diz “entendi”. A consulta deve utilizar quinta e manter o mesmo serviço, salvo se ele também mudou.

Confirme os campos que afetam a ação no momento certo. Uma confirmação breve de serviço, unidade e horário pode resolver ambiguidade antes de uma reserva. Não repita todo o histórico: destaque apenas os valores relevantes ao próximo passo.

Se a conversa inclui dois pedidos, vincule cada dado ao pedido correspondente. Um telefone de contato para uma solicitação não deve ser copiado para outra por conveniência. Quando não está claro a qual registro a pessoa se refere, faça uma pergunta específica.

O sistema conectado também precisa conferir o pedido e o direito de acesso. Não dependa apenas de o agente lembrar uma correção. Combine com o responsável pela integração como o pedido certo será identificado e como uma alteração indevida será recusada.

Não deixe um retorno antigo confirmar um pedido novo

O histórico não é a única fonte de confusão. Uma consulta pode levar tempo, e a pessoa pode corrigir o pedido enquanto espera. O resultado recebido depois pode corresponder ao valor anterior, mesmo que sua resposta pareça válida.

Em um exemplo fictício, o agente consulta disponibilidade na unidade norte. Antes do retorno, a pessoa escolhe a unidade sul. O horário encontrado no norte não confirma disponibilidade no sul. A conversa precisa esclarecer a associação e executar a consulta adequada quando a integração permite.

Na revisão, registre a ordem dos eventos: pedido, parâmetros enviados, correção e resultado recebido. Essa sequência ajuda a separar problema de referência de indisponibilidade do serviço. Um resultado tecnicamente bem-sucedido pode não responder à intenção atual.

Defina comportamento para operações cujo resultado permanece incerto. Não anunciar uma confirmação é diferente de declarar que nada aconteceu. Se houve uma tentativa de escrita, o responsável pela integração deve oferecer uma forma de verificar o estado antes de repetir a ação.

Planeje conversas extensas sem prometer memória ilimitada

Modelos trabalham com limites de contexto que variam conforme a configuração. Não publique um número como regra universal sem verificar o modelo em uso. Mesmo dentro do limite, um histórico longo pode tornar referências menos claras e aumentar a presença de informações irrelevantes.

O caminho prático é reduzir complexidade da tarefa. Divida pedidos quando a pessoa mistura assuntos sem relação. Use uma confirmação curta ao mudar de assunto e explique o que ainda falta concluir. Essa organização melhora a compreensão da pessoa, além de apoiar a resposta seguinte.

Não prometa que o agente lembrará contatos anteriores. Memória entre chamadas depende de uma capacidade implementada, dados disponíveis e autorização. Uma consulta ao CRM pode recuperar informação pertinente quando configurada; isso não equivale a lembrança automática de toda conversa.

Compare conversas curtas e longas com as mesmas decisões importantes. Se os erros surgirem depois de muitas perguntas e respostas, veja qual informação foi perdida. A solução pode ser confirmar melhor um dado, limitar a tarefa ou pedir ao responsável pela conexão que ajuste como as informações são enviadas.

Monte testes que exijam manter referências

Comece com um caso de referência simples: um pedido, uma correção e uma ação. Depois introduza uma pergunta intermediária. Por fim, inclua dois pedidos e uma informação parecida em cada um. Essa progressão ajuda a localizar o ponto em que a associação deixa de ser confiável.

Defina resultado esperado para cada cenário. O agente pode precisar perguntar novamente, e isso não é necessariamente falha. Uma clarificação curta é melhor que executar a ação sobre o registro errado. Avalie se a pergunta remove a ambiguidade ou apenas repete uma frase genérica.

Confira parâmetros e estados finais em operações configuradas. Para respostas informativas, compare a regra aplicada e o contexto que a qualifica. Não reduza a avaliação a uma nota de naturalidade: o pedido pode soar bem e continuar incorreto.

Inclua mudança de intenção, negação e correção tardia. Uma pessoa pode dizer “não quero cancelar, quero saber o prazo”. A resposta deve usar essa intenção atual e respeitar os limites da operação. Preserve exemplos com falha para repetir após mudanças.

Use a revisão para melhorar o desenho da tarefa

Ao investigar uma falha, descreva o erro de forma concreta. “Usou terça depois da correção para quinta” informa mais que “esqueceu o contexto”. Esse registro permite avaliar se a mudança realmente corrige o comportamento observado.

Compare instruções, fontes e ferramentas da versão testada. Uma mudança na integração pode alterar a maneira de identificar resultados; uma nova instrução pode acrescentar decisões concorrentes. Sem registrar a configuração, a equipe não consegue atribuir a melhora ou a piora com segurança.

Reúna casos em que a pessoa precisou repetir informação. Alguns revelam falha de referência; outros mostram uma pergunta inicial difícil de entender. Revise também a experiência de atendimento, porque uma tarefa confusa força mais correções mesmo quando os dados são mantidos corretamente.

Amplie o escopo apenas depois de validar os casos atuais. A capacidade de conversar sobre muitos assuntos não comprova que o agente consegue executar todos com precisão. Um recorte claro e verificável é uma base mais útil para crescer.