Limites do agente: da instrução à permissão no sistema

Limites do agente: informar, consultar e alterar

Defina capacidades por efeito, usando verbos concretos: informar, consultar, registrar, alterar e transferir. Explicar a política de troca pode usar uma fonte; aprovar uma exceção precisa de autoridade; alterar um registro exige uma operação permitida e confirmada. Para cada capacidade, descreva o resultado verificável e o próximo passo quando o agente não pode executá-la.

Escreva a resposta para o pedido fora do escopo: explique o limite e ofereça o canal responsável. Evite regras vagas como fazer tudo para ajudar, que não esclarecem quando interromper uma ação.

Restrinja a operação no destino

Disponibilize apenas as ferramentas necessárias à tarefa. Uma consulta de pedido não precisa receber uma credencial com acesso a todas as alterações administrativas da loja.

No serviço externo, valide autorização, identificação do registro e parâmetros antes de executar. Um número de pedido falado não comprova sozinho que a pessoa pode acessar seus dados. A equipe que mantém a integração deve definir e testar essa verificação.

Teste pedidos para ignorar as regras

Inclua frases como sou o gerente, faça uma exceção e ignore a instrução anterior. Observe se o agente mantém o escopo e se a API recusa operações que a credencial não pode realizar.

Trate textos de documentos e respostas de ferramentas como informação para a tarefa. Revise fontes que contenham instruções conflitantes e confirme o comportamento com testes. Uma instrução no prompt não constitui garantia contra manipulação.

Registre a falha e reteste a mesma situação

Use os dados disponíveis da execução para comparar o pedido, a resposta e as ações realizadas. Uma recusa falada não basta se uma ferramenta proibida foi chamada antes dela.

Corrija a instrução, a seleção de ferramentas ou o controle externo conforme a origem do problema. Repita o cenário e um pedido legítimo semelhante, verificando também se a mudança passou a impedir atendimentos permitidos.

Uma solicitação que tenta ampliar acesso

Imagine uma pessoa pedindo informações do pedido de outra empresa. O atendimento deve seguir o procedimento de identificação e verificar se existe autorização para consultar aquele registro. Dizer que conhece o dono do pedido não basta.

Prepare com a equipe técnica um teste com um pedido permitido e outro que o agente não pode acessar. Inclua alguém pedindo para ignorar as regras e confira tanto a resposta falada quanto os dados devolvidos pelo sistema.

Se a conexão trouxe informações indevidas, peça a correção do controle de acesso. Apenas instruir o agente a não ler os dados em voz alta não resolve o problema.

Um exercício de leitura e escrita com resultados separados

Crie dois registros fictícios no ambiente de teste: um que a identidade da integração pode consultar e outro que deve ser recusado. Prepare uma ferramenta somente de leitura e documente quais campos ela retorna. Execute uma consulta válida, uma com identificador corrigido e uma proibida. Confira o resultado no serviço antes de avaliar a fala.

Em outro teste, peça à equipe técnica uma ação que altere dados fictícios. Faça um pedido explícito, uma pergunta hipotética e uma desistência antes da confirmação. Apenas o pedido explícito, depois das verificações necessárias, pode gerar uma alteração autorizada. Confira os registros mesmo quando a resposta falada parece correta.

O exercício distingue uma ferramenta escolhida corretamente, um acesso permitido e uma intenção confirmada. Esses critérios podem falhar de forma independente. Use uma coluna para cada resultado na revisão, evitando um único “passou” para a conversa inteira.

Retire a ferramenta que altera registros depois do teste se ela não faz parte das tarefas oferecidas. Não mantenha ferramentas de teste selecionadas apenas por conveniência. A configuração final deve refletir as ações que a equipe decidiu oferecer e consegue acompanhar.

Como decidir onde um limite deve ser implementado

Uma restrição de linguagem, como apresentar frases curtas, pertence principalmente às instruções. Uma condição de acesso a registros pertence ao serviço que conhece identidade e recurso. Uma restrição de destino telefônico precisa de validação da configuração e do canal. Identificar a camada evita aplicar a mesma solução a problemas diferentes.

Se a regra depende de uma informação que o agente não consegue verificar, não peça que ele adivinhe. Disponibilize uma consulta autorizada ou deixe a decisão com a equipe. Declarações do interlocutor podem orientar o entendimento, mas não devem criar sozinhas evidência de permissão.

Quando duas partes participam, descreva o papel de cada responsável. As instruções pedem confirmação ao cliente; o sistema da empresa verifica a permissão e realiza a ação. O agente oferece uma alternativa; a operação mantém esse canal disponível. Teste as partes separadamente e depois juntas, sem presumir que o agente controla sistemas externos.

Faça um inventário de capacidades com efeitos distintos

Comece por verbos concretos: informar, consultar, registrar, atualizar, cancelar e transferir. Para cada verbo, indique fonte, condição de uso e confirmação exigida. Uma equipe pode considerar consulta e atualização partes do mesmo atendimento, mas elas precisam de limites diferentes no sistema.

