Hasta hace poco, armar un agente en Salesforce era un trabajo de clics dentro de cada org. Probar, versionar y llevar ese agente de un sandbox a producción tenía bastante de artesanal.
Con Agentforce DX, el agente pasa a ser un archivo de código que vive en su proyecto, se valida, se prueba y se despliega como cualquier otra metadata. Y en paralelo, Salesforce empezó a exigir un MFA resistente al phishing que cambia cómo entran los admins a sus orgs.
Los dos temas fueron protagonistas de una Clase de los Jueves de Vantegrate, el 11 de junio, con JuanMa, Esti, Josu y Fran. Acá tienen el recorrido completo, ordenado para que lo apliquen en su equipo.
Qué es Agentforce DX y por qué cambia el desarrollo de agentes
Agentforce DX es una extensión para Visual Studio Code, Cursor o el editor que usen, más un conjunto de comandos de la Salesforce CLI. Su promesa es simple: que desarrollar un agente se parezca a desarrollar en Apex o con Flows.
Agentforce DX transforma el desarrollo de agentes en Salesforce, permitiendo tratarlos como código para una gestión y despliegue más eficientes y controlados.
En la práctica, eso significa tres cosas. El agente queda escrito en texto legible, se puede probar localmente contra una org y se despliega con el mismo pipeline que el resto del proyecto.
Si recién empiezan a explorar agentes de IA, este enfoque les ahorra muchos dolores de cabeza al pasar de una demo a producción.
Cómo instalarlo
El primer paso es buscar la extensión oficial de Agentforce DX en el marketplace del editor. Fíjense que sea la publicada por Salesforce, porque hay varias con nombres parecidos.
La documentación oficial trae la guía paso a paso. Si su equipo trabaja con Salesforce para desarrolladores, probablemente ya tengan la CLI instalada y el proceso lleva pocos minutos.
Crear un proyecto con el Agent Project Template
Con la extensión lista, se crea un proyecto nuevo con la opción de proyecto con manifest. Ahí aparece una plantilla nueva: el Agent Project Template.
En la misma lista hay otras plantillas, como las de aplicaciones React para Experience Cloud.
Al crear el proyecto, Salesforce genera automáticamente la estructura que hace falta:
Bots, la definición del agente que ve la org.
Clases Apex y Flows, que suelen ser las acciones del agente.
GenAI Planner Bundle y GenAI Planner Templates.
Prompt templates, que ya existían antes.
AiAuthoringBundle, la metadata nueva y la más importante.
AiAuthoringBundle: la definición del agente
El AiAuthoringBundle es la definición completa del agente, y llegó junto con Agent Script. Antes, desplegar un agente entre entornos generaba muchas dudas y a veces obligaba a configurarlo a mano en cada org.
Como todo en Salesforce, viene acompañado de un XML para el despliegue. La plantilla trae además un agente de ejemplo que pueden usar como punto de partida o borrar.
El agente como código: qué hay adentro
Lo más llamativo es que el agente se puede leer como un documento. Es un archivo de texto estructurado, que cualquiera con algo de paciencia puede entender.
Arriba aparecen las instrucciones del sistema (el clásico "sos un agente que…"), el mensaje de bienvenida y la configuración. Después vienen las variables y el idioma en el que responde.
El router, el orquestador del agente
La pieza central es el router. Está en todos los agentes, sean de atención al cliente, de voz o para empleados.
El router decide qué camino tomar según lo que pide la persona. En la plantilla de ejemplo puede consultar el clima, eventos o hoteles, derivar a un tema fuera de alcance o pedir aclaración ante una consulta ambigua.
Topics que ahora se llaman subagentes
Lo que antes conocían como topics ahora se llaman subagentes. Salesforce los renombró en su evento TDX, pero el concepto es el mismo.
Cada subagente tiene una descripción, sus instrucciones y sus acciones. Hay uno que viene por defecto: la escalación a un humano, que puede apuntar a un Flow que rutee por Omni-Channel hacia quien esté disponible.
Acciones deterministas en Apex, Flow o Prompt Template
El ejemplo del clima muestra bien la idea. La instrucción le dice al agente que, si alguien pregunta por el clima, use la acción de clima y no invente una respuesta.
Esa acción puede ser una clase Apex, un Flow o un Prompt Template. Así se combina el criterio del modelo de lenguaje con lógica de negocio predecible.
Probar el agente: simulación y Live Test
Antes de probar hay que autenticarse contra una org desde el editor, con el login de siempre en el navegador. Después, desde la paleta de comandos aparecen las acciones nuevas: preview, validate, publish y abrir el agente en la org.
El preview ofrece dos modos, y conviene entender bien la diferencia:
Simulación: el agente corre localmente desde el proyecto contra la org, pero todo cambio de datos se revierte. Es como ejecutar un Flow con rollback.
Live Test: el agente trabaja con datos reales y puede crear o modificar registros.
En la clase, Esti probó el Live Test con un agente que todavía no estaba desplegado y, como era de esperar, falló. La regla práctica: lo local se prueba en simulación y el modo en vivo queda para agentes ya publicados.
Agent Tracer: ver cómo razona el agente
Con la simulación corriendo, el Agent Tracer muestra cada paso: el mensaje de entrada, la decisión del router, las herramientas que activó y el motor de razonamiento. Ahí se ve, por ejemplo, que detectó una pregunta sobre el clima y eligió el subagente correcto.
Es mucha información, pero vale oro para refinar. Si necesitan el detalle completo, la opción de abrir el JSON muestra todo en crudo.
Además, queda un historial de simulaciones. Sirve para ajustar el agente hasta que haga exactamente lo que esperan.
Validar y publicar sin sorpresas
Como el agente es código, una coma fuera de lugar puede romperlo. Por eso el comando validate es el primer paso antes de cualquier despliegue.
En la demo, la validación pasó, pero la publicación falló: el agente llamaba a una clase Apex de clima que no existía en la org.
La lección es valiosa: validar revisa la sintaxis, no las dependencias. Antes de publicar, asegúrense de que cada Apex, Flow o Prompt Template que usa el agente esté desplegado en el destino.
Con un agente real, que usaba Apex y Flows existentes, la publicación funcionó. Salesforce generó una nueva versión del agente, visible tanto en el proyecto como en la org.
Del editor al pipeline de DevOps
Publicar se puede hacer con clic derecho, desde la paleta o desde la Salesforce CLI. Esa última opción es la que abre la puerta a los pipelines.
Por detrás, el proceso siempre es el mismo: validar el agente y después publicarlo. Por eso pueden integrarlo a herramientas como Gearset o Copado, igual que el resto de su metadata.
Para equipos que mantienen varias orgs, esto es un cambio enorme. El agente deja de ser una configuración frágil y pasa a tener versiones, revisiones y despliegues repetibles.
Tests de agentes
El paso siguiente es testear agentes de forma automatizada. La idea es definir casos del estilo "cuando el usuario pregunte esto, el agente tiene que responder aquello", y guardarlos como se guardan los tests de Apex o de Flows.
Hoy eso se resuelve con comandos de terminal y con el Testing Center en el setup. En la clase quedó para profundizar en otra sesión.
Skills oficiales de Salesforce para trabajar con su LLM
Uno de los momentos más prácticos fue el de las skills. Una skill es, básicamente, un archivo de instrucciones grande con algunos recursos de ejemplo, que le explica a su asistente de código cómo trabajar con algo específico.
Salesforce publicó un kit oficial con skills para Agentforce DX. Entre ellas están Developing Agentforce y Testing Agentforce, pensadas para desarrollar y testear agentes.
El kit no se limita a agentes. También trae skills para Data Cloud, OmniStudio, mobile, branding e integraciones, muy útil si trabajan con MuleSoft.
Cómo se instalan
Se instalan con un comando en la terminal, que muestra la lista para elegir con la barra espaciadora. Después pregunta para qué asistente las quieren (Claude Code, Cursor, OpenCode o Antigravity, entre otros) y si van a valer para todos sus proyectos o solo para el actual.
Las skills se pueden editar y adaptar a las reglas de su equipo. Un ejemplo clásico para Apex: recordarle al asistente que no envíe emails dentro de un ciclo.
Los recursos incluidos muestran cómo debería verse un Apex bien hecho, cómo usar un Flow dentro del agente o cómo resolver una escalación. Con eso, su asistente deja de improvisar y empieza a seguir las buenas prácticas de la plataforma.
¿Por qué Agentforce y no otra IA?
Desde el chat llegó una pregunta muy honesta: ¿no es más complicado implementar Agentforce que configurar otra IA de uso público? El equipo respondió con los mismos argumentos que usa con clientes.
Seguridad y datos ya resueltos
El primer punto es el Einstein Trust Layer, que enmascara los datos que el agente procesa, junto con la política de retención cero. Con otras herramientas, toda esa capa de seguridad y el acceso a los datos del CRM hay que construirlos desde cero.
Si este tema les preocupa, vale la pena revisar cómo encaran la seguridad de la plataforma y la transparencia de datos quienes implementan IA en serio.
Determinismo y contexto de negocio
El segundo argumento es el determinismo. Agentforce mezcla el criterio del modelo con acciones en código y Flows, y eso le da previsibilidad donde más importa.
El tercero es que ya están parados sobre Salesforce. Objetos, Flows, layouts y procesos existentes se reutilizan, en lugar de montar un backend aparte.
Observabilidad y el auto de Fórmula 1
Fran lo explicó con una imagen: lo que se ve en una demo técnica es cómo se arma el auto de Fórmula 1. Una vez configurado, desarrollar se parece mucho a escribir buenos prompts.
También contaron el caso de un equipo que dudaba de su elección porque una API tardaba muchos segundos en responder. Justamente, la visibilidad de cuánto tarda cada paso la estaban obteniendo con las herramientas de Agentforce.
Ahora bien, no es para todos. Si una empresa no usa Salesforce y tiene todo montado en otro CRM, migrar solo por la IA probablemente no tenga sentido; para quienes ya están en la plataforma, conviene conocer las opciones de Salesforce y los planes y precios antes de decidir.
MFA resistente al phishing: el cambio que puede dejarlos afuera
La segunda parte de la clase fue la más picante. Salesforce empezó a exigir MFA resistente al phishing para los usuarios privilegiados, y el código de la app autenticadora deja de alcanzar.
Salesforce actualiza sus requisitos de MFA, exigiendo métodos resistentes a phishing que cambian el acceso a las orgs y requieren preparación.
El motivo oficial es la ola de ataques de phishing. Fran sumó su sospecha: también apunta a la costumbre de compartir un mismo usuario admin entre varias personas.
A quiénes afecta
Se consideran usuarios privilegiados quienes tengan, en su perfil o en un permission set, alguno de estos permisos:
View All Data.
Modify All Data.
Customize Application.
Author Apex.
Ojo con un detalle que surgió en vivo. Se trata de los permisos a nivel sistema, no del "ver todo" sobre un objeto puntual.
El cronograma anunciado
Según lo que repasaron en la clase, el cambio llega primero a los sandboxes y después a producción, en etapas. Conviene revisar la comunicación oficial de Salesforce para confirmar en qué etapa está cada org.
Como estos calendarios pueden moverse, revisen siempre la comunicación oficial de Salesforce para su org. Lo importante es no enterarse el día que alguien no puede entrar.
Si no saben por dónde empezar, nuestro equipo ayuda a preparar orgs para cambios como este.
Qué es una passkey
Una passkey es una clave criptográfica guardada en un dispositivo o en un gestor de claves. Funciona con desbloqueo facial, huella, Windows Hello o Face ID, y no se puede robar con un mail falso.
El MFA tradicional usaba un código o una notificación push del autenticador. Ese código se podía dictar o reenviar, y ahí estaba el agujero.
Compartir una passkey en un vault de equipo
Muchas empresas de la región no pagan una licencia por cada persona que despliega a producción. Para ese escenario, el equipo probó una solución que funcionó: guardar la passkey en el vault de equipo de Bitwarden.
Cada persona tiene su propio usuario en ese vault. Al iniciar sesión en Salesforce, la extensión del navegador ofrece usar la passkey guardada, y como queda en el vault y no en un equipo físico, se puede compartir.
En la clase comentaron que el plan de equipo costaba unos 4 dólares por usuario por mes, el más barato que encontraron. Otras opciones, como 1Password, resultaron más caras.
Si trabajan en rubros regulados, como servicios financieros o salud, validen esta práctica con su área de seguridad. Lo ideal sigue siendo un usuario por persona, con su propia passkey.
Cómo prepararse desde hoy
Un plan corto para no quedar trabados:
Listen quiénes tienen permisos privilegiados en cada org, incluidos los permission sets.
Configuren passkeys para esos usuarios primero en sandbox y después en producción.
Instalen la extensión de Agentforce DX y creen un proyecto de prueba con la plantilla de agentes.
Sumen las skills oficiales a su asistente de código y prueben en simulación antes de publicar.
Si quieren seguir aprendiendo, en Vantegrate Pulse publicamos guías de cada Masterclass y en recursos hay material descargable. Y si prefieren que los acompañemos con Agentforce, DevOps o la migración del login, pueden agendar una demo.
Preguntas frecuentes
¿Qué es Agentforce DX?
Es una extensión para Visual Studio Code y otros editores, junto con comandos de la Salesforce CLI, que permite desarrollar agentes de Agentforce como código. Con ella pueden crear, probar en simulación, validar y publicar agentes desde su proyecto.
¿Qué diferencia hay entre el modo simulación y el Live Test?
En simulación, el agente corre contra la org pero revierte cualquier cambio de datos. En Live Test trabaja con datos reales y requiere que el agente ya esté publicado.
¿Se pueden desplegar agentes con Gearset o Copado?
Sí, porque la publicación también se hace desde la Salesforce CLI. El pipeline valida el agente y después lo publica, igual que con el resto de la metadata.
¿Quiénes necesitan MFA resistente al phishing en Salesforce?
Los usuarios privilegiados: admins y quienes tengan View All Data, Modify All Data, Customize Application o Author Apex. Para ellos deja de alcanzar el código del autenticador y pasan a necesitar una passkey o un método equivalente.
¿Se puede compartir una passkey entre varias personas?
Técnicamente sí, guardándola en el vault de equipo de un gestor de claves como Bitwarden. Igual conviene evaluarlo con el área de seguridad, porque la práctica recomendada es un usuario por persona.
