Como os administradores da Salesforce configuram tópicos, ações e salvaguardas no Agentforce

Os administradores do Salesforce configuram agentes autônomos no Agentforce estabelecendo domínios operacionais estruturados, ferramentas de negócios executáveis e controles de governança em múltiplas camadas dentro do Agentforce Builder. Diferente dos chatbots tradicionais baseados em regras que seguem árvores de decisão determinísticas, o Agentforce utiliza o Atlas Reasoning Engine para interpretar dinamicamente a intenção do usuário, formular planos de ação e executar tarefas de forma autônoma. Para garantir que esses agentes autônomos operem com confiabilidade, segurança e dentro dos limites corporativos, os administradores devem configurar três blocos de construção fundamentais: tópicos (topics) que classificam e delimitam o escopo do trabalho, ações (actions) que executam a lógica de negócios e proteções (guardrails) que impõem restrições comportamentais, privacidade de dados e caminhos de escalonamento para atendentes humanos.

Base arquitetônica: o Atlas Reasoning Engine

Para configurar um agente autônomo com eficácia, os administradores precisam entender como o Agentforce processa as interações do usuário. No centro do Agentforce está o Atlas Reasoning Engine, que coordena o comportamento do agente por meio de um ciclo contínuo de "raciocinar-agir-observar" (reason-act-observe):

• Classificação de intenção (Intent Classification): Quando um usuário final envia uma solicitação, o Atlas avalia a mensagem comparando-a com as descrições de classificação de todos os tópicos ativos atribuídos ao agente.
• Montagem do contexto (Context Assembly): Uma vez selecionado o tópico, o Atlas assimila as instruções em linguagem natural do tópico, as ações disponíveis, o histórico de conversas e os dados relevantes do cliente recuperados por meio do Salesforce CRM ou do Data Cloud.
• Formulação do plano (Plan Formulation): O mecanismo de raciocínio avalia quais ações (se houver) são necessárias para atender à solicitação do usuário e determina os parâmetros necessários a serem extraídos da conversa.
• Execução da ação e observação (Action Execution and Observation): O agente executa a ação escolhida — como consultar um registro de inventário ou atualizar o status de um caso — e observa o resultado retornado. Se forem necessárias etapas adicionais, o mecanismo continuará raciocinando até que o objetivo seja alcançado ou um limite de escalonamento seja acionado.

Como o Atlas raciocina dinamicamente em vez de seguir uma árvore de diálogo pré-roteirizada, os administradores não precisam construir caminhos de ramificação estáticos. Em vez disso, definem os limites, as ferramentas e os objetivos, permitindo que o mecanismo encontre o caminho ideal para a resolução.

Etapa 1: Configurando tópicos (Topics) no Agentforce Builder

Os tópicos servem como os domínios funcionais primários do agente. Eles agrupam recursos relacionados, fornecem contexto e definem os limites dentro dos quais o agente está autorizado a operar.

Acessando o Builder e criando tópicos

1. No menu Configuração (Setup) do Salesforce, use a caixa de Busca rápida (Quick Find) para navegar até Agentforce Agents (ou Einstein Agents, dependendo da configuração da versão).
2. Selecione o agente desejado na lista e clique em Open in Builder.
3. No painel de navegação à esquerda do Agentforce Builder, selecione a guia Topics.
4. Clique em New Topic para criar um tópico personalizado do zero ou escolha entre os modelos de domínio padrão pré-configurados (como Order Management, Billing Inquiries ou Case Escalation).

Definindo metadados do tópico e escopo de classificação

Cada tópico requer três campos de configuração críticos que influenciam diretamente como o Atlas Reasoning Engine roteia as solicitações recebidas:

• Nome do tópico (Topic Name): Um rótulo claro e descritivo que identifica a função de negócios (por exemplo, Billing_and_Invoices ou Appointment_Scheduling).
• Descrição de classificação (Classification Description): Uma explicação semântica detalhada de quais intenções, consultas e solicitações do usuário pertencem a este tópico. O Atlas depende fortemente dessa descrição para calcular a similaridade de intenção. Por exemplo, em vez de um rótulo curto como "Dúvidas sobre faturamento", escreva: "Trata de consultas relacionadas a faturas de clientes, histórico de cobrança, métodos de pagamento, solicitações de recibos, contestações de cobrança e taxas de renovação de assinatura."
• Escopo (Scope): Um resumo conciso que descreve o que o agente pode e não pode resolver dentro deste domínio. Isso serve como um limite contextual imediato para o modelo quando ele começa a raciocinar.

Redigindo instruções no nível do tópico

As instruções do tópico fornecem as diretrizes comportamentais específicas e as etapas de procedimento que o agente deve seguir quando um tópico estiver ativo. Os administradores devem redigir as instruções em linguagem natural clara e imperativa:

• Orientação sequencial (Sequential Guidance): Descreva a ordem padrão de operações (por exemplo: "1. Solicite ao cliente o ID do pedido (Order ID). 2. Verifique se o ID do pedido corresponde a um registro existente. 3. Recupere o status do envio e resuma o cronograma de entrega.").
• Lógica condicional (Conditional Logic): Defina regras de tratamento para cenários específicos (por exemplo: "Se o status do pedido for 'Entregue', mas o cliente afirmar que não recebeu o pacote, inicie um fluxo de escalonamento para pacote extraviado.").
• Diretrizes de estilo e tom (Style and Tone Directives): Especifique as preferências de comunicação (por exemplo: "Forneça respostas concisas e profissionais. Evite jargões técnicos ao explicar os itens de linha da fatura.").

Os administradores devem buscar um design focado: normalmente de 10 a 15 tópicos distintos por agente, garantindo uma sobreposição semântica mínima entre as descrições de classificação para que o mecanismo não hesite nem classifique incorretamente as solicitações.

Etapa 2: Vinculando e configurando ações (Actions)

As ações são as ferramentas funcionais que um agente invoca para recuperar informações, criar ou atualizar registros e executar lógicas de negócios externas. Sem ações, um agente só pode conversar; com ações, um agente pode realizar trabalho real.

Tipos de ações disponíveis para administradores

Os administradores podem vincular vários tipos de ações a um tópico:

Configurando parâmetros e metadados da ação

Ao adicionar uma ação a um tópico, os administradores devem configurar as definições de parâmetros com descrições precisas em linguagem natural:

1. Selecionar a ação: Na exibição de detalhes do tópico, clique em Add Action e pesquise pelo Flow, método Apex, modelo de prompt ou serviço externo de destino.
2. Definir a descrição da ação: Forneça uma explicação explícita do que a ação realiza e quando ela deve ser chamada. O Atlas lê essa descrição para decidir se a ação é adequada para a etapa atual do seu plano de raciocínio.
3. Mapear parâmetros de entrada: Para cada parâmetro de entrada obrigatório (como caseId, customerId ou billingZipCode), especifique se o agente deve extrair o valor do contexto da conversa em andamento, solicitá-lo diretamente ao usuário ou passar uma variável de sistema estática.
4. Definir o tratamento da saída: Configure como o agente processa os valores retornados pela ação. Especifique se a saída deve ser retornada diretamente ao usuário como uma mensagem sintetizada ou repassada ao ciclo de raciocínio como contexto para uma ação subsequente.
5. Exigir confirmação (operações com alteração de estado): Para operações sensíveis ou irreversíveis — como processar um pagamento, cancelar um contrato ou excluir um agendamento de serviço —, os administradores podem habilitar requisitos de confirmação, forçando o agente a solicitar explicitamente a verificação do usuário antes de executar a ação.

Etapa 3: Implementando proteções (Guardrails) em múltiplas camadas

Agentes autônomos exigem uma governança robusta para evitar alucinações, vazamento de dados, violações de políticas e modificações não autorizadas de dados. Os administradores implementam proteções em quatro camadas distintas: instruções conversacionais, lógica determinística, permissões de acesso e controles de confiança da plataforma.

1. Proteções conversacionais por meio de instruções em linguagem natural

A primeira linha de defesa é declarar explicitamente restrições negativas nas instruções do tópico. Os administradores devem tratar as instruções como procedimentos operacionais padrão (POPs) fornecidos a um funcionário:

• Proibições explícitas: Articule claramente o que o agente nunca deve fazer (por exemplo: "Nunca prometa um crédito financeiro ou reembolso superior a US$ 50 sem encaminhar para um supervisor.").
• Proteção à privacidade: Instrua o agente sobre como lidar com entradas confidenciais do cliente (por exemplo: "Nunca peça ao cliente o número completo do cartão de crédito, dados da conta bancária ou número do documento de identidade emitido pelo governo. Se o cliente fornecer voluntariamente essas informações, não as repita na conversa.").
• Gatilhos de escalonamento suave: Especifique critérios exatos para quando o agente deve interromper o processamento e transferir o cliente para um atendente humano via Omni-Channel (por exemplo: "Se o usuário mencionar medidas legais, exigir falar com um gerente duas vezes ou usar linguagem abusiva, invoque imediatamente a ação Transfer to Agent.").

2. Proteções de lógica determinística

Embora os LLMs se destaquem na compreensão de nuances conversacionais, cálculos críticos e regras de negócios determinísticas nunca devem ser deixados para estimativas generativas. Os administradores devem aplicar limites estritos transferindo a lógica crítica para código determinístico:

• Usar Flows e Apex para cálculos e validações: Se um desconto precisar seguir faixas estritas com base no valor do tempo de vida do cliente (LTV), encapsule o cálculo dentro de um fluxo de inicialização automática (Autolaunched Flow) ou método Apex. Faça o agente invocar a ação em vez de calcular descontos de forma generativa.
• Validação de saída: Use regras de validação e elementos de decisão de fluxo para rejeitar parâmetros de entrada inválidos antes que os registros sejam confirmados no banco de dados.

3. Proteções de permissão e controle de acesso

Os agentes do Agentforce executam ações dentro de um contexto de execução específico. Os administradores devem impor o princípio do menor privilégio em toda a identidade do agente:

• Usuário e perfil de agente dedicados: Cada agente opera sob um registro de usuário dedicado do Salesforce. Os administradores devem criar um perfil e um conjunto de permissões (Permission Set) especializados e adaptados exclusivamente ao escopo operacional do agente.
• Segurança em nível de objeto e campo (FLS): Garanta que o conjunto de permissões do agente conceda apenas acesso de leitura (Read) ou edição (Edit) aos objetos padrão e personalizados específicos necessários para os tópicos atribuídos. Nunca conceda a permissão Modify All Data ou permissões administrativas amplas.
• Regras de compartilhamento (Sharing Rules): Verifique se o usuário do agente respeita os padrões para toda a organização (OWDs) e as regras de compartilhamento baseadas em funções, garantindo que ele não possa recuperar registros de clientes fora do seu território ou divisão autorizada.

4. Proteções no nível da plataforma: Einstein Trust Layer

O Agentforce opera sobre o Einstein Trust Layer da Salesforce, oferecendo recursos de segurança integrados que exigem configuração administrativa mínima:

• Retenção zero de dados (Zero-Data Retention): O Einstein Trust Layer garante que os modelos de fundação de terceiros não retenham nem utilizem para treinamento os dados de clientes empresariais enviados nos prompts.
• Mascaramento automatizado de dados: Informações de identificação pessoal (PII) — como números de previdência social, endereços de e-mail e números de telefone — são detectadas e mascaradas automaticamente antes que o prompt saia do limite de confiança do Salesforce.
• Defesa contra toxicidade e injeção de prompt: As entradas do usuário e as saídas geradas pelo modelo são verificadas em busca de linguagem tóxica, discurso de ódio e ataques de injeção de prompt que tentem violar as instruções do agente.
• Trilha de auditoria e observabilidade: Cada interação, incluindo os dados de aterramento (grounding) recuperados, o prompt enviado, o raciocínio intermediário do modelo e a resposta final, é registrada nos registros de auditoria do Data Cloud para revisão de conformidade e governança.

Etapa 4: Testes, observabilidade e aprimoramento

Antes de implantar um agente em canais reais de clientes ou internos, os administradores devem validar seus caminhos de raciocínio e aprimorar suas instruções.

Usando o painel de visualização de conversas

O Agentforce Builder inclui um painel de Preview interativo que permite aos administradores simular conversas em tempo real:

1. Testar o "caminho feliz" (Happy Path): Insira consultas padrão de usuários para verificar se o agente classifica corretamente a intenção, seleciona o tópico adequado e chama a ação correspondente.
2. Inspecionar rastros de raciocínio: Clique no resumo de raciocínio na janela de visualização para revisar o processo de pensamento interno do agente. Inspecione qual tópico foi selecionado, quais instruções influenciaram a resposta e quais parâmetros de entrada foram passados para as ações invocadas.
3. Testar casos extremos e proteções: Envie intencionalmente consultas fora do escopo, solicitações ambíguas e prompts adversários (como pedir ao agente que ignore suas instruções ou revele configurações internas do sistema). Confirme se o agente permanece dentro do escopo, cita adequadamente as políticas da empresa ou escala para um representante humano.

Implantação e monitoramento em produção

Concluídas a configuração e os testes em sandbox:

• Ativação de canais: Ative o agente e atribua-o aos canais de implantação, como Salesforce Service Cloud Messaging, sites do Experience Cloud, aplicativos móveis ou espaços de trabalho internos do Slack.
• Agentforce Command Center: Monitore métricas de desempenho em tempo real, incluindo taxas de desvio (autoatendimento), distribuição de tópicos, taxas de sucesso de ações e frequências de escalonamento.
• Ajuste contínuo de prompts: Revise os logs de sessão em que o agente escalou prematuramente ou classificou intenções incorretamente. Refine as descrições de classificação de tópicos e adicione instruções negativas esclarecedoras para eliminar ambiguidades ao longo do tempo.

Ao definir sistematicamente tópicos granulares, capacitá-los com ações invocáveis robustas e protegê-los com barreiras de proteção em múltiplas camadas, os administradores do Salesforce transformam modelos generativos em colegas de trabalho digitais autônomos e confiáveis, capazes de impulsionar a eficiência corporativa enquanto salvaguardam os padrões da empresa.