Optimización de recursos y costos para Agentic Enterprise

Los agentes autónomos consumen recursos de Salesforce de forma diferente a la automatización determinista. Las cargas de trabajo de los agentes son impredecibles y continuas, en vez de fijas y vinculadas a transacciones. La tesis de valor por costo del pilar Optimización de recursos y costos lleva directamente a Agentic Enterprise. Eficiencia de recursos significa utilizar la capacidad que ya paga, y optimización de costos significa dirigir el gasto deliberadamente hacia las funciones autónomas que obtienen un retorno. Los agentes cambian la forma de ambos. El diseño eficiente de los agentes mantiene el consumo bajo control, y la selección del modelo de precios, el modelado del costo total de propiedad (TCO) y la gobernanza financiera mantienen el gasto alineado con el valor. Este documento trata la eficiencia de recursos y la optimización de costos como una decisión, ya que para los agentes son dos vistas del mismo objetivo.

Los agentes cambian la previsibilidad del consumo. Un proceso Apex tradicional funciona en un conjunto de registros conocido con un costo de recurso conocido. Un agente opera conversacionalmente, y una sola plática puede ejecutar docenas de acciones como el agente razona a través de una tarea. Cada acción consume límites reguladores dentro de su propia transacción en vez de acumularlos en la plática. La preparación de contexto para un turno puede consultar 200 registros o 20.000, dependiendo de lo que solicite el usuario. El consumo de API se acelera porque los agentes pueden actuar de forma autónoma y los agentes proactivos, salientes y programados actúan de forma continua en vez de solo durante una transacción de usuario. Esta imprevisibilidad es la razón por la que la gestión de recursos de agentes debe ser defensiva por diseño en vez de ajustada después de que se produzca un pico de consumo.

El lado del costo cambia igual. Los agentes autónomos presentan precios basados en el consumo que se comportan de forma diferente a las licencias por asiento tradicionales. Agentforce ofrece dos modelos de precios basados en consumo, Flex Credits y Per-Conversation. Cada implementación de agente selecciona uno de estos modelos. Una organización utiliza un modelo de consumo a la vez. , pero un complemento Por usuario, ofrecido por usuario al mes para uso sin medición, puede aplicar capas junto con un modelo de consumo de modo que los agentes de cara al cliente se ejecuten en Flex Credits o Per-Conversation mientras los empleados utilizan licencias sin medición. Data 360 potencia la fundamentación de agentes a través de la búsqueda y recuperación de vectores, y consume capacidad de procesamiento de datos, mientras que MuleSoft activa integraciones de agentes que consumen capacidad de API. Estos costos variables se amplían con el uso de agentes, lo que crea un patrón de inversión que necesita una gobernanza financiera creada para la variabilidad en vez de para una suscripción anual fija.

Las soluciones diseñadas para valor de negocio con costo optimizado en Agentic Enterprise mantienen el consumo de agentes eficiente a través de acciones que procesan registros en plazos de contexto disciplinados masivos y almacenamiento en caché. También dirigen deliberadamente el gasto a través del modelo de precios correcto, completan el modelado de TCO y el monitoreo de costos continuo con resultados de negocio. Sin esa alineación, las implementaciones de agentes acumulan costos sin demostrar un valor proporcional, y un agente que razona en un bucle sin límites puede quemar créditos más rápido de lo que la supervisión humana puede intervenir. El mismo trabajo de eficiencia que mantiene un agente dentro de sus límites reguladores lo mantiene dentro de su presupuesto de crédito, que es la tesis de pilar expresada en términos de agente.

Este documento trata lo que cambia cuando los agentes están en la imagen. Para los patrones de optimización de recursos y costos fundacionales que se aplican a cada solución de Salesforce, incluyendo optimización de desempeño, límites reguladores, análisis de TCO y disciplina de licencias, consulte el pilar Optimización de recursos y costos. La gobernanza de los agentes y la supervisión humana están conectadas con los pilares Confianza y Justicia, que abarcan los componentes del programa que mantienen el comportamiento autónomo seguro y responsable.

El consumo de recursos de agentes sigue la misma mecánica de plataforma que Flow o Apex, pero su invocación impredecible dirigida por pláticas hace que el consumo sea más difícil de pronosticar y, por lo tanto, requiere patrones defensivos. Sus responsabilidades de optimización abarcan presupuestos con límite regulador entre cadenas de acción, consumo de API, latencia de respuesta, eficiencia de fundamentación de Data 360, gestión de plazos de contexto y el diseño componible que permite a los agentes ampliar sin duplicaciones. Cada responsabilidad es una decisión de valor por costo antes de ser técnica, porque los agentes repiten ineficiencias en cada plática.

Los agentes invocan acciones que desencadenan Apex, Flujos e integraciones. Una sola plática puede ejecutar docenas de acciones según el motivo del agente a través de una tarea compleja. La disciplina fundamental es la misma que para cualquier solución de Salesforce, pero el patrón de invocación impredecible aumenta las apuestas. Diseñe acciones para aceptar recopilaciones de modo que un agente que actualiza 50 casos invoque una acción en vez de 50 llamadas separadas. Una sola acción que opera en un conjunto de registros consume muchas menos consultas de Lenguaje de consulta de objetos de Salesforce (SOQL) y operaciones de Lenguaje de manipulación de datos (DML) para el mismo trabajo. Gestione el presupuesto SOQL entre cadenas de acción deliberadamente, ya que un flujo de trabajo que invoca de 10 a 15 acciones puede acercarse o superar el límite síncrono de 100 consultas cuando cada acción ejecuta varias consultas propias. Utilice consultas de relaciones para recuperar datos principales y secundarios en una sola declaración, y haga referencia a datos en caché en Caché de plataforma entre acciones en la misma plática. Estas dos prácticas mantienen una cadena de múltiples acciones dentro de su presupuesto.

Mueva operaciones de agentes que superan los límites síncronos a Apex colocable en cola o por lotes, donde el contexto asíncrono duplica aproximadamente el margen de maniobra de SOQL y CPU disponible para el trabajo. Las grandes operaciones analíticas, como puntuar 1.000 prospectos o analizar opiniones entre casos históricos, pertenecen al procesamiento asíncrono en vez de bloquear una plática. La inferencia de modelo de lenguaje grande en sí se produce fuera de Salesforce y consume Flex Credits en vez de tiempo de CPU Apex, de modo que el presupuesto de CPU que perfila se consume por la lógica de acción, las transformaciones de datos y las integraciones que desencadena el agente. Los escenarios de sesgo de datos donde los registros principales están asociados con miles de registros secundarios merecen una atención defensiva particular con los agentes. Esta vulnerabilidad surge porque un agente puede solicitar “todo el historial” para una cuenta con decenas de miles de registros relacionados de una forma que una consulta determinista nunca haría. Diseñe acciones con límites de registros secundarios y paginación, y aplique muestreo cuando los volúmenes superen el umbral de sesgo de datos. Estos límites evitan que una solicitud impredecible se convierta en una consulta sin límites. Rastreo de sesiones Agentforce identifica qué acciones consumen consultas excesivas a nivel de sesión, y Scale Center monitorea el desempeño general de las transacciones Apex y el estado de la organización.

Las arquitecturas de agentes consumen las API con mayor rapidez que los flujos de trabajo dirigidos por usuarios, ya que los agentes funcionan de forma autónoma y, para agentes proactivos o programados, de forma continua. El modo en que aparece un agente determina cómo reduce la capacidad de API. Los agentes invocados a través de la API de REST consumen una llamada por turno de plática. Los agentes integrados en páginas Lightning a través de componentes estándar no consumen una llamada de API por interacción, aunque su costo aún se mide en los créditos o pláticas del modelo de precios elegido. Los componentes web Lightning personalizados que realizan llamadas de REST directas consumen capacidad de API. Los componentes creados en adaptadores de red Lightning Data Service no, porque Lightning Data Service sirve desde una caché del lado del cliente compartida en vez de emitir una llamada de API. Monitoree el consumo en Monitoreo de eventos durante un piloto de modo que comprenda el uso real antes de una implementación completa.

Los patrones dirigidos por eventos son la palanca más grande en el consumo de API de agente derrochador. La publicación de un evento de plataforma cuando una condición requiere la intervención de un agente evita los sondeos programados que consumen llamadas de API independientemente de que haya o no trabajo por hacer, y un agente que se suscribe a eventos de Captura de datos cambiantes mantiene el contexto actual sin las llamadas de sondeo diarias que un orquestador externo realizaría de otro modo. La lógica de valor por costo es directa: Un sondeo que no encuentra trabajo es capacidad gastada para nada, y un evento que se desencadena solo en un cambio real es capacidad gastada solo en trabajo real. La generación aumentada de recuperación agrega su propio consumo, porque cada búsqueda vectorial en Data 360 consume computación, de modo que establezca límites de recuperación para devolver solo los resultados que el agente utiliza actualmente.

La latencia para un turno de agente es la suma del tiempo de inferencia LLM, el tiempo de ejecución de acciones, el tiempo de consulta de Data 360 y el tiempo de integración cuando esos pasos se ejecutan en secuencia. Cuando no lo hacen, es la bifurcación paralela más larga más cualquier paso secuencial. La latencia es un problema de costo así como un problema de experiencia, porque una acción lenta mantiene los recursos abiertos durante más tiempo y un usuario frustrado inicia más pláticas de las que lo haría uno resuelto. Las solicitudes más cortas generan respuestas más rápidas, de modo que elimine instrucciones verbosas, ejemplos redundantes y contexto innecesario. El contexto selectivo mejora la latencia y la calidad de las respuestas, donde un volcado de contexto exhaustivo solo agrega ruido. Mantenga las acciones rápidas a través de SOQL selectivo en campos indexados, masificación y datos de referencia en caché, porque una acción de 3 segundos se convierte en un cuello de botella independientemente de la rapidez de la inferencia. Valide consultas de acción con la herramienta Plan de consulta para identificar exploraciones de tablas completas que aumentan la latencia de acción.

La orquestación de Agent Builder puede ejecutar acciones en paralelo cuando no existen dependencias entre ellas, por ejemplo, la recuperación de detalles de cuenta y oportunidades relacionadas al mismo tiempo tarda tanto como la más lenta de las dos en vez de la suma de ambas. Para llamadas que se despliegan en múltiples sistemas descendentes, empareje Agentforce con una plataforma de integración como MuleSoft; el agente invoca una sola acción, MuleSoft recibe la solicitud y emite llamadas paralelas a sistemas backend, luego devuelve una respuesta agregada. Caché de plataforma elimina la latencia de inferencia y consulta para solicitudes repetidas, y el procesamiento de trabajo no urgente de forma asíncrona, como un análisis de documentos largo, permite al agente reconocer la solicitud inmediatamente y devolver el resultado cuando está lista en vez de mantener la plática abierta.

Data 360 proporciona la búsqueda vectorial que fundamenta respuestas de agentes en datos actuales en vez de en los datos de entrenamiento del modelo únicamente, y su eficiencia rige tanto la calidad de fundamentación como el cálculo que consume para alcanzarla. Troceado, selección de incrustación, filtrado de metadatos y límites de resultados son las decisiones más valiosas. Knowledge fragmentado en segmentos con sentido semántico, porque los fragmentos demasiado pequeños fuerzan muchas recuperaciones para una pregunta mientras que los fragmentos demasiado grandes diluyen la relevancia con contexto irrelevante e inflan el presupuesto de token llevado a inferencia. Seleccione un modelo de integración que coincida con el modo en que sus agentes consultan actualmente, ya que la similitud pregunta-respuesta se comporta de forma diferente a la clasificación de documentos, y valide la opción frente a consultas representativas. Combine la similitud semántica con filtros de metadatos de modo que las restricciones de negocio se mantengan independientemente de la similitud, como excluir productos descontinuados de una recomendación sin importar cuán cerca esté la coincidencia. Establezca límites máximos para devolver solo los resultados que utiliza el agente. Por ejemplo, si 5 resultados informan a una respuesta, la recuperación de 50 agrega 45 resultados no utilizados a la carga de trabajo de base y el presupuesto de token.

Los perfiles unificados son eficientes en recursos porque un agente que consulta un perfil unificado de Data 360 recupera el contexto completo del cliente en una sola operación en vez de orquestar consultas separadas en Cuenta, Contacto, Oportunidad, Caso y Campaña para cada turno. Configure instancias de Data 360 en las regiones que los requisitos normativos demandan de modo que los agentes que procesan datos para una jurisdicción concreta consulten la instancia que mantiene datos personales dentro de ella.

Las ventanas de contexto de modelo de idioma grande albergan un número finito de tokens, y la gestión de ese presupuesto mantiene una larga plática coherente sin agotar la capacidad o inflar el costo de cada llamada de inferencia. Priorice deliberadamente en vez de truncar arbitrariamente: historial de pláticas recientes tiene la prioridad más alta, los datos de negocio críticos como el estado y los permisos de registros actuales se encuentran en segundo lugar y el historial anterior solo se incluye cuando el espacio lo permite. Tras los primeros turnos, resuma la plática anterior en una descripción general concisa que conserva hechos críticos sin llevar un historial literal completo. Este resumen mantiene la continuidad sin aumentar el presupuesto de tokens. Almacene contexto ampliado en Data 360 u objetos personalizados como memoria externa consultada on demand en vez de reproducir el historial completo en cada llamada, y devuelva solo los campos esenciales de cada acción, porque una respuesta que lleva los 50 campos de un registro cuando la tarea necesita 8 gasta presupuesto de contexto mejor asignado a plática o fundamentación.

La creación de agentes desde componentes reutilizables reduce los costos de desarrollo y mantenimiento. Una función creada una vez y reutilizada es mucho más barata a lo largo de su vida útil que la misma función reimplementada y mantenida por separado para cada agente. Las bibliotecas de acciones centralizadas que cubren operaciones de registro, aprobaciones, notificaciones y validación permiten a los equipos de plataforma mantener un comportamiento, una seguridad y un desempeño coherentes entre cada agente consumidor, y permiten que un nuevo agente se reúna desde elementos constructivos probados en días en vez de crearse desde acciones personalizadas durante semanas. Los agentes especializados centrados con límites de dominio claros mantienen un contexto más estrecho y un comportamiento más claro que un único agente universal que intenta cada escenario, y la orquestación de Agent Builder coordina especialistas cuando una tarea cruza dominios. Las plantillas de solicitudes validadas en Generador de solicitudes capturan patrones probados para fundamentación, razonamiento y formato de respuesta de modo que la calidad se mantiene coherente a medida que se acelera el desarrollo, y una base de Knowledge compartida en Data 360 fundamenta muchos agentes desde un origen, de modo que una actualización llega a cada consumidor a la vez en vez de requerir un cambio en cada agente.

Los equipos de compañía componen cada vez más múltiples agentes juntos en vez de crear agentes monolíticos individuales, con un agente orquestador descomponiendo una solicitud y delegando en subagentes especializados, o agentes especializados trasladándose entre sí a medida que una plática se mueve entre dominios. Esta composición plantea preguntas de recursos y costos más allá de lo que enfrenta un único agente, porque los gastos generales de orquestación, Trust entre agentes y traspaso de estado se componen en una cadena en vez de permanecer contenidos en una acción. Mantenga las solicitudes de orquestación restringidas, limitadas a clasificar la intención y el enrutamiento, en vez de solicitar al orquestador que también razone sobre la tarea subyacente, ya que ese razonamiento pertenece al subagente con el contexto relevante, y limite la profundidad de la cadena a menos que un caso de uso requiera claramente un anidado más profundo que de orquestador a subagente. Trate cada respuesta de subagente como una entrada no fiable, como lo haría con una respuesta de API externa. Valide su forma prevista y el cumplimiento de las reglas de negocio antes de actuar sobre ella. Aplique la seguridad a nivel de campo y la colaboración de forma independiente para cada acción de agente.

Pase solo el estado que necesita el agente receptor, utilizando una carga de transferencia estructurada de Id. de registro, resumen de tareas y campos relevantes en vez de reenviar el historial de pláticas sin procesar, de modo que el presupuesto de tokens en toda la cadena permanezca controlado y persista el estado de sesión entre agentes en Data 360 o un objeto personalizado cuando una transferencia debe sobrevivir en transacciones separadas. Los límites reguladores se aplican por agente, no una vez por plática, de modo que cada agente de una cadena traza su propio presupuesto de SOQL, DML y CPU. Una cadena de un orquestador y tres subagentes consume cada uno de esos límites cuatro veces más, y las cadenas más profundas multiplican aún más el consumo. La misma multiplicación dirige el costo, lo que hace que la profundidad de cadena sin límites sea un riesgo de costo superior al límite regulador.

