Guia do Agentforce sobre como garantir um comportamento confiável do agente: uma estrutura de 6 níveis de determinismo

Olfa Kharrat, Diretora de gerenciamento de produtos - Agentforce
Reinier van Leuken, Diretor sênior de gerenciamento de produtos - Agentforce

A confiança tem sido o valor nº 1 da Salesforce desde a sua fundação, em 1999, quando foi pioneira em um novo modelo tecnológico de cloud computing e SaaS. As empresas confiam na Salesforce ao armazenar dados corporativos valiosos na nuvem, com a certeza de que esses dados estão seguros e regidos pelos controles de acesso adequados. Isso continua sendo essencial, mas, na era da IA de agentes, a definição de confiança é ainda mais ampla. À medida que as empresas passam a depender cada vez mais de agentes autônomos para executar funções de negócios críticas, esses agentes precisam se tornar parceiros de negócios confiáveis, cujo trabalho seja preciso, relevante e, acima de tudo, confiável.

Então, como criar um agente confiável? Confiabilidade normalmente significa gerar o mesmo resultado para a mesma entrada. No entanto, os agentes nem sempre funcionam assim, pois são movidos por grandes modelos de linguagem (LLMs), que são, por natureza, não determinísticos. Isso dá aos agentes a flexibilidade de desenvolver soluções criativas adaptadas a circunstâncias específicas, sem a necessidade de programar explicitamente cada condição ou situação que enfrentam. Ainda assim, os agentes precisam de governança para atender aos requisitos de negócios e seguir as diretrizes operacionais. Ao executar processos de negócios, eles devem demonstrar confiabilidade e entregar resultados alinhados a restrições determinísticas. O determinismo impõe uma rigidez e uma disciplina que entram em choque com a autonomia e a flexibilidade que os agentes proporcionam. Portanto, a chave para criar agentes bem-sucedidos é encontrar o equilíbrio certo entre fluidez criativa e controle corporativo.

Este documento aborda as principais considerações para o desenvolvimento de agentes confiáveis. Ele define seis níveis de controle de agentes e fornece as práticas recomendadas para obter e manter o controle sobre o comportamento do agente em cada um desses níveis. A orientação aborda as maneiras pelas quais o motor de raciocínio do Agentforce funciona. À medida que o Agentforce se expande, este documento será atualizado para refletir as práticas recomendadas mais recentes.

Este documento pressupõe familiaridade básica com o design e a criação de agentes no Agentforce. Para uma introdução ao Agentforce, recomendamos o seguinte:

• Consulte os recursos em agentforce.com.
• Siga a trilha Torne-se um campeão do Agentblazer . Essa trilha explora os principais conceitos de IA e ajuda você a criar um agente básico para tarefas essenciais.
• Leia mais sobre o Agentforce em help.salesforce.com , especificamente em Projetar e implementar agentes . Este mapa de aprendizado orienta você por todas as etapas principais do ciclo de vida: desde a concepção da solução até a configuração do agente, incluindo testes, implantação e monitoramento.

Para entender melhor o comportamento dos agentes, vamos primeiro compará-los com seus equivalentes mais rígidos: os chatbots.

Chatbots: Seguem regras com rigidez

Os chatbots seguem árvores de decisão predefinidas que estruturam os diálogos em que podem participar. A navegação por essas árvores de decisão é determinada pelas respostas fornecidas pelo usuário. Essa resposta pode ser escolhida a partir de um conjunto predefinido de opções ou pode ser um texto livre. No caso de uma resposta em texto livre, utiliza-se um modelo preditivo para classificação de intenção. Essas árvores mapeiam todos os caminhos possíveis da conversação e determinam as respostas do chatbot em cada etapa. O comportamento do chatbot é rigidamente definido por regras pré-estabelecidas. Se a entrada do usuário não corresponder a um caminho reconhecido, ou se o modelo preditivo não tiver sido treinado para reconhecer uma determinada intenção, o chatbot não conseguirá responder adequadamente.

Agentes: Adaptáveis e intuitivos

Em contraste, os agentes utilizam o poder dos LLMs e seus recursos avançados em processamento de linguagem natural (NLP). Os LLMs permitem que os agentes compreendam a intenção por trás da entrada do usuário, mesmo que ela seja expressa de forma inesperada. Com base nessa compreensão da intenção, o agente pode selecionar a ação mais adequada entre várias possibilidades. Um agente pode até mesmo formular respostas totalmente novas. Essa flexibilidade e adaptabilidade diferenciam os agentes de seus equivalentes em chatbots.

Uma analogia culinária

A diferença entre chatbots e agentes pode ser comparada ao contraste entre um cozinheiro iniciante e um chef experiente.

• O cozinheiro iniciante (chatbot) depende fortemente de uma receita detalhada, com medidas precisas, instruções passo a passo e tempos de preparo específicos. Qualquer desvio da receita resulta em um desastre culinário. Da mesma forma, um chatbot precisa operar dentro dos limites de sua árvore de decisão pré-programada.
• Já o chef experiente (agente) possui anos de prática culinária e intuição. Com uma compreensão geral das suas preferências e uma breve descrição dos ingredientes disponíveis, ele pode preparar uma refeição deliciosa que atenda às suas necessidades. As etapas podem variar a cada preparo, e cada versão do prato pode trazer diferenças sutis, mas o resultado final é sempre satisfatório. Da mesma forma, um agente pode adaptar sua abordagem com base no contexto e na intenção da entrada do usuário, resultando em uma interação bem-sucedida.

Em resumo, a diferença fundamental entre agentes e chatbots está em sua adaptabilidade e na capacidade de lidar com entradas inesperadas.

Uma característica distinta da inteligência de um agente está em sua capacidade de orquestrar e acionar as ações mais adequadas no momento certo. Essa flexibilidade elimina a necessidade de programar detalhadamente cada possível interação do usuário.

No Agentforce, criar um agente envolve tópicos, ações e instruções e descrições em linguagem natural.

Tópicos

Os tópicos são os "trabalhos a serem realizados" pelo agente. Eles têm atributos como descrição de classificação, escopo e instruções que definem cada trabalho e como deve ser executado. Os tópicos contêm ações que o agente pode executar, juntamente com instruções que determinam como essas ações são realizadas.

Ações

As ações são as tarefas predefinidas que o agente pode executar para realizar seu trabalho. Existem cinco tipos de ações:

• executar código Apex
• chamar uma API
• executar um fluxo
• obter uma resposta de LLM a partir de um modelo de prompts
• chamar um modelo preditivo

Instruções e descrições em linguagem natural

A definição de um agente contém instruções em linguagem natural que descrevem os ativos do agente e definem as diretrizes dentro das quais ele deve operar. As instruções são aplicadas tanto às ações quanto aos tópicos.

• Ações. Uma ação contém:
  • Instruções que descrevem o que a ação faz e que informam ao motor de raciocínio quando executá-la.
  • Entradas com uma descrição em linguagem natural para que o agente possa prepará-las.
  • Saídas com uma descrição em linguagem natural de como formatá-las e usá-las.
• Tópico. Um tópico contém instruções que definem como executar suas ações em um nível superior. Por exemplo, as instruções podem especificar proteções quanto ao tom de voz, à sequência desejada de ações, a possíveis pré-requisitos ou ao momento de encaminhar conversas para humanos. O tópico também contém uma descrição de classificação e uma definição de escopo. Tudo isso garante que o agente permaneça dentro do escopo de seu papel definido e execute a tarefa.
• Dados. Os agentes precisam de dados para ter sucesso em suas funções. Os dados podem ser estruturados, como dados de CRM, ou não estruturados, como artigos da base de conhecimento da empresa. Os agentes acessam dados usando entradas de ação. Por exemplo, uma ação pode chamar um modelo de prompts baseado em dados de CRM ou enriquecido com blocos de dados não estruturados usando técnicas de geração aumentada por recuperação (RAG).

Esses vários elementos básicos, quando configurados corretamente, ajudam um agente a cumprir sua finalidade enquanto opera dentro dos limites apropriados.

O motor de raciocínio do Agentforce orquestra esses elementos básicos para gerar o comportamento de agentes correto. Ele utiliza as instruções e descrições em linguagem natural definidas em tópicos e ações. É baseado no ReAct, um novo paradigma de raciocínio para LLMs introduzido em 2022 por Yao et al.. Esse paradigma imita o gerenciamento de tarefas humanas ao raciocinar sobre um problema, executar uma ação, observar os resultados e repetir o ciclo até a conclusão da tarefa.

Os agentes da Salesforce seguem esse paradigma:

1. Reason: Compreender a intenção do usuário e alinhá-la ao tópico e às ações corretas.
2. Act: Iniciar a cadeia correta de ações.
3. Observe: Avaliar os resultados da ação em relação à intenção do usuário. Se a intenção não for atendida, raciocinar novamente com base no resultado obtido até o momento e nas instruções e descrições de tópico/ação. Se a intenção for atendida, fornecer a resposta final seguindo as possíveis instruções de formatação.
4. Repeat: Repetir essas etapas até que a etapa final instruída seja alcançada.

O motor de raciocínio usa LLMs em todas as etapas de Reason e Observe. Dependendo do tipo de ação, ele também pode usar LLMs na etapa Act.

Esta seção descreve uma abordagem em camadas para aprimorar o determinismo dos agentes. Cada nível se baseia no anterior, com maior complexidade e recursos que estabelecem mais controle sobre o comportamento do agente.

O primeiro nível se concentra em permitir que os agentes identifiquem tópicos relevantes de forma autônoma e, em seguida, selecionem as ações apropriadas com base em metas em vez de instruções explícitas. O mecanismo principal envolve o uso de uma compreensão contextual para responder às entradas do usuário. Embora tecnicamente qualquer tipo de ação possa ser adicionado, nesse nível presumimos que as ações sejam ações de prompt. Tópicos sem instruções com ações de prompt oferecem uma forma rápida e eficiente de lidar com consultas comuns.

Nesse nível, a ênfase está em estabelecer uma base de capacidade de resposta e autonomia dos agentes por meio de uma compreensão dinâmica.

Com base na seleção de ações sem instruções, esse nível introduz instruções explícitas para orientar o comportamento do agente. Adicionar instruções precisas aumenta o controle sobre como os agentes respondem a diferentes situações. As instruções aos agentes podem ser expressas como regras, diretrizes, proteções e exemplos. Essas instruções fornecem ao agente uma orientação específica sobre como lidar com diversos tópicos, executar ações e processar seus resultados. O objetivo desse nível é fornecer uma orientação clara ao agente para aumentar a consistência e melhorar a conformidade com as diretrizes e processos da empresa.

A fundamentação envolve conectar a compreensão e as respostas do agente a fontes externas de conhecimento. Ela ajuda a garantir que as informações fornecidas pelo agente sejam mais precisas, atualizadas e relevantes. Esse nível integra o acesso a bancos de dados, bases de conhecimento e outros repositórios de informações. Basear as respostas do agente em dados verificados aumenta sua confiabilidade e credibilidade.

Esse nível adiciona a capacidade de os agentes trabalharem com variáveis. As variáveis permitem que os agentes personalizem interações, mantenham o contexto em várias interações e ajustem dinamicamente seu comportamento com base em pontos de dados específicos mantidos durante a sessão do agente. Por exemplo, um agente pode capturar as preferências do usuário, detalhes do pedido e outras informações relevantes e, em seguida, usar esses dados para personalizar a interação. Com variáveis, os agentes conseguem lidar melhor com interações mais complexas, predefinidas e personalizadas.

Esta etapa integra o agente às principais funcionalidades do Salesforce: Apex, APIs e fluxo. A integração permite que o agente realize ações complexas no ecossistema da Salesforce, como acessar e manipular dados, acionar fluxos de trabalho e interagir com outros sistemas.

• O Apex fornece controle programático.
• As APIs permitem integração perfeita com outros apps
• Os fluxos permitem a automação de processos de negócios complexos.

Esse nível transforma o agente em uma ferramenta poderosa, capaz de executar tarefas sofisticadas e contribuir diretamente para os resultados de negócios.

Com base nas integrações técnicas do Nível 5, esse nível final introduz o raciocínio determinístico para preencher a lacuna entre a IA probabilística e a lógica de negócios rígida. Embora os níveis anteriores dependam do LLM para decidir qual ferramenta usar, o Script do agente permite que você "codifique" o próprio processo de raciocínio. Ao usar uma tela no estilo de documento ou um código direto, você pode definir caminhos imutáveis, como portas de autenticação obrigatórias, ramificação condicional if/else e transições forçadas de tópicos, que o agente deve seguir independentemente da entrada do usuário. Essa abordagem de raciocínio híbrido permite que você integre a flexibilidade conversacional de um LLM a camadas de execução garantida. O Nível 6 transforma o agente em um parceiro de nível empresarial zero trust, capaz de lidar com conformidade de alto risco, divulgações regulatórias e dependências complexas em várias etapas com precisão absoluta.

Começando com uma linha de base de capacidade de resposta e autonomia do agente, considere um agente que consiste apenas em tópicos e ações, com suas descrições correspondentes. Podemos usar esse agente de exemplo para apresentar as diferentes etapas do motor de raciocínio e mostrar como ele utiliza essas descrições para selecionar os tópicos corretos e, em seguida, as ações a serem executadas. Ao omitir as instruções de tópicos deste exemplo, podemos observar que os agentes nesse primeiro nível têm o maior grau de liberdade quando comparados com agentes de níveis superiores. No nível um, o agente tem total liberdade para selecionar a ação que considera apropriada, com base exclusivamente na conversa em andamento.

Analise as seguintes considerações para o motor de raciocínio:

• As definições de configuração são fixas para o LLM do motor de raciocínio. Os criadores de agentes não podem alterá-las. Atualmente, o criador de agentes pode escolher entre um LLM da OpenAI ou um LLM da Anthropic hospedado na infraestrutura da Salesforce para fins de raciocínio. Isso está sujeito a alterações à medida que mais modelos são adicionados.
• Histórico padrão do motor de raciocínio: Sempre que uma solicitação é feita ao motor de raciocínio (etapas 2 a 5), ele recupera automaticamente o histórico das solicitações e respostas mais recentes. Isso garante que o contexto da conversa seja mantido para o motor de raciocínio. Além das interações com o cliente, essas chamadas para o LLM do planejador incluem chamadas para o LLM do motor de raciocínio para outras solicitações, como seleção de tópicos.

O processo de raciocínio envolve quatro etapas principais:

1. Seleção de tópicos
2. Seleção de ações
3. Ciclos agentes
4. Verificação de fundamentação

Os tópicos são projetados para melhorar a precisão com que os agentes classificam a ação ou a sequência de ações correta. Cada tópico deve consistir em ações semanticamente distintas, todas pertencentes a uma descrição concisa do tópico e, portanto, relacionadas a uma função de agente semelhante.

O tópico correto é selecionado pelo LLM do motor de raciocínio (etapa 2-3 do diagrama). Ele seleciona o tópico cuja descrição de classificação mais se aproxima do último enunciado, usando um prompt de tópico. Esse prompt de tópico contém as descrições de classificação de todos os tópicos e o histórico da conversa. Além de enunciados e respostas dos agentes, o histórico da conversa inclui as ações executadas e seus resultados. Além disso, o prompt incorpora instruções cruciais que exigem análise dentro do contexto do histórico da conversa e obrigam o LLM a compartilhar seu processo de raciocínio.

Considerações adicionais:

• Existe automaticamente um tópico oculto adicional para enunciados "fora do tópico", junto com os tópicos visíveis. Este tópico é selecionado quando nenhum outro tópico existente se alinha ao enunciado. Isso ajuda o agente a evitar classificações incorretas. Este tópico não tem ações. Ele existe apenas para ajudar o motor de raciocínio a formular uma resposta apropriada mais tarde.
• No prompt do tópico, são usados apenas o nome e a descrição da classificação.
• O LLM do motor de raciocínio pode escolher apenas um tópico por vez.
• As conversas podem mudar inesperadamente. Sempre que um enunciado é recebido, o motor de raciocínio avança para a etapa de seleção de tópicos, o que significa que um novo tópico pode ser selecionado a cada enunciado.

O objetivo dos tópicos é duplo:

1. Reduzir o risco de confundir o motor de raciocínio agrupando ações, evitando que ele selecione as ações incorretas.
2. Orientar a seleção e a execução de ações com instruções (mais sobre isso no Nível 2: Controle de agentes: adicionar instruções).

Ao organizar cuidadosamente as capacidades do agente em tópicos claramente definidos, compostos por ações relacionadas, o agente opera de forma mais eficaz e previsível, além de ser mais fácil de atualizar e expandir. Há duas abordagens possíveis para o design de tópicos: de cima para baixo e de baixo para cima.

• Na abordagem de cima para baixo, os tópicos são projetados primeiro como trabalhos de alto nível a serem realizados pelo agente, e as ações individuais são então definidas para esses tópicos.
• Na abordagem de baixo para cima, primeiro todas as ações individuais são definidas e, em seguida, agrupadas em tópicos.

Ambas as abordagens levam a bons resultados quando aplicadas corretamente.

Abordagem de baixo para cima

Esta seção detalha a abordagem de baixo para cima, pois ela se alinha de perto aos motivos pelos quais o motor de raciocínio precisa de tópicos desde o início.

Etapa 1: Liste todas as ações do agente

Comece listando todas as ações específicas que o agente deve ser capaz de executar. Nesse estágio, é melhor ser muito específico do que excessivamente geral. Evite tentar agrupar ou simplificar ações prematuramente. O objetivo é criar uma visão abrangente e detalhada do que o agente pode fazer.

Por exemplo, no caso de um agente de atendimento ao cliente, a lista inicial pode incluir:

• Devolver um pedido: usado para iniciar o processo de devolução de um pedido.
• Verificar a disponibilidade em estoque: usado para verificar se um produto está disponível.
• Verificar as políticas de troca de produtos: usado para recuperar informações sobre regras de troca.
• Responder perguntas com base em conhecimento: usado para responder perguntas gerais ou no estilo FAQ.
• Verificar promoções: usado para verificar promoções ou descontos disponíveis.
• Prever data de entrega: usado para estimar a data/hora prevista de entrega.
• Verificar status do pedido: usado para encontrar o status atual do pedido de um cliente.
• Encontrar pedidos de clientes: usado para recuperar todos os pedidos anteriores ou ativos de um cliente específico.
• Solucionar problemas técnicos: usado para resolver problemas técnicos com um produto ou serviço.
• Encontrar termos do pedido: usado para recuperar todos os termos relacionados a um pedido.
• Encontrar ativos do cliente: usado para identificar ou recuperar ativos associados a um cliente.
• Alterar endereço de entrega.

Observe que uma ação como "Resolver reclamações de clientes" é ampla demais neste ponto. As ações devem representar o menor nível de granularidade no comportamento do agente. As reclamações podem ser de vários tipos, e diferentes ações já as abrangem:

• Problemas pós-entrega, como solução de problemas de produtos danificados ou com mau funcionamento, já estão cobertos por "Solucionar problemas técnicos".
• Problemas de pré-entrega, como entregas ausentes, necessidade de alterar datas de entrega ou modificação de pedidos, já estão cobertos por ações como "Verificar status do pedido", "Prever data de entrega" ou "Devolver um pedido".
• Preocupações gerais de clientes, como consultas sobre políticas, já estão cobertas por "Responder perguntas com conhecimento" ou "Verificar políticas de troca de produtos".

Etapa 2: Marque pares de ações (ou múltiplos) que possam causar confusão no raciocínio.

Marque ações de natureza semelhante, pois elas podem confundir o motor de raciocínio. Suas descrições podem não ser suficientemente diferentes do ponto de vista semântico e, portanto, o motor de raciocínio não saberá qual ação selecionar na etapa 5.

Por exemplo, "Solucionar problemas técnicos" e "Responder perguntas com conhecimento" têm descrições semelhantes, mas suas funcionalidades podem ser significativamente diferentes. Marcar essas sobreposições semânticas ajudará a identificar quais ações separar em vários tópicos.

Etapa 3: Crie agrupamentos iniciais de ações em tópicos

Quando as ações estiverem claramente definidas e suas sobreposições semânticas identificadas, elas poderão ser agrupadas em tópicos preliminares. Um tópico é uma categoria lógica de funcionalidade: um agrupamento de ações que, juntas, representam uma capacidade ou habilidade coerente do agente.

