Skip to main content

Agentes de Agentforce: el camino nativo de la plataforma

El camino nativo de Salesforce como un instrumento del kit — el correcto cuando el trabajo vive en el modelo de seguridad y necesita acciones gobernadas y auditables sobre datos del cliente (principio 7). Cómo se arma un agente de Agentforce: Topics que acotan los trabajos, Instructions que guían el comportamiento, el Atlas Reasoning Engine gestionado que planifica sobre ellos, Actions que actúan, grounding vía Data 360, y el Einstein Trust Layer haciendo la gobernanza. Qué tenés vos y qué tiene la plataforma — y dónde el trabajo le pasa la posta a un agente externo.

Referencia·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Agarrá Agentforce cuando el trabajo vive dentro del modelo de seguridad de Salesforce y el agente tiene que tomar acciones gobernadas y auditables sobre datos del cliente — leer un caso de servicio bajo las sharing rules del usuario, actualizar un registro, groundear una respuesta sobre el perfil unificado (principio 7). Ese es el trabajo para el que está construido este instrumento, y la razón para elegirlo no es lealtad a una plataforma sino encaje: cuando la acción y los datos están los dos adentro de Salesforce, la plataforma ya es dueña del grounding, los permisos y el audit trail que de otro modo armarías a mano.

Esta página es cómo se arma un agente de Agentforce, parte por parte, y — igual de importante — qué tenés vos versus qué tiene la plataforma. Vos conectás los Topics, las Instructions, las Actions y el grounding; la plataforma corre el loop de planificación y la gobernanza. Es un instrumento componible, no el kit entero: un sistema real muchas veces corre un agente de Agentforce on-platform y un agente externo afuera, y se pasan la posta. El vocabulario de acá — agente, tool, acción, grounding, control loop — es el vocabulario de qué es un agente; esta página lo da por sabido.

Topics: los trabajos que un agente maneja

Un Topic es un alcance de trabajo — un trabajo que el agente sabe hacer. Agrupa las Actions relacionadas para ese trabajo con las instrucciones de cuándo y cómo usarlas. Un agente tiene un set de Topics, y el planificador elige el que encaja con el pedido: un Topic "gestionar pedido" con sus Actions de buscar-pedido y actualizar-pedido, un Topic "agendar turno" con sus Actions de calendario, cada uno teniendo solo lo que ese trabajo necesita.

La disciplina es la misma disciplina de menor privilegio que gobierna las tools (principio 5): un Topic debería ser el alcance más angosto que igual hace el trabajo. Un Topic que mete todas las Actions que tiene la org es un Topic que el planificador va a usar mal — no puede razonar limpio sobre cuándo actuar cuando el límite está borroso. Mantené cada Topic en un trabajo coherente, con las Actions y las instrucciones de ese trabajo y nada más, y el planificador tiene una elección limpia para hacer en vez de una adivinanza.

Instructions: guiar el comportamiento en lenguaje natural

Las Instructions son la guía en lenguaje natural que orienta al agente adentro de un Topic — qué debería hacer, dónde están sus límites, cuándo actuar y cuándo pasarle la posta a un humano. Son la expresión nativa de la plataforma de la disciplina del system prompt de qué es un agente: las instrucciones vagas son la causa más común de un agente que se va por las ramas, y Agentforce no cambia eso. "Ayudá al cliente con su pedido" no le da nada al planificador para sostener; "buscá el pedido que el cliente nombra, confirmá el ítem antes de cualquier cambio, nunca canceles un pedido por encima de cierto valor sin pasarle la posta a un humano" le da límites adentro de los cuales puede actuar.

Escribí las Instructions como escribirías la descripción de una tool: decí qué hacer, cuándo hacerlo y — lo más útil — cuándo no. Los límites que escribís acá son guía sobre la que el planificador razona, no una capa de aplicación dura. Los límites duros — qué tiene permitido tocar una Action, como quién corre — viven en el modelo de permisos de la plataforma y en la definición de la Action, donde el modelo no puede convencer a nadie de darle la vuelta. Las Instructions guían; los permisos aplican. Necesitás los dos, y nunca tendrías que confundir uno con el otro.

El Atlas Reasoning Engine: el planificador gestionado

El loop de planificación es la parte que acá no tenés vos. El Atlas Reasoning Engine es el planificador gestionado de Agentforce — presentado en patrones de orquestación como la opción de razonamiento gestionado; esta página va un nivel más adentro de lo que eso significa para cómo construís. Atlas planifica sobre los Topics, las Actions y el grounding que vos conectás: lee el pedido, decide qué Topic encaja, decide qué Actions llamar y en qué orden, y groundea su razonamiento sobre los datos que la plataforma recupera — todo adentro del modelo de seguridad de Salesforce.

La consecuencia práctica es una división del trabajo limpia. Vos tenés las tools, las instrucciones y el grounding — los Topics, las Actions, qué tiene permitido hacer cada una, y sobre qué datos responde el agente. La plataforma tiene el control loop — el ciclo razonar → actuar → observar que un build externo te haría escribir y acotar a vos. Ese es el trade-off de gestionado-o-custom de patrones de orquestación, dicho en concreto: cedés control sobre el loop y te resuelven la planificación, el grounding y la gobernanza. Cuando el trabajo encaja en el modelo de seguridad, es un buen trade; cuando necesitás un control flow que Atlas no te da — un grafo específico, un modelo que Salesforce no alcanza — esa es la señal para componer un agente externo en su lugar.

Actions: cómo actúa el agente

