Agentforce Observability não mede adoção, e isso muda como você deve reportar resultado
Entenda a diferença entre saúde operacional do agente e adoção de negócio antes de levar métricas erradas para o board
O Agentforce Observability foi desenhado para confiança operacional, não para provar ROI de adoção. Para medir adoção de verdade é preciso combinar Agent Analytics, dados do Data 360 e feedback qualitativo do time de negócio.
Tem uma pergunta que volta sempre na mesma semana em que o cliente assina o contrato de Agentforce: "beleza, e como eu vou provar pro board que isso está funcionando?". E aí o admin abre o Observability, vê um monte de gráfico bonito, e sai da reunião sem saber se aquilo responde a pergunta de negócio ou só a pergunta de infraestrutura.
Essa confusão não é falta de competência de ninguém. É porque Observability e adoção são duas coisas diferentes que o Salesforce resolveu empacotar no mesmo produto, e cada papel dentro do projeto enxerga uma fatia diferente do bolo.
O que o Observability realmente mede
O Agentforce Observability nasceu para resolver um problema de confiança operacional, não de ROI de negócio. É um produto que entrega as ferramentas para medir, analisar e otimizar agentes, focado em dois casos de uso: Agent Optimization, para explorar interações não resolvidas e lacunas de conhecimento usando o modelo de dados de Session Tracing , e Agent Analytics, que é onde a maioria dos admins procura adoção sem saber que está procurando no lugar certo.
O Agent Analytics permite analisar tópicos do agente, feedback médio e métricas de efetividade como taxa de escalonamento, taxa de deflexão e sessões abandonadas . Isso é operação, é qualidade de resposta, é saúde do agente. Não é, por si só, adoção no sentido que um VP de vendas ou de serviço entende: "minha equipe está usando isso de verdade, ou só está rodando no fundo sem ninguém interagir?".
Os dados que alimentam esses dashboards vêm do Data 360. O Session Tracing Data Model registra toda interação, entradas do usuário, respostas do agente, passos de raciocínio, chamadas ao modelo de linguagem e verificações de guardrail, armazenando tudo em Data 360 . Isso importa demais na hora de desenhar governança: se você já tem Data 360 ativo no projeto, o custo marginal de observabilidade é baixo, mas se sua org ainda não tem uma estratégia de dados madura, vai sentir a limitação na hora de cruzar isso com outros objetos de negócio.
Tecnicamente, vale saber que o refresh não é tempo real. O Session Tracing refresca a cada 30 minutos aproximadamente, Agent Analytics atualiza métricas a cada 45 a 60 minutos, Moments e Quality Scores são diários, e Tags são semanais . Isso derruba de cara a expectativa de quem quer ver no dashboard, na hora, o impacto de um ajuste de prompt que acabou de fazer.
As três frentes que compõem o produto
Vale separar mentalmente em três blocos, porque cada um serve a uma audiência diferente no projeto:
- Agent Analytics: a camada de negócio. Mostra volume, efetividade, tendência de KPI. É aqui que o service leader ou o sales ops encontra algo parecido com "adoção", ainda que de forma indireta via volume de sessões e engajamento por tópico.
- Agent Optimization: a camada de arquiteto e dev.
Fornece visibilidade de ponta a ponta de cada interação, agrupa solicitações similares para revelar padrões e identifica problemas de configuração . É onde você vai quando o agente está "tecnicamente funcionando" mas entregando resposta ruim.
- Agent Health Monitoring: a camada de operação e SRE.
Rastreia métricas de saúde quase em tempo real e envia alertas sobre erros críticos e picos de latência , com disponibilidade geral chegando na Spring 2026.
Nenhuma dessas três frentes nasceu pensando em "quantos usuários internos realmente estão usando o Employee Agent" ou "quantos vendedores estão de fato confiando na recomendação do Sales agent em vez de ignorar". Isso é adoção no sentido clássico de change management, e o Observability não resolve isso sozinho.
Onde a arquitetura entra
Se você quer medir adoção de verdade, não dá para terceirizar isso 100% pro dashboard nativo. Minha recomendação de projeto é combinar três camadas: Agent Analytics para efetividade e volume, relatório customizado em cima dos dados de Data 360 (ou exportado via Tableau, para quem tem Tableau Plus) cruzando sessão com objeto de negócio real (oportunidade, caso, pedido), e um processo simples de feedback qualitativo com o time de negócio, porque número sozinho não conta a história de confiança.
Porque todo projeto de Agentforce que começa sem definir "o que é sucesso" antes de ativar o agente, termina na reunião de trimestre sem resposta pra pergunta óbvia: valeu a pena? O Observability entrega dado técnico de sobra, mas confundir taxa de deflexão com adoção real do negócio é um erro clássico que gera relatório bonito e decisão de continuidade errada. Isso afeta diretamente a credibilidade do projeto perante a liderança, principalmente quando o investimento em Agentforce Revenue Management ou em agentes de serviço precisa ser justificado na próxima rodada de budget.
Essa dúvida de admin no Reddit é sintoma de um padrão que vejo em quase todo projeto de Agentforce: a empolgação de ativar o agente chega antes da definição de métrica de sucesso, e aí o Observability vira bode expiatório de uma lacuna que é de planejamento, não de produto.
- Defina adoção com o negócio antes de ativar o agente: volume de sessão não é a mesma coisa que confiança do usuário na resposta.
- Use Agent Analytics para efetividade (deflexão, escalonamento, abandono) e trate isso como saúde do agente, não como KPI de adoção isolado.
- Cruze dados do Session Tracing (via Data 360, Tableau com licença Plus, ou relatório customizado) com objetos de negócio reais para enxergar impacto de fato.
- Ajuste a expectativa de stakeholder sobre tempo de atualização: nada aqui é tempo real, os ciclos de refresh variam de 30 minutos a semanal dependendo da métrica.
- Para Employee Agents internos, não dependa só do dashboard nativo: complemente com pesquisa simples de satisfação ou taxa de reuso por usuário.
Cuidado com dois erros recorrentes. O primeiro é tratar taxa de deflexão alta como sinônimo de adoção saudável: um agente pode estar "resolvendo" muita coisa e ainda assim ser evitado pelos usuários que preferem o caminho antigo. O segundo é subestimar a dependência de Data 360 bem configurado: sem fundação de dados organizada, a análise de Observability fica superficial e você acaba brigando com o dashboard em vez de brigar com o problema de negócio. Antes de prometer relatório de adoção pro cliente, confirme qual licença está disponível (Tableau Plus muda o que dá para customizar) e alinhe expectativa sobre o que é nativo e o que vai exigir construção adicional.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.
A resposta sai do que está publicado aqui. Se não estiver, ele diz que não sabe em vez de inventar.