Defina lo que hace el orquestador cuando un subagente falla, agota el tiempo de espera o devuelve un resultado de baja confianza, ya sea un reintento limitado, una respuesta de reserva o una distribución a un humano, de modo que un tiempo de espera de subagente único no se convierta en fallo de toda la cadena. Correlacione una solicitud entre cada agente que toca con un Id. de rastreo compartido propagado a través de la carga de transferencia, ya que diagnosticar qué agente en una cadena causó un pico de latencia o un pico de costo requiere registros de correlación manual entre sesiones de agentes separadas.

Las acciones fallidas y las llamadas fallidas de agentes secundarios no solo afectan a la fiabilidad, ya que cada reintento puede volver a ejecutar el trabajo de SOQL, DML y CPU ya empleado en el intento fallido, y en una cadena de múltiples agentes este costo se compone del número de agentes descendentes fallidos. Bajo precios basados en consumo, los mismos compuestos de fallo gastan así como calculan: una acción reintentada reanuda créditos bajo Flex Credits. Diseñe lógica de reintento para tener en cuenta la fiabilidad y el costo. Distinga los fallos transitorios, como el tiempo de espera de una llamada o la contención de bloqueo, de los fallos lógicos, como un error de validación o una entrada incorrecta, antes de decidir cómo responder, ya que un fallo transitorio puede valer un reintento limitado mientras que un fallo lógico falla de forma idéntica en la repetición y solo quema presupuesto para un fallo de repetición garantizado que debe distribuirse inmediatamente en su lugar.

Límite máximo de intentos de reintento por acción, en dos o tres intentos, y aplique un retroceso exponencial entre ellos en vez de una reinvocación inmediata, porque un reintento sin límites o en bucle cerrado en una acción intensa de SOQL o DML puede agotar los límites síncronos en una sola transacción o quemar hasta el presupuesto de cadena acumulativo y el gasto de crédito acumulativo en una plática de múltiples agentes. Diseñe acciones de modo que una llamada reintentada produzca el mismo estado final que una llamada realizada con éxito única, utilizando una clave de idempotencia como un Id. de solicitud o un Id. externo con lógica de alteración en vez de inserción, de modo que un reintento actualice el mismo registro en vez de crear un duplicado; una acción que carece de idempotencia fuerza un reintento a duplicar el consumo de recursos a través de registros descendentes duplicados o duplicar las acciones facturadas o pláticas para el trabajo que ya se produjeron una vez.

Realice un seguimiento del estado de finalización por agente en una cadena, ya que la acción de un agente puede confirmar DML correctamente antes de que falle un agente descendente, y un controlador de fallos que sabe lo que ya se realizó correctamente puede compensar o reanudar desde el punto de fallo en vez de reiniciar y volver a facturar toda la cadena. Aflore el estado de reintento o en curso al usuario final mientras un reintento limitado está en vuelo, porque un usuario que ve silencio y repite su solicitud desencadena una plática completamente nueva y un nuevo conjunto de acciones, lo que agrava el costo de facturación y el recurso del intento original con uno duplicado.

Los patrones de optimización de recursos descritos en este documento solo ayudan si un arquitecto puede ver dónde está gastando un agente consultas SOQL, tiempo de CPU, filas DML y tokens cuando se está ejecutando en producción. Sin visibilidad por acción y por sesión, una brecha de límite o una regresión de latencia aparece como un síntoma sin forma de rastrearlo hasta la acción o el agente en la cadena que lo causó. Esta preocupación es distinta de la visibilidad del gasto que proporciona Digital Wallet bajo Monitoreo de costos y Gobernanza financiera. Digital Wallet muestra cuántos créditos o pláticas consumió un agente, mientras que las herramientas muestran por qué se consumieron, en el nivel de la consulta individual, la fila DML o la acción que impulsó ese consumo. La herramienta correcta depende de lo que la organización y el acuerdo de asistencia de un cliente concreto otorgan actualmente, no de qué herramienta es teóricamente la mejor, de modo que haga coincidir la recomendación con su licencia y nivel de acceso en vez de tomar como valor predeterminado la herramienta más capaz disponible.

Cualquier arquitecto puede crear Eventos de plataforma personalizados que se desencadenan al inicio y al final de cada acción e invocación de subagente. Estos eventos rastrean la ejecución en una plática utilizando solo funciones de plataforma estándar, emparejadas con el registro a nivel de acción en un objeto personalizado capturando el conteo de consultas SOQL, el tiempo de CPU, el conteo de filas DML y el uso de pilas cuando se ejecuta cada acción. Ambos eventos son consultables a través de reportes o SOQL y proporcionan a cada organización una capacidad de diagnóstico de línea base independientemente de la edición o las licencias complementarias. Monitoreo de eventos, presentado anteriormente para realizar un seguimiento del consumo de API durante los pilotos, también aflora patrones de uso de recursos agregados entre sesiones de agentes de toda la organización para clientes cuya organización incluye ese complemento, permitiendo a un arquitecto identificar qué flujos de trabajo tienden a límites reguladores entre muchas pláticas en vez de diagnosticar uno por uno. Scale Center ofrece un rastreo profundo de transacciones que se acercan a los límites reguladores, a las que se accede habitualmente a través de una implicación de asistencia o disponibles directamente en niveles de cuenta que la otorgan.

Los agentes de versionado de forma independiente hacen posible la implementación, la reversión y la comparación controladas, y protege la inversión en un agente de trabajo mientras la mejora. Dirija el comportamiento por la configuración siempre que sea posible, utilizando Tipos de metadatos personalizados y Generador de solicitudes para que los administradores ajusten las plantillas de solicitudes y la selección de acciones sin un ciclo de desarrollo. Utilice la función piloto de pruebas A/B para enrutar un pequeño subconjunto de usuarios a una versión experimental. Compare la calidad, la satisfacción y la realización de tareas antes de una implementación completa. Esta comparación valida mejoras con el uso real y detecta regresiones mientras la exposición está limitada. Defina contratos de interfaz claros entre componentes, especificando entradas, salidas, errores y expectativas de desempeño, de modo que se pueda sustituir una implementación sin modificar los agentes que dependen de ella.