Ao criar esses agrupamentos:

• Evite sobreposição semântica usando o menor número possível de tópicos.
• Certifique-se de que cada tópico contenha ações que tenham relação significativa entre si.
• Garanta que as ações de suporte que precisam ser executadas em cadeia estejam presentes no mesmo tópico.

Aqui está um exemplo de agrupamento inicial para um agente de atendimento ao cliente:

Tópico 1:

• Devolver um pedido
• Verificar a disponibilidade do estoque
• Verificar políticas de troca de produtos
• Verificar promoções
• Prever data de entrega
• Encontrar termos de pedidos de clientes
• Verificar status do pedido
• Encontrar pedidos de clientes
• Encontrar ativos do cliente
• Responder perguntas com conhecimento
• Alterar endereço de entrega

Tópico 2:

• Solucionar problemas técnicos
• Encontrar ativos do cliente

Etapa 4: Escreva descrições de classificação para tópicos e divida-os, se necessário

Depois de obter o agrupamento inicial, escreva descrições de classificação para cada tópico.

• O tópico 2, em nosso exemplo, trata claramente de problemas técnicos com produtos.
• O tópico 1, no entanto, cobre um escopo mais amplo. Ele é em grande parte sobre gerenciamento de pedidos, mas contém algumas ações que não estão relacionadas a isso, como verificar promoções e responder perguntas com conhecimento. O tópico 1 não pode ser descrito de forma clara e concisa em uma única frase e, portanto, deve ser dividido em tópicos diferentes.

Após o refinamento, temos:

• Tópico 1: Gerenciamento de pedidos: Descreve ações relacionadas ao gerenciamento e à modificação de pedidos de clientes e à logística relacionada, exceto qualquer coisa ligada a troca e devolução.
  • Verificar a disponibilidade do estoque: Determine se um produto está em estoque.
  • Prever a data de entrega: Estime quando um pedido chegará.
  • Verificar o status do pedido: Encontre o status do pedido de um cliente.
  • Encontrar pedidos de clientes: Recupere todos os pedidos feitos por um cliente.
  • Alterar endereço de entrega.
• Tópico 2: Solução de problemas
  • Encontrar ativos do cliente: Recupere os dispositivos ou produtos registrados do cliente.
  • Solução de problemas técnicos: Forneça assistência técnica ou diagnósticos.
• Tópico 3: Troca: Descreve ações relacionadas à troca e devolução de pedidos.
  • Devolver um pedido: Inicie o processo de devolução de pedidos.
  • Verificar as políticas de troca de produtos: Forneça regras de troca para produtos.
  • Encontrar pedidos de clientes: Recupere todos os pedidos feitos por um cliente.
  • Encontrar termos de pedidos de venda: recupere todos os termos relacionados a um pedido.
• Tópico 4: Suporte ao produto: Descreve ações transversais usadas para recuperação e roteamento de informações.
  • Responder perguntas com conhecimento: Responda às dúvidas gerais dos clientes usando informações da base de conhecimento.
  • Verificar promoções: Veja promoções ou descontos atuais.

Para recapitular, primeiro crie uma lista abrangente de todas as ações possíveis e marque a sobreposição semântica entre essas ações. Em seguida, crie um conjunto de tópicos que, no mínimo, resolva toda a sobreposição semântica (para que o motor de raciocínio não fique confuso dentro dos limites de um tópico). Depois, escreva a descrição de classificação de cada tópico. Se os tópicos forem muito amplos, divida-os em tópicos mais granulares. Ao implementar essas orientações, você pode criar um agente que não apenas tenha um bom desempenho, mas também seja fácil de manter e ampliar.

Essa estrutura oferece suporte a um melhor raciocínio, uma execução mais precisa e limites de decisão mais claros dentro do comportamento do agente. Também depende da colaboração entre designers, engenheiros e especialistas no assunto para tornar os recursos do agente mais transparentes e modulares.

Considerações adicionais para a criação eficaz de tópicos

• Número ideal de tópicos: Para melhorar o desempenho dos LLMs na classificação do tópico certo, geralmente é recomendável não exceder 10 tópicos. Mas isso é apenas uma regra prática. Além disso, cada tópico deve ter uma descrição clara e distinta. Em última análise, o número ideal de tópicos depende da distância semântica entre as descrições de classificação de tópicos. Se os tópicos tiverem descrições de classificação muito diferentes, o risco de sobreposição de tópicos será minimizado. Mais práticas recomendadas para evitar sobreposição entre tópicos são descritas aqui .
• Equilibre o tamanho e a clareza do tópico: Em geral, é útil ter tópicos pequenos em termos de ações e instruções para facilitar a classificação, mas criar tópicos demais com descrições muito semelhantes pode gerar confusão, assim como a sobreposição semântica entre as ações leva a classificações incorretas. Portanto, é importante ter descrições de tópicos claramente diferenciadas semanticamente. Você pode usar LLMs para ajudar a criar essas classificações bem diferenciadas.
• Linguagem padrão e clareza contextual: Os LLMs podem não estar cientes dos significados e abreviações específicos de uma empresa ou setor. Use uma linguagem padrão ou seja muito explícito ao explicar os significados das palavras em seu contexto específico.
• Apenas o nome e a descrição do tópico são enviados no prompt do tópico. Portanto, alterar o escopo ou as instruções do tópico não terá impacto na seleção do tópico.

Exemplo em ação

Imagine que um agente de serviço receba uma solicitação de política de garantia para um relógio. O problema de garantia não parece estar relacionado à troca ou ao suporte do produto. O gerenciamento de pedidos parece ser o tópico mais apropriado para atender a essa solicitação. Por isso, o último tópico é escolhido pelo motor de raciocínio como o mais provável para atender ao pedido.

Após a seleção do tópico, o motor de raciocínio seleciona as ações certas a serem executadas no tópico selecionado. Novamente, o LLM do motor de raciocínio é responsável por isso, usando outro prompt chamado prompt de observação. O objetivo do prompt de observação é obter a próxima etapa do processo de raciocínio. A próxima etapa pode ser qualquer uma das seguintes opções:

• Lançar uma ação
• Solicitar entradas de ação do usuário
• Solicitar esclarecimentos sobre a solicitação do usuário
• Enviar a resposta final ao usuário (atendendo à solicitação do usuário) quando o ciclo de ação estiver concluído (consulte a Etapa de raciocínio 3 para obter mais detalhes)

A entrada no prompt de observação é formada por todas as descrições de todas as ações do tópico, bem como do histórico da conversa.

Práticas recomendadas para design de ação

As ações são as tarefas predefinidas que o agente pode executar para realizar seu trabalho. As ações são as definições mais detalhadas de trabalho. Há cinco tipos diferentes de ações do agente: (1) executar código Apex, (2) chamar uma API, (3) executar um fluxo, (4) obter uma resposta de LLM a um modelo de prompt e (5) chamar um modelo preditivo. A maioria dessas ações pode ser determinística. Uma exceção é obter uma resposta a um modelo de prompts (desde que a ação externa do sistema, do Flow ou do Apex não contenha elementos probabilísticos, como invocações de prompt). Abordaremos essas questões no quinto nível de controle de agentes.

1. Controlar o comportamento do agente em ações de prompt: Há duas maneiras de implementar controle sobre o comportamento do agente em ações de prompt: (1) adicionar mais instruções ao modelo de prompts por meio da engenharia de prompts e (2) configurar os hiperparâmetros do LLM que gera a resposta ao prompt, especialmente a temperatura (consulte a documentação ). A redução da temperatura reduz a variabilidade nas respostas geradas, o que aumenta sua repetibilidade e a confiabilidade do agente.
2. Número ideal de ações dentro de um único tópico: De forma semelhante ao número máximo de tópicos, o número de ações dentro de um tópico não deve exceder 10. Mas, novamente, essa é uma regra prática. O verdadeiro fator determinante é a distância semântica entre as ações. Quando as ações são claramente distinguíveis por sua descrição, esse número pode ser maior. No entanto, não há medida numérica para a distância semântica; isso depende da interpretação do criador de agentes. Quanto maior a diferença de significado entre as descrições das ações, maior a distância semântica. A sobreposição deve ser evitada em todos os momentos aqui.
3. Descrições das ações: Ao contrário do que o nome sugere, a "instrução da ação" na verdade funciona como uma instrução que o LLM do motor de raciocínio usa para selecionar a ação correta do tópico. Observe que o uso de descrições de ações semanticamente distintas pode melhorar significativamente a qualidade de suas classificações. Analise cuidadosamente essas descrições e, especialmente, compare todas as descrições de ações pertencentes a um único tópico.

Exemplo em ação

Vamos continuar com o exemplo anterior em que um agente de serviço recebeu uma pergunta sobre a política de garantia de um relógio. Depois de selecionar o tópico Gerenciamento de pedidos, a ação mais provável é escolhida. Como esse é o tópico de gerenciamento de pedidos, a primeira etapa lógica é pesquisar o pedido (caso contrário, para que recuperar as informações de garantia?) iniciando a ação de pesquisa de pedido.

Um enunciado do usuário pode acionar a execução de várias ações antes que uma resposta seja enviada de volta ao usuário. Isso se deve aos ciclos agentes, que continua selecionando e executando a próxima ação mais adequada até que uma das seguintes condições seja atendida:

• O LLM do motor de raciocínio determina que a solicitação está concluída. Nesse caso, ele descobre que a solicitação do usuário é atendida pela resposta. Observe que parte dessa verificação inclui uma verificação de fundamentação, verificando se a resposta está fundamentada nas saídas da ação. Nenhuma informação na resposta deve ser inventada pelo LLM do motor de raciocínio, pois isso pode levar a alucinações ou a respostas incorretas.
• Nenhuma ação adequada é encontrada.
• O máximo permitido de chamadas de LLM para a etapa atual é atingido. Esse número é definido pelo próprio motor de raciocínio.

As ações não estão sujeitas a um tempo limite específico. Isso serve para evitar interrupções quando os tempos de execução da ação variam de acordo com sua complexidade. Algumas ações são simplesmente mais complexas de executar do que outras.

Exemplo em ação

Depois de iniciar uma pesquisa de pedido, o motor de raciocínio avalia a resposta gerada até o momento e decide que precisa realizar mais etapas antes que uma resposta possa ser enviada de volta ao usuário. Ele está prestes a consultar a política de garantia, agora que o pedido está presente no histórico da conversa.

No entanto, ao fazer isso, o agente percebe que o cliente realmente comprou dois relógios, conforme retornado pela ação "pesquisa de pedidos". Portanto, nos ciclos agentes, o motor de raciocínio agora decide pedir ao cliente que especifique para qual relógio específico precisa de informações de garantia.

Evite excesso de scripts

Evite criar scripts excessivos sobre como os agentes devem conversar com os usuários. O excesso de scripts pode limitar a capacidade de um agente de criar afinidade, compreender as necessidades específicas do usuário e responder de forma eficaz, em tempo real, a circunstâncias dinâmicas. Além disso, instruções muito longas podem tornar o agente mais lento para responder e confundir o motor de raciocínio. Forçar o determinismo por meio de instruções não é a abordagem preferida.

O que não fazer

Por exemplo, não é necessário instruir um agente a evitar referências a concorrentes em respostas de atendimento. Isso pode levar a um comportamento indesejado, pois o agente também pode se recusar a responder perguntas referentes à integração com um provedor que também seja concorrente. Em vez disso, a instrução pode ser algo como "ao discutir concorrentes, responda tendo em mente o melhor interesse da empresa". Isso evita instruções restritivas e condicionais, como "mencione apenas o concorrente xyz no caso de...", e, em vez disso, aproveita os recursos de raciocínio do LLM. Este exemplo mostra como as instruções podem ser dadas em um nível mais alto e abstrato, semelhante à forma como um colaborador de atendimento humano seria treinado após ingressar na empresa.

Vamos dar uma olhada em mais alguns exemplos do que não fazer. Estas são algumas instruções inadequadas dadas a um agente de serviço que lida com perfis de candidatos em um site de recrutamento. Essas instruções tentam antecipar todas as possíveis declarações do cliente e, portanto, devem ser evitadas:

Instrução 1: O agente recebe o seguinte enunciado: "Posso adicionar uma foto ao meu perfil?" Em seguida, pergunte imediatamente ao cliente: "Qual é o seu tipo de perfil?"

Instrução 2: Se o cliente indicar um perfil premium, responda "deixe-me verificar os detalhes do seu contrato". Em seguida, pesquise os detalhes do contrato e verifique se foi acordado que ele pode atualizar a foto do perfil.

Se foi acordado que o candidato pode fazer isso, responda "sim, é possível que eu atualize para você. Você pode fornecer sua nova imagem?" Depois que a foto for recebida, atualize o perfil do candidato de acordo. Se o contrato não incluir alterações na foto do perfil, diga "desculpe, isso não é possível. Vou encaminhar você para um agente humano"

Instrução 3: Perfil não premium: Se o cliente indicar um perfil não premium, responda com: "Você não pode atualizar sua foto. Se você quiser fazer isso, por favor me avise e eu transferirei você para um agente humano."

Instrução 4: Se o tipo de perfil não estiver claro, responda com "não consegui entender seu tipo de perfil".

O que fazer em vez disso

Em vez desse tipo de microgerenciamento, use uma abordagem mais flexível que instrua o comportamento e a conduta do agente. Considere as seguintes práticas recomendadas:

1. Use ações de RAG/conhecimento para políticas e regras contidas em artigos de conhecimento (em vez de escrevê-las como instruções). As informações relevantes são recuperadas no momento certo. Para o exemplo acima, isso significa que um artigo de conhecimento intitulado "Atualização de imagem" deve declarar: "Somente candidatos com um perfil premium cujo contrato permita alterações de imagem podem atualizar sua foto."
2. Descreva as principais diretrizes e proteções individualmente, independentemente da conversa. Forneça aos agentes uma explicação clara e concisa do comportamento ou procedimento esperado em questão.

Com base nessas práticas recomendadas, um conjunto melhor de instruções pode ser assim:

Instrução 1 : "Use ações de conhecimento para verificar políticas em caso de solicitações de alterações de conta."

Instrução 2 : "Não responda a perguntas para as quais nenhuma política aplicável possa ser encontrada."

A aplicação das diretrizes acima pode melhorar os resultados do agente. Agora, se o cliente solicitar ao agente uma mudança de perfil, ele entenderá que precisa recuperar a política necessária da base de conhecimento, interpretar as regras recuperadas, aplicar essas regras ao contexto e, por fim, responder ao cliente. Em contraste com o excesso de scripts, essa abordagem comportamental é muito mais genérica e amplamente aplicável. Sem precisar escrever cada conversa possível, o agente agora pode responder de forma flexível com o comportamento desejado a uma variedade mais ampla de tópicos de conversa.

Aplicar sequência de ação (não aplicável ao Script do agente)

O prompt de observação inclui instruções e descrições de ações, mas sem uma ordem definida. Se a sequência de ações for crítica, ela deverá ser explicitamente declarada na mesma instrução. Com o Script do agente, podemos impor uma ordem de execuções graças às transições. Isso será explicado mais adiante no sexto capítulo.

Vamos continuar com o exemplo de agentes de sites de recrutamento. O agente deve ser capaz de lidar com o planejamento de entrevistas com o entrevistador apropriado. Para isso, o agente deve primeiro verificar a disponibilidade dos recrutadores e, em seguida, propor três horários possíveis ao candidato.

Neste caso, para manter a ordem de execução, as instruções não devem estar em caixas separadas:

1. Instrução 1: Verifique a disponibilidade dos entrevistadores.
2. Instrução 2: Em seguida, proponha horários apropriados para o candidato.

Essas instruções não funcionam porque o motor de raciocínio não sabe a que se refere a declaração "Em seguida" na Instrução 2. Isso ocorre porque as instruções são enviadas para o motor de raciocínio como um grupo, não em uma ordem específica.

Em vez disso, as instruções que definem a sequência devem ser combinadas em uma única declaração e escritas assim:

1. Instrução 1: Verifique a disponibilidade dos entrevistadores. Em seguida, proponha horários apropriados para o candidato.

Aplicar a saída da ação sem reescrever

O motor de raciocínio é em si mesmo um LLM. É responsável por gerar a resposta final de acordo com os ciclos agentes. A abordagem é necessária para aplicar instruções de agentes que fornecem proteções para a geração de respostas ou para combinar saídas de várias ações que faziam parte dos ciclos agentes, a fim de atender à solicitação do usuário.

No entanto, quando a expectativa é que apenas uma ação de prompt tenha sido executada, uma instrução pode ser implementada para orientar o agente a nunca alterar a saída dessa ação. Isso garante um comportamento dos agentes mais previsível e confiável.

Aplicar essa adesão estrita em modelos de prompts aprovados torna-se crucial em determinados cenários, especialmente quando consistência, conformidade e mensagens predefinidas são importantes. Estes são dois exemplos:

• Setores regulamentados: As organizações que operam em setores altamente regulamentados (como finanças, saúde ou jurídico) geralmente exigem controle rígido sobre todas as comunicações voltadas para o cliente. Os modelos de prompts aprovados garantem que as respostas estejam em conformidade com os requisitos legais e regulatórios, minimizando o risco de interpretação errada, responsabilidade ou disseminação de informações imprecisas.
• Respostas pré-testadas e validadas: Quando os modelos de prompts foram submetidos a testes e validação rigorosos para garantir precisão, eficácia e resultados desejados. O desvio desses modelos pode minar sua eficácia e valor. A adesão rigorosa garante que as mensagens comprovadas sejam entregues de forma consistente.

Essa instrução limita a liberdade do agente de alterar a saída das ações. Certifique-se de que a instrução faça referência à saída do modelo de prompts (como "promptResponse"), conforme mostrado neste Rastreador de planos.

Portanto, a instrução neste caso pode ser:

" Não altere a saída promptResponse, independentemente do canal do agente. "

Limitações na imposição da adesão estrita:

Quando uma interação exige várias ações distintas dos agentes, impor a adesão estrita a um único modelo não é viável. Na verdade, nesse cenário, o motor de raciocínio precisa consolidar essas ações em uma única resposta e, portanto, alterar a saída de cada ação.

Número ideal de instruções

Com base nas características gerais do LLM, o número alvo de instruções varia entre 5 e 10, dependendo da complexidade da instrução e da interação da instrução. Essas características de instrução influenciam o número de instruções que o motor de raciocínio pode seguir:

• Clareza e especificidade: Regras bem definidas são mais fáceis de seguir.
• Conflitos entre regras: Se as regras se contradizem, é necessária lógica adicional para resolvê-las.
• Extensão e complexidade: Se cada regra exigir raciocínio profundo, considere dividi-las em instruções menores.

Se for muito importante seguir explicitamente uma instrução, adicione termos que reflitam sua importância:

• Urgência e importância (imediata, urgente, crítica, essencial, obrigatória)
• Autoridade e aplicação (obrigatório, compulsório, rigorosamente aplicado)
• Consequências e avisos (a violação resultará em, o não cumprimento levará a, a não conformidade pode resultar em, penalidades rígidas se aplicam, tolerância zero)
• Clareza e objetividade (obrigatório, proibido, vedado, não permitido, sempre/nunca)

A fundamentação das respostas nos dados melhora significativamente a confiança e a confiabilidade dos agentes. As respostas fundamentadas são baseadas em informações factuais, em vez de especulações ou conhecimentos desatualizados. A geração aumentada por recuperação (RAG) é uma técnica amplamente adotada que permite que um agente acesse e use uma base de conhecimento para formular respostas mais precisas e contextualmente relevantes. Com base na consulta de um usuário, um agente usa o RAG para recuperar informações relevantes das fontes de dados aplicáveis e, em seguida, aumenta a solicitação com essas informações antes de enviá-las ao LLM. Um agente que usa RAG tem maior qualidade, precisão e utilidade geral das interações com agentes, o que aumenta a confiança e a satisfação do usuário. As melhores práticas para RAG são amplamente descritas em um white paper disponível publicamente chamado Agentforce e RAG: melhores práticas para melhores agentes.

Conhecimento x instruções

Diferenciar conhecimento e instruções é importante ao encontrar o equilíbrio certo entre orientação e flexibilidade, pois elas atendem a diferentes propósitos:

