Análise editorial original do OrbTrail, ampliada com pesquisa complementar, contexto prático e referências verificadas.
Um novo episódio do Salesforce Admins Podcast, publicado em 13 de agosto, recoloca a preparação de metadados no centro dos projetos de Agentforce. A entrevistada Skye Tyler descreve um cenário comum: pessoas conseguem interpretar quatro campos de data parecidos porque conhecem o processo e as exceções acumuladas ao longo dos anos; um agente não possui essa memória institucional. Quando nomes, descrições e help texts não explicam a diferença, o modelo precisa escolher com contexto insuficiente. A resposta pode soar correta e até funcionar repetidas vezes, mas isso não transforma uma decisão probabilística em uma regra confiável.
A conclusão importante não é que toda alucinação nasce em um campo sem descrição. Respostas erradas também podem decorrer de dados desatualizados, instruções conflitantes, recuperação inadequada, permissões, ações mal definidas ou limitações do modelo. Metadados são uma das camadas de contexto. Ainda assim, eles têm uma função especial no Salesforce: descrevem tanto o modelo de dados quanto automações e componentes do próprio agente. Ignorar essa camada deixa o planner tentando inferir o significado de elementos customizados que não existiam no treinamento geral do modelo.
A recomendação do podcast é trabalhar de forma incremental. Em vez de prometer uma limpeza completa da org, a equipe começa pelo processo que será atendido pelo agente e revisa os objetos, campos, automações e integrações que esse processo alcança. OrbTrail amplia essa orientação com uma exigência: a melhoria só está concluída quando a mesma bateria de solicitações, executada antes e depois da alteração, demonstra seleção mais consistente de subagentes, ações e resultados. Sem essa comparação, preencher descrições melhora documentação, mas não prova confiabilidade.
Mapeie o alcance real
Liste objetos, campos, Flows, ações, tópicos e sistemas externos que o caso de uso pode consultar ou executar.
Remova significados concorrentes
Diferencie propósito, regra de uso, unidade, origem e restrições nos pontos que o planner e as pessoas precisam interpretar.
Preserve a suíte de solicitações
Registre perguntas comuns, ambiguidades, exceções e resultados esperados antes de alterar o metadata.
Teste rota e resposta
Meça subagente, sequência de ações e resultado; rejeite ganhos de fluência que não corrigem a decisão.
Descrição de campo ajuda, mas o planner enxerga uma cadeia maior
O artigo de Joshua Birk sobre metadata como blueprint explica que Agentforce pode usar descrições de objetos, campos, fórmulas e ações para interpretar customizações. A documentação atual do Agentforce mostra a outra metade: o agente também possui metadata próprio. Bot e BotVersion identificam agente e versão; GenAiPlannerBundle reúne subagentes e ações; GenAiPlugin representa um subagente; GenAiFunction representa uma ação; e instruções do plugin orientam o comportamento. Isso significa que a pergunta ‘qual descrição devemos melhorar?’ não pode parar no Object Manager. Um campo perfeitamente documentado ainda pode ser usado pela ação errada se dois subagentes tiverem responsabilidades sobrepostas ou se seus contratos forem vagos.
Considere um agente de renovação com ‘Data de renovação’, ‘Data de término’ e ‘Prazo de cancelamento’. A descrição útil não repete o rótulo. Ela informa o evento representado, a fonte responsável, o fuso ou a granularidade relevante e quando o campo não deve ser usado. A ação que consulta o contrato precisa declarar entradas e saídas com a mesma precisão; o subagente precisa indicar quais solicitações pertencem ao seu trabalho. A análise deve percorrer a cadeia semântica completa: pergunta do usuário, subagente, ação, objeto, campo e resposta. É ali que contradições aparecem.
Limpe pela fronteira do agente e trate o restante como inacessível
A abordagem incremental reduz custo, mas só funciona quando o alcance do agente é uma fronteira técnica, não uma intenção escrita em uma apresentação. O podcast alerta que um agente pode explorar registros relacionados quando encontra uma possível conexão. Portanto, o inventário precisa partir das ações realmente disponíveis, dos campos retornados, das permissões da identidade de execução e de cada sistema externo que fornece contexto. O que não pertence ao caso de uso deve ser retirado da superfície ou explicitamente bloqueado, e não apenas deixado sem documentação esperando que o modelo ignore.
Essa fronteira também evita uma limpeza destrutiva. Renomear API names, alterar tipos ou remover campos pode quebrar Flows, Apex, regras, relatórios e integrações. Em muitos casos, melhorar descrição e help text oferece contexto sem mudar contratos técnicos; em outros, a ambiguidade revela duplicidade que merece uma refatoração controlada. A decisão exige análise de dependências, proprietário do processo, sandbox e rollback. O objetivo não é tornar todo metadata elegante para a IA. É tornar inequívoco o conjunto que o agente pode usar, preservando compatibilidade para pessoas e automações.
A prova da limpeza é uma diferença mensurável no comportamento
A Agentforce Testing API separa verificações que ajudam a localizar a melhora. Um teste de subagente compara a rota escolhida com o subagente esperado; um teste de ação verifica a sequência de ações; e um teste de resultado usa comparação semântica entre o resultado esperado e o produzido. Há ainda avaliações de coerência, completude, concisão, latência e aderência às instruções. Para metadata, a primeira linha de evidência deve ser rota e ação. Uma resposta mais bonita que continua consultando o campo errado é uma regressão mascarada por fluência.
Monte a linha de base antes de editar. Inclua sinônimos usados por usuários, perguntas incompletas, campos com nomes semelhantes, registros sem valores e casos em que o agente deve pedir esclarecimento ou recusar. Depois da mudança, execute exatamente a mesma suíte e examine conversas com falha. O indicador principal pode ser a taxa de seleção correta de subagente e ação; o resultado semântico funciona como segunda camada. Métricas operacionais — escalonamento, retrabalho e correção humana — só entram depois, quando volume e instrumentação permitem atribuição responsável.
Metadados de IA precisam entrar no processo normal de mudança
O risco retorna no sprint seguinte se descrições forem tratadas como um mutirão anterior ao lançamento. A orientação do podcast é atualizar o metadata relacionado sempre que um objeto ou Flow muda e tornar a revisão obrigatória para novos processos com agentes. O material recente da Salesforce sobre Center of Excellence complementa essa ideia ao pedir proprietário para mudanças de schema, registro de dívida técnica, baseline de qualidade de dados e política de governança de IA. A cadência sugerida é operacional e contínua, não uma aprovação trimestral distante da entrega.
Um gate prático de mudança pergunta: o significado de algum campo, ação ou saída mudou; a fronteira de acesso foi ampliada; as descrições e instruções continuam coerentes; e a suíte representativa passou? Salve metadata do agente, definições de teste e resultado aprovado junto da versão promovida. A conclusão é menos glamourosa que trocar de modelo, mas mais operacional: Agentforce não conhece as convenções privadas da empresa por osmose. Se o sistema não registra o que cada elemento significa e o pipeline não testa como esse significado é usado, o agente continuará preenchendo as lacunas por probabilidade.