Un agente actúa a través de Actions — el término de Agentforce para las tools de un Topic. Los tres tipos de ejecución (Flow, Apex, Prompt Template) están detallados en tools y acciones; en corto, una Flow Action corre el trabajo de forma declarativa, una Apex Action lo corre en código, y una Prompt Template Action llama a un prompt groundeado. Esta página no los vuelve a enseñar — leé esa página para saber cómo construir cada tipo y para la disciplina de tools seguras (menor privilegio, validación de argumentos, idempotencia, un gate sobre cualquier cosa de consecuencia) que aplica a una Action exactamente igual que a cualquier otra tool.

Lo que vale la pena recalcar acá es lo que te compra quedarte on-platform. Una Action se ejecuta como un usuario, bajo los permisos de ese usuario; las sharing rules y la seguridad a nivel de campo siguen aplicando; y la plataforma registra qué corrió. La disciplina de radio de explosión y audit trail que un build externo arma a mano está, on-platform, parcialmente aplicada por el modelo de seguridad que ya operás. Ese es el núcleo de por qué Agentforce es el instrumento correcto cuando el trabajo vive en el modelo de seguridad de Salesforce — la gobernanza no está pegada encima, es donde corre la acción.

Grounding a través de Data 360

Un agente de Agentforce responde sobre tus datos a través de grounding sobre el perfil de Data 360 (Data Cloud). El mecanismo es el mismo de qué es un agente: el agente no responde desde el entrenamiento del modelo, responde desde hechos recuperados en esta corrida. En la plataforma, esos hechos vienen a través de retrievers sobre el perfil unificado — el agente lee al mismo cliente que ve el resto de Salesforce, resuelto y actual, en vez de adivinar desde parámetros.

Acá es donde aterriza el principio 2 adentro de Agentforce: groundeá antes de generar. Un agente groundeado sobre un modelo fragmentado o desactualizado está equivocado con seguridad, y equivocado con seguridad es peor que "no sé" porque alguien actúa sobre eso. El modelo debajo del agente está aguas arriba de casi todo problema de calidad que el agente va a tener, y por eso el lado del grounding tiene su propia disciplina — corré el chequeo de agent-readiness de Data 360 antes de que el agente lea datos de marketing o de servicio, no después de que salga la primera respuesta equivocada.

El Einstein Trust Layer: la gobernanza que corre la plataforma

El Einstein Trust Layer es la capa de gobernanza y seguridad de la plataforma alrededor del LLM que usa el agente. Se sienta entre Agentforce y el modelo, y es una razón real por la que el camino nativo de la plataforma encaja bien con trabajo regulado y de datos del cliente. A la altura que importa para una decisión de build, cubre un set bien establecido de controles:

  • Recuperación segura de datos — los datos de grounding se traen adentro del modelo de seguridad, respetando los permisos del usuario que corre en vez de entregarse a un modelo con acceso amplio.
  • Dynamic grounding — los datos relevantes del cliente se traen al prompt en tiempo de pedido, así el agente razona sobre hechos actuales.
  • Enmascarado de datos — los campos sensibles se pueden enmascarar antes de que el prompt llegue al proveedor del modelo, así la PII no queda expuesta donde no hace falta.
  • Cero retención de datos — el proveedor del modelo no retiene los prompts ni las respuestas, así tus datos del cliente no se usan para entrenar un modelo externo ni quedan de su lado.
  • Scoring de toxicidad — la salida generada se puntúa por toxicidad, dándote una señal sobre la que actuar antes de que llegue a una persona.
  • Un audit trail — la interacción se registra, que es la precondición para ser dueño de lo que hizo el agente (principio 11).

El punto de composición: Agentforce acá, un agente externo allá

Agentforce es un instrumento, y el encuadre honesto es composición, no elección (principio 7). El camino nativo de la plataforma es el correcto cuando el trabajo vive en el modelo de seguridad de Salesforce y necesita acciones gobernadas y auditables sobre datos del cliente. Un agente externo de LangGraph o Claude API es el correcto cuando el trabajo es off-platform, necesita un control flow que Atlas no te da, o alcanza un modelo y sistemas que Salesforce no — mirá agentes externos para ese lado. Un sistema real frecuentemente corre los dos: Agentforce dueño de las acciones in-platform sobre datos gobernados, un agente externo dueño de un paso que no puede, y un traspaso limpio entre ellos donde la responsabilidad tiene una costura (principio 9).

La decisión de qué superficie para qué trabajo adentro de Marketing Cloud — Agentforce versus un modelo externo — es su propio framework, y no se repite acá; el Style Guide de IA de Marketing Cloud la tiene completa. Lo que esta página resuelve es más angosto y vale la pena decirlo claro: Agentforce no es la respuesta a "¿deberíamos usar un agente?", es la respuesta a "el trabajo es gobernado, on-platform y actúa sobre datos del cliente — qué lo planifica y lo corre". Cuando ese es el trabajo, que la plataforma sea dueña del loop y de la gobernanza es exactamente el trade que querés.

El hilo conductor

Un agente de Agentforce es Topics que acotan los trabajos, Instructions que guían el comportamiento, el Atlas Reasoning Engine que planifica sobre ellos, Actions que actúan adentro del modelo de seguridad, grounding sobre el perfil de Data 360, y el Einstein Trust Layer corriendo la gobernanza. Vos tenés las tools, las instrucciones y el grounding; la plataforma tiene el loop y la capa de seguridad. Esa división es todo el atractivo — y todo su límite. Cuando el trabajo encaja en el modelo de seguridad, es el camino más gobernado a un agente que sale; cuando no, esa es la señal para componer un agente externo y pasar la posta. La habilidad es saber qué trabajo tenés, no defender el instrumento. (Mirá gotchas de agentes para los modos de falla que un build nativo de la plataforma igual hereda, y el Style Guide de agentes para la vara que un agente pasa antes de salir.)

Related

Reference: