Como preparar um agente no Tigy: prompts, conhecimento e contexto

Escolha a camada certa

As instruções dizem o que o agente deve fazer e como conversar. A base de conhecimento reúne documentos aprovados para consulta. O contexto é a informação disponível na conversa atual. As ferramentas conectam o agente a outros sistemas para consultar ou alterar dados, dentro das funções e permissões configuradas.

Enviar um arquivo não basta

Na Base de conhecimento, envie o documento e aguarde o processamento. Depois selecione a fonte no agente de prompt e salve. Um arquivo existente no workspace não deve ser presumido disponível para todos os agentes.

Teste uma pergunta cuja resposta esteja na fonte e outra que não esteja. Corrija organização, conteúdo e seleção antes de acrescentar instruções para compensar uma fonte ausente. O procedimento não é um treinamento personalizado do modelo.

Correções pertencem à conversa em curso

Exemplo fictício: a pessoa informa DEMO-17 e corrige para DEMO-71 antes da consulta. O agente deve confirmar o identificador corrigido e usá-lo na ferramenta. O destino ainda precisa verificar autorização.

Na próxima chamada, não presuma que DEMO-71 esteja automaticamente disponível. Se a tarefa exige continuidade, configure uma consulta autorizada ao sistema externo. Solicite e confirme informações ausentes sem colocar dados de um cliente nas instruções compartilhadas.

Revisar histórico não é memória automática

A área de execuções permite investigar registros quando disponíveis. Uma transcrição útil para a equipe não comprova que o agente vai recuperá-la na próxima conversa. Defina explicitamente como a continuidade será obtida e quais campos são necessários.

Evite copiar conversas reais completas para documentos de acesso geral. Para elaborar instruções, prefira exemplos sintéticos e regras sem dados pessoais. Revise fontes e permissões com os responsáveis antes de disponibilizá-las ao atendimento.

Melhore por hipótese e verificação

Se o agente respondeu uma política errada, investigue a fonte. Se confirmou um resultado sem consulta, revise instruções e ferramenta. Se usou o número antigo, verifique reconhecimento, confirmação e parâmetros enviados. Cada problema pede uma correção diferente.

Altere uma camada por vez e repita o pedido problemático junto de um caso válido. Registre a versão e o observado antes de publicar. Conversas ajudam a escolher mudanças; não prometem aprendizado permanente automático.

Configurar conhecimento é o mesmo que fazer fine-tuning?

Não. Fine-tuning é ajuste dos parâmetros de um modelo por treinamento adicional. Selecionar documentos prepara fontes para consulta; escrever um prompt define instruções; uma ferramenta consulta ou altera o sistema externo. A configuração documentada neste guia não promete fine-tuning personalizado nem aprendizado automático com cada chamada.

Escolha a mudança pela causa: política errada pede revisão da fonte; regra de confirmação ausente pede instrução; status desatualizado pede consulta ao sistema atual. Teste o caso que falhou e um caso válido após o ajuste. Histórico disponível para revisão não significa que outra conversa receberá aqueles dados automaticamente.

Localize o problema antes de escolher o ajuste

Quando um agente dá uma resposta ruim, é tentador acrescentar mais uma regra ao prompt. Esse ajuste ajuda se o problema está na condução da conversa, mas não corrige todos os tipos de falha. Uma política ausente precisa de uma fonte aprovada. Um pedido sem estado atualizado precisa de consulta ao sistema. Uma variável vazia precisa de tratamento para ausência. Uma ação indevida exige validação na integração. Diagnosticar a camada correta evita transformar o prompt em uma coleção de remendos que não resolve a causa.

Em uma loja fictícia, o agente pergunta novamente pelo número do pedido que o cliente acabou de informar. A informação está na conversa; o problema pode estar na instrução de usar dados já fornecidos ou no modo de confirmar o identificador. Em outra chamada, ele informa um prazo antigo porque a base contém a política anterior. Acrescentar “seja preciso” não substitui a atualização da fonte. Em uma terceira, a API devolve uma solicitação em análise e o agente anuncia conclusão: agora é preciso alinhar a interpretação dos estados e a linguagem permitida.

Descreva a falha observada antes de escrever a solução. Registre o que a pessoa pediu, qual evidência estava disponível, o que o agente fez e qual seria o resultado esperado. Esse pequeno diagnóstico distingue defeitos semelhantes na aparência. Uma resposta sem dado pode vir de documento não selecionado, consulta indisponível ou pergunta fora do escopo. Cada caso pede uma correção diferente.

“Treinar”, neste contexto, significa configurar e testar instruções, fontes, contexto e ferramentas do agente. Não significa que cada chamada altera automaticamente o modelo ou ensina uma regra permanente. A melhoria depende das mudanças que a equipe faz e da verificação de seus efeitos. Essa distinção ajuda a planejar um processo repetível, com decisões explícitas em vez de esperar aprendizado espontâneo.

Escreva comportamento observável em vez de qualidades vagas

Qualidades como “educado”, “inteligente” e “eficiente” são úteis para indicar intenção, mas não dizem como resolver uma situação difícil. Troque parte dessa abstração por comportamento observável. Em vez de apenas “seja objetivo”, instrua a fazer uma pergunta por vez e a não repetir dados já confirmados. Em vez de “resolva o problema”, defina a consulta que pode ser feita, o estado que permite a ação e a saída quando a ferramenta não responde.

Organize as instruções em papel, objetivo, condução, ferramentas e limites. O objetivo precisa ser pequeno o bastante para ser verificado em uma chamada. “Ajudar clientes a acompanhar pedidos” é mais fácil de avaliar que “encantar todo cliente em qualquer situação”. A segunda frase pode coexistir como orientação de tom, mas não substitui a definição do atendimento. Inclua exemplos breves de sucesso e de exceção, sem transformar o documento em um roteiro rígido que ignora a resposta do interlocutor.

Para cada regra nova, pergunte em qual teste ela será observada. “Use o identificador corrigido pelo cliente” pode ser verificado com uma chamada em que a pessoa troca um dígito. “Não confirme alteração sem retorno da ferramenta” pode ser verificado com falha ou estado pendente. Se não há maneira de distinguir cumprimento e descumprimento, talvez a regra esteja vaga ou combinando comportamentos demais. Divida-a até que a avaliação fique clara.

Evite repetir a mesma orientação em várias partes com palavras diferentes. Além de dificultar manutenção, uma repetição pode entrar em conflito com outra exceção. Quando uma regra muda, deve existir um lugar reconhecível para editá-la. Preserve as instruções sobre limites e sobre ausência de informação mesmo ao simplificar. Um prompt curto que omite o tratamento de falhas pode parecer elegante, mas deixar o agente improvisando exatamente nos casos mais difíceis.

Use fontes e contexto para resolver necessidades diferentes

Uma base de conhecimento deve responder perguntas sobre informações aprovadas que fazem sentido para o público do agente. Contexto inicial pode fornecer dados disponíveis antes da conversa. Ferramentas consultam ou alteram sistemas durante o atendimento quando configuradas para isso. Essas capacidades se complementam, mas não são substitutas automáticas. Colocar uma lista de pedidos em um documento compartilhado não cria uma consulta individual atualizada e autorizada.

Para uma operação fictícia de agendamento, a base pode explicar duração e preparação do serviço. O contexto inicial pode indicar a unidade procurada. Uma consulta de disponibilidade precisa verificar horários no sistema de agenda. Se o cliente mudar a unidade durante a ligação, a conversa deve considerar a correção e a integração deve consultar o local certo. Um valor inicial não deve ser tratado como verdade imutável quando a pessoa corrige o próprio pedido.

Prepare explicitamente o comportamento para valores ausentes. Se o nome não veio no contexto, o agente pode usar uma saudação neutra; não precisa inventar um nome nem interromper o atendimento para obtê-lo sem necessidade. Se a unidade está ausente e muda a resposta, uma pergunta curta resolve. A distinção entre dado opcional e condição essencial impede que campos vazios causem bloqueios desnecessários.

Nos documentos, confira processamento concluído, associação ao agente e conteúdo pertinente. Teste uma pergunta direta, uma pergunta que exige outro trecho e uma pergunta não coberta. Nas ferramentas, teste retorno válido, estado pendente e erro. No contexto, teste valor correto, vazio e corrigido. Essas verificações separadas mostram de onde vem a informação e como o agente deve agir quando uma peça falta. Só depois avalie a conversa completa, em que essas capacidades aparecem juntas e podem produzir efeitos diferentes.

Faça uma revisão que possa ser repetida depois de cada mudança

Um processo de melhoria começa com uma versão de referência e uma coleção pequena de chamadas representativas. Inclua pedidos comuns, correções do cliente, silêncio, perguntas fora do escopo e falhas de integração. Registre o resultado esperado de cada caso. Sem essa referência, uma nova versão pode parecer melhor porque foi testada com perguntas mais fáceis ou porque o revisor se concentrou apenas no problema recém-corrigido.

Altere uma causa principal por vez quando isso for viável. Se você altera ferramentas, reescreve prompt e substitui documentos simultaneamente, fica difícil explicar por que o resultado mudou. Em uma correção urgente, várias alterações podem ser necessárias, mas registre quais foram feitas e preserve os cenários anteriores. O objetivo não é transformar revisão em burocracia; é permitir que a equipe entenda uma regressão e saiba o que investigar primeiro.

Avalie tanto a resposta quanto o resultado real. O agente pode dizer “não consegui registrar” mesmo que o pedido exista no sistema, ou anunciar sucesso sem que ele tenha sido criado. Para alterações, confira o registro com a equipe responsável. Para consultas, compare a resposta com os dados recebidos. Para orientações, confira se a regra está na fonte aprovada.

Depois de publicar uma versão, use uma amostra de atendimentos para descobrir variações que não estavam na coleção inicial. Transforme falhas recorrentes em testes permanentes e atribua um responsável pela correção. Um bom ciclo de melhoria deixa claro o que mudou, por que mudou e qual evidência sustenta a mudança. Ele também preserva limites: se a fonte continua ausente ou a operação continua sem autorização, o agente deve explicar a restrição. Mais configuração só representa avanço quando torna o atendimento correto, útil e verificável.