Como salvar, testar e publicar versões de agentes no Tigy

Prepare uma mudança identificável

Salvar um agente preserva o rascunho; publicar torna uma versão validada disponível para execução. Antes de alterar o rascunho no Tigy AI, descreva o problema e a mudança esperada. Confira workspace, instruções, ferramentas e fontes, salve e teste os casos afetados. Depois da publicação, verifique uma nova conversa no canal usado pelos clientes.

Uma mudança na informação de um serviço externo pode afetar o atendimento mesmo sem alteração do prompt. Registre essa dependência quando ela fizer parte do teste.

Valide e publique

Revise os erros de validação apresentados no editor e corrija os campos indicados. Selecione Publicar, aguarde a confirmação e confira a versão publicada no histórico.

Um rascunho pode ser salvo ainda incompleto. A publicação exige validação; salvar com sucesso não garante que a mesma configuração possa ser publicada.

Confira o canal com uma nova conversa

Publicar não associa um número telefônico ao agente. Configure esse vínculo separadamente na integração de telefonia. Depois, inicie uma nova conversa pelo canal pretendido e confirme o comportamento.

Anote o número da versão e os cenários usados na verificação. Isso ajuda a comparar o resultado depois de uma mudança.

Use o histórico como evidência

Abra uma versão anterior para consultar a configuração e comparar mudanças quando a interface oferecer essa opção. Selecionar uma versão para visualizar não significa restaurar ou publicar.

Se encontrar uma alteração problemática, aplique a correção ao rascunho atual, salve, teste e publique. Confira novas conversas para verificar a correção na operação.

Publique uma mudança com hipótese e evidência

Escreva o problema observado, a regra modificada e o cenário que deve melhorar. Salve o rascunho, execute os casos afetados e confira condições próximas. Se você ajustou confirmação de datas, teste também correções e pedidos sem data.

Corrija validação antes de publicar e confira o histórico após a confirmação. Faça uma nova conversa pelo canal utilizado. Uma sessão iniciada anteriormente não comprova o comportamento das próximas chamadas.

Defina quem acompanha a primeira amostra após a publicação. Compare fala, ferramenta e efeito no destino. Uma mudança aprovada no editor pode revelar uma dependência telefônica ou externa que não estava presente no teste.

Prepare a recuperação antes de precisar dela

Consulte uma versão anterior como referência e aplique a correção ao rascunho atual. Verifique permissões, salve, teste e publique a configuração corrigida. Se o atendimento precisa continuar durante a investigação, prepare uma rota alternativa operacional.

Uma correção deve ser seguida por nova validação. Alterar o prompt não desfaz registros externos criados nem altera automaticamente documentos ou números. Se houve operação indevida, trate o efeito no sistema responsável.

Registre a causa e acrescente um cenário que evita repetição. O objetivo do histórico não é apenas voltar, mas compreender por que a alteração falhou e preservar a configuração que atende corretamente.

Defina o que está mudando na versão

Uma publicação deve ter um motivo concreto. Alterar uma apresentação, acrescentar uma fonte e permitir uma operação de escrita são mudanças diferentes, com verificações diferentes. Antes de editar, registre o comportamento atual, o resultado desejado e a parte da configuração que precisa mudar. Isso evita publicar uma coleção de alterações cujo efeito não pode ser explicado depois.

No Tigy, salvar e publicar são ações distintas. O rascunho permite preparar mudanças, enquanto a versão publicada identifica a configuração disponibilizada para execução. Um salvamento bem-sucedido não significa que a validação de publicação passou. Confira o estado e a confirmação em vez de assumir que o último texto salvo já atende novas conversas.

Use o histórico para identificar número, data e configuração de referência. A documentação informa que visualizar uma versão histórica não a publica automaticamente. Se você precisa corrigir um comportamento, consulte a versão anterior como referência, aplique a alteração ao rascunho atual e siga o processo de salvar, testar e publicar. Não trate a prévia como restauração implícita.

Considere um exemplo fictício: a política de retirada mudou de horário. A versão precisa apontar para a fonte correta e preservar as demais tarefas. Um segundo exemplo acrescenta cancelamento de pedido. Nesse caso, o contrato da ferramenta, a autorização e a confirmação de efeito também precisam de revisão. Ambos podem parecer mudanças pequenas no editor, mas o risco operacional é diferente.

Um documento, uma chave de acesso ou a conexão com outro sistema pode mudar mesmo sem alteração nas instruções do agente. Registre essas mudanças junto da publicação. Ao comparar versões, confira também o que mudou fora do agente; assim, uma falha na integração não será atribuída por engano à IA.

Combine validação estrutural com teste de atendimento

A validação do editor verifica condições necessárias à publicação, mas não substitui avaliação do atendimento. Uma configuração pode passar e ainda responder pela fonte errada ou confirmar um resultado indevido. Antes de publicar, use cenários com expectativa escrita: tarefa válida, informação ausente, correção do cliente, fonte indisponível e solicitação fora do escopo.