• Conhecimento: Pense no conhecimento como a biblioteca de livros à qual o agente tem acesso ao gerar suas respostas. Os exemplos incluem documentos, artigos de conhecimento e white papers. Isso pode incluir políticas e regras gerais da empresa. O conhecimento também pode se referir a arquivos transacionais, como emails, transcrições de chamadas e até mesmo o histórico de conversas (de agentes). Por fim, o conhecimento inclui campos de texto longo em dados estruturados. O conhecimento geralmente é levado ao agente por meio da RAG.
• Instruções: Pense nas instruções como o conjunto mínimo de regras que esclarecem ao agente quando usar cada ação. As instruções também podem colocar proteções em toda a conversa, como o tom de voz necessário. Muitas vezes, as instruções podem ser mais concisas e flexíveis sem sacrificar a clareza ou a intenção. Em vez de fornecer um script rígido com respostas específicas para cada cenário possível do cliente, considere implementar diretrizes e princípios gerais que ajudem o agente a selecionar a(s) ação(ões) certa(s) em várias situações.

Geração aumentada por recuperação

A geração aumentada por recuperação (RAG) atua como uma camada de dados inteligente para o conhecimento. Ela oferece aos agentes acesso a informações em vários formatos e fornece fragmentos de texto relevantes para responder perguntas. Com a RAG, os agentes podem obter respostas de LLM mais precisas sem sobrecarregar o prompt do LLM com conteúdo desnecessário ou exceder sua janela de contexto.

No tempo de execução, a RAG executa três etapas:

1. Recuperação: O sistema de IA pesquisa um grande banco de dados ou fonte de conhecimento para coletar informações relevantes para o prompt do LLM. Isso é feito usando a pesquisa semântica, uma técnica mais sofisticada em comparação com a pesquisa tradicional baseada em palavras-chave. Ao contrário da pesquisa por palavra-chave, que combina termos exatos, a pesquisa semântica entende o significado ou o contexto por trás das palavras. Ela identifica informações relevantes com base nos conceitos ou nas relações entre os termos, em vez de apenas procurar combinações precisas de palavras. A pesquisa por palavra-chave também pode desempenhar um papel nesse processo de recuperação, fortalecendo a pesquisa semântica com correspondência de palavras-chave para terminologia ou nomes específicos. Esse tipo de pesquisa é chamado de pesquisa híbrida.
2. Aumento: As informações recuperadas são adicionadas ao prompt.
3. Geração: O LLM gera uma resposta contextualmente apropriada e mais precisa graças ao prompt que foi aprimorado com o conhecimento recuperado.

No Agentforce, a RAG pode ser usada com ou sem um modelo de prompts:

1. RAG baseada em prompts: Nessa abordagem, as instruções que especificam como gerar a resposta estão nas instruções prompt em um modelo de prompts. Nesse caso, a resposta depende inteiramente do que o LLM gera. Além das instruções do prompt, há maneiras de influenciar a resposta, como definições de configuração do LLM no Einstein Studio, mas o resultado ainda não é determinístico.
2. RAG baseada em motor de raciocínio: Em vez de usar um modelo de prompts, o agente usa uma ação que recupera blocos (por meio de um fluxo ou classe Apex) e os armazena em uma variável (consulte a próxima seção). Nessa abordagem, o motor de raciocínio (em vez do LLM) gera respostas diretamente, com base nos dados recuperados. As instruções que governam a geração de respostas são instruções agent, em vez de instruções de modelo de prompts. A variável que contém o conteúdo recuperado ainda pode ser passada explicitamente como entrada para uma ação. Ela também pode ser fornecida ao motor de raciocínio, concedendo-lhe acesso padrão ao conteúdo da variável. Essa abordagem tem desvantagens. Há um risco potencial de sobrecarregar o motor de raciocínio com conteúdo e responsabilidade. Além disso, ao contrário de um prompt, os parâmetros do LLM do motor de raciocínio não são configuráveis. Por outro lado, o motor de raciocínio pode gerar sua resposta usando tanto os blocos recuperados quanto o histórico da conversa.

O método recomendado é a opção 1. Ele reduz o número de tarefas que o motor de raciocínio deve realizar e, assim, melhora a qualidade da resposta. A próxima seção explora uma exceção a essa regra, na qual o conteúdo é preservado durante toda a conversa e, portanto, fornecido explicitamente a uma ação.

Práticas recomendadas de RAG

• Evitar instruções de RAG com script: em vez de vincular diretamente instruções a artigos específicos para perguntas específicas, aproveite a inteligência da RAG para encontrar dinamicamente a fonte de dados mais relevante e o fragmento de texto preciso. O processo de correspondência da RAG é baseado em uma compreensão mais ampla da questão, não apenas no mapeamento exato da pergunta à fonte.
• Consolidar tópicos: agrupe categorias de perguntas relacionadas em um único tópico. A RAG pode identificar respostas relevantes com base no tipo de pergunta, mesmo dentro de um tópico mais amplo. Por exemplo, problemas do produto, como problemas de manutenção e bateria, podem ser agregados em um tópico mais abrangente.
• Armazenar a saída da RAG em uma variável: quando o número de limites de interação puder ser alcançado, armazene a saída da RAG em uma variável. Isso mantém as informações acessíveis para orientar as interações dos agentes além do limite padrão. Um exemplo disso será fornecido na próxima seção.

Certos processos de negócios exigem uma execução ainda mais previsível, como impor uma sequência específica de ações ou condições para acionar ações ou tópicos.

Para alcançar esse comportamento determinístico, podem ser usadas variáveis. As variáveis funcionam como uma forma estruturada de memória de agente de curto prazo que pode servir como entradas ou saídas de ações. Além disso, o estado de uma variável pode controlar o acionamento de tópicos e ações específicos.

Maneiras pelas quais as variáveis apoiam a determinação

As variáveis podem ajudar a alcançar o determinismo guiado dos agentes das seguintes maneiras:

1. Fundamentação dinâmica persistente: As variáveis permitem que os agentes atualizem continuamente sua compreensão do mundo, mantendo informações importantes que permanecem inalteradas por quaisquer interações subsequentes. Esse método garante que informações críticas, que podem ser dados não estruturados recuperados via RAG, ou dados estruturados, como informações de perfil do usuário, sejam mantidas durante toda a conversa, independentemente da duração da conversa.
2. Entradas/saídas de ações: As variáveis podem ser usadas como entrada e saída para ações. A ação se refere explicitamente às variáveis, e a execução da ação não depende do motor de raciocínio para definir essas entradas e saídas, o que aumenta o determinismo do agente.
3. Filtragem: As variáveis podem ser usadas para determinar a execução condicional de ações ou tópicos. As variáveis permitem um fluxo específico de informações entre ações e determinismo na execução da ação. Esse recurso é particularmente crucial para regras de segurança em que as ações não podem ser iniciadas se variáveis de entrada específicas, como email, não forem verificadas.

Tipos de variáveis no Agentforce

O Agentforce tem dois tipos de variáveis:

• As variáveis de contexto são variáveis geradas pelo sistema que armazenam informações sobre o usuário e as sessões de conversa.
• As variáveis personalizadas podem ser instanciadas pelo usuário. Elas armazenam qualquer tipo de informação usada para qualquer uma das três maneiras pelas quais as variáveis suportam o determinismo.

Os tipos de variáveis oferecem suporte aos seguintes recursos:

Vamos nos aprofundar nas variáveis com um exemplo de caso de uso: um agente de solução de problemas voltado para o cliente. Neste exemplo, as variáveis são usadas para todas as três finalidades: fundamentação dinâmica persistente, entradas/saídas de ação e filtragem.

Neste exemplo, o agente ajuda um cliente a solucionar um problema técnico de dispositivo. A solução de problemas geralmente envolve passar por várias etapas. O agente deve oferecer uma experiência de atendimento que imite o trabalho de um agente de serviço humano. Para fazer isso, o agente não deve fornecer todas as etapas de solução de problemas de uma vez ao cliente. Em vez disso, ele deve oferecer instruções passo a passo, além da capacidade de navegar entre as etapas (incluindo voltar às etapas abordadas anteriormente), com base em como o cliente responde.

Um desafio disso é a capacidade do agente de reter todas as etapas de solução de problemas durante toda a conversa. Devido à memória limitada do agente, em função do número restrito de interações que ele pode armazenar, essas etapas podem ser excluídas do contexto do motor de raciocínio se a conversa se tornar longa.

A maneira de lidar com esse desafio é usar uma variável para fundamentar dinamicamente o motor de raciocínio nas etapas de solução de problemas. Ao recuperar as informações e armazená-las em uma variável, elas permanecem disponíveis e podem ser atualizadas durante toda a conversa. O motor de raciocínio usa as informações armazenadas nessa variável para fundamentação dinâmica.

Neste exemplo, um tópico inclui duas ações. Essas duas ações são necessárias para manter um fluxo de dados consistente. A primeira ação é usada para preencher a variável que contém todas as etapas de solução de problemas. A segunda ação usa essa variável durante a solução de problemas em si.

1. Ação 1: "Preencha as etapas de resolução de problemas". Esta é a ação inicial, acionada pela primeira introdução do agente ao problema. Ele usa a geração aumentada por recuperação (RAG) para extrair todas as etapas de resolução necessárias de uma base de conhecimento indexada. A ação armazena a saída resultante em uma variável chamada "Etapas de resolução".
2. Ação 2: "Use no meio da resolução de um problema". Esta é uma ação baseada em um prompt que gera a próxima etapa de solução de problemas mais provável a ser usada durante o processo de solução de problemas. O agente é instruído a usar essa ação durante a resolução de um problema.

A pergunta original do cliente é inserida em ambas as ações. A segunda ação tem outra entrada: o conteúdo da variável "Etapas de resolução". Essa variável foi definida pela primeira ação. A segunda ação não recuperará as etapas de solução de problemas em si, mas as obterá como entrada da primeira ação por meio da variável. O diagrama a seguir mostra o fluxo de dados entre essas duas ações.

A ação "usar no meio da resolução de um problema" sempre se referirá às etapas originais de solução de problemas recuperadas pela ação Etapas de resolução de problemas. Esse fluxo de dados garante que as etapas de solução de problemas sejam mantidas de forma consistente e sempre presentes, independentemente da duração da conversa.

Para executar as ações definidas neste exemplo, instruções específicas são necessárias, como "Sempre execute as 'Preencher etapas de resolução' primeiro." No entanto, dada a natureza não determinística dos LLMs usados pelos agentes, isso pode levar a uma ordem diferente em determinados casos. Para garantir uma ordem determinística de execução, introduzimos filtros condicionais nessas variáveis para impor a sequência de ação adequada. O agente lê o valor da variável "Etapas de resolução" e define dois filtros com base em se essa variável tem ou não um valor.

• A ação Etapas de resolução de problemas só pode ser executada se a variável "Etapas de resolução" estiver em branco.
• A ação "Usar no meio da resolução de um problema" só pode ser executada se a variável "Etapas de resolução" estiver preenchida.

Esses filtros condicionais agora aplicam deterministicamente a sequência de execução da ação: O "Uso no meio da resolução de um problema" deve esperar até que as Etapas de resolução de problemas concluam seu trabalho, garantindo que a variável "Etapas de resolução" sempre tenha um valor.

Para garantir a execução correta da ação, uma terceira ação é necessária para redefinir a variável "Etapas de resolução" se o problema for totalmente resolvido. Como resultado, o agente é redefinido para o estado necessário para ajudar com um possível problema novo e diferente. Essa terceira ação é chamada de "Esvaziar a variável de resolução". O diagrama de ação completo é ilustrado abaixo.

As variáveis são cruciais para permitir que nosso agente de solução de problemas resolva os problemas dos clientes, permitindo:

• Fundamentação dinâmica persistente: As variáveis armazenam etapas de solução de problemas, garantindo que elas estejam disponíveis durante toda a conversa, independentemente da duração ou do número de interações. Isso evita que o agente esqueça o contexto.
• Fluxo de dados: As variáveis facilitam o fluxo de dados entre as ações. Por exemplo, a variável "Etapas de resolução" armazena as etapas de solução de problemas recuperadas da ação Etapas de resolução de problemas e as fornece como entrada para a ação Usar no meio da resolução de um problema.
• Determinismo: As variáveis podem ser usadas como filtros para impor uma ordem específica de execução da ação. Por exemplo, a ação Usar no meio da resolução de um problema é executada somente se a variável Etapas de resolução estiver preenchida, garantindo que a ação Etapas de resolução de problemas seja executada primeiro.

Na era da IA generativa, a IA preditiva continua sendo extremamente importante, pois forma a inteligência fundamental que orienta, aprimora e contextualiza as capacidades generativas. Enquanto a IA generativa se concentra na criação de novos conteúdos, como texto, imagens ou vídeos, os modelos preditivos fazem previsões sobre o futuro com base em informações de dados comerciais em tempo real. Exemplos de resultados comerciais incluem probabilidade de rotatividade do cliente, probabilidade de conversão, probabilidade de encaminhamento de casos, valor da vida útil do cliente e classificação de casos. As previsões podem ajudar a antecipar as necessidades do usuário, personalizar resultados, tomar decisões e otimizar a relevância do conteúdo em tempo real, tudo analisando tendências e números. Por exemplo, em apps como aprendizado personalizado, saúde ou planejamento financeiro, a IA preditiva garante que os resultados generativos se alinhem aos contextos individuais e aos prováveis cenários futuros. Juntas, a IA preditiva e generativa criam uma poderosa sinergia, combinando previsão com criatividade para gerar soluções tecnológicas mais inteligentes, adaptáveis e impactantes.

Como integrar a saída do modelo preditivo aos fluxos de trabalho dos agentes

Para incorporar resultados do modelo preditivo aos fluxos de trabalho dos agentes, basta adicionar ações do modelo preditivo aos ativos do Agentforce. O Model Builder fornece os meios de criar ou registrar modelos preditivos (BYO) e esses modelos são então usados pelo agente para fazer previsões. As previsões resultantes (bem como os preditores) podem ser armazenadas em variáveis personalizadas. Os agentes podem usar esses valores de variáveis como entradas e condicionar a execução de ações e tópicos específicos.

Exemplos de casos de uso integrados a modelos preditivos

• Segmentação: Execute uma classificação multiclasse para segmentação de clientes e use o segmento resultante para filtrar determinadas ações. Por exemplo, reserve ações premium para clientes de nível premium.
• Probabilidade de escalonamento: Preveja a probabilidade de escalonamento para um caso de serviço. Se essa probabilidade exceder um determinado limite, permita a execução de ações que resolvam o caso mais rapidamente ou encaminhem para agentes humanos mais depressa.
• CPG: Planeje uma promoção somente se o aumento nas vendas (pontuação calculada por um modelo preditivo) exceder um determinado limite.
• Comércio: Proponha um produto somente se a propensão à compra exceder um determinado limite.

Certos processos de negócios precisam ser executados em uma ordem precisa e não exigem entrada do usuário durante a execução. Nesse caso, um fluxo predeterminado de etapas pode ser aplicado por meio de fluxos, APIs ou Apex. Se você já tem um fluxo confiável na produção, isso é uma boa indicação de que ele pode ser mantido e usado pelo agente para a execução desse processo de negócios. Todos os exemplos a seguir incluem sequências predeterminadas de etapas que o agente pode executar sem a entrada do usuário. O comportamento dos agentes nesse caso consiste em identificar qual processo determinístico executar, como coletar as entradas necessárias e como interpretar e processar as saídas.

Os processos de negócios com muitas etapas sequenciais (mais de três, como regra geral) e muitas dependências de variáveis se tornam muito complexos e complicados para serem aplicados com instruções. Nesse caso, é possível simplesmente codificá-los usando os tipos de ação determinística listados nesta seção. Por fim, observe que essas implementações podem incluir elementos não determinísticos, como chamar LLMs com modelos de prompts resolvidos. Portanto, eles não são necessariamente completamente determinísticos, de ponta a ponta, e ainda podem demonstrar os níveis desejados de fluidez pelos quais os agentes são conhecidos.

A sequência de etapas em uma jornada de marketing é condicionada por regras fixas e não depende de nenhuma entrada conversacional do usuário. Portanto, o fluxo pode ser usado como uma ação do Agentforce. Uma ação invocável pode ser criada para concluir tarefas em segundo plano ou acionadas por eventos a partir de um componente da solução que pode chamar um fluxo ou uma classe Apex. Adicione uma ação invocável a um fluxo ou classe Apex e especifique a tarefa que o agente conclui, bem como as condições que acionam o agente. As ações invocáveis também podem carregar as variáveis de contexto do agente e transmitir informações importantes.

Os fluxos da Salesforce podem ser usados para automatizar tarefas rotineiras, como criar tarefas de acompanhamento, enviar emails de lembrete ou atualizar registros. Os fluxos tornam o trabalho mais eficiente e produtivo. Os agentes também podem executar fluxos usando ações de fluxo. Devido ao seu determinismo, os fluxos são uma ótima maneira de direcionar o comportamento de agentes quando um processo de negócios precisa ser executado em uma sequência específica. Uma boa indicação de que uma ação de fluxo é preferida é quando o tópico conteria instruções como "Primeiro, faça isso, depois faça isso e, finalmente, faça isso". O gerenciamento de sequências com mais de três etapas torna-se complicado por meio de instruções e variáveis.

Os fluxos também podem incluir elementos não determinísticos chamando prompts. Um nó de prompt no fluxo invoca um modelo de prompts e coleta a resposta que pode ser passada para outros elementos no fluxo. Esses elementos adicionais podem novamente ser nós de prompts, por exemplo resumindo a resposta anterior, criando assim uma cadeia de prompts. Isso é particularmente útil quando as regras para encadeamento de prompts são definidas por elementos fixos e não dependem da entrada do usuário. Um exemplo é a RAG de agentes, na qual uma sequência predefinida de recuperadores ou prompts em um fluxo pode acessar fontes de dados específicas em uma ordem específica, como inicialmente recuperar dados do documento de país de um usuário antes de consultar outras fontes, conforme necessário. Esse mecanismo de encadeamento impõe uma extração confiável e ordenada de informações relevantes.

De forma semelhante aos fluxos, as ações do Apex e da API são determinísticas, pois uma sequência predefinida de ações pode ser codificada. Essas ações podem incluir elementos não determinísticos, como invocar modelos de prompts ou chamadas de LLM. No entanto, em sua definição, eles executam essas etapas de forma determinística, o que reduz a variabilidade de agentes ao chamar a ação no momento certo, coletar a entrada necessária e processar a saída. Essas responsabilidades ainda precisam ser governadas por instruções de agentes, por isso são não determinísticas. As ações Apex e API são o equivalente pro-code das ações de fluxo.

Do raciocínio probabilista ao determinístico

Nos níveis de determinismo de 1 a 5, adicionamos progressivamente estrutura ao ambiente do agente. Nós definimos o que ele poderia fazer (Nível 1, tópicos), depois orientamos como ele deveria se comportar (Nível 2, instruções), agregamos fundamentação com base na verdade (Nível 3, dados), gerenciamos seu estado (Nível 4, variáveis) e fornecemos ferramentas rígidas (Nível 5, ações determinísticas). No entanto, o mecanismo central de tomada de decisões permaneceu fundamentalmente probabilístico. O motor de raciocínio ainda estava decidindo por conta própria qual ferramenta escolher ou qual pergunta fazer a seguir, e para essa decisão dependemos totalmente no grande modelo de linguagem (LLM).

O Nível 6, Script do agente, muda a base dessa arquitetura. Ele introduz a capacidade de codificar o próprio processo de raciocínio.

Com o Script do agente, passamos da criação do prompt do modelo para a criação de scripts do agente. Isso não significa voltar aos chatbots rígidos e antigos, mas, chamamos esse processo de raciocínio híbrido. Ele permite que você integre o poder criativo e conversacional do LLM entre camadas de lógica imutável e determinística. Você define explicitamente o caminho crítico de execução (os "obrigatórios"), deixando espaços específicos de liberdade para o LLM lidar com a compreensão da linguagem natural e a geração de respostas.

