Otimização de recursos e custo para a empresa do agente

Agentes autônomos consomem recursos do Salesforce de maneira diferente da automação determinística. As cargas de trabalho do agente são imprevisíveis e contínuas, em vez de fixas e vinculadas a transações. A tese de valor por custo do pilar Recurso e Otimização de custo leva diretamente para a Enterprise do agente. A eficiência do recurso significa usar a capacidade que você já paga, e a otimização de custo significa direcionar o gasto deliberadamente para os recursos autônomos que ganham um retorno. Os agentes mudam a forma de ambos. O design eficiente do agente mantém o consumo sob controle, e a seleção de modelo de precificação, a modelagem de custo total de propriedade (TCO) e a governança financeira mantêm o gasto alinhado ao valor. Este documento trata a eficiência do recurso e a otimização de custo como uma decisão, pois, para agentes, são duas visões da mesma meta.

Os agentes alteram a previsibilidade do consumo. Um processo Apex tradicional opera em um conjunto de registros conhecido com um custo de recurso conhecido. Um agente opera de modo conversacional e uma única conversa pode executar dezenas de ações como os motivos do agente em uma tarefa. Cada ação consome limites do controlador em sua própria transação, em vez de acumulá-los na conversa. A preparação de contexto para um turno pode consultar 200 registros ou 20 mil, dependendo do que o usuário pedir. O consumo de API é acelerado porque os agentes podem agir de modo autônomo e agentes proativos, de saída e agendados agem continuamente, em vez de apenas durante uma transação do usuário. Essa imprevisibilidade é por que o gerenciamento de recursos do agente precisa ser defensivo por design, em vez de ajustado após um pico de consumo ocorrer.

O lado do custo muda igualmente. Os agentes autônomos introduzem uma precificação baseada em consumo que se comporta de maneira diferente da licença por lugar tradicional. A Agentforce oferece dois modelos de precificação baseados em consumo, Flex Credits e Per-Conversation. Cada implantação do agente seleciona um destes modelos. Uma organização usa um modelo de consumo por vez, mas um complemento Por usuário, oferecido por usuário por mês para uso não medido, pode ser colocado em camadas junto com um modelo de consumo para que os agentes voltados para o cliente sejam executados em Créditos flexíveis ou Por conversa enquanto os funcionários usam licenças não medidas. O Data 360 capacita a fundamentação do agente por meio da pesquisa e recuperação de vetores e consome capacidade de processamento de dados, enquanto o MuleSoft habilita integrações de agente que consomem capacidade da API. Esses custos variáveis são dimensionados com o uso do agente, o que cria um padrão de investimento que precisa de governança financeira criada para variabilidade, em vez de uma assinatura anual fixa.

Soluções projetadas para valor comercial com custo otimizado no Agent Enterprise mantêm o consumo do agente eficiente por meio de ações que processam registros em massa, janelas de contexto disciplinadas e armazenamento em cache. Eles também direcionam deliberadamente o gasto pelo modelo de precificação correto, a modelagem completa de TCO e o monitoramento contínuo de custo com relação aos resultados dos negócios. Sem esse alinhamento, as implantações do agente acumulam custo sem demonstrar valor proporcional, e um agente que tenha motivos em um loop não vinculado pode queimar créditos mais rapidamente do que a supervisão humana pode intervir. O mesmo trabalho de eficiência que mantém um agente dentro de seus limites de regulador mantém-o dentro de seu orçamento de crédito, que é a tese de pilar expressa em termos agentes.

Este documento abrange as alterações quando os agentes estão no cenário. Para os padrões de otimização de custo e recurso básicos que se aplicam a cada solução do Salesforce, incluindo otimização de desempenho, limites do regulador, análise de TCO e disciplina de licenciamento, consulte o pilar Otimização de recursos e custo. A governança dos agentes e a supervisão humana se conectam aos pilares de Trust e Fairness, que abrangem os componentes do programa que mantêm o comportamento autônomo seguro e responsável.

O consumo de recursos do agente segue a mesma mecânica de plataforma que o Fluxo ou o Apex, mas sua invocação imprevisível e conduzida por conversas torna o consumo mais difícil de prever e, portanto, requer padrões defensivos. Suas responsabilidades de otimização abrangem o orçamento de limite de controlador entre cadeias de ação, consumo de API, latência de resposta, eficiência de fundamentação do Data 360, gerenciamento de janela de contexto e design composível que permite aos agentes escalar sem duplicação. Cada responsabilidade é uma decisão de valor por custo antes de uma decisão técnica, pois os agentes repetem ineficiências em cada conversa.

Os agentes chamam ações que acionam Apex, fluxos e integrações. Uma única conversa pode executar dezenas de ações como os motivos do agente em uma tarefa complexa. A disciplina fundamental é a mesma de qualquer solução do Salesforce, mas o padrão de invocação imprevisível aumenta as apostas. Projete ações para aceitar coleções de modo que um agente atualizando 50 casos invoque uma ação em vez de 50 chamadas separadas. Uma única ação que opera em uma coleção de registros consome muito menos consultas da Linguagem de consulta de objeto do Salesforce (SOQL) e operações da Linguagem de manipulação de dados (DML) para o mesmo trabalho. Gerencie o orçamento SOQL entre cadeias de ação deliberadamente, pois um fluxo de trabalho que chama 10 a 15 ações pode se aproximar ou exceder o limite síncrono de 100 consultas quando cada ação executa várias consultas por conta própria. Use consultas de relacionamento para recuperar dados pai e filho em uma única instrução e referenciar dados armazenados em cache no Cache da plataforma entre ações na mesma conversa. Essas duas práticas mantêm uma cadeia de várias ações dentro de seu orçamento.

Mova operações de agente que excedem limites síncronos para o Apex Queueable ou Batch, em que o contexto assíncrono duplica aproximadamente o espaço de trabalho SOQL e CPU disponível para o trabalho. Operações analíticas grandes, como pontuar 1.000 leads ou analisar o sentimento em casos históricos, pertencem ao processamento assíncrono em vez de bloquear uma conversa. A própria inferência de modelo de idioma grande ocorre fora do Salesforce e consome créditos Flex em vez de tempo de CPU do Apex, portanto, o orçamento de CPU que você definir é consumido pela lógica de ação, transformações de dados e as integrações que o agente aciona. Cenários de distorção de dados em que os registros pai são associados a milhares de registros filho merecem atenção defensiva especial com os agentes. Essa vulnerabilidade surge porque um agente pode solicitar “todo o histórico” para uma conta com dezenas de milhares de registros relacionados de uma maneira que uma consulta determinística nunca faria. Projete ações com limites de registro filho e paginação rígidos e aplique amostragem quando os volumes excederem o limite de discagem de dados. Esses limites impedem que uma solicitação imprevisível se transforme em uma consulta não vinculada. O Rastreamento de sessão do Agentforce identifica quais ações consomem consultas excessivas no nível da sessão e o Centro de escala monitora o desempenho geral da transação do Apex e a integridade da organização.

As arquiteturas de agente consomem as APIs mais rapidamente do que os fluxos de trabalho conduzidos pelo usuário, pois os agentes operam de modo autônomo e, para agentes proativos ou agendados, continuamente. A exibição de um agente determina como ele reduz a capacidade da API. Os agentes chamados por meio da API REST consomem uma chamada por turno de conversa. Os agentes integrados a páginas do Lightning por meio de componentes padrão não consomem uma chamada de API por interação, embora seu custo ainda seja medido nos créditos ou conversas do modelo de precificação escolhido. Componentes da Web Lightning personalizados que fazem chamadas REST diretas consomem a capacidade da API. Componentes criados com adaptadores de conexão do Lightning Data Service não funcionam, pois o Lightning Data Service atende a partir de um cache compartilhado no lado do cliente, em vez de emitir uma chamada de API. Monitore o consumo no Monitoramento de evento durante um piloto para que você entenda o uso real antes de uma distribuição completa.

Os padrões conduzidos por evento são a maior alavanca no consumo de API de agente desperdiçado. Publicar um evento de plataforma quando uma condição requer intervenção do agente evita a pesquisa agendada que consome chamadas à API, independentemente de haver trabalho a fazer ou não, e um agente que assina eventos de Captura de dados de alteração mantém o contexto atual sem as chamadas diárias de pesquisa que um orquestrador externo faria de outra forma. A lógica de valor por custo é direta: Uma pesquisa que não encontra trabalho é capacidade gasta para nada, e um evento que é acionado apenas em uma alteração real é capacidade gasta apenas em trabalho real. A geração aumentada pela recuperação adiciona seu próprio consumo, pois cada pesquisa vetorial em relação ao Data 360 consome computação, portanto, defina os limites de recuperação para retornar apenas os resultados que o agente realmente usa.

A latência de um turno do agente é a soma do tempo de inferência do LLM, tempo de execução da ação, tempo de consulta do Data 360 e tempo de integração quando essas etapas são executadas em sequência. Quando não, é a ramificação paralela mais longa, além de todas as etapas sequenciais. A latência é uma preocupação de custo, bem como uma preocupação de experiência, porque uma ação lenta mantém os recursos abertos por mais tempo e um usuário frustrado inicia mais conversas do que uma solucionada. Avisos menores geram respostas mais rápidas, portanto, remova instruções verbosas, exemplos redundantes e contexto desnecessário. O contexto seletivo melhora a latência e a qualidade da resposta, em que um dump de contexto exaustivo adiciona apenas ruído. Mantenha ações rápidas por meio de SOQL seletivo em campos indexados, massificação e dados de referência em cache, pois uma ação de 3 segundos se torna um gargalo, não importa o quão rápida seja a inferência. Valide consultas de ação com a ferramenta Plano de consulta para identificar verificações de tabela completa que aumentam a latência da ação.

A orquestração do Criador de agentes pode executar ações em paralelo quando não há dependências entre elas, por exemplo, recuperar detalhes da conta e oportunidades relacionadas ao mesmo tempo leva tanto tempo quanto o mais lento dos dois, em vez de a soma de ambos. Para chamadas encaminhadas para vários sistemas a jusante, emparelhe o Agentforce com uma plataforma de integração, como o MuleSoft; o agente chama uma única ação, o MuleSoft recebe a solicitação e emite chamadas paralelas aos sistemas de back-end, depois retorna uma resposta agregada. O Cache da plataforma remove a inferência e a latência de consulta para solicitações repetidas, e processar trabalho não urgente de modo assíncrono, como uma análise de documento longo, permite que o agente reconheça a solicitação imediatamente e retorne o resultado quando estiver pronto, em vez de manter a conversa aberta.