La economía de los agentes comienza con el costo total de propiedad medido con respecto al valor de negocio, pero los precios basados en el consumo de los agentes autónomos hacen que el lado del costo se comporte de la misma manera que las licencias tradicionales. El modelo de precios que seleccione es una decisión arquitectónica fundamental, porque determina para qué optimizar en todo el ciclo de vida de los agentes. Esta sección establece los modelos de precios, la imagen completa del TCO para una implementación de agente y la decisión de creación frente a compra para funciones de agente.

Agentforce ofrece dos modelos de precios basados en el consumo, y una organización selecciona uno de los dos para una implementación de agente concreta. Flexible Créditos precio por acción de agente, lo que hace que la eficiencia de la acción sea la palanca para el control de costos. Los precios por plática cobran una tarifa plana por plática independientemente de la longitud o la complejidad, lo que hace que la contención de pláticas sea la palanca. Las suscripciones por usuario proporcionan un uso de agente no medido como un complemento de cara al empleado en vez de un tercer modelo de consumo, y cambian el enfoque de optimización de eficiencia de consumo a adopción, porque el valor proviene de usuarios con licencia implicando activamente al agente en vez de minimizar cada interacción. Los dos modelos de consumo no están mezclados para la misma organización, pero un complemento Por usuario, ofrecido por usuario al mes para uso sin medición, puede aplicar capas junto con un modelo de consumo de modo que los agentes de cara al cliente se ejecuten en Flex Credits o Per-Conversation mientras los empleados utilizan licencias sin medición.

Bajo Flex Credits, los costos de acción se fijan por acción hasta un tope de token definido. A diferencia de los precios de inferencia basados en tokens, el costo del crédito no varía con la longitud de la solicitud o la complejidad del modelo, de modo que una respuesta de una frase y una respuesta de múltiples párrafos cuestan lo mismo. Una interacción de múltiples acciones consume créditos para cada acción, de modo que una interacción que recupera datos, motivos y actualiza un registro consume los créditos de tres acciones, y la generación aumentada de recuperación agrega más acciones a través de la búsqueda vectorial y la recuperación de documentos antes del razonamiento. Por lo tanto, comprender el número medio de acciones por transacción de negocio es el requisito previo para el modelado de costos bajo Flex Credits.

Bajo Precio por plática, se aplica una tarifa plana por plática, y múltiples turnos en una sesión cuentan como una sola plática, de modo que el control de costos proviene de la resolución de un problema en una plática y la definición de límites de sesión claros en vez de recortar acciones individuales. La fundamentación de Data 360 y la integración de MuleSoft consumen su propia capacidad junto con el modelo elegido, ya que la generación de incrustaciones y la búsqueda de similitudes reducen la capacidad de procesamiento de datos para cada consulta fundamentada y cada acción externa consume capacidad de API en los sistemas de origen y de destino.

El costo total de propiedad (TCO) para una implementación de agente abarca seis categorías, y el modelado de las seis convierte una estimación de crédito en una decisión de inversión fundamentada. Los costos de desarrollo cubren el diseño de agentes, la ingeniería de solicitudes, el desarrollo de la integración y las pruebas, y varían ampliamente desde un simple agente de un solo propósito a un sistema de múltiples agentes con orquestación compleja. Los costos de conferencia dependen del modelo de precios seleccionado y requieren modelar volúmenes de acción previstos bajo Flex Credits, volúmenes de plática bajo Por plática o conteos de usuarios con licencia bajo Por usuario. Para agentes basados en grandes bases Knowledge, la infraestructura de Data 360 que impulsa la fundamentación puede rivalizar o superar el costo de inferencia. Los costos de infraestructura cubren las licencias de Data 360 y MuleSoft, los entornos sandbox adicionales y la infraestructura de monitoreo, y son predominantemente fijos o de función escalonada basándose en niveles de capacidad. Los costos operativos cubren operaciones de monitoreo, refinamiento de solicitudes, respuesta ante incidentes y asistencia al usuario, y para programas de agentes maduros equivalen comúnmente a una fracción significativa del costo de desarrollo anualmente, coherente con los indicadores generales de la industria para agentes de IA en vez de una cifra específica de Salesforce. Los costos gubernamentales cubren la revisión de seguridad, la supervisión humana, el registro de auditoría y la validación de cumplimiento que crecen con la autonomía y el riesgo de los agentes, y el pilar Equidad cubre los componentes esenciales del programa. Los costos de cambio cubren la capacitación de usuarios, la adaptación de procesos de negocio y la gestión de cambios organizativos, y son las categorías que los equipos subestiman con mayor frecuencia.

Cree modelos de TCO de hojas de cálculo que proyecten costos de 3 a 5 años. Documente supuestos para volúmenes de interacciones, conteos de acciones y crecimiento. Ejecute análisis de confidencialidad para identificar los supuestos que más afectan al total, luego centre la validación en esos supuestos. Modele las tres estructuras de costos, Flex Credits, Per-Conversation y Per-User, con respecto al uso proyectado antes de confirmar, porque la estructura óptima depende del patrón de uso y la opción incorrecta es costosa de deshacer una vez que un agente está en producción.

La decisión de creación frente a compra para agentes sigue la misma lógica que para cualquier función de Salesforce, sopesando el tiempo de puesta en valor inmediato de una solución preparada con el ajuste preciso de una construcción personalizada en un horizonte de TCO de 3 a 5 años. Los flujos de trabajo de materias primas favorecen la compra mientras que las funciones principales que dirigen la diferenciación patentada justifican la creación. Agentic Enterprise ofrece un espectro de opciones en vez de una opción binaria. Los agentes Agentforce preintegrados, como un Agente de servicio o un Representante de desarrollo de ventas, proporcionan funciones probadas con una implementación rápida y actualizaciones mantenidas por plataforma. Consumen créditos bajo el modelo de precios seleccionado. Los agentes disponibles comercialmente de la comunidad de proveedores de software independientes de Salesforce (ISV) se ofrecen a través de AgentExchange, donde puede encontrar una solución que ya cumple un requisito en vez de crearla. Los agentes personalizados creados con Agent Builder proporcionan un ajuste preciso y una diferenciación competitiva a costa de un desarrollo anticipado además de un refinamiento y mantenimiento rápidos continuos. La personalización de un agente preconstruido a través del Generador de solicitudes y la configuración de acciones proporciona un punto medio que cuesta menos que el desarrollo personalizado completo mientras se adapta el agente a su organización. Más allá del costo, sopese los requisitos de tiempo para valorar, la capacidad de desarrollo interno, la diferenciación estratégica y la tolerancia a la dependencia de proveedores, y registre la decisión en un Registro de decisión de arquitectura de modo que pueda volver a evaluarse a medida que cambian los requisitos.

Los agentes de implementación con una comprensión clara de la estructura de costos subyacente hace que la capacidad autónoma se amplíe de forma sostenible en vez de agotar un conjunto de presupuestos. La palanca de optimización depende del modelo de precios, porque lo que ajusta para controlar el costo difiere entre el pago por acción, el pago por plática y el pago por usuario. El principio es constante entre los tres: ajustar el consumo al valor entregado actualmente, de modo que un agente capaz no queme su presupuesto silenciosamente más rápido de lo que devuelve el resultado de negocio.

Bajo Flex Credits, la optimización significa minimizar las acciones por resultado de negocio preservando la calidad. Resuelva solicitudes sencillas en una sola acción en vez de un flujo de trabajo de múltiples pasos, de modo que responder a preguntas frecuentes o realizar una búsqueda rutinaria no consuma los créditos de una cadena de tres acciones. Consolide operaciones en una sola acción donde tenga sentido, combinando recuperación, análisis y respuesta en vez de pagar por cada una por separado cuando una acción serviría. Almacene en caché respuestas para solicitudes repetidas de modo que las preguntas más frecuentes sirvan desde caché en vez de consumir acciones nuevas en cada consulta idéntica, que es la palanca de eficiencia más grande bajo este modelo cuando se repite una parte significativa de consultas.

Bajo Precios por plática, optimización significa resolver problemas en una sola plática en vez de en varias. Diseñe límites y tiempos de espera de sesiones de modo que una plática persista de forma apropiada sin terminar prematuramente y forzar una nueva plática facturable. Centre la capacidad del agente en la resolución de la primera plática de modo que una tarea se complete en la plática inicial en vez de requerir un seguimiento. Realice un seguimiento del índice de resolución de la primera plática como una medición de rentabilidad y desaliente la ampliación del ámbito donde un usuario abre pláticas separadas para problemas relacionados que el contexto de plática existente podría haber gestionado.

Bajo Suscripciones por usuario, la optimización significa maximizar el valor que devuelve cada usuario con licencia, porque el consumo no se mide y el costo es fijo por asiento. Céntrese en la adopción de modo que los usuarios con licencia impliquen activamente al agente, realice un seguimiento de la utilización para identificar usuarios de bajo uso para la capacitación dirigida o la reasignación de licencias y conecte interacciones de agentes con resultados de negocio por población de usuarios de modo que los casos de uso de alto valor justifiquen la inversión mientras que el uso de bajo valor señale una necesidad de optimización o un modelo de precios diferente. Revise poblaciones de usuarios en una cadencia de modo que las licencias permanezcan alineadas con el uso real.

Independientemente del modelo de precios, la arquitectura influye en el costo. Implemente agentes de triaje que gestionan el enrutamiento inicial con lógica sencilla y dirigen a los usuarios a un agente especializado solo cuando la complejidad lo requiere, de modo que las invocaciones complejas costosas solo se producen cuando están garantizadas. Vuelva a la automatización tradicional para escenarios deterministas donde la lógica basada en reglas es suficiente, lo que permite a los flujos gestionar las rutas deterministas a un costo más bajo mientras los agentes gestionan las situaciones ambiguas que realmente necesitan razonamiento. Recupere datos de fundamentación de forma selectiva, invocando la búsqueda de vectores y la recuperación de documentos solo cuando el razonamiento del agente lo requiera en vez de en cada interacción, de modo que el consumo de Data 360 realice un seguimiento de las necesidades reales. Estos patrones mantienen el costo de razonamiento y consumo de la arquitectura proporcional a la dificultad del trabajo.

El monitoreo de costos para agentes autónomos es más difícil que para cargas de trabajo tradicionales, porque los agentes no siguen un patrón de solicitud-respuesta predecible. Un agente puede iterar a través del razonamiento de múltiples pasos, invocar herramientas de forma adaptativa basándose en condiciones de tiempo de ejecución y coordinar otros agentes, lo que produce un consumo de crédito altamente variable difícil de pronosticar. Sin monitoreo, un agente que realiza un trabajo iterativo profundo puede consumir un gran volumen de créditos antes de que nadie intervenga, y el diseño de solicitudes ineficiente o los bucles de razonamiento redundantes pueden agotar presupuestos silenciosamente en toda una flota de agentes. Por lo tanto, una gobernanza efectiva requiere visibilidad en tiempo real del consumo por agente y por operación, alertas automatizadas y controles que eviten el costo desbocado mientras se mantiene la autonomía que hace que los agentes sean útiles. La gobernanza financiera para agentes también necesita una propiedad clara y una aprobación por niveles creada para el consumo variable en vez de para el costo de computación estático.

Salesforce Digital Wallet es la herramienta integrada para monitorear productos basados en consumo incluyendo Agentforce Flex Credits, y las organizaciones que utilizan Flex Credits deben establecerla como el mecanismo principal de monitoreo de costos en vez de crear tableros personalizados para replicar lo que proporciona. Digital Wallet entrega datos de consumo casi en tiempo real con perspectivas de uso a nivel de acción, un desglose por agente que muestra qué agentes consumen más, alertas de consumo proactivas y tendencias históricas para análisis y pronósticos de patrones. Haga coincidir el monitoreo con el modelo de precios. Bajo Flex Credits (Créditos flexibles), realice un seguimiento del consumo por agente, población de usuarios, periodo de tiempo y tipo de acción, y complemente Digital Wallet con tableros personalizados que conectan el consumo de crédito con transacciones de negocio. Bajo Precios por plática, monitoree volúmenes de plática, longitud media e índices de finalización. Bajo Suscripciones por usuario, monitoree la utilización en vez del consumo, realizando un seguimiento de los usuarios activos y el valor de negocio por usuario de modo que se muestre que la inversión de licencia entrega un valor proporcional.

La atribución de costos por interacción conecta el consumo con transacciones de negocio y revela el costo por caso resuelto, por prospecto cualificado o por pedido procesado, lo que permite el cálculo del desempeño de las inversiones y la comparación de casos de uso cruzado. La alerta de presupuesto desencadena la notificación cuando el consumo se acerca a umbrales definidos, en umbrales como el 70% y el 85% del presupuesto, de modo que la optimización se produce antes de alcanzar un límite. Configure alertas por agente y por caso de uso en vez de solo para toda la organización para localizar un problema en su origen. La detección de anomalías aflora el pico de consumo repentino que señala un patrón de uso inesperado o un bucle de razonamiento que necesita investigación. Comparta tableros de costos con partes interesadas de negocio y equipos técnicos de modo que la transparencia impulse el uso de agentes conscientes de los costos.

Aplique la gobernanza financiera antes de confirmar gastos a una arquitectura de agente. Requiera un caso de negocio para una inversión de agente que cubra el TCO proyectado para 3 a 5 años bajo el modelo de precios seleccionado, los resultados de negocio esperados con un método de medición, una comparación con alternativas incluyendo procesos manuales y automatización tradicional, y una evaluación de riesgo que cubra la calidad, la seguridad y el riesgo operativo. Defina umbrales de aprobación que separan las inversiones que un departamento puede autorizar de aquellas que requieren aprobación ejecutiva, de modo que un agente de alto riesgo o alta inversión reciba un escrutinio proporcionado. Imponga implementaciones piloto que validan supuestos antes de la producción completa, porque un piloto revela el consumo real, la calidad y la adopción que informan la decisión de inversión de producción y la selección del modelo de precios.

Gestione el patrimonio de agentes como una cartera en vez de agente por agente, porque una vista de cartera revela oportunidades de optimización que se pierden una revisión de un solo agente. Revise todos los agentes juntos, comparando el costo, el uso, el valor de negocio y la alineación estratégica, y defina criterios de extinción que retiren agentes con baja adopción, mal desempeño de las inversiones, funciones sustituidas o costo excesivo, de modo que los agentes de bajo valor no acumulen y consuman presupuesto indefinidamente. Reasigne la inversión de agentes de bajo desempeño a oportunidades de alto valor como una práctica continua que realinea el gasto con prioridades cambiantes en vez de una limpieza puntual.

La asignación de costos crea responsabilidad por el consumo de agentes, y las organizaciones la implementan a través de los mismos dos modelos que se aplican al resto de la plataforma. Showback reporta costos de agentes por unidad de negocio sin un cargo interno, lo que crea conciencia de costos e informa el debate de optimización sin la contención de la facturación interna. La devolución de cargos asigna costos de agentes reales a las unidades de negocio consumidoras, lo que impulsa un comportamiento de optimización más sólido porque el costo afecta a un presupuesto departamental directamente, pero requiere un método de asignación preciso para evitar conflictos. Un enfoque híbrido aplica devolución de cargos a agentes de producción de gran volumen mientras utiliza la devolución de cargos para agentes experimentales o de bajo volumen, lo que equilibra la rendición de cuentas para inversiones importantes con la flexibilidad para la innovación.

Las arquitecturas de agentes introducen consideraciones de sostenibilidad propias, porque la inferencia de modelo de lenguaje grande es computacionalmente intensiva y algunos agentes se ejecutan de forma continua en vez de solo en transacciones desencadenadas por usuarios discretas. Los agentes proactivos, salientes y programados funcionan sin un usuario en el bucle, los agentes conversacionales acumulan consumo en muchos turnos y la búsqueda de vectores, la preparación de contextos y la ejecución de acciones se suman a la carga de infraestructura. El diseño de agentes sostenible minimiza el desperdicio computacional mientras mantiene la experiencia con capacidad de respuesta. Como en el pilar Optimización de recursos y costos, la relación entre una solución y las emisiones del centro de datos es indirecta. La eficiencia de un solo arrendatario no reduce directamente las emisiones. Sin embargo, las mejoras de eficiencia entre todos los arrendatarios ayudan a Salesforce a ejecutar su infraestructura con una utilización superior y aplazar la ampliación de la capacidad. y las prácticas de sostenibilidad fundacionales del pilar Optimización de recursos y costos se aplican a los agentes, y las estrategias de eficiencia que siguen tratan lo que es específico de los sistemas conversacionales con tecnología de modelo de lenguaje grande. Cada uno también reduce el costo, por lo que la sostenibilidad y la relación calidad-precio son la misma disciplina medida con diferentes resultados.

La inferencia es el componente que más recursos consume de una arquitectura agente, de modo que la eficiencia da sus frutos con la longitud de las solicitudes, el uso del contexto y el almacenamiento en caché. Optimice las solicitudes para transmitir la intención en menos tokens eliminando instrucciones verbosas y ejemplos redundantes, porque una solicitud más corta reduce el cálculo del relleno previo proporcionalmente aunque no cambie el cálculo de la generación de la respuesta. Gestione la ventana de contexto resumiendo el historial de pláticas después de los primeros turnos y devolviendo solo campos esenciales de cada acción, de modo que el presupuesto de tokens llevado a cada inferencia permanezca limitado en vez de crecer con la plática.

La búsqueda vectorial y las consultas de perfil unificado consumen recursos computacionales, de modo que la misma disciplina de filtrado y límite de resultados que controla el costo de fundamentación también reduce la carga de infraestructura de la fundamentación. Establezca límites máximos para devolver solo los resultados que utiliza el agente, porque la recuperación de 50 cuando 5 informa a la respuesta conlleva 45 resultados no utilizados que consumen presupuesto de token de fundamentación sin beneficio, y utilice filtros de metadatos para restringir la búsqueda antes de la clasificación de similitud. Consulte perfiles unificados para ensamblar contexto completo en una sola operación en vez de emitir consultas separadas en varios objetos para cada turno, y perfiles de caché para agentes con alta afinidad de usuario, como un agente de ventas que trabaja en un conjunto fijo de cuentas, de modo que el ensamblaje de contexto repetido no repita la consulta.

Las acciones de agentes consumen consultas SOQL, operaciones DML y tiempo de CPU, de modo que la masificación, el almacenamiento en caché y la disciplina asíncrona del pilar Optimización de recursos y costos se aplica directamente a acciones de agentes. Diseñe acciones para aceptar recopilaciones de modo que la actualización de muchos registros sea una operación en vez de muchas, utilice consultas de relaciones para recuperar datos principales y secundarios en una sola declaración, almacene en caché datos de referencia en Caché de plataforma y DML por lotes en una recopilación en vez de por registro. Mueva operaciones que superan los límites síncronos a Apex colocable en cola o por lotes, procese trabajo no urgente como puntuaje masivo o enriquecimiento histórico de forma asíncrona y programe trabajos por lotes desencadenados por agentes para plazos de menor producción donde sea posible de modo que la carga se extienda a lo largo del tiempo en vez de concentrarse durante las horas de oficina. Monitoree la ejecución asíncrona de modo que un retraso de cola señale una necesidad de planificación de capacidad antes de que se convierta en un fallo.

Los patrones de consumo de agentes evolucionan a medida que crece el uso, de modo que la sostenibilidad requiere monitoreo continuo en vez de un pase puntual. Realice un seguimiento de los tokens medios por inferencia a través de la telemetría de uso disponible de modo que un tamaño de solicitud creciente aflore una oportunidad de optimización, monitoree la distribución de longitud de plática de modo que las pláticas sin límites revelen un problema de límite de tareas y analice la frecuencia de ejecución de acciones en Monitoreo de eventos de modo que una acción de alta frecuencia se convierta en una prioridad de optimización. Revise patrones de consultas de Data 360 para encontrar consultas comunes que vale la pena almacenar en caché o calcular previamente, realice un seguimiento del índice de aciertos de caché semántico de modo que un índice bajo desencadene el ajuste de umbrales y mida percentiles de latencia de modo que la latencia de cola exponga cualquier cuello de botella. Revise el uso de agentes regularmente para la desviación de ámbito. Por ejemplo, investigue un agente cuya longitud de plática media crece de un puñado de turnos a varios durante varios meses. Restrinja los límites del agente de modo que el consumo vuelva al plan. Algunas de estas superficies de monitoreo exponen el uso en tableros agregados en vez de como un registro discreto por inferencia, de modo que confirme la telemetría exacta disponible para su configuración cuando diseñe el monitoreo.

La optimización de recursos determina si las arquitecturas de agentes se amplían a medida que crecen las poblaciones y se amplían los casos de uso, y la optimización de costos determina si esa ampliación devuelve un valor de negocio proporcional. Estas dos decisiones forman un único mandato:

• Eficiencia arquitectónica: diseñe acciones con masificación, presupuestar SOQL entre cadenas de acción, mover procesamiento pesado a asíncrono, optimizar el consumo de API a través de patrones compuestos y dirigidos por eventos, gestionar plazos de contexto a través de la priorización y el resumen y construir arquitecturas componibles a partir de componentes reutilizables.
• Directrices financieras: Seleccione el modelo de precios deliberadamente, modele el TCO completo antes de confirmar, monitoree el consumo frente a resultados de negocio y rija la inversión a través de la aprobación por niveles y la revisión de cartera.

Las organizaciones que dominan estos patrones entregan experiencias de agentes con capacidad de respuesta dentro de las restricciones de la plataforma mientras mantienen el gasto alineado con el valor que devuelven los agentes.

Las directrices de optimización de recursos y costos fundamentales para todas las soluciones de Salesforce, incluyendo optimización de desempeño, límites reguladores, análisis de TCO, disciplina de licencias y gobernanza de costos, residen en el pilar Optimización de recursos y costos. Los componentes de gobernanza de agentes, supervisión humana y programa de seguridad se conectan a los pilares Trust y Fairness. Las directrices de implementación de agentes detalladas en este documento, que abarcan la eficiencia de recursos, la economía, la optimización de acciones, la gobernanza y la sostenibilidad, se recopilan en la biblioteca de patrones de agentes.

Comparta sus comentarios sobre el Marco de trabajo bien diseñado.