Ao projetar fluxos de trabalho, é crucial evitar o uso de agentes baseados em LLM que utilizam scripts, apenas para substituir a lógica determinística, em que as próximas etapas já estão claras e corrigidas. Se um processo seguir um caminho previsível sem a necessidade de raciocínio complexo para decodificar ações subsequentes, a introdução de um modelo generativo adiciona latência, custo e uma margem de erro desnecessários. Os fluxos programáticos tradicionais permanecem superiores para processos que são puramente determinísticos e não precisam de raciocínio. A utilização de um LLM para roteamento simples ou transições lineares é uma opção de excesso de utilização de engenharia que compromete a confiabilidade de um sistema que, de outra forma, poderia ser tratado por um fluxo de procedimento padrão.

Como regra geral, as soluções agênticas devem ser consideradas quando o sistema está lidando com entradas não estruturadas que devem ser sintetizadas a partir de fontes diferentes e de alta variância (possivelmente incluindo entradas conversacionais) antes que uma decisão possa ser tomada.

Mas como alcançar esse nível de controle? Há dois caminhos distintos, projetados tanto para o arquiteto de negócios quanto para o desenvolvedor de código profissional.

Para agregar o Nível 6: determinismo ao seu agente, não é rigorosamente necessário escrever um código. A Salesforce fornece duas modalidades para gerar o Script do agente subjacente, democratizando o acesso ao raciocínio determinístico.

Para analistas comerciais, administradores e profissionais de pouco código, o Nível 6 pode ser acessado diretamente no criador de agentes.

Nós introduzimos uma tela estilo documento que serve como uma interface de texto para script. Em vez de escrever código, você escreve a lógica do tópico em linguagem estruturada e natural. Depois, o criador interpreta sua intenção e a compila no Script do agente em segundo plano.

• Você escreve: "Primeiro, verifique se o pedido tem mais de 30 dias. Em caso afirmativo, diga ao usuário que não podemos aceitar devoluções e encerre educadamente a conversa. Se não tiver, pergunte a condição do item."
• O sistema compila essa narrativa em linguagem natural automaticamente nas estruturas if/else necessárias, verificações de variáveis e comandos end_conversation.

Isso permite que você escreva a lógica em linguagem natural e faça com que a plataforma a converta em código, garantindo que até mesmo profissionais não programadores possam implementar proteções rígidas e determinismo.

Para desenvolvedores que buscam o máximo de precisão, você também pode escrever o Script do agente diretamente no criador de agentes. A tela com a narrativa em linguagem natural pode ser virada para ver o script subjacente e, dessa maneira, o desenvolvedor agora pode codificar diretamente o script. Essa abordagem permite inclusive uma experiência de criação híbrida: algumas instruções são escritas em linguagem natural na tela, enquanto outras são elaboradas com scripts (ou as existentes são modificadas) diretamente usando código. Ao alternar entre essas duas experiências, você verá que as duas modalidades são sempre mantidas perfeitamente alinhadas.

As duas modalidades exploram todo o potencial do Nível 6:

• Rastreamento detalhado: você pode percorrer a execução do script para ver exatamente onde as variáveis mudaram ou as ramificações foram obtidas.
• Tratamento complexo de loops: gerencie lógica sofisticada de repetição ou alterações de estado multivariáveis que são difíceis de descrever em linguagem natural.
• Controle de versão: trate o comportamento do agente como código, compatível com pipelines git e CI/CD para controle de versão do agente.

Independentemente de gerar o Script do agente por meio do criador ou escrevê-lo manualmente, a mesma saída será produzida: o Script do agente é convertido em um gráfico de agente que é executado pelo Atlas Reasoning Engine.

Para dominar o Nível 6, é preciso entender o que acontece por trás de todo o processo. O Script do agente controla o comportamento por meio de estruturas programáticas específicas dentro de blocos de raciocínio. Ao contrário dos prompts padrão, que são sugestões para o LLM seguir, elas consistem em comandos que serão executados independentemente do que acontecer. Ou seja, antes, durante ou depois do processo de raciocínio, e eles possuem vários tipos distintos de determinismo. Primeiro, analisaremos alguns desses padrões em geral e forneceremos alguns exemplos triviais e, em seguida, ilustraremos mais detalhadamente com exemplos de projetos arquitetônicos de agentes com script.

Nos Níveis 1 a 5, esperávamos que o agente fizesse algo (realizasse uma ação) antes ou depois de uma determinada etapa do processo. No Nível 6, nós o forçamos a fazer isso. O que estiver escrito nos blocos before_reasoning e after_reasoning sempre será executado, respectivamente antes e depois de invocar o LLM para raciocinar com base nas instruções. Podem ser procedimentos como executar outras ações, fazer a transição para tópicos, definir variáveis e assim por diante.

Por exemplo, usando o comando run dentro das instruções before_reasoning de um tópico, você pode executar uma ação mesmo antes que o LLM seja invocado para gerar uma resposta. Isso garante que os dados estejam disponíveis imediatamente, eliminando a latência de raciocínio ou o risco de o agente esquecer de chamar a ferramenta.

A estrutura do script:

Com o determinismo condicional, você pode usar a lógica de programação padrão para controlar o fluxo. Isso é fundamental para fluxos de trabalho de conformidade em que as etapas não podem ser ignoradas ou reinventadas.

A estrutura do script:

Neste exemplo, o LLM nunca tem a opção de alucinar uma aprovação para um usuário não VIP. A ramificação é obtida deterministicamente pelo mecanismo.

Outro controle poderoso é a capacidade de forçar o agente a sair do tópico atual e entrar em outro. Isso impede que o agente fique preso ou entre em conversas não relacionadas.

A estrutura do script:

Essa transição não é uma sugestão, mas um redirecionamento rígido do fluxo de execução que depende do valor de uma variável. Note que, embora o redirecionamento seja rígido e inegociável, um processo normal de raciocínio ocorre novamente dentro do tópico ao qual o agente agora é forçado.

Além disso, com o Script do agente, você pode forçar explicitamente uma transição de uma ação para a próxima imediatamente após a conclusão. Essa funcionalidade garante que o agente siga um fluxo rígido e determinístico, em vez de depender da tomada de decisões probabilísticas ou autônomas em cada etapa. Ao encadear essas ações em uma sequência predefinida, você pode garantir que tarefas específicas sejam executadas em uma ordem precisa, fornecendo controle total sobre a lógica e o comportamento do agente.

O Script do agente oferece acesso direto de leitura/gravação à memória de curto prazo do agente (variáveis). Você pode definir variáveis explicitamente com base nas saídas de ação, evitando um jogo telefônico em que um LLM possa interpretar incorretamente a saída JSON de uma ferramenta.

A estrutura do script:

Para ter uma boa compreensão sobre o poder do Script do agente, devemos olhar além dos comandos individuais e observá-los em conjunto. Os seguintes padrões arquitetônicos (derivados de nossa coleção de receitas do Script do agente ) demonstram como o Nível 6: determinismo resolve desafios corporativos complexos.

O problema: os agentes padrão geralmente sofrem com latência de raciocínio. Eles esperam que o usuário faça uma pergunta, depois pensam em qual ferramenta usar. Depois, podem até perguntar ao usuário informações que já poderiam ter sido recuperadas e só então chamar a ação. Isso cria uma experiência atrasada e desarticulada. O Script do agente: pré-raciocínio de determinismo.

Usamos o comando run para injetar dados antes mesmo de o LLM ser ativado.

Exemplo: o agente de triagem de emergência. Imagine um agente lidando com um relatório de falta de energia. Em vez de pedir ao usuário seu endereço e aguardar, no momento em que a sessão é iniciada, o script executa automaticamente um comando get_current_location_by_IP and check_grid_status.

O resultado: o agente não começa com "Como posso ajudar você?" Tudo começa com um CRM. "Vejo que você está ligando do setor norte, onde há um incêndio confirmado em um transformador. Já adicionei sua residência à lista de restauração prioritária. Você tem um gerador reserva que esteja funcionando?"

A lógica:

Prompts longos (que fornecem ao agente todas as regras de uma só vez) levam ao aumento da probabilidade de alucinação no processo de raciocínio. O agente esquece a regra A porque está olhando para a regra Z.

A solução do Script do agente: injeção de instruções just-in-time com fundamentação condicional por meio de uma combinação de RAG e lógica condicional. Ele mostra ao agente apenas as regras que se aplicam ao momento exato da conversa.

Exemplo: fornecer regras para ofertas não qualificadas. Por que dar ao agente as regras sobre solicitar aumentos de crédito, quando a pontuação de crédito do cliente nem sequer permite que isso comece?

A lógica:

A fundamentação condicional está eliminando a possibilidade de erro removendo totalmente as informações que distraem quando não são necessárias.

O problema: em uma conversa complexa com o agente (como uma solicitação de hipoteca, entrevista de seleção de emprego ou uma sessão de solução de problemas técnicos), o agente mantém uma lista de perguntas obrigatórias para que todas as informações necessárias sejam capturadas do usuário. No entanto, os usuários costumam desviar do assunto. Um agente padrão pode seguir o novo assunto e esquecer de voltar a essas perguntas obrigatórias, deixando a solicitação ou a conversa incompleta.

No centro desse sistema está a navegação com informações de estado, que trata a conversa como uma lista de verificação rigorosa que deve ser completamente verificada antes que qualquer transição possa ocorrer.

Por meio da navegação com estado, o agente se move entre tópicos com base estritamente no estado da variável atual ou permanece bloqueado em um tópico até que condições específicas sejam atendidas. Isso impede que o agente siga caminhos inadmissíveis, mesmo quando um usuário tenta desviar a conversa com outros assuntos. Por exemplo, em um pedido de hipoteca de alto risco, se um usuário solicitar o horário de funcionamento da agência, o agente não tenta apenas seguir o caminho certo. Em vez disso, o script detecta o desvio e pode acionar uma transição forçada para um tópico de redefinição de conformidade. Ao bloquear o agente em uma "sala lógica" específica, torna-se matematicamente impossível para ele discutir tópicos não aprovados ou sair de uma sessão até que cada variável obrigatória seja capturada com sucesso.

Exemplo: o inspetor de manutenção; um agente está orientando um técnico a fazer uma verificação de segurança de 10 pontos no motor de uma aeronave. O técnico diz: "Espere, também notei um arranhão na fuselagem".

O comportamento:

1. O agente reconhece o arranhão (linguagem natural).
2. Ele registra o arranhão em uma variável (Gerenciamento de estado).
3. Ele se recusa a fechar a sessão ou trocar de tópico até conseguir uma confirmação: "Observei o arranhão na fuselagem, mas não podemos passar para a parte externa até que você confirme a configuração de torque na válvula de admissão. Que leitura foi essa?"

A lógica:

No entanto, uma conversa guiada deve ser mais do que apenas uma lista sequencial de perguntas. Caso contrário, o agente funciona mais como um "formulário disfarçado". Seu principal valor está na triagem inteligente: usar perguntas iniciais de descoberta para encaminhar o usuário para o formulário ou fluxo de trabalho correto.

A transição de um script simples para um Script do agente robusto se torna lógica quando a complexidade aumenta. Em vez de apenas perguntar, o agente começa a fazer: Por exemplo, o agente pode extrair etapas de solução de problemas da documentação, navegar por políticas internas ou executar chamadas de API para sistemas externos para resolver problemas em tempo real.

Com a introdução do Script do agente como Nível 6 na estrutura de níveis de determinismo, agora você tem um espectro completo de controle, desde a criatividade aberta de um tópico de Nível 1 até a lógica rígida e orientada por código de um Script do agente de Nível 6.

Mas ter um martelo não faz com que cada problema seja um prego.

O erro mais comum a ser cometido é pensar que "quanto maior é melhor", e os agentes agora devem ser totalmente controlados usando script para todos os assuntos. Isso não é verdade. A verdadeira arte da arquitetura e do design de agentes está em dimensionar corretamente o determinismo aplicando um nível de controle exato o suficiente para garantir a segurança, sem sacrificar a flexibilidade conversacional que torna a IA valiosa em primeiro lugar. Não crie scripts excessivos para seus agentes a ponto de transformá-los em chatbots sofisticados.

Este capítulo fornece uma estrutura de decisão para ajudar você a determinar quando confiar na autonomia guiada dos Níveis 1 a 5 e quando aplicar a precisão com script do Nível 6. Não se tratam de leis rígidas, mas sim regras básicas e têm como objetivo fornecer uma estrutura contextual de como pensar sobre as diferentes opções e níveis de determinismo.

Para simplificar a decisão, podemos dividir os seis níveis em duas zonas estratégicas distintas:

• A filosofia: "confie, mas verifique". Você fornece ao agente a meta, os dados e as ferramentas (que podem ser determinísticas, consulte o Nível 5), mas deixa que o motor de raciocínio decida o melhor caminho para chegar lá.
• O mecanismo: raciocínio probabilístico. O agente analisa a intenção do usuário e seleciona dinamicamente a melhor ferramenta para o trabalho.
• Melhor para: descoberta, perguntas e respostas gerais, tarefas de baixo risco, amplos escopos de serviço.

Você deve confiar nos comportamentos padrão e probabilísticos dos Níveis 1 a 5 quando:

1. O caminho certo nem sempre é o mesmo

Em muitos cenários conversacionais, um caminho rígido e codificado é, na verdade, uma desvantagem, porque o caminho de conversação correto é variável. Para interações dinâmicas, como compras pessoais ou planejamento de férias, não há uma única sequência correta; um usuário pode priorizar preço, localização ou comodidades em qualquer ordem que escolher. Nesses casos, forçar um script com estado (stateful) cria uma frustrante experiência robótica, por isso é mais eficaz basear-se nas instruções para definir a persona e as metas do agente, permitindo que o usuário lidere o fluxo. Essa abordagem também aumenta significativamente a velocidade de lançamento no mercado, pois a criação de scripts complexos de Nível 6 com variáveis e ramificações aninhadas geralmente é um exagero para tarefas como agentes internos de perguntas frequentes de RH. Ao fundamentar o agente em dados e RAG, você pode ignorar a necessidade de ter um script manual exaustivo e permitir que o mecanismo de recuperação lide com a conversa dinamicamente conforme sua base de conhecimento existente.

2. Dimensionamento por meio do determinismo modular: como evitar o pesadelo da manutenção

Quando o escopo do seu agente atinge uma escala massiva, por exemplo, gerenciando 500 consultas diferentes de suporte de TI com seus próprios processos, o principal desafio não é se você pode criar um único script agêntico determinístico, mas se deveria. A tentativa de mapear todas as permutações possíveis de 500 tarefas em um Script do agente gigante cria um pesadelo de manutenção. Sempre que uma política muda ou uma nova etapa de solução de problemas é adicionada, você corre o risco de quebrar uma rede de lógica massiva e interconectada.

A solução é se afastar de um script monolítico e seguir em direção a ações determinísticas de nível 5. Em vez de criar scripts para toda a conversa, você cria fluxos robustos e isolados para as ações de alto nível e valor, como redefinições de senha ou desbloqueio de contas. Então, você permite que o motor de raciocínio aja como um controlador de tráfego, identificando a intenção do usuário a partir de sua formulação exclusiva e encaminhando-a para a ação determinística apropriada. Essa abordagem oferece o melhor dos dois mundos: a confiabilidade de um script para tarefas críticas e uma arquitetura flexível e escalável que não entra em colapso sob seu próprio peso à medida que sua biblioteca de tarefas cresce.

• A filosofia: "Independentemente do que você quiser e raciocinar, em qualquer caso, faça exatamente isso." Você define o caminho. O agente é a interface para executar sua lógica. Isso coloca a criatividade do agente em camadas de lógica obrigatória.
• O mecanismo: raciocínio determinístico. O "cérebro" segue um gráfico pré-compilado; o LLM é usado apenas para raciocínio, compreensão da linguagem natural e geração de respostas onde o script permite.
• Melhor para: conformidade, transações financeiras, árvores de diagnóstico, fluxos de trabalho de alto risco, conformidade e setores altamente regulamentados.

Note que dentro das faixas determinísticas que o Nível 6 estabelece, todas as opções do Nível 1-5 ainda estão disponíveis!

Você deve passar a usar o Script do agente quando "quase certo" não for suficiente.

1. Os portões obrigatórios (segurança e autenticação)

Se um usuário pedir para transferir dinheiro, você não poderá confiar no LLM para a possibilidade de solicitar autenticação. Você precisa de uma garantia matemática de que o fluxo de autenticação seja executado antes do fluxo de transação.

• A solução do Script do agente: use executar @actions.verify_identity dentro de um bloco before_reasoning ou na parte superior do script para forçar a conformidade antes que o LLM gere um único token.

2. Conformidade regulatória

Em setores como saúde ou finanças, os agentes geralmente precisam ler um aviso de isenção de responsabilidade na íntegra ou fazer perguntas em uma ordem legalmente obrigatória.

• A solução do Script do agente: codifique a divulgação.

3. Dependências complexas em várias etapas e sequências de ações obrigatórias

Se a etapa B exigir a saída da etapa A e a etapa C depender de um cálculo da etapa B, será arriscado confiar em um LLM para passar essas variáveis por meio de contexto de prompt em um jogo de "telefone sem fio". Além disso, quando a execução de uma determinada ação é estritamente obrigatória após outra ação, a sequência precisa ser integrada.

• As soluções do Script do agente: use set @variables.x = @outputs.y para vincular explicitamente dados entre etapas, garantindo fidelidade perfeita. Use as instruções run e @utils.transition para codificar a sequência.

4. Como evitar o desvio de tópicos

Na solução de problemas de alto risco (por exemplo, "Meu marca-passo está emitindo um alerta sonoro"), você não quer que o agente se distraia se o usuário perguntar repentinamente: "Como está o tempo?"

• A solução do Script do agente: use @utils.transition para bloquear o usuário no tópico Protocolo de emergência até que o problema seja resolvido, desabilitando explicitamente a capacidade de desvio.

As arquiteturas de agentes mais maduras não escolhem uma ou outra; elas usam o Nível 6 como esqueleto e os Níveis 1 a 5 como o músculo. Assim, o padrão que surge é o de um sanduíche determinístico. Você pode usar o Script do agente para lidar com o início e o fim críticos de uma conversa, deixando o meio aberto para um raciocínio flexível.

• Etapa 1 (Nível 6): o Script do agente força a triagem e a autenticação.
  • Resultado: o usuário é identificado com segurança, e a intenção é classificada.
• Etapa 2 (Níveis 1 a 5): transferências do Script do agente para um tópico padrão.
  • Resultado: o agente usa RAG e ações padrão, instruções e talvez até mesmo variáveis para resolver o problema do usuário de forma flexível.
• Etapa 3 (Nível 6): o agente detecta que o problema foi resolvido e faz a transição de volta para o Script do agente para as ações de fechamento.
  • Resultado: o Script do agente força a coleta de pontuações de CSAT e linguagem de despedida compatível.

Recomendação final: comece com os níveis 1 a 5 para ter velocidade e descoberta e monitore seus registros. Se você perceber que o agente está tendo dificuldade para lidar com consistência, não seguindo uma sequência ou parâmetros alucinantes, fortaleça seletivamente esse fluxo de trabalho específico com o Nível 6.

O Script do agente é a peça final do quebra-cabeça para agregar determinismo aos agentes. Ele reconhece que, embora a IA seja probabilística, os negócios são determinísticos. Ao adotar o Script do agente (seja por meio da tela que oferece suporte à criação de agentes em linguagem natural ou em código direto), você não está limitando a inteligência do seu agente; você está se concentrando nela. Você está criando um sistema em que a arte da conversa encontra a ciência da execução de processos, garantindo que seus fluxos de trabalho mais críticos sejam executados exatamente como projetados, sempre.

O Nível 6 também é a percepção de que ser autônomo não significa ser descontrolado.

Durante anos, a discussão no setor foi em torno de regras versus IA em relação à tomada de decisões e otimização de processos. O campo de regras rígidas defendia a previsibilidade. O grupo de IA defendia a flexibilidade. O Script do agente encerra essa discussão provando que a arquitetura correta não é ou, mas e.

Ao adotar o Script do agente, você está criando agentes híbridos: sistemas que possuem a espinha dorsal rígida do código e a mente flexível de um LLM. O futuro da IA corporativa não tem a ver com modelos maiores. Tem a ver com um melhor controle. Com o Script do agente, esse controle está finalmente em suas mãos.