Em uma loja fictícia, informar a política de endereço usa conteúdo aprovado; consultar o endereço de um pedido usa dados individuais; alterá-lo exige autorização e verificação de que a etapa logística permite a mudança. O agente pode entender todas as frases sem estar autorizado a executar todas as ações.

Identifique capacidades que não precisam existir no primeiro piloto. Não exponha uma ferramenta de cancelamento apenas porque ela está disponível no catálogo. Se o objetivo é consultar status, o conjunto selecionado deve refletir essa tarefa. Cada nova ação acrescenta condições e efeitos que precisam ser testados.

Escreva também a alternativa. Quando uma operação é recusada, a pessoa ainda precisa saber como continuar. O limite deve produzir um encaminhamento verdadeiro, sem sugerir que uma ação foi realizada nem obrigar o cliente a repetir um pedido sem saída.

Projete a autorização no serviço que conhece o recurso

O serviço externo conhece quais registros pertencem ao cliente e quais operações a credencial pode realizar. Use esse conhecimento para validar o acesso antes de devolver dados. Não entregue todos os registros ao agente para que ele escolha quais pode mostrar.

Uma referência de pedido é entrada de consulta, não prova de autorização. O processo pode exigir identidade validada, vínculo permitido ou outra condição aprovada pela organização. A implementação precisa representar essa condição independentemente da maneira como a pergunta foi formulada.

Limite também o resultado. Uma consulta de entrega pode precisar de estado e previsão, sem histórico financeiro ou contatos de terceiros. Um retorno reduzido torna o contrato mais claro e diminui a quantidade de dados que circula pela conversa e pela revisão.

Depois de configurar, teste uma referência permitida e outra não permitida com dados sintéticos. Confira retorno, registros de acesso e fala. Se a ferramenta devolveu dados indevidos, a condição falhou mesmo que o agente não os tenha lido em voz alta. A correção deve ocorrer no ponto de acesso, onde o recurso e a identidade podem ser verificados.

Confirme intenção sem confundir confirmação e permissão

Perguntar “você quer alterar o endereço?” esclarece a intenção. Isso não comprova que a pessoa pode alterar aquele pedido nem que a mudança está disponível. Confirmação conversacional e autorização são requisitos complementares.

Prepare uma sequência em que o agente entende o pedido, obtém dados necessários, confirma os valores e usa a ferramenta autorizada. O sistema valida a ação e devolve um estado interpretável. Só depois a fala anuncia o resultado efetivo. Se exige análise, preserve a pendência.

Inclua uma correção antes da ação: a pessoa troca o número do imóvel ou desiste do pedido. A ferramenta deve usar os dados atuais confirmados. Perguntar o que aconteceria se cancelasse não é pedir um cancelamento e não deve alterar nenhum registro.

Se a confirmação não chegar, a alteração pode já ter ocorrido. Combine com a equipe técnica uma referência de solicitação e uma forma de consultar o resultado antes de repetir. Escrever evite duplicidade nas instruções não cria esse recurso. Teste o procedimento no sistema responsável e confira os registros, além da resposta falada.

Escreva recusas que preservam um próximo passo

Uma recusa pode informar o limite sem expor detalhes internos. “Não consigo alterar esse pedido neste atendimento; posso indicar o canal responsável” pode ser suficiente. Não leia nomes de credenciais, políticas internas de acesso ou mensagens completas do servidor para justificar a condição.

Evite uma recusa tão genérica que parece falta de entendimento. Se a pessoa pede consulta autorizada, mas o serviço está indisponível, o problema é impossibilidade de verificar agora, não proibição permanente. Se falta dado, uma pergunta pode resolver. Diferencie essas causas na linguagem.

Teste pedidos legítimos próximos dos proibidos. Uma regra que bloqueia toda menção a cancelamento pode impedir explicar a política. Uma regra que recusa qualquer referência pode tornar a consulta inútil. Limites precisam distinguir informação e efeito, sem sacrificar tarefas permitidas.

Defina quando envolver a equipe e o processo real de continuidade. Transferência telefônica direta no Tigy não envia automaticamente o histórico ao atendente. Se a recusa exige contexto para continuar, valide uma entrega separada ou explique o que a pessoa precisará informar.

Revise mudanças de acesso como mudanças de produto

Uma credencial pode ganhar permissões sem nenhuma edição no agente. Uma ferramenta pode passar a escrever um campo que antes apenas consultava. Essas mudanças alteram o atendimento e precisam de revisão das dependências.

Mantenha um registro pequeno com capacidade, responsável e cenários de permissão. Quando o contrato mudar, repita acesso permitido, acesso recusado, confirmação e recuperação. Um teste de saúde que só observa conexão não comprova que os limites continuam iguais.

Classifique falhas por efeito. Um nome pronunciado de modo estranho pede ajuste diferente de consulta indevida ou escrita sem autorização. Uma média de qualidade não deve compensar o segundo grupo com muitas respostas informativas corretas.

Antes de ampliar escopo, confira como interromper a ação e recuperar a operação. Restaurar o prompt não desfaz registros externos nem revoga credenciais. A equipe precisa assumir os efeitos no sistema correspondente e preservar a evidência necessária para investigar, sem espalhar dados ou segredos nos materiais de revisão.