Quando um agente modifica um registro, não há usuário a responsabilizar. Nenhuma sessão para anexar uma entrada de auditoria. Nenhum humano que conscientemente aprovou a ação. Esse é o problema de governança que o Agentforce cria em escala — e a plataforma não resolve por você.
A Salesforce reportou 3,8 bilhões de AWUs processados com crescimento de 111% trimestre a trimestre. Alguém está pagando por esse processamento, e alguém é responsável pelas mudanças de registro que esses agentes fizeram. Este post é sobre construir a arquitetura que mantém ambos sob controle.
Custo de AWU: Previsão e Onde Arquitetos Sobre-Provisionam
Um Agentic Work Unit (AWU) é consumido cada vez que um agente realiza uma ação: uma chamada de ferramenta, uma leitura de registro, uma escrita de registro, uma etapa de raciocínio. O modelo de cobrança significa que uma cadeia de agentes mal projetada não apenas produz resultados ruins — produz resultados ruins e caros.
O padrão de sobre-provisionamento mais comum que já vi são agentes que entram em loop. Um agente é configurado para fazer retry em input ambíguo, então chama a mesma ferramenta três vezes com parâmetros ligeiramente diferentes tentando resolver uma incerteza que deveria ter sido tratada por um design de prompt melhor ou por retornar uma resposta estruturada de "precisa de esclarecimento". Cada iteração consome AWUs.
Uma abordagem prática de previsão: instrumente uma amostra de 50 a 100 requisições representativas em sandbox e registre o consumo de AWU por tipo de requisição. Em seguida modele contra o volume esperado em produção. Não modele contra a complexidade média — modele contra o percentil 90, porque é onde as surpresas de orçamento aparecem.
Padrões que consistentemente sobre-consomem em escala:
- Ações de recuperação sem limite: um agente que busca "todos os registros relacionados" em vez de uma consulta delimitada. Em volumes pequenos isso é invisível. Em escala de produção, uma conta com 2.000 casos tem um footprint de AWU completamente diferente de uma com 5.
- Loops de retry sem backoff: agentes configurados para repetir chamadas de ferramentas com falha indefinidamente, consumindo AWUs enquanto aguardam um sistema externo se recuperar.
- Etapas de raciocínio desnecessárias: agentes promovidos para "pensar passo a passo" para operações CRUD simples que não se beneficiam de chain-of-thought.
Configure alertas de consumo de AWU a 70% do limite do seu entitlement. Quando você está a 90%, já está em modo de recuperação.
Design de Audit Trail para Ações de Agentes
Os audit trails de Flow funcionam porque um humano iniciou o Flow — há uma sessão, um ID de usuário e uma intenção implícita anexados à mudança. Quando um agente modifica um registro, nada disso é verdade por padrão. A entrada de auditoria mostra o usuário de integração ou o running user do connected app do agente, e o "por quê" está completamente ausente.
Essa lacuna importa para compliance. Se um auditor perguntar por que a Oportunidade XYZ teve seu estágio alterado numa data específica, "o agente do Agentforce fez isso" não é uma resposta aceitável na maioria das indústrias reguladas.
A arquitetura que eu recomendo: toda ação de agente que modifica um registro deve escrever um registro complementar em um objeto customizado Agent_Audit__c antes de executar o DML. No mínimo, capture:
- O nome e versão do agente
- A requisição que disparou a ação (ou um resumo sanitizado se contiver PII)
- A ação específica tomada e em qual registro
- O estado dos dados antes da mudança (um snapshot JSON dos campos relevantes)
- O nível de confiança ou resumo de raciocínio se o modelo o expõe
- Um correlation ID que se vincula de volta ao log completo da sessão do agente
Isso não é automático. Você precisa construir a ação que escreve o registro de auditoria e invocá-la explicitamente na sequência de ações do seu agente. Os logs de auditoria nativos do Agentforce fornecem dados no nível de sessão; eles não fornecem contexto de mudança no nível de campo vinculado à intenção de negócio.
Para orgs sob SOX, HIPAA ou frameworks regulatórios similares, esse objeto de auditoria complementar é não-negociável. Projete-o no início do projeto, não como um retrofit.
Estratégia de Rollback
Uma cadeia de agentes executa 15 mudanças de registro. A etapa 12 falha. A plataforma faz rollback da transação DML da etapa 12, mas as etapas 1 a 11 já foram commitadas. Você agora tem um workflow parcialmente executado sem caminho de recuperação embutido.
O Salesforce não fornece compensação automática no estilo saga para cadeias de agentes com múltiplas etapas. Você projeta para isso, ou aceita execução parcial como um estado permanente.
Existem duas abordagens viáveis dependendo da sua tolerância e orçamento de complexidade.
Rollback baseado em checkpoints: antes de cada estágio significativo da cadeia, faça snapshot do estado dos registros relevantes no objeto Agent_Audit__c (ou num objeto de snapshot específico para isso). Se a cadeia falhar, um Flow ou job Apex compensatório pode restaurar os snapshots. Isso funciona bem quando o número de registros afetados é delimitado e previsível.
Re-execução idempotente: projete cada ação na cadeia para ser idempotente — executá-la duas vezes produz o mesmo resultado que executá-la uma vez. Então, em caso de falha, você re-executa a cadeia inteira do passo 1 com o mesmo input. Isso requer que suas ações verifiquem pré-condições antes de escrever ("se este registro já tem status X, pule a escrita") e que as chamadas ao sistema externo também sejam idempotentes. Mais trabalho de design no início, mas recuperação de falhas mais simples.
O que não funciona: confiar que o agente vai se recuperar. Se a etapa 12 falhou por causa de uma violação de constraint de dados ou de um timeout downstream, o agente não tem contexto suficiente para saber em que estado as etapas 1 a 11 deixaram a org. A recuperação deve estar fora do agente.
Checkpoints Human-in-the-Loop
Para indústrias reguladas, cadeias de agentes totalmente autônomas muitas vezes não são aceitáveis — não porque a tecnologia não consiga fazer isso, mas porque os frameworks regulatórios exigem aprovação humana documentada para certas categorias de ação.
O padrão prático: bloqueie ações de alto risco atrás de um Platform Event ou de uma fila de aprovação customizada. O agente executa até o checkpoint, publica um evento (ou cria um registro Pending_Approval__c), e aguarda. Um humano revisa e aprova ou rejeita. A cadeia de agente retoma ou termina com base na decisão.
O desafio de implementação é que o agente não "espera" no sentido tradicional. Você precisa persistir o estado da cadeia no checkpoint, armazenar contexto suficiente para retomar de forma limpa, e invocar a lógica de continuação quando a aprovação chegar. Isso é arquiteturalmente mais próximo de um workflow assíncrono do que de uma execução de agente única.
Evite a tentação de fazer cada ação requerer aprovação — isso não é automação, é um workflow de aprovação complicado. Bloqueie as categorias genuinamente de alto risco: ações irreversíveis, transações de alto valor, mudanças em dados regulados. Todo o resto deve fluir de forma autônoma.
O Problema do Agente Zumbi
Um agente fica preso num estado ambíguo — esperando por um sistema externo que está fora do ar, preso num loop de retry, ou travado numa chamada de ferramenta que nunca resolve. Ele não está falhando com força suficiente para expor um erro. Está apenas consumindo AWUs e não fazendo progresso. Esse é um agente zumbi.
A plataforma não tem um circuit breaker embutido para isso no nível da cadeia. Você o constrói.
Padrões de detecção que funcionam:
- Execução com limite de tempo: defina um tempo máximo de wall-clock para a cadeia. Se a execução não tiver concluído em N segundos, dispare um evento de encerramento e escreva um registro de diagnóstico. O Agentforce tem seu próprio comportamento de timeout, mas não é configurável por cadeia — você precisa de monitoramento externo.
- Limite de consumo de AWU por requisição: se uma única requisição consumiu mais de X AWUs sem produzir uma resposta final, trate isso como anômalo e sinalize para investigação.
- Dead letter queue: ações de agente que falham após esgotar os retries devem escrever em uma fila de falhas persistente (
Agent_Dead_Letter__cou similar) com contexto completo. Sem isso, cadeias com falha desaparecem em logs que ninguém monitora.
O padrão de circuit breaker para dependências externas: mantenha um registro de Custom Metadata que rastreia o estado de saúde de cada sistema externo que seus agentes chamam. Antes de fazer um callout, a ação verifica se o sistema alvo está marcado como DEGRADED ou DOWN. Se estiver, falha rapidamente com um erro estruturado em vez de tentar a chamada e queimar o timeout completo. Um job de monitoramento separado atualiza o estado de saúde com base nas taxas de sucesso de chamadas recentes.
Nada disso está embutido no Agentforce. É infraestrutura que você traz consigo.
Próximo nesta série: dar a agentes acesso seguro de leitura/escrita a ERPs legados e mainframes — a camada de integração que a documentação pula.
Qual é sua abordagem para governança de agentes? LinkedIn.