O Data 360 fornece a pesquisa vetorial que baseia as respostas do agente nos dados atuais, em vez de apenas nos dados de treinamento do modelo, e sua eficiência controla a qualidade da fundamentação e o cálculo que você consome para alcançá-la. Particionamento, integração de seleção, filtragem de metadados e limites de resultados são as decisões mais valiosas. Particione o Knowledge em segmentos semânticamente significativos, porque fragmentos muito pequenos forçam muitas recuperações para uma pergunta, enquanto fragmentos muito grandes diluem a relevância com contexto irrelevante e inflamam o orçamento do token levado à inferência. Escolha um modelo de integração que corresponda à maneira como seus agentes realmente consultam, pois a similaridade de pergunta e resposta se comporta de maneira diferente da classificação de documento, e valide a opção em relação a consultas representativas. Combine a similaridade semântica com filtros de metadados para que as restrições de negócios se mantenham independentemente da similaridade, como excluir produtos descontinuados de uma recomendação, não importa o quão próxima seja a correspondência. Defina limites top-k para retornar apenas os resultados que o agente usa. Por exemplo, se 5 resultados informarem uma resposta, recuperar 50 adicionará 45 resultados não utilizados à carga útil de fundamentação e orçamento de token.

Os perfis unificados são eficientes com relação ao recurso porque um agente que consulta um perfil unificado do Data 360 recupera o contexto completo do cliente em uma única operação, em vez de orquestrar consultas separadas em Conta, Contato, Oportunidade, Caso e Campanha para cada turno. Configure as instâncias do Data 360 nas regiões que os requisitos regulatórios exigem para que os agentes que processam dados para uma determinada jurisdição consultem a instância que mantém dados pessoais dentro dela.

Janelas de contexto de modelo de idioma grande contêm um número finito de tokens, e gerenciar esse orçamento mantém uma longa conversa coesa sem esgotar a capacidade nem aumentar o custo de cada chamada de inferência. Priorize deliberadamente em vez de truncar arbitrariamente: O histórico de conversas recentes tem a prioridade mais alta, dados de negócios críticos, como estado e permissões de registro atuais, vêm em segundo plano e o histórico antigo é incluído apenas quando o espaço permite. Após os primeiros vários turnos, resuma a conversa anterior em uma visão geral concisa que preserve fatos críticos sem levar o histórico literal completo. Esse resumo preserva a continuidade sem aumentar o orçamento do token. Armazene o contexto estendido no Data 360 ou objetos personalizados como memória externa consultada sob demanda, em vez de reproduzir o histórico completo em cada chamada, e retorne apenas os campos essenciais de cada ação, pois uma resposta que carrega todos os 50 campos de um registro quando a tarefa precisa 8 gasta o orçamento de contexto mais alocado para conversa ou fundamentação.

Criar agentes usando componentes reutilizáveis reduz os custos de desenvolvimento e manutenção. Um recurso criado uma vez e reutilizado é muito mais barato durante sua vida útil do que o mesmo recurso reimplementado e mantido separadamente para cada agente. Bibliotecas de ações centralizadas que abrangem operações de registro, aprovações, notificações e validação permitem que as equipes da plataforma mantenham o comportamento, a segurança e o desempenho consistentes em todos os agentes consumidores, e permitem que um novo agente seja montado a partir de blocos de construção comprovados em dias, em vez de criar com ações personalizadas ao longo de semanas. Agentes especializados focados com limites de domínio claros mantêm um contexto mais estreito e um comportamento mais claro do que um único agente universal tentando cada cenário, e a orquestração do Criador de agentes coordena especialistas quando uma tarefa cruza domínios. Os modelos de prompts validados no Criador de prompts capturam padrões comprovados para a fundamentação, o raciocínio e a formatação de respostas para que a qualidade permaneça consistente à medida que o desenvolvimento é acelerado, e uma base de Knowledge compartilhada no Data 360 baseia muitos agentes de uma só fonte, de modo que uma atualização alcança todos os consumidores de uma só vez, em vez de exigir uma mudança para cada agente.

Equipes empresariais cada vez mais compõem vários agentes juntos, em vez de criar agentes monolíticos únicos, com um agente orquestrador decomponendo uma solicitação e delegando a subagentes especializados, ou agentes especializados entregando um ao outro à medida que uma conversa se move entre domínios. Esta composição levanta questões de recursos e custos além do que um único agente enfrenta, porque a sobrecarga de orquestração, o Trust interagente e a transferência de estado integram uma cadeia em vez de ficarem confinados a uma única ação. Mantenha os avisos de orquestração estreitos, limitados à classificação de intenção e roteamento, em vez de pedir para o orquestrador também justificar a tarefa subjacente, pois esse raciocínio pertence ao subagente com o contexto relevante e limite a profundidade da cadeia, a menos que um caso de uso exija claramente aninhamento mais profundo do que orquestrador-a-subagente. Trate cada resposta de subagente como uma entrada não confiável, como faria com uma resposta de API externa. Valide sua forma esperada e a conformidade com as regras de negócios antes de agir com base nela. Imponha a segurança e o compartilhamento em nível de campo de modo independente para cada ação do agente.

Passe apenas o estado de que o agente receptor precisa, usando uma carga útil de transferência estruturada de IDs de registro, resumo de tarefa e campos relevantes em vez de encaminhar o histórico de conversa bruto, de modo que o orçamento do token em toda a cadeia permaneça controlado e persista no estado da sessão entre agentes no Data 360 ou em um objeto personalizado quando uma transferência deve sobreviver em transações separadas. Os limites do controlador se aplicam por agente, não uma vez por conversa, assim, cada agente em uma cadeia obtém seu próprio orçamento de SOQL, DML e CPU. Uma cadeia de um orquestrador e três subagentes consome cada um desses limites quatro vezes mais, e cadeias mais profundas multiplicam o consumo ainda mais. A mesma multiplicação gera custo, o que torna a profundidade da cadeia não vinculada um risco de custo maior do que um limite do regulador.

