Optimización de recursos y costes 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 coste del pilar Optimización de recursos y costes se traslada directamente a Agentic Enterprise. Eficiencia de recursos significa utilizar la capacidad que ya paga y optimización de costes significa dirigir el gasto deliberadamente hacia las funciones autónomas que obtienen un rendimiento. Los agentes cambian la forma de ambos. El diseño eficiente de agentes mantiene el consumo bajo control, y la selección de modelo de precios, el modelado de coste 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 costes 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 opera en un conjunto de registros conocido con un coste de recurso conocido. Un agente opera conversacionalmente, y una sola conversación puede ejecutar docenas de acciones según razona el agente 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 conversación. 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 coste cambia tanto. Los agentes autónomos introducen 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 un uso no medido, puede crear una capa junto con un modelo de consumo de modo que los agentes de cara al cliente se ejecuten en Flex Credits o Por conversación mientras los empleados utilizan licencias no medidas. 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 costes 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 comercial con un coste optimizado en Agentic Enterprise mantienen el consumo de agentes eficiente a través de acciones que procesan registros en plazos de contexto masivos y disciplinados y almacenamiento en caché. También dirigen deliberadamente el gasto a través del modelo de precios correcto, completan el modelado de TCO y la supervisión de costes continua con respecto a resultados comerciales. Sin esa alineación, las implementaciones de agentes acumulan costes 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 a 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 agentes.
Este documento trata lo que cambia cuando los agentes están en la imagen. Para los patrones de optimización de recursos y costes fundacionales que se aplican a cada solución de Salesforce, incluyendo optimización de rendimiento, límites reguladores, análisis de TCO y disciplina de licencias, consulte el pilar Optimización de recursos y costes. La gobernanza de los agentes y la supervisión humana están conectadas con los pilares Confideicomiso y Justicia, que cubren los componentes del programa que mantienen un 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 conversación 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 duplicación. Cada responsabilidad es una decisión de valor por coste antes de ser técnica, porque los agentes repiten ineficiencias en cada conversación.
Los agentes invocan acciones que desencadenan Apex, flujos e integraciones. Una sola conversación puede ejecutar docenas de acciones según razone el 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 única acción que opera en una recopilación de registros consume muchas menos consultas de Salesforce Object Query Language (SOQL) y operaciones de Data Manipulation Language (DML) para el mismo trabajo. Gestione el presupuesto de 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 hacer referencia a datos almacenados en caché en Platform Cache entre acciones en la misma conversación. 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 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 la puntuación de 1.000 candidatos o el análisis de opiniones entre casos históricos, pertenecen al procesamiento asíncrono en vez de bloquear una conversación. La inferencia de modelo de gran idioma 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. Agentforce Session Tracing identifica qué acciones consumen consultas excesivas a nivel de sesión, y Scale Center supervisa el rendimiento general de transacciones Apex y el estado de la organización.
Las arquitecturas de agentes consumen API con mayor rapidez que los flujos de trabajo dirigidos por el usuario, 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 conversación. Los agentes incrustados en páginas Lightning a través de componentes estándar no consumen una llamada de API por interacción, aunque su coste aún se mide en los créditos o conversaciones del modelo de precios elegido. Los componentes web Lightning personalizados que realizan llamadas REST directas consumen capacidad de API. Los componentes creados en adaptadores de cable 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. Supervise el consumo en Supervisión 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 agentes derrochadores. 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 si hay o no trabajo por hacer, y un agente que se suscribe a eventos de Cambiar Captura de datos 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 coste es directa: Un sondeo que no encuentra trabajo es capacidad gastada para nada, y un evento que se activa solo en un cambio real es capacidad gastada solo en trabajo real. La generación aumentada de recuperación agrega su propio consumo, ya que 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.
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 coste 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 conversaciones que una resuelta. Las solicitudes más cortas generan respuestas más rápidas, de modo que elimine instrucciones verborrágicas, 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 sin importar la rapidez de la inferencia. Valide consultas de acción con la herramienta Plan de consulta para identificar exploraciones de tabla 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 el más lento de los dos en vez de la suma de ambos. Para llamadas que se despliegan a múltiples sistemas descendentes, empareje Agentforce con una plataforma de integración como MuleSoft; el agente invoca una única 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á listo en vez de mantener la conversación abierta.
Data 360 proporciona la búsqueda vectorial que fundamenta las respuestas de agentes en datos actuales en vez de en los datos de entrenamiento del modelo por separado, y su eficiencia rige tanto la calidad de fundamentación como el cálculo que consume para alcanzarla. La segmentación, la selección de integración, el filtrado de metadatos y los límites de resultados son las decisiones más valiosas. Knowledge fragmentado en segmentos con sentido semántico, porque los fragmentos que son demasiado pequeños fuerzan muchas recuperaciones para una pregunta mientras que los fragmentos que son 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 en consultas representativas. Combine la similitud semántica con filtros de metadatos de modo que las restricciones comerciales se mantengan independientemente de la similitud, como excluir productos descontinuados de una recomendación independientemente de lo cerca que esté la coincidencia. Establezca límites máximos para devolver solo los resultados que utiliza el agente. Por ejemplo, si 5 resultados informan una respuesta, la recuperación de 50 agrega 45 resultados no utilizados al presupuesto de carga y token de fundamentación.
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 determinada 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 conversación larga coherente sin agotar la capacidad o inflar el coste de cada llamada de inferencia. Priorice deliberadamente en vez de truncar arbitrariamente: historial de conversación reciente tiene la prioridad más alta, los datos comerciales críticos como el estado y los permisos de registro actuales se incluyen en segundo lugar y el historial anterior solo se incluye cuando el espacio lo permite. Después de los primeros turnos, resuma la conversación anterior en una descripción general concisa que preserve 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 bajo demanda 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 conversación o fundamentación.
Los agentes de creación de componentes reutilizables reducen los costes 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, seguridad y rendimiento coherentes entre cada agente consumidor, y permiten que un nuevo agente se reúna a partir de elementos constructivos probados en días en vez de crearse a partir de 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 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 empresa 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 pasándose entre sí a medida que una conversación se mueve entre dominios. Esta composición plantea preguntas de recursos y costes 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 el 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 comerciales antes de actuar sobre ella. Aplique la seguridad y la colaboración a nivel de campo 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 conversaciones sin procesar, de modo que el presupuesto de token 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 conversación, 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 cadenas más profundas multiplican el consumo aún más. La misma multiplicación dirige el coste, lo que hace que la profundidad de cadena sin límites sea un riesgo de coste más que un riesgo de 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 único tiempo de espera de subagente 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 provocó un pico de latencia o un pico de coste requiere correlacionar manualmente registros 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 coste 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 coste. Distinga fallos transitorios, como un tiempo de espera de llamada o conflicto de bloqueo, de fallos lógicos, como un error de validación o una entrada mal formada, 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.
Restrinja los 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, ya que un reintento sin límites o de bucle cerrado en una acción intensa de SOQL o DML puede agotar los límites síncronos en una única transacción o quemar hasta el presupuesto en cadena acumulativo y el gasto de crédito acumulativo en una conversación 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 o conversaciones facturadas 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 gestor de fallos que sabe lo que ya se realizó con éxito 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 conversación completamente nueva y un nuevo conjunto de acciones, lo que agrava el coste de recurso y facturación 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 Supervisión de costes y Gobernanza financiera. Digital Wallet muestra cuántos créditos o conversaciones 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 en realidad, 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 activan al inicio y al final de cada acción e invocación de subagente. Estos eventos rastrean la ejecución en una conversación utilizando solo funciones de plataforma estándar, emparejadas con el registro a nivel de acción en un objeto personalizado capturando el recuento de consultas SOQL, el tiempo de CPU, el recuento de filas DML y el uso de pilas cuando se ejecuta cada acción. Ambos eventos son consultables a través de informes o SOQL y proporcionan a cada organización una función de diagnóstico de línea base independientemente de la edición o la licencia complementaria. Supervisión de eventos, presentada 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 conversaciones 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 versión 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 de prueba A/B piloto 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 rendimiento, 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 coste total de propiedad medido con respecto al valor comercial, pero los precios basados en el consumo de agentes autónomos hacen que el lado del coste se comporte de la misma manera que las licencias tradicionales. El modelo de precios que seleccione es una decisión arquitectónica fundamental, ya que 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. Flex Credits price per agent action (Precio flexible de créditos por acción de agente), lo que hace que la eficiencia de la acción sea la palanca para el control de costes. Los precios por conversación cobran una tarifa plana por conversación independientemente de la longitud o complejidad, lo que hace que la contención de conversaciones sea la palanca. Las suscripciones por usuario proporcionan un uso de agentes sin medir 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 que los usuarios con licencia implican 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 un uso no medido, puede aplicar capas junto con un modelo de consumo de modo que los agentes de cara al cliente se ejecuten en Flex Credits o Por conversación mientras los empleados utilizan licencias no medidas.
Bajo Flex Credits (Créditos flexibles), los costes de acción se fijan por acción hasta un límite máximo de tokens definido. A diferencia de los precios de inferencia basados en tokens, el coste 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 comercial es el requisito previo para el modelado de costes bajo Flex Credits.
Bajo Precios por conversación, se aplica una tarifa plana por conversación, y múltiples turnos en una sesión cuentan como una sola conversación, de modo que el control de costes proviene de resolver un problema en una conversación y definir 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 integración de la generación y la búsqueda de similitudes reduce la capacidad de procesamiento de datos para cada consulta fundamentada y cada acción externa consume capacidad de API tanto en el sistema de origen como en el de destino.
El coste 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 costes de desarrollo cubren el diseño de agentes, la ingeniería de solicitudes, el desarrollo de integración y las pruebas, y varían ampliamente desde un simple agente de un solo propósito hasta un sistema de múltiples agentes con orquestación compleja. Los costes de conferencia dependen del modelo de precios seleccionado y requieren modelar volúmenes de acción previstos bajo Flex Credits, volúmenes de conversación bajo Por conversación o recuentos 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 coste de inferencia. Los costes de infraestructura cubren las licencias de Data 360 y MuleSoft, los entornos sandbox adicionales y la infraestructura de supervisión, y son predominantemente fijos o de función escalonada basándose en niveles de capacidad. Los costes operativos cubren operaciones de supervisión, refinamiento de solicitudes, respuesta a incidentes y asistencia a usuarios, y para programas de agentes maduros equivalen habitualmente a una fracción significativa del coste de desarrollo anualmente, coherente con los indicadores generales del sector para agentes de IA en vez de una cifra específica de Salesforce. Los costes de gobernanza 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 costes de cambio cubren la formación de usuarios, la adaptación de procesos comerciales 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 costes de 3 a 5 años. Documente suposiciones para volúmenes de interacción, recuentos de acciones y crecimiento. Ejecute un análisis de sensibilidad para identificar los supuestos que más afectan al total, luego centre la validación en esos supuestos. Modele las tres estructuras de costes, 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, ponderando el tiempo inmediato en valor 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 propia 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 al coste del desarrollo por adelantado además de un refinamiento y mantenimiento rápidos continuos. La personalización de un agente predefinido 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 coste, pondere 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 ejecución que comprenden claramente la estructura de costos subyacente hacen que la capacidad autónoma se amplíe de forma sostenible en lugar de agotar un conjunto de presupuestos. La palanca de optimización depende del modelo de precios, porque lo que ajusta para controlar el coste difiere entre el pago por acción, el pago por conversación y el pago por usuario. El principio es constante entre los tres: ajustar el consumo con respecto al valor entregado actualmente, de modo que un agente capaz no queme silenciosamente su presupuesto más rápido de lo que devuelve el resultado comercial.
Bajo Flex Credits (Créditos flexibles), la optimización significa minimizar las acciones por resultado comercial 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 más 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 conversación, optimización significa resolver problemas en una sola conversación en vez de en varias. Diseñe límites y tiempos de espera de sesiones de modo que una conversación persista de forma apropiada sin finalizar prematuramente y forzar una nueva conversación facturable. Centre la capacidad del agente en la resolución de la primera conversación de modo que una tarea se complete en la conversación inicial en vez de requerir un seguimiento. Realice un seguimiento del índice de resolución de la primera conversación como una medición de coste-eficiencia y desaliente la expansión del ámbito donde un usuario abre conversaciones separadas para problemas relacionados que el contexto de conversación 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 coste es fijo por asiento. Céntrese en la adopción de modo que los usuarios con licencia impliquen activamente al agente, realicen un seguimiento de la utilización para identificar usuarios de bajo uso para la formación dirigida o la reasignación de licencias y conecten interacciones de agentes con resultados comerciales 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 las 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 coste. Implemente agentes de triaje que gestionan el enrutamiento inicial con lógica sencilla y dirigen los usuarios a un agente especializado solo cuando la complejidad lo requiere, de modo que las invocaciones complejas costosas se producen solo cuando están garantizadas. Vuelva a la automatización tradicional para escenarios deterministas donde la lógica basada en reglas es suficiente, permitiendo a los flujos gestionar las rutas deterministas a menor coste mientras los agentes gestionan las situaciones ambiguas que realmente necesitan razonamiento. Recupere datos de fundamentación de forma selectiva, invocando la búsqueda vectorial 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 la necesidad real. Estos patrones mantienen el coste de razonamiento y consumo de la arquitectura proporcional a la dificultad del trabajo.
La supervisión de costes 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 de forma adaptativa herramientas basadas en condiciones de tiempo de ejecución y coordinar otros agentes, lo que produce un consumo de crédito altamente variable que es difícil de pronosticar. Sin supervisión, 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 silenciosamente los presupuestos 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 costes desbocados preservando la autonomía que hace que los agentes sean útiles. La gobernanza financiera para los agentes también necesita una propiedad clara y una aprobación por niveles creada para el consumo variable en vez de para el coste de cálculo estático.
Salesforce Digital Wallet es la herramienta integrada para supervisar productos basados en consumo, incluyendo Agentforce Flex Credits, y las organizaciones que utilizan Flex Credits deben establecerla como el mecanismo principal de supervisión de costes en vez de crear paneles 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 previsiones de patrones. Compare la supervisión 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 paneles personalizados que conectan el consumo de crédito con transacciones comerciales. Bajo Precios por conversación, supervise volúmenes de conversación, longitud media e índices de finalización. Bajo Suscripciones por usuario, supervise la utilización en vez del consumo, realizando un seguimiento de los usuarios activos y el valor comercial por usuario de modo que se muestre que la inversión de licencia entrega un valor proporcional.
La atribución de costes por interacción conecta el consumo con transacciones comerciales y revela el coste por caso resuelto, candidato cualificado o pedido procesado, lo que permite el cálculo del rendimiento de las inversiones y la comparación de casos de uso cruzado. La alerta de presupuesto desencadena la notificación a medida que 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 paneles de costes con partes interesadas comerciales y equipos técnicos de modo que la transparencia impulse el uso de agentes conscientes de los costes.
Aplique la gobernanza financiera antes de confirmar gastos a una arquitectura de agentes. Requerir un caso comercial para una inversión de agente que cubre el TCO proyectado durante 3 a 5 años bajo el modelo de precios seleccionado, los resultados comerciales 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 cubre 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 de alta inversión reciba un escrutinio proporcionado. Implementaciones piloto obligatorias que validan supuestos antes de la producción completa, porque un piloto revela el consumo, la calidad y la adopción reales que informan la decisión de inversión en 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 una revisión de un solo agente pierde. Revise todos los agentes juntos, comparando el coste, el uso, el valor comercial y la alineación estratégica, y defina criterios de extinción que retiren agentes con baja adopción, mal rendimiento de las inversiones, funciones sustituidas o coste excesivo, de modo que los agentes de bajo valor no acumulen y consuman presupuesto indefinidamente. Reasigne la inversión de agentes de bajo rendimiento a oportunidades de alto valor como una práctica continua que realinea el gasto con prioridades en evolución en vez de una limpieza puntual.
La asignación de costes 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 costes de agentes por unidad comercial sin un cargo interno, lo que crea conciencia de costes e informa el debate de optimización sin la disputa de la facturación interna. La devolución de cargos asigna costes de agentes reales a las unidades comerciales de consumo, lo que impulsa un comportamiento de optimización más sólido porque el coste afecta directamente a un presupuesto departamental, pero requiere un método de asignación preciso para evitar disputas. Un enfoque híbrido aplica la 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 intensiva en computación 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 de conversación 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 los desechos computacionales mientras mantiene la experiencia con capacidad de respuesta. Como en el pilar Optimización de recursos y costes, la relación entre una solución y las emisiones del centro de datos es indirecta. La eficiencia de un único 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 expansión de la capacidad. y las prácticas de sostenibilidad fundacionales del pilar Optimización de recursos y costes se aplican a los agentes, y las estrategias de eficiencia que siguen abordan lo específico de los sistemas de conversación con tecnología de modelo de lenguaje grande. Cada uno también reduce el coste, por lo que la sostenibilidad y el valor por coste son la misma disciplina medida en función de diferentes resultados.
La inferencia es el componente más intensivo en recursos 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 verborrágicas y ejemplos redundantes, ya que una solicitud más corta reduce el cálculo de prerrelleno proporcionalmente aunque no cambia el cálculo de generación de la respuesta. Gestione la ventana de contexto resumiendo el historial de conversaciones después de los primeros turnos y devolviendo solo campos esenciales de cada acción, de modo que el presupuesto de tokens que se lleva a cada inferencia permanezca limitado en vez de crecer con la conversación.
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 coste 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, ya que 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 utilizan filtros de metadatos para restringir la búsqueda antes de la clasificación de similitud. Consulte perfiles unificados para reunir contexto completo en una 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 conjunto 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 costes 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 única 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 en cola o por lotes, procese trabajo no urgente como puntuación masiva 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 el horario de oficina. Supervise 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 supervisión continua 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, supervise la distribución de longitudes de conversación de modo que las conversaciones sin límites revelen un problema de límite de tareas y analice la frecuencia de ejecución de acciones en Supervisión de eventos de modo que una acción de alta frecuencia se convierta en una prioridad de optimización. Revise patrones de consulta de Data 360 para encontrar consultas comunes que vale la pena almacenar en caché o calcular previamente, realice un seguimiento del índice de coincidencias de caché semántico de modo que un índice bajo desencadene el ajuste de umbral 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 conversación media crece de un puñado de turnos a muchos durante varios meses. Restrinja los límites del agente de modo que el consumo vuelva al plan. Algunas de estas superficies de supervisión exponen el uso en paneles 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 la supervisión.
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 costes determina si esa escala devuelve un valor comercial proporcional. Estas dos decisiones forman un mandato único:
- Eficiencia arquitectónica: diseñar acciones con masificación, presupuestar SOQL entre cadenas de acción, mover el procesamiento pesado a asíncrono, optimizar el consumo de API a través de patrones compuestos y dirigidos por eventos, gestionar ventanas de contexto a través de la priorización y el resumen y crear arquitecturas componibles a partir de componentes reutilizables.
- Orientación financiera: Seleccione el modelo de precios deliberadamente, modele el TCO completo antes de confirmar, supervise el consumo con respecto a los resultados comerciales 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 fundamentales de optimización de recursos y costes para todas las soluciones de Salesforce, incluyendo optimización de rendimiento, límites reguladores, análisis de TCO, disciplina de licencias y regulación de costes, se encuentran en el pilar Optimización de recursos y costes. 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.