Para mudança de conteúdo, teste pergunta direta e pergunta com premissa antiga. A segunda revela se o agente corrige a informação pela fonte atual ou aceita a frase do cliente como verdade. Para mudança de ferramenta, confira parâmetros e retorno, além da resposta. Para escrita, confirme o estado persistido no sistema de ensaio.

Use texto para investigar decisões sem áudio e voz para avaliar entendimento, pronúncia e turnos. Não declare que o canal telefônico foi validado se todos os ensaios ocorreram no editor. Uma publicação pode estar correta e o número ainda apontar para outro agente. O canal escolhido precisa de verificação própria.

Depois de corrigir uma falha, repita um caso anterior que funcionava. Uma orientação ampla de encaminhamento pode eliminar a resposta errada e passar a transferir quase todos os pedidos. O teste de regressão mostra se a mudança preserva o escopo útil. Mantenha os casos que representam decisões distintas, sem duplicar perguntas apenas por variação de frase.

Quando a validação rejeitar a publicação, examine os campos indicados. Repetir a ação sem mudar a configuração não resolve uma exigência estrutural. A documentação informa que uma publicação rejeitada não substitui a definição publicada por uma inválida. Confira o histórico e corrija o rascunho conscientemente.

Confira a publicação em uma nova conversa

Depois de publicar, aguarde a confirmação e confira a versão no histórico. Em seguida, inicie uma nova conversa no canal pretendido com um caso que depende da alteração. Essa etapa verifica o comportamento disponibilizado, e não somente o texto no rascunho. Use uma pergunta que permita distinguir a regra nova da anterior.

Para telefonia, confira a associação do número ao agente. A documentação do Tigy ressalta que publicar não faz essa associação automaticamente. Um teste no número errado pode levar a concluir que a publicação falhou quando a configuração de canal é a causa. Revise destino e contexto antes de mexer novamente nas instruções.

Não use o resultado de uma sessão antiga como única prova da mudança. A orientação de publicação pede iniciar uma nova conversa. Registre a versão relevante e os detalhes do ensaio para que outra pessoa consiga reproduzir a verificação. Um comentário dizendo “pareceu funcionar” oferece pouca evidência para investigar uma divergência futura.

Confira a tarefa que você alterou e uma tarefa essencial que já funcionava. A publicação deve corrigir o problema sem prejudicar o que estava aprovado. Nas integrações, confirme qual sistema e ambiente foram usados: um teste com dados fictícios não comprova funcionamento no sistema que receberá clientes reais.

Se a nova conversa não apresenta a mudança, investigue publicação confirmada, agente selecionado, canal e dependências. Localizar a etapa evita publicar várias correções sem causa clara. O histórico ajuda a entender a definição, mas não explica sozinho toda alteração de conteúdo ou serviço externo.

Prepare uma correção que possa ser verificada

Uma mudança problemática precisa de um caso reproduzível. Registre a entrada e a diferença em relação à expectativa. Consulte a versão anterior para identificar o comportamento útil, mas revise também mudanças externas. Aplicar instruções antigas não corrige uma API que passou a devolver outro estado ou uma política que realmente mudou.

Use o rascunho atual para preparar a correção, salve, teste e publique conforme o processo documentado. Não anuncie restauração apenas por abrir uma prévia histórica. Depois, repita a verificação em nova conversa. O objetivo é disponibilizar uma configuração correta, com evidência, e não apenas encontrar uma tela em que o texto anterior aparece.

Informe à equipe operacional qual comportamento mudou e como identificar pendências. Se a versão anterior produziu registros incorretos, corrigir o agente não repara automaticamente esses registros. O responsável precisa avaliar o efeito externo e tratar as solicitações afetadas pelo procedimento da empresa.

Dê um responsável ao ciclo de versões

Defina quem aprova conteúdo, quem mantém ferramentas e quem decide a publicação. Uma única pessoa pode cumprir várias funções em um piloto pequeno, mas as responsabilidades precisam estar claras. Sem isso, uma mudança externa pode acontecer sem teste e uma correção pode ficar pronta sem ser publicada.

Mantenha uma nota breve com objetivo, versão, casos verificados e limitações. Essa informação ajuda a equipe a interpretar chamadas novas e a planejar a próxima alteração. O histórico técnico e a explicação operacional se complementam: um mostra o que foi disponibilizado, a outra mostra por que e com qual evidência.

Anote mudanças que o histórico não explica sozinho

Quando a publicação coincidir com uma mudança em outro sistema, registre as duas alterações. A conexão pode passar a enviar dados em outro formato, uma chave pode perder acesso ou um documento pode receber conteúdo novo. Comparar instruções ajuda, mas não mostra tudo que mudou. Considere a configuração completa utilizada na conversa.

Inclua na nota a verificação escolhida e o responsável pelo sistema externo. Isso facilita reproduzir a condição sem depender de lembranças de quem acompanhou a mudança.