Defina o que o orquestrador faz quando um subagente falha, atinge o tempo limite ou retorna um resultado de baixa confiança, seja uma nova tentativa limitada, uma resposta de fallback ou uma escalação para um humano, de modo que um único tempo limite do subagente não caia em cascata e falhe toda a cadeia. Correlacione uma solicitação em cada agente que ele toca com um ID de rastreamento compartilhado propagado por meio da carga útil de transferência, pois diagnosticar qual agente em uma cadeia causou um pico de latência ou um pico de custo, caso contrário, requer a correlação manual de registros entre sessões de agente separadas.

Ações com falha e chamadas de agente filho com falha não afetam apenas a confiabilidade, pois cada nova tentativa pode executar novamente o trabalho de SOQL, DML e CPU já gasto na tentativa com falha, e em uma cadeia de vários agentes esse custo é combinado com o número de agentes com falha a jusante. Na precificação baseada em consumo, os mesmos compostos de falha gastam e calculam: uma ação experimentada novamente consome créditos em créditos flexíveis. Projete a lógica de nova tentativa para considerar a confiabilidade e o custo. Diferencie falhas temporárias, como um tempo limite de chamada ou uma contenção de bloqueio, de falhas lógicas, como um erro de validação ou uma entrada malformada, antes de decidir como responder, pois uma falha temporária pode valer uma nova tentativa limitada, enquanto uma falha lógica falha de maneira idêntica na repetição e queima apenas o orçamento para uma falha garantida de repetição que deve ser escalada imediatamente.

Capte novas tentativas por ação, em duas ou três tentativas, e aplique um retorno exponencial entre elas, em vez de uma nova invocação imediata, porque uma nova tentativa sem limite ou com loop estreito em uma ação pesada em SOQL ou DML pode esgotar limites síncronos em uma única transação ou queimar o orçamento da cadeia cumulativa e os gastos de crédito cumulativos em uma conversa com vários agentes. Projete ações de modo que uma chamada repetida gere o mesmo estado final de uma única chamada bem-sucedida, usando uma chave de idempotency, como um ID da solicitação ou um ID externo com lógica de inserção e atualização, em vez de inserir, de modo que uma nova tentativa atualize o mesmo registro em vez de criar um duplicado; uma ação sem idempotency força uma nova tentativa a duplicar o consumo de recurso por meio de registros duplicados a jusante ou o dobro das ações ou conversas faturadas para o trabalho que já aconteceu uma vez.

Acompanhe o estado de conclusão por agente em uma cadeia, pois a ação de um agente pode confirmar DML com sucesso antes de um agente downstream falhar, e um manipulador de falha que sabe o que já foi bem-sucedido pode compensar ou retomar do ponto de falha em vez de reiniciar e faturar toda a cadeia. Detecte a nova tentativa ou o status em andamento para o usuário final enquanto uma nova tentativa limitada estiver em andamento, pois um usuário que vê o silêncio e repete sua solicitação aciona uma nova conversa e um novo conjunto de ações, complicando o custo de recurso e faturamento da tentativa original com uma duplicada.

Os padrões de otimização de recurso descritos neste documento só ajudam se um arquiteto puder ver onde um agente está realmente gastando consultas SOQL, tempo de CPU, linhas DML e tokens quando está em execução. Sem visibilidade por ação e por sessão, uma violação de limite ou regressão de latência aparece como um sintoma sem maneira de rastreá-la de volta à ação ou agente na cadeia que a causou. Esta preocupação é diferente da visibilidade do gasto que a Digital Wallet fornece sob Monitoramento de custos e governança financeira. A Digital Wallet mostra quantos créditos ou conversas um agente consumiu, enquanto a ferramenta mostra por que eles foram consumidos, no nível da consulta individual, da linha DML ou da ação que impulsionou esse consumo. A ferramenta certa depende do que a organização e o acordo de suporte de um determinado cliente realmente concedem, não de qual ferramenta é a melhor teoricamente, portanto, combine a recomendação com seu nível de licença e acesso em vez de usar como padrão a ferramenta mais eficiente disponível.

Qualquer arquiteto pode criar eventos de plataforma personalizados que são acionados no início e no fim de cada ação e chamada de subagente. Esses eventos rastreiam a execução em uma conversa usando apenas recursos de plataforma padrão, juntamente com o registro em nível de ação para um objeto personalizado que captura a contagem de consultas SOQL, o tempo de CPU, a contagem de linhas DML e o uso de heap quando cada ação é executada. Ambos os eventos são consultáveis por meio de relatórios ou SOQL e oferecem a cada organização um recurso de diagnóstico de linha de base, independentemente da licença de edição ou complemento. O Monitoramento de evento, introduzido anteriormente para rastrear o consumo da API durante pilotos, também detecta padrões de uso de recurso agregados em sessões de agente em toda a organização para clientes cuja organização inclui esse complemento, permitindo que um arquiteto identifique quais fluxos de trabalho estão se aproximando dos limites do controlador em muitas conversas, em vez de diagnosticar uma por vez. O Centro de escala oferece rastreamento profundo de transações que se aproximam dos limites do controlador, geralmente acessadas por meio de um engajamento de Suporte ou disponíveis diretamente nos níveis da conta que a concedem.

A geração de versões pelos agentes de modo independente torna possível distribuição controlada, reversão e comparação e protege o investimento em um agente de trabalho enquanto você o melhora. Promova o comportamento pela configuração sempre que possível, usando Tipos de metadados personalizados e Criador de prompts para que os administradores ajustem modelos de prompts e seleção de ação sem um ciclo de desenvolvimento. Use o recurso de teste A/B piloto para rotear um pequeno subconjunto de usuários para uma versão experimental. Compare a qualidade, a satisfação e a conclusão da tarefa antes de uma distribuição completa. Essa comparação valida melhorias com uso real e detecta regressões enquanto a exposição é limitada. Defina contratos de interface claros entre componentes, especificando entradas, saídas, erros e expectativas de desempenho para que uma implementação possa ser substituída sem modificar os agentes que dependem dela.

A economia do agente começa com o custo total de propriedade medido em relação ao valor dos negócios, mas a precificação baseada em consumo de agentes autônomos faz com que o lado do custo se comporte da maneira que o licenciamento tradicional não faz. O modelo de precificação selecionado é uma decisão arquitetônica fundamental, pois determina para o que você otimiza em todo o ciclo de vida do agente. Esta seção estabelece os modelos de precificação, o panorama completo do TCO para uma implementação do agente e a decisão de criar versus comprar para funcionalidades do agente.

A Agentforce oferece dois modelos de precificação baseados em consumo, e uma organização seleciona um dos dois para uma determinada implantação do agente. Ação de créditos flexíveis com preço por agente, que torna a eficiência da ação a alavanca para o controle de custo. A precificação por conversa cobra uma tarifa fixa por conversa, independentemente da duração ou da complexidade, o que torna a contenção da conversa a alavanca. As assinaturas por usuário fornecem o uso não medido do agente como um complemento voltado para o funcionário, em vez de um terceiro modelo de consumo, e mudam o foco da otimização de eficiência de consumo para adoção, pois o valor vem de usuários licenciados que engajam ativamente o agente, em vez de minimizar cada interação. Os dois modelos de consumo não são mistos para a mesma organização, mas um complemento Por usuário, oferecido por usuário por mês para uso não medido, pode ser colocado em camadas junto com um modelo de consumo para que os agentes voltados para o cliente sejam executados em Créditos flexíveis ou Por conversa enquanto os funcionários usam licenças não medidas.

Em Créditos flexíveis, os custos da ação são fixos por ação até um limite de token definido. Diferentemente da precificação de inferência baseada em token, o custo de crédito não varia com a duração do aviso ou a complexidade do modelo, portanto, uma resposta de uma frase e uma resposta de vários parágrafos custam o mesmo. Uma interação de várias ações consome créditos para cada ação, assim, uma interação que recupera dados, motivos e atualiza um registro consome os créditos de três ações, e a geração aumentada por recuperação adiciona mais ações por meio da pesquisa vetorial e recuperação de documentos antes do raciocínio. Entender o número médio de ações por transação comercial é, portanto, o pré-requisito para a modelagem de custo em Créditos flexíveis.

Em Precificação por conversa, uma tarifa fixa é aplicada por conversa e vários turnos em uma sessão contam como uma única conversa, portanto, o controle de custo vem da resolução de um problema em uma conversa e da definição de limites de sessão claros, em vez de cortar ações individuais. A fundamentação do Data 360 e a integração do MuleSoft consomem sua própria capacidade junto com o modelo escolhido, pois a integração de geração e pesquisa de similaridade reduz a capacidade de processamento de dados para cada consulta fundamentada e cada ação externa consome a capacidade da API nos sistemas de origem e de destino.

O custo total de propriedade (TCO) para uma implementação do agente abrange seis categorias, e a modelagem de todos os seis transforma uma estimativa de crédito em uma decisão de investimento informada. Os custos de desenvolvimento cobrem design de agente, engenharia rápida, desenvolvimento de integração e testes, e variam amplamente de um agente de uso único simples a um sistema de vários agentes com orquestração complexa. Os custos de referência dependem do modelo de precificação selecionado e exigem a modelagem de volumes de ação esperados em Créditos flexíveis, volumes de conversa em Por conversa ou contagens de usuários licenciados em Por usuário. Para agentes baseados em grandes bases de Knowledge, a infraestrutura do Data 360 que ativa a fundamentação pode competir ou exceder o custo de inferência. Os custos de infraestrutura cobrem as licenças do Data 360 e do MuleSoft, sandboxes adicionais e infraestrutura de monitoramento, e são predominantemente fixos ou funções de etapa com base em níveis de capacidade. Os custos operacionais cobrem operações de monitoramento, refinamento imediato, resposta a incidentes e suporte ao usuário, e para programas de agentes maduros, eles geralmente equivalem a uma fração significativa do custo de desenvolvimento anual, consistindo com os indicadores gerais do setor para agentes de IA, em vez de um número específico do Salesforce. Os custos de governança cobrem a revisão de segurança, supervisão humana, registro de auditoria e validação de conformidade, que aumentam com a autonomia e o risco dos agentes, e o pilar de Fairness abrange os componentes essenciais do programa. Os custos de mudança cobrem treinamento de usuários, adaptação de processos de negócios e gerenciamento de mudanças organizacionais, e são as equipes de categoria que mais frequentemente subestimam.

Crie modelos de TCO da planilha que projetem custos de 3 a 5 anos. Documente pressuposições para volumes de interação, contagens de ações e crescimento. Execute a análise de confidencialidade para identificar as pressuposições que mais afetam o total e, em seguida, concentre a validação nessas pressuposições. Modele todas as três estruturas de custo, Créditos flexíveis, Por conversa e Por usuário, com relação ao uso projetado antes de confirmar, pois a estrutura ideal depende do padrão de uso e a escolha incorreta é cara de desativar uma vez que um agente está em produção.

A decisão de criar versus comprar para agentes segue a mesma lógica de qualquer funcionalidade do Salesforce, ponderando o tempo imediato para o valor de uma solução pronta para uso com relação ao ajuste preciso de uma compilação personalizada em um horizonte de TCO de 3 a 5 anos. Os fluxos de trabalho de commodity favorecem a compra, enquanto os recursos principais que conduzem à diferenciação proprietária justificam a criação. A Agentic Enterprise oferece um espectro de opções em vez de uma opção binária. Agentes do Agentforce pré-criados, como um agente de serviço ou um representante de desenvolvimento de vendas, fornecem funcionalidades comprovadas com implantação rápida e atualizações mantidas pela plataforma. Eles consumem créditos sob o modelo de precificação selecionado. Agentes comercialmente disponíveis da comunidade de fornecedor de software independente (ISV) do Salesforce são oferecidos por meio do AgentExchange, em que você pode encontrar uma solução que já atenda a um requisito em vez de criá-la. Os agentes personalizados criados com o Agent Builder fornecem ajuste preciso e diferenciação competitiva ao custo de desenvolvimento inicial mais refinamento e manutenção imediatos contínuos. Personalizar um agente pré-criado por meio do Criador de prompts e da configuração de ação fornece um meio que custa menos do que o desenvolvimento personalizado completo, ao mesmo tempo que adapta o agente à sua organização. Além do custo, pondere requisitos de tempo para valor, capacidade de desenvolvimento interno, diferenciação estratégica e tolerância de dependência do fornecedor e registre a decisão em um Registro de decisão de arquitetura para que possa ser reavaliada conforme os requisitos mudam.

A implementação de agentes com uma compreensão clara da estrutura de custos subjacente torna a escala de capacidade autônoma sustentável em vez de esgotar um conjunto de orçamentos. A alavanca de otimização depende do modelo de precificação, pois o que você ajusta para controlar o custo difere entre pagar por ação, pagar por conversa e pagar por usuário. O princípio é constante em todos os três: ajuste o consumo com relação ao valor realmente entregue, de modo que um agente capaz não queime silenciosamente seu orçamento mais rapidamente do que retorna o resultado dos negócios.

Em Créditos flexíveis, a otimização significa minimizar as ações por resultado de negócios enquanto preserva a qualidade. Resolva solicitações simples em uma única ação, em vez de um fluxo de trabalho de várias etapas, para que responder a uma pergunta frequente ou realizar uma pesquisa de rotina não consuma os créditos de uma cadeia de três ações. Consolide operações em uma única ação quando isso fizer sentido, combinando recuperação, análise e resposta em vez de pagar por cada uma separadamente quando uma ação servir. Armazene respostas em cache para solicitações repetidas para que as perguntas frequentes sejam atendidas em cache, em vez de consumir novas ações em cada consulta idêntica, que é a maior alavanca de eficiência nesse modelo quando uma proporção significativa de consultas é repetida.

Em Precificação por conversa, a otimização significa resolver problemas em uma única conversa, em vez de entre várias. Projete limites e tempos limite de sessão para que uma conversa persista adequadamente sem encerrar prematuramente e forçar uma nova conversa faturável. Concentre a funcionalidade do agente na resolução da primeira conversa para que uma tarefa seja concluída na conversa inicial em vez de exigir acompanhamento. Acompanhe a taxa de resolução da primeira conversa como uma métrica de custo-eficiência e impeça a expansão de escopo em que um usuário abre conversas separadas para problemas relacionados que o contexto da conversa existente poderia ter tratado.

Em assinaturas por usuário, a otimização significa maximizar o valor retornado por cada usuário licenciado, pois o consumo não é medido e o custo é fixo por lugar. Concentre-se na adoção para que os usuários licenciados interajam ativamente com o agente, rastreie a utilização para identificar usuários de baixo uso para treinamento direcionado ou realocação de licença e conecte interações do agente aos resultados de negócios por população de usuários para que casos de uso de alto valor justifiquem o investimento, enquanto o uso de baixo valor sinalizar uma necessidade de otimização ou um modelo de precificação diferente. Revise os preenchimentos de usuários em um ritmo para que as licenças fiquem alinhadas ao uso real.

Independentemente do modelo de precificação, a arquitetura influencia o custo. Implemente agentes de triagem que lidam com o roteamento inicial com lógica simples e direcione os usuários a um agente especializado apenas quando a complexidade o exigir, de modo que chamadas complexas caras aconteçam apenas quando são justificadas. Volte à automação tradicional para cenários determinísticos em que a lógica baseada em regras é suficiente, permitindo que os Fluxos lidem com os caminhos determinísticos a um custo menor enquanto os agentes lidam com as situações ambíguas que realmente precisam de raciocínio. Recupere dados de fundamentação seletivamente, invocando a pesquisa vetorial e a recuperação de documentos apenas quando o raciocínio do agente o exigir, em vez de em cada interação, de modo que o consumo do Data 360 rastreie a necessidade real. Esses padrões mantêm o custo de raciocínio e consumo da arquitetura proporcional à dificuldade do trabalho.

O monitoramento de custo para agentes autônomos é mais difícil do que para cargas de trabalho tradicionais, pois os agentes não seguem um padrão de resposta à solicitação previsível. Um agente pode iterar por meio do raciocínio de várias etapas, invocar de modo adaptativo ferramentas com base em condições de tempo de execução e coordenar outros agentes, o que produz um consumo de crédito altamente variável que é difícil de prever. Sem monitoramento, um agente que realiza um trabalho iterativo profundo pode consumir um grande volume de créditos antes de qualquer pessoa intervir, e design de prompt ineficiente ou loops de raciocínio redundantes podem silenciosamente drenar orçamentos em toda uma frota de agentes. Portanto, a governança eficaz exige visibilidade em tempo real do consumo por agente e por operação, alerta automatizado e controles que impedem o custo de escape enquanto preservam a autonomia que torna os agentes úteis. A governança financeira para agentes também precisa de propriedade clara e aprovação estratificada criada para consumo variável em vez de custo de computação estático.

O Salesforce Digital Wallet é a ferramenta integrada para monitorar produtos baseados em consumo, incluindo Agentforce Flex Credits, e as organizações que usam Flex Credits devem estabelecê-lo como o principal mecanismo de monitoramento de custos em vez de criar painéis personalizados para replicar o que ele fornece. O Digital Wallet fornece dados de consumo quase em tempo real com percepções de uso em nível de ação, um detalhamento por agente mostrando quais agentes consomem mais, alertas proativos de consumo e tendências históricas para análise de padrões e previsões. Combine o monitoramento com o modelo de precificação. Em Créditos flexíveis, acompanhe o consumo por agente, população de usuários, período e tipo de ação e complemente a Digital Wallet com painéis personalizados que conectam o consumo de crédito às transações comerciais. Em Precificação por conversa, monitore volumes de conversa, duração média e taxas de conclusão. Em Assinaturas por usuário, monitore a utilização em vez de o consumo, rastreando usuários ativos e valor comercial por usuário para que o investimento em licença seja mostrado para entregar valor proporcional.

A atribuição de custo por interação conecta o consumo a transações comerciais e revela o custo por caso resolvido, por lead qualificado ou por pedido processado, o que habilita o cálculo do retorno sobre o investimento e a comparação entre casos de uso. O alerta de orçamento aciona a notificação à medida que o consumo se aproxima dos limites definidos, em limites como 70% e 85% do orçamento, de modo que a otimização ocorre antes de um limite ser alcançado. Configure alertas por agente e por caso de uso, em vez de apenas para toda a organização, para localizar um problema em sua origem. A detecção de anomalia detecta o pico de consumo repentino que sinaliza um padrão de uso inesperado ou um loop de raciocínio que precisa de investigação. Compartilhe painéis de custo com partes interessadas de negócios e equipes técnicas para que a transparência promova o uso sensível ao custo pelos agentes.

Aplique a governança financeira antes de confirmar o gasto em uma arquitetura de agente. Exija um caso de negócio para um investimento de agente que cubra o TCO projetado em 3 a 5 anos no modelo de precificação selecionado, os resultados de negócios esperados com um método de medida, uma comparação com alternativas, incluindo processos manuais e automação tradicional, e uma avaliação de risco que abranja qualidade, segurança e risco operacional. Defina limites de aprovação que separam os investimentos que um departamento pode autorizar dos que exigem aprovação executiva para que um agente de alto investimento ou alto risco receba uma análise proporcional. Mandate implantações piloto que validam pressuposições antes da produção completa, pois um piloto revela o consumo real, a qualidade e a adoção que informam tanto a decisão de investimento de produção quanto a seleção do modelo de precificação.

Gerencie a propriedade do agente como um portfólio, em vez de agente por agente, pois uma exibição de portfólio revela oportunidades de otimização que uma revisão de agente único perde. Revise todos os agentes juntos, comparando custo, uso, valor de negócios e alinhamento estratégico, e defina critérios para descontinuar agentes com baixa adoção, baixo ROI, funcionalidade substituída ou custo excessivo para que agentes de baixo valor não acumulem e consomem orçamento indefinidamente. Realocar o investimento de agentes de baixo desempenho para oportunidades de alto valor como uma prática contínua que realinha o gasto com prioridades em evolução, em vez de uma limpeza única.

A alocação de custo cria a responsabilidade pelo consumo do agente e as organizações o implementam por meio dos mesmos dois modelos que se aplicam ao restante da plataforma. O Showback relata os custos dos agentes por unidade de negócios sem uma cobrança interna, o que cria uma consciência de custo e informa a discussão de otimização sem a contenção de faturamento interno. O Chargeback aloca os custos reais do agente às unidades de negócios consumidoras, o que impulsiona um comportamento de otimização mais forte porque o custo afeta diretamente um orçamento do departamento, mas exige um método de alocação preciso para evitar disputas. Uma abordagem híbrida aplica o chargeback a agentes de produção de alto volume enquanto usa o showback para agentes experimentais ou de baixo volume, que balanceia a responsabilidade por investimento importante com a flexibilidade para inovação.

As arquiteturas de agente apresentam suas próprias considerações de sustentabilidade, pois a inferência de modelo em grande idioma é computacionalmente intensiva e alguns agentes são executados continuamente em vez de apenas em transações acionadas por usuário separadas. Agentes proativos, de saída e agendados operam sem um usuário no loop, agentes conversacionais acumulam o consumo em muitos turnos, e pesquisa vetorial, preparação de contexto e execução de ação aumentam a carga da infraestrutura. O design de agente sustentável minimiza o desperdício computacional enquanto mantém a experiência responsiva. Como no pilar Recurso e Otimização de custo, o relacionamento entre uma solução e as emissões do data center é indireto. A eficiência de um único locatário não reduz diretamente as emissões. No entanto, ganhos de eficiência em todos os locatários ajudam o Salesforce a executar sua infraestrutura com maior utilização e adiar a expansão de capacidade. e as práticas de sustentabilidade fundamentais do pilar Recurso e Otimização de custo se aplicam a agentes, e as estratégias de eficiência que seguem, ambos abordam o que é específico para sistemas de conversa baseados em modelo de grande idioma. Cada um também reduz o custo, o que é por isso que a sustentabilidade e o valor por custo são a mesma disciplina medida em relação a diferentes resultados.

A inferência é o componente com mais uso de recursos de uma arquitetura agente, portanto, a eficiência se paga com a duração do aviso, o uso do contexto e o armazenamento em cache. Otimize avisos para transmitir a intenção em menos tokens removendo instruções verbosas e exemplos redundantes, pois um aviso menor reduz o pré-preenchimento do cálculo proporcionalmente, embora não altere o cálculo da geração da resposta. Gerencie a janela de contexto resumindo o histórico da conversa após os primeiros vários turnos e retornando apenas campos essenciais de cada ação para que o orçamento do token carregado em cada inferência permaneça limitado em vez de crescer com a conversa.

Pesquisa de vetores e consultas de perfil unificado consomem recursos computacionais, assim, a mesma disciplina de limite de resultado e filtragem que controla o custo de fundamentação também reduz a carga da infraestrutura de fundamentação. Defina limites de top-k para retornar apenas os resultados que o agente usa, pois recuperar 50 quando 5 informa a resposta carrega 45 resultados não utilizados que consomem orçamento de token de fundamentação sem nenhum benefício e use filtros de metadados para limitar a pesquisa antes da classificação de similaridade. Consulte perfis unificados para montar o contexto completo em uma operação, em vez de emitir consultas separadas em vários objetos para cada turno, e armazene perfis em cache para agentes com alta afinidade de usuário, como um agente de vendas trabalhando em um conjunto fixo de contas, para que a montagem de contexto repetida não repita a consulta.

As ações do agente consomem consultas SOQL, operações DML e tempo de CPU, assim, a disciplina de massificação, armazenamento em cache e assíncrona do pilar Otimização de recurso e custo se aplica diretamente às ações do agente. Projete ações para aceitar coleções de modo que a atualização de muitos registros seja uma operação em vez de muitas, use consultas de relacionamento para recuperar dados pai e filho em uma única instrução, armazenar em cache os dados de referência no Cache da plataforma e colocar DML em lote em uma coleção em vez de por registro. Mova operações que excedem limites síncronos para o Apex enfileirável ou em lote, processe trabalhos não urgentes, como pontuação em massa ou aprimoramento histórico, de forma assíncrona e agende trabalhos em lote acionados pelo agente para janelas fora de pico quando possível para que a carga se espalhe ao longo do tempo, em vez de se concentrar durante o horário comercial. Monitore a execução assíncrona para que uma pendência de fila sinalize uma necessidade de planejamento de capacidade antes de se tornar uma falha.

Os padrões de consumo do agente evoluem conforme o uso aumenta, assim, a sustentabilidade exige monitoramento contínuo, em vez de uma passagem única. Acompanhe os tokens médios por inferência por meio da telemetria de uso disponível para que um tamanho de prompt crescente detecte uma oportunidade de otimização, monitore a distribuição de comprimento da conversa para que conversas não vinculadas revelem um problema de limite de tarefa e analise a frequência de execução de ação no Monitoramento de evento para que uma ação de alta frequência se torne uma prioridade de otimização. Revise os padrões de consulta do Data 360 para encontrar consultas comuns que valem o armazenamento em cache ou pré-computamento, rastreie a taxa de interação de cache semântico para que uma taxa baixa acione o ajuste do limite e meça percentis de latência para que a latência da cauda exponha qualquer gargalos. Revise o uso do agente regularmente quanto ao desvio de escopo. Por exemplo, investigue um agente cuja duração média da conversa cresce de um punhado de turnos para muitos ao longo de vários meses. Refine os limites do agente para que o consumo volte ao plano. Algumas dessas superfícies de monitoramento expõem o uso em painéis agregados, em vez de como um registro por inferência distinto, portanto, confirme a telemetria exata disponível para sua configuração ao projetar o monitoramento.

A otimização de recurso determina se as arquiteturas do agente são dimensionadas à medida que as populações crescem e os casos de uso se expandem, e a otimização de custo determina se essa escala retorna valor de negócio proporcional. Estas duas decisões formam um único mandato:

• Eficiência arquitetônica: projete ações com massificação, oriente SOQL entre cadeias de ação, mova processamento pesado para assíncrono, otimize o consumo de API por meio de padrões compostos e conduzidos por evento, gerencie janelas de contexto por meio de priorização e resumo e crie arquiteturas composíveis a partir de componentes reutilizáveis.
• Diretriz financeira: selecione o modelo de precificação deliberadamente, crie um modelo para concluir o TCO antes de confirmar, monitorar o consumo em relação aos resultados dos negócios e controlar o investimento por meio de aprovação em níveis e revisão de portfólio.

As organizações que dominam esses padrões proporcionam experiências responsivas aos agentes dentro das restrições da plataforma enquanto mantêm o gasto alinhado ao valor retornado pelos agentes.

A orientação básica de recurso e otimização de custo para todas as soluções do Salesforce, incluindo otimização de desempenho, limites do regulador, análise de TCO, disciplina de licenciamento e governança de custo, estão no pilar de Otimização de recurso e custo. Os componentes de governança do agente, supervisão humana e programa de segurança se conectam aos pilares Trust e Fairness. A orientação detalhada de implementação do agente neste documento, abrangendo eficiência de recursos, economia, otimização de ação, governança e sustentabilidade, são coletadas na biblioteca de padrões de agente.

Compartilhe seu feedback sobre o Framework bem-construído.