O que os números do Agentic Enterprise Index realmente dizem sobre implementar Agentforce
Salesforce publicou dados de adoção de agentes em produção. Passei o filtro de arquiteto pelos números para separar sinal de marketing
Salesforce divulgou seu segundo Agentic Enterprise Index com dados reais de clientes usando Agentforce em produção. Analiso o que os números de crescimento, velocidade de deploy e sofisticação de agentes significam na prática para quem está desenhando arquitetura hoje.
Todo relatório de adoção de IA generativa vem com aquele número bonito de crescimento exponencial. O Agentic Enterprise Index não é diferente: agentes saltaram de uma média de 5 por conta em fevereiro de 2025 para 13 em abril de 2026, crescimento mensal composto de 7%. Só que, diferente da maioria dos relatórios de vendor, esse aqui tem um recorte interessante: só entrou na conta cliente que manteve agente em produção todos os meses do período. Isso filtra bastante ruído de POC que nunca saiu do papel.
O dado que mais me chamou atenção não foi o crescimento em quantidade, foi o tempo de deploy. Em abril de 2026, a média para colocar um agente em produção caiu para 1,9 dia, uma redução de 53% desde o início do período medido. Isso bate com o que vejo em projeto: o gargalo de Agentforce nunca foi construir o Topic e a Action no Agent Builder. É modelar a instrução certa, testar o grounding, decidir política de permissão e garantir que o Data Cloud tem o dado limpo para alimentar aquele agente. Quando esse trabalho de base já existe (e cada vez mais clientes já passaram por essa curva), o deploy em si é rápido mesmo.
Outro ponto que vale destacar: o número médio de ações por conta cresceu 31% ao mês composto ao longo dos 15 meses analisados. Ou seja, agente que nasce resolvendo uma coisa específica (responder FAQ, resumir caso) começa a assumir mais responsabilidade dentro do mesmo escopo. Isso é exatamente o padrão que vejo em cliente: o agente de atendimento que começa só triando ticket e seis meses depois já está atualizando campo, disparando Flow e criando registro relacionado. É crescimento orgânico de escopo, e isso tem implicação direta de governança que a maioria dos times não está tratando com o cuidado necessário.
A Salesforce também criou uma métrica própria, o Agentic Work Unit (AWU), para tentar medir volume de trabalho executado por agente em vez de consumo de token. Analistas de mercado já criticaram essa métrica por não se conectar claramente a resultado de negócio, e eu concordo com a ressalva: AWU é útil para a Salesforce mostrar tração em call de resultado, mas não é a métrica que eu levaria para uma reunião de ROI com cliente. Lá, o que interessa é redução de tempo de resolução, taxa de escalação para humano, custo por interação. AWU é proxy de atividade, não de valor entregue.
Um dado qualitativo que faz sentido de campo: o relatório aponta que manufatura, serviços financeiros e healthcare construíram redes de agentes mais sofisticadas (usando uma escala de 1 a 5 de complexidade cognitiva) do que setores tradicionalmente vistos como early adopters de tecnologia, como tech e retail. Não me surpreende. Empresas reguladas tendem a investir mais tempo desenhando processo, permissão e trilha de auditoria antes de soltar agente em produção, e isso paradoxalmente gera implementações mais maduras, mesmo que mais lentas para sair do papel.
O ponto mais prático do relatório, na minha leitura, é a mudança de comportamento do usuário final: as pessoas pararam de perguntar para o agente e começaram a instruir o agente a executar. Em vez de "como eu solicito férias", o funcionário diz "estou saindo de férias, preenche o formulário para mim com esses dados". Isso é o divisor de águas entre um chatbot com IA e um agente de fato: a mudança de postura consultiva para postura de execução de ação. E é exatamente aí que a arquitetura precisa estar pronta, porque ação errada de agente tem custo de negócio real, diferente de resposta errada num FAQ.
Esses números servem como termômetro de mercado: se o tempo de deploy está caindo e o escopo dos agentes está crescendo, isso significa que times de arquitetura precisam parar de tratar Agentforce como piloto isolado e começar a desenhar governança de permissão, auditoria e escopo de ação desde o primeiro agente, porque a expansão de responsabilidade vem rápido e sem aviso.
O dado sobre setores regulados terem redes mais sofisticadas também é um recado prático: sofisticação não vem de tecnologia mais avançada, vem de processo mais maduro por trás. Isso desmistifica a ideia de que basta ativar Agentforce para ter resultado sofisticado.
Este texto é uma leitura própria sobre dados publicados pela Salesforce em seu segundo Agentic Enterprise Index. Os números de crescimento, tempo de deploy e AWU são factuais e vêm de estudo da própria empresa com dados de clientes; as interpretações sobre governança, ROI e maturidade setorial são análise minha a partir de experiência de projeto, não afirmação da fonte original.
Antes de comemorar tempo de deploy rápido, valide se sua organização já tem a base pronta: Data Cloud com dado limpo e unificado, política de permissão desenhada por Topic e Action, e processo de teste de grounding documentado. Deploy rápido só é vantagem se o trabalho de fundação já foi feito; caso contrário, você só está acelerando a entrega de um agente mal calibrado.
Se seu agente está expandindo escopo de ação organicamente (como o índice sugere que é o padrão), formalize esse crescimento com revisão periódica de permissão e auditoria de ações executadas, não deixe o escopo crescer só porque "funcionou até agora".
Cuidado com o AWU como métrica de sucesso em apresentação para stakeholder de negócio. Volume de ação executada não é sinônimo de valor entregue, e um agente pode gerar muito AWU fazendo trabalho redundante ou de baixa qualidade. Prefira métricas conectadas a resultado: tempo de resolução, taxa de escalonamento, satisfação do usuário final.
O salto de agente "responde pergunta" para agente "executa ação" muda completamente o peso de erro. Um agente que erra uma resposta é inconveniente; um agente que erra uma ação (atualiza campo errado, dispara Flow indevido) é incidente de dado. Trate a transição de nível de sofisticação como gatilho para reforçar teste, sandbox e trilha de auditoria, não como upgrade natural sem fricção.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.