Flow como ação de agente no Agentforce: o caminho mais curto entre automação clássica e IA conversacional

O atalho que já existe na sua org

Quem constrói automações com Salesforce Flow tem um caminho direto para entrar no Agentforce sem precisar escrever Apex ou se aventurar em prompt templates complexos: transformar um Autolaunched Flow em uma ação customizada do agente. É o tipo de configuração que parece incremental, mas muda o comportamento do agente de forma fundamental. Em vez de apenas devolver respostas baseadas em conhecimento, o agente passa a criar registros, atualizar campos, disparar e-mails e orquestrar processos inteiros — tudo a partir de uma conversa em linguagem natural.

O que é uma ação baseada em Flow no Agentforce

No Agentforce, ações são as tarefas que o agente consegue executar. A Salesforce entrega um conjunto de ações padrão — consultar dados, identificar registros por nome, entre outras — mas o ganho real aparece quando você cria ações próprias adaptadas ao seu contexto de negócio.

O Atlas Reasoning Engine lê a descrição da ação, decide quando ela é relevante dentro da conversa, coleta os inputs necessários com o usuário, executa o Flow no backend e devolve os outputs ao chat. Nenhum clique humano em tela. Nenhuma navegação de interface.

Por isso, o Flow precisa obrigatoriamente ser do tipo Autolaunched. Screen Flows e Record-Triggered Flows não funcionam neste cenário — não são invocáveis de forma assíncrona pelo motor de raciocínio.

O fluxo de construção, na prática

A montagem segue três etapas que merecem atenção redobrada, especialmente nos detalhes de configuração:

1. Construir o Autolaunched Flow com a interface correta

Defina todas as variáveis de input e output antes de salvar o Flow e criar a ação a partir dele. Esse ponto é crítico: depois que a ação do agente é vinculada ao Flow, alterar a interface de entradas e saídas implica praticamente refazer a ação do zero.

Cada variável marcada como Available for input ou Available for output precisa ter uma descrição clara e objetiva. Não é detalhe cosmético — é exatamente esse texto que o Agentforce usa para entender o que coletar do usuário e o que devolver na conversa. Uma descrição vaga aqui é um bug de comportamento no agente.

2. Criar a ação do agente

Em Setup > Agentforce Assets, escolha o tipo Flow e referencie o Flow construído. A descrição da ação funciona como instrução direta para o motor de raciocínio decidir quando acioná-la. Escreva como se estivesse explicando para um colega que nunca viu o processo: o que a ação faz, em que situação ela deve ser usada e o que ela retorna. Quanto mais precisa for essa descrição, menor o risco de roteamento incorreto.

3. Adicionar a ação a um Topic (Subagent)

Topics — recentemente renomeados para Subagents — agrupam o escopo de atuação do agente, e as ações vivem dentro deles. A separação entre Topics é tão importante quanto a configuração das próprias ações: ela define os limites de responsabilidade de cada agente e evita colisão de roteamento.

Nas configurações de input e output, alguns detalhes têm impacto direto no comportamento em produção:

• Require input: marque sempre que o Flow não puder executar sem aquele valor. Sem isso, o agente pode tentar rodar com campo vazio e falhar silenciosamente — o pior tipo de falha.
• Collect data from user: define se o valor vem da conversa ativa ou do contexto da sessão. Confundir esses dois cenários gera coleta de dados desnecessária ou, pior, uso de contexto desatualizado.
• Show in conversation: pelo menos um output precisa estar marcado. Caso contrário, o agente executa o Flow e não tem nada para mostrar ao usuário — a conversa simplesmente congela.
• Filter from agent action: útil para dados sensíveis que não devem aparecer no chat nem ser referenciados pelo modelo na resposta. Use com critério em cenários que envolvem dados pessoais ou informações regulatórias.

Onde os projetos costumam tropeçar

Alguns padrões de erro se repetem com frequência em times que estão desenhando ações via Flow pela primeira vez:

• Descrições vagas ou ausentes no Flow e nas variáveis. O resultado é um motor de raciocínio sem contexto suficiente para decidir corretamente — e você vai perceber isso pelos comportamentos estranhos do agente, não por mensagens de erro explícitas.
• Interface de inputs/outputs mal planejada, gerando retrabalho intenso porque a ação fica "presa" ao design inicial do Flow.
• Instruções genéricas na ação, que se sobrepõem a outras ações do mesmo agente e confundem o roteamento. O agente escolhe a ação errada, ou não escolhe nenhuma, e o problema parece estar no modelo quando na verdade está na descrição.
• Inputs obrigatórios não marcados como required, levando a execuções incompletas e respostas inconsistentes que são difíceis de reproduzir e depurar.

Leitura editorial

Esse padrão de integração é provavelmente o ponto de entrada mais pragmático para times que já dominam Flow e querem começar a entregar valor real com Agentforce. Toda a lógica declarativa que já existe na org — criação de Case, abertura de Work Order, cálculos, chamadas a sistemas externos via HTTP Callout em Flow — pode ser reaproveitada diretamente como capacidade executável do agente. O reaproveitamento de ativos é real, não é marketing.

O ponto de atenção é de governança. Quanto mais ações baseadas em Flow você expõe ao agente, mais importante fica a curadoria das descrições e a separação clara entre Topics e Subagents. Sem esse cuidado, o Atlas Reasoning Engine começa a errar a escolha da ação, e o agente passa a parecer instável — sem que o problema esteja, de fato, no modelo.

Trate a biblioteca de ações como um produto interno: nomenclatura consistente, descrições padronizadas, testes de roteamento e versionamento dos Flows usados como ações.

É um trabalho que se parece muito mais com design de API do que com automação declarativa tradicional. E quanto antes o time absorver essa mentalidade, melhor a qualidade dos agentes que vai entregar.