Comece pela decisão, não pela interface
Uma tela de conversa pode esconder tipos de trabalho muito diferentes. “Atribuir casos desta região a esta fila” é uma regra explícita. “Explicar por que este cliente está insatisfeito com base em várias mensagens” exige interpretação. Pedir a um modelo que faça as duas coisas sem distingui-las dificulta os testes.
As orientações de arquitetura da Salesforce distinguem automação tradicional, trabalho de agentes e orquestração híbrida. Seus exemplos se referem aos próprios produtos Salesforce; eles fundamentam a distinção arquitetural, não uma afirmação de que a REDA tenha todas as capacidades do Agentforce. [1]
- A solicitação chega
- A IA propõe uma categoria
- As regras validam a rota
- A equipe trata a exceção
Divida o trabalho em três responsabilidades
| Responsabilidade | Abordagem inicial adequada |
|---|---|
| Condições conhecidas e resultados exatos | Flow ou código com validação explícita e tratamento de erros. |
| Ler, resumir ou propor a partir de texto variável | Resultado da IA avaliado com base em evidências e uma finalidade definida. |
| Decisões importantes ou ambíguas | Um revisor responsável com um caminho claro de escalonamento. |
Este é um referencial inicial, não uma regra de que todo Flow seja seguro ou toda etapa de IA exija uma tela de aprovação separada. Escala, comportamento das transações, permissões e consequências de falhas continuam importantes.
Um exemplo prático: encaminhar uma solicitação de atendimento
Cenário ilustrativo. Uma mensagem recebida contém uma reclamação de manutenção e uma dúvida de cobrança. A IA propõe duas categorias e destaca os trechos relevantes. Um processo configurado verifica as categorias permitidas, o acesso ao registro e os campos de encaminhamento obrigatórios. Um coordenador revisa pedidos mistos ou sem suporte, em vez de permitir que o modelo invente uma nova fila.
A ação de encaminhamento deve receber uma categoria validada e um identificador de registro, não uma instrução irrestrita para “resolver tudo”. Mantenha a regra existente que atribui uma categoria aprovada à sua fila. O modelo ajuda a interpretar o pedido; a ação controlada realiza a atualização.
Teste o limite entre as duas abordagens
- Um pedido que corresponda claramente a uma categoria deve seguir a rota esperada.
- Um pedido com instruções conflitantes deve se tornar uma exceção.
- Uma atualização de registro que falhou não deve ser descrita como concluída.
- Enviar o mesmo pedido duas vezes não deve criar trabalho duplicado silenciosamente.
Teste também volume e limites de transação para o desenho escolhido. A demonstração de um pedido bem-sucedido não prova que um processo em lote, uma execução agendada ou um canal de portal se comporte da mesma forma.
Onde REDA AI se encaixa
REDA AI pode ser configurada em torno de instruções de negócio, contexto disponível e ferramentas permitidas, com experiências diferentes para profissionais, automações e usuários externos. Integrar com automações existentes ainda exige desenho e testes; isso não acontece apenas escrevendo um prompt.
Traga o Flow existente ou o diagrama do processo à primeira conversa. Podemos identificar onde ele deve continuar determinístico e onde vale avaliar uma etapa assistida por IA. Explore a plataforma.
Fontes
- Salesforce Architects — Determining agentic vs. traditional workflow automation. Acessado em 22 de setembro de 2026.