Orchestration Density: como escolher entre Flow, Apex e Agentforce com critério

O problema de escolha que ninguém quer admitir que tem

Existe uma decisão que ficou mais frequente, e mais complicada, desde que o Agentforce entrou em cena: até onde vai o território de um agente e a partir de qual ponto Flow, Apex ou Agente autônomo continuam sendo a resposta certa. Esse julgamento está sendo feito, todo dia, no achismo. E o custo disso aparece mais tarde: latência desnecessária, custo de tokens para resolver algo determinístico, imprevisibilidade em processos que precisam de consistência.

Para dar método a essa escolha, foi proposto o Orchestration Density Framework — um modelo que propõe medir a complexidade de raciocínio de um workflow antes de abrir qualquer builder. A premissa é direta: comece sempre pelo menor nível de densidade que resolve o problema. Subir de Flow para Agent Script, ou de Agent Script para um agente autônomo, só se justifica quando o desenho do processo genuinamente exige isso. Do contrário, você está pagando caro para resolver algo que um Flow determinístico entregaria em milissegundos.

Os três fatores do framework

O modelo propõe avaliar a densidade de orquestração a partir de três dimensões, nesta ordem:

1. Execution path — você consegue mapear todos os ramos do processo em design time? Se sim, automação tradicional é o ponto de partida. Um "nó em branco" não é uma lacuna para preencher depois: é o sinal de que o próximo passo só pode ser decidido em runtime. Esse é o território de agentes.
2. Goal complexity — cada ponto de decisão é resolvível por regra ou por julgamento? Flow lida bem com centenas de condições. O que muda o jogo não é a quantidade de regras — é quando o resultado depende de contexto que não cabe em um campo estruturado.
3. Modality mix — quais tipos de dado entram no processo? Estruturado de CRM, semiestruturado (e-mails, transcrições) ou não estruturado em tempo real (áudio, telemetria)? Modalidade alta não implica densidade alta automaticamente; às vezes uma única etapa de IA dentro de um Flow já resolve o problema.

A combinação dos três fatores aponta para o padrão arquitetural adequado:

• Baixa densidade: Flow ou Apex no comando, mesmo que façam chamadas pontuais a modelos de linguagem.
• Média densidade: Agent Script orquestra, acionando Flows e Apex conforme necessário.
• Alta densidade: um ou mais agentes autônomos são a única arquitetura viável.

O que muda na prática

Os casos de uso que ilustram o framework ajudam a calibrar o critério de forma concreta.

Notificações de outage: parece candidato a agente, não é

O gatilho é binário, as regras de segmentação são conhecidas, a consistência de mensagem é obrigatória e a trilha de auditoria não é opcional. Milissegundos importam. É Flow e Apex, ponto. Introduzir um agente aqui seria trocar previsibilidade por complexidade sem nenhum ganho real.

Geração de preço em quotes: CPQ existe por uma razão

Por mais que um LLM produza números "plausíveis", pricing é compromisso comercial. Precisa ser determinístico, rastreável e idêntico para a mesma entrada. CPQ foi construído exatamente para esse contrato. Delegar essa responsabilidade a um modelo é um risco arquitetural sem justificativa técnica.

Discovery conversacional + CPQ: o exemplo de densidade média

Aqui a fronteira é desenhada de propósito: o agente conduz a conversa de discovery, interpreta contexto não estruturado e entrega inputs estruturados para o CPQ calcular. Raciocínio onde o caminho não pode ser determinado antecipadamente, regra onde consistência é inegociável. Essa separação é o que torna a arquitetura defensável.

Atendimento inbound e nurturing de leads: sem alternativa determinística

Esses são os casos onde o agente não substitui um Flow — ele cobre um espaço que Flow nunca conseguiu cobrir. O caminho não pode ser desenhado em design time porque depende do que o cliente vai dizer, de como vai responder, de qual direção a conversa vai tomar. Densidade alta não é uma escolha de estilo; é uma necessidade estrutural.

Leitura editorial

O ponto forte do framework é dar vocabulário para conversas que hoje acontecem no achismo. A distinção entre rule-resolvable e judgment-resolvable é algo que vale levar para a reunião de discovery e refinement. Ela ajuda a frear o entusiasmo de transformar qualquer requisito em agente e, ao mesmo tempo, oferece critério para defender o uso de Agentforce quando ele realmente é a única opção viável — não por hype, mas por necessidade arquitetural.

O framework não é uma régua oficial de produto. É um guia de arquitetura — e precisa ser tratado como tal.

A aplicação prática ainda depende de validar em org, medir custos de execução reais, definir governança sobre quando agentes podem acionar Flows e como auditar decisões tomadas em runtime. Nenhum framework substitui esse trabalho.

Mas como ponto de partida para padronizar decisões de automação dentro de um time ou de uma squad de arquitetura — para substituir "achei que fazia sentido usar um agente" por um critério compartilhado — ele cumpre bem o papel.