Salesforce Summer '26 lanza la orquestación multi-agente el 15 de junio. La auditoría de Sales Ops antes de que sus agentes empiecen a hacer handoffs

El 15 de junio está a dos semanas de distancia, y la funcionalidad más importante para los equipos de Sales Ops no es un nuevo Dashboard ni un forecast más inteligente. Es un nuevo problema de gobernanza.

La versión Summer '26 de Salesforce pasa a disponibilidad general (GA) el 15 de junio de 2026, y el titular para Sales Ops es la orquestación multi-agente dentro de Agentforce: la capacidad de encadenar múltiples agentes para que se pasen el trabajo entre sí a lo largo de todo un flujo de trabajo de ingresos. Junto con Slack First Sales, que muestra el contexto del CRM de forma conversacional dentro de Slack para que los representantes actúen donde ya trabajan, esta versión cambia lo que significa gobernar un proceso de ingresos habilitado por IA.

El cambio no es menor. Con despliegues de un solo agente, su trabajo de gobernanza implicaba un único agente: qué lee, qué escribe, qué lo activa. La orquestación multi-agente significa que sus agentes ahora se pasan el trabajo entre sí, y cada uno de esos handoffs es un punto donde el pipeline puede tener fugas, entrar en bucles o desviarse sin que ningún ser humano lo note. Los datos del State of Sales 2026 de Salesforce dejan claro que esto importa a escala: casi nueve de cada diez vendedores planean usar agentes de IA para 2027, y se espera que los agentes de IA reduzcan el tiempo de investigación en un 34%. Eso supone muchos agentes tocando muchos negocios. Si el grafo de handoffs está mal diseñado antes del 15 de junio, pasará la segunda mitad del año desenredando leads fantasma.

Qué se lanza realmente el 15 de junio

Datos clave

• Fecha GA de Summer '26: 15 de junio de 2026 (fuente: Salesforce Newsroom)
• Vendedores que planean usar agentes de IA para 2027: casi 9 de cada 10 (fuente: Salesforce State of Sales 2026)
• Reducción esperada en tiempo de investigación gracias a agentes de IA: 34% (fuente: Salesforce State of Sales 2026)

La orquestación multi-agente es el cambio central: los agentes individuales de Agentforce ahora pueden conectarse en una secuencia donde el output de cada agente se convierte en el input del siguiente. Un agente de investigación puede completar la inteligencia de un prospecto y pasarla a un agente de prospección. El agente de prospección puntúa el engagement y lo pasa a un agente de calificación. El agente de calificación toma una decisión de etapa y lo pasa a un agente de actualización de CRM. El agente de actualización de CRM escribe los campos y lo pasa a un agente de forecasting. Son cinco agentes tocando un mismo negocio, sin que haya un ser humano en el proceso para los pasos intermedios.

Slack First Sales se lanza junto a esto. Los datos del CRM aparecen dentro de los hilos de Slack en formato conversacional, para que los representantes respondan a las notificaciones sobre negocios sin salir de Slack. Los agentes escriben los resultados de esas interacciones de vuelta en Salesforce automáticamente. Para los equipos que ya viven en Slack, esto es genuinamente útil. Pero introduce una segunda pregunta de gobernanza: ¿quién es dueño del registro de auditoría cuando la respuesta de un representante en Slack activa una escritura de agente en Salesforce?

El resto de Summer '26 incluye actualizaciones en Einstein, Data Cloud y las nubes de industria. Este artículo trata exclusivamente sobre la capa de orquestación y el handoff de Slack. Las actualizaciones del agente de engagement de clientes de Summer '26 se cubrieron por separado para la evaluación a nivel de CRO.

Por qué la orquestación multi-agente cambia el trabajo de Sales Ops

Antes de la orquestación, su lista de verificación de gobernanza de Agentforce tenía más o menos una sola fila: un agente, sus permisos de lectura, sus permisos de escritura, sus condiciones de activación, su estado de error.

Después de la orquestación, esa fila única se convierte en un grafo. Y el grafo es la nueva superficie de gobernanza.

Piense en cómo se ve realmente un flujo de trabajo de ingresos de cinco agentes cuando se ejecuta. El agente de investigación consulta fuentes de datos externas y escribe un objeto de inteligencia de prospecto. Activa el agente de prospección cuando una puntuación de confianza supera un valor establecido. El agente de prospección genera una secuencia de mensajes y escribe campos de estado de engagement. Activa el agente de calificación cuando un prospecto abre un número específico de touchpoints. El agente de calificación evalúa los criterios de etapa y escribe el campo de etapa de la oportunidad. Activa el agente de actualización de CRM cuando los criterios se cumplen. El agente de actualización de CRM escribe campos del negocio en el registro de oportunidad. Activa el agente de forecasting al cierre de semana. El agente de forecasting actualiza las categorías de commit.

Eso son ocho eventos de handoff distintos entre cinco agentes, cada uno tocando diferentes objetos y campos del CRM. Si cualquiera de esos handoffs falla, el registro aguas abajo es incorrecto. Y como ningún ser humano aprobó los pasos intermedios, los datos incorrectos se multiplican antes de que alguien los vea en un informe.

Por eso su trabajo como Sales Ops pasa de "configurar un agente" a "ser dueño del grafo de handoffs". El grafo es donde vive ahora la gobernanza del proceso de ingresos. Si no lo diseña deliberadamente antes del 15 de junio, el comportamiento predeterminado entra en producción y usted hereda lo que las condiciones de activación de Salesforce out-of-the-box produzcan en su entorno de datos específico.

Para un contexto más profundo sobre cómo funciona la gobernanza de AI Sales Ops y los registros de auditoría en el stack de AI Sales Ops más amplio, ese framework aplica directamente aquí: la orquestación hace los requisitos del registro de auditoría más complejos, no menos.

Los tres modos de fallo de handoff que Sales Ops debe bloquear

Handoffs fantasma

Un handoff fantasma ocurre cuando el Agente A marca el trabajo como transferido, pero el Agente B nunca lo procesa. El lead queda en un estado muerto entre las colas de dos agentes. Ninguno de los agentes genera un error. No se activa ninguna alerta. La oportunidad simplemente deja de avanzar.

Este es el modo de fallo más común en cualquier sistema basado en colas, y la orquestación multi-agente agrega una nueva versión de este problema. La verificación de auditoría: para cada handoff en su grafo, confirme que existe un evento de acuse de recibo explícito por parte del agente receptor, no solo un estado de "enviado" del agente originador. Si no puede verificar el acuse de recibo, no puede verificar que el handoff se completó.

Bucles trampa

Un bucle trampa ocurre cuando el Agente B no cumple la condición para avanzar y devuelve el trabajo al Agente A. El Agente A lo reevalúa, no cumple su propia condición de salida, y lo devuelve al Agente B. El lead orbita entre dos agentes hasta que se activa un tiempo de espera o un ser humano revisa la cola.

El ejemplo concreto: un agente de calificación que requiere una puntuación MEDDIC por encima de un umbral para avanzar un negocio, combinado con un agente de investigación que se vuelve a ejecutar cuando la calificación devuelve datos incompletos. Si el agente de investigación no puede encontrar los datos que el agente de calificación necesita, entran en bucle. La verificación de auditoría: cada ruta de handoff necesita una salida definida para el estado "sin avance": ya sea un número máximo de reintentos, un estado de reserva (como la cola de revisión humana) o un estado de error explícito que aparezca en un informe.

Deriva de autoridad

La deriva de autoridad es la menos obvia y la más peligrosa. Ocurre cuando un agente escribe en campos que no estaba diseñado para gestionar porque la capa de orquestación no aplica permisos de escritura por agente.

Así es como sucede. Su agente de actualización de CRM está diseñado para escribir el monto de la oportunidad y la fecha de cierre. Pero durante la configuración de la orquestación, alguien le da acceso de escritura amplio porque era más fácil configurarlo una sola vez que delimitar campo por campo. El agente de calificación aguas abajo detecta una discrepancia y escribe una corrección en los mismos campos. Ahora dos agentes están escribiendo en los mismos campos de oportunidad, cada uno con una lógica diferente, y el historial del campo muestra una secuencia de actualizaciones que ningún ser humano realizó intencionalmente.

La verificación de auditoría: cada agente en el grafo de orquestación necesita un alcance de escritura de campos documentado. Ese alcance debe aplicarse a nivel de permisos, no solo como una convención de configuración. Verifique ahora si su configuración actual de Agentforce aplica permisos de objetos por agente o si la capa de orquestación hereda el conjunto de permisos de agente a nivel de organización.

El framework Hand-Off Triplet

Para cada handoff de agente a agente en su grafo de orquestación, documente tres elementos. Este es el Hand-Off Triplet.

Condición de activación. ¿Qué evento específico, valor de campo o umbral hace que el Agente A pase el trabajo al Agente B? Sea preciso: "cuando la puntuación del lead supera 75" es una condición de activación. "Cuando el agente decide que está listo" no lo es.

Autoridad de escritura de campos. ¿Qué campos del CRM puede escribir el Agente A antes del handoff? ¿Qué campos puede escribir el Agente B después de recibirlo? Estas listas no deben superponerse. Si lo hacen, decida qué agente tiene precedencia y documéntelo explícitamente.

Ruta de reversión. Si el Agente B falla después de recibir el handoff, ¿qué ocurre con el registro? ¿Persiste la última escritura del Agente A? ¿La oportunidad se queda en la etapa que el Agente A estableció? ¿Existe una cola donde los errores aparecen para revisión humana, o se registran de forma silenciosa?

A continuación, un ejemplo. El handoff entre el agente de calificación y el agente de actualización de CRM en un flujo de trabajo estándar de Agentforce:

• Condición de activación: el agente de calificación establece Etapa = "SQL" (lead calificado por ventas) y puntuación MEDDIC >= 80
• Autoridad de escritura de campos: el agente de calificación escribe solo los campos Etapa y Puntuación MEDDIC. El agente de actualización de CRM escribe solo los campos Monto, Fecha de cierre y Categoría de forecast. Sin superposición.
• Ruta de reversión: si el agente de actualización de CRM falla, los campos Etapa y Puntuación MEDDIC conservan sus últimos valores del agente de calificación. Se activa un evento de error en la cola de revisión de Sales Ops en Salesforce. El negocio se marca con el estado "Error de agente: revisión manual".

Sin la ruta de reversión, un error en el agente de actualización de CRM deja un negocio en etapa SQL para siempre, sin fecha de cierre, sin monto y sin ninguna señal de que algo salió mal. Ese negocio aparecerá en los informes de cobertura del pipeline, inflará los números del forecast y, finalmente, será detectado en una revisión de pipeline, tres semanas después, por un gerente que se pregunta por qué el negocio se enfrió.

Para los equipos que están rediseñando sus etapas del pipeline para acomodar la progresión impulsada por agentes, vale la pena revisar el framework de diseño de etapas del pipeline antes del 15 de junio: los criterios de salida del agente deben coincidir con la lógica de etapas en la que sus representantes y gerentes ya confían.

Slack First Sales: la segunda auditoría

Slack First Sales crea una segunda categoría de handoff: la ruta de escritura del representante al agente que se ejecuta a través de Slack. Cuando un representante responde a una notificación de negocio en Slack y un agente interpreta esa respuesta y escribe de vuelta en Salesforce, tres preguntas necesitan respuesta antes del 15 de junio.

• ¿Quién es dueño de la escritura del campo? Cuando un agente escribe en un registro de oportunidad basándose en una respuesta de Slack, ¿esa escritura aparece bajo el perfil del agente o del representante? Esto importa para los registros de auditoría y para la atribución en disputas de comisiones.
• ¿Dónde está el límite de permisos? El agente que escribe en Salesforce desde una interacción de Slack necesita el mismo nivel de restricción en la escritura de campos que cualquier otro agente en su grafo de orquestación. Confirme que la ruta activada por Slack sigue el mismo modelo de permisos que sus agentes configurados directamente, no una ruta separada con menos restricciones.
• ¿Se registra la interacción? Los mensajes de Slack no son registros de actividad de Salesforce de forma predeterminada. Si la respuesta de Slack de un representante se convierte en la base para que un agente escriba un cambio de etapa, ese mensaje de Slack es el registro de evidencia para ese cambio. Confirme que su sincronización de actividad de Slack a Salesforce está activa antes del 15 de junio, o tendrá escrituras en el CRM sin ninguna justificación legible por humanos.

Para los equipos que están pensando en el diseño del modelo de datos del CRM considerando las escrituras impulsadas por agentes, la pregunta de la propiedad de los campos se vuelve más urgente cuando los agentes, y no los representantes, son los principales escritores en los campos clave de oportunidad.

La auditoría de 5 preguntas antes del 15 de junio

Incluya estas cinco preguntas en su calendario para esta semana. Reserve dos horas, abra su configuración de Agentforce y trabaje en cada una.

1. ¿Tiene una lista documentada de cada handoff de agente a agente en su configuración actual de Agentforce? Si no es así, mapéelos ahora. No puede auditar lo que no ha nombrado.
2. Para cada handoff, ¿puede enunciar la condición de activación con precisión? Los activadores vagos producen comportamientos inconsistentes. Si su respuesta incluye la palabra "aproximadamente" o "cuando parece estar listo", defínala con más precisión.
3. ¿Cada agente tiene un alcance de escritura de campos documentado, y ese alcance se aplica a nivel de permisos? Las convenciones de configuración se deterioran con el tiempo. La aplicación de permisos no.
4. ¿Cada handoff tiene una ruta de reversión definida para el estado de error? Recorra el escenario de fallo para cada handoff: ¿cómo queda el registro si el agente receptor falla? ¿Es ese estado recuperable sin intervención manual?
5. Para cualquier interacción de Slack First Sales: ¿está activa su sincronización de actividad de Slack a Salesforce, y ha confirmado qué escrituras activadas por Slack aparecen bajo el perfil del agente frente al del representante? Ejecute una interacción de prueba antes del 15 de junio, no después.

Los equipos que han trabajado en los modos de fallo de la puntuación de leads con IA reconocerán el mismo patrón aquí: el fallo generalmente no es el modelo de IA, sino la capa de gobernanza que rodea lo que el modelo puede escribir y quién revisa los outputs. La orquestación amplía significativamente esa superficie.

Qué hacer esta semana

Tiene aproximadamente 13 días antes de que Summer '26 entre en producción. Esto es lo que más importa antes del 15 de junio.

Mapee el grafo. Liste cada agente en su organización de Agentforce y dibuje las conexiones de handoff entre ellos. Este es el Paso Cero. Nada más en la auditoría es posible sin esto.

Aplique el Hand-Off Triplet a cada conexión. Para cada handoff en el grafo, documente la condición de activación, la autoridad de escritura de campos en cada lado y la ruta de reversión. Tres columnas, una fila por handoff. Comience con los handoffs que tocan los campos de oportunidad más utilizados: Etapa, Monto, Fecha de cierre, Categoría de forecast.

Aplique los alcances de escritura de campos a nivel de permisos. No dependa de convenciones de configuración que dependen de que los administradores futuros sigan la intención no documentada del administrador actual. Si el Agente A no debe escribir el campo Monto, elimine ese permiso explícitamente.

Configure su cola de errores. Decida dónde aparecen los errores de los agentes y quién los revisa. Si hoy no tiene una cola de revisión de Sales Ops para errores de agentes, créela antes del 15 de junio, no después de haber detectado handoffs fantasma en los datos del pipeline.

Ejecute una interacción de prueba de Slack First Sales. Antes de que entre en producción para toda su organización, active una interacción de Slack manualmente, confirme que la escritura del campo aparece correctamente en Salesforce, verifique el registro de actividad y compruebe qué nombre de perfil aparece en la escritura.

Las prácticas de higiene del pipeline que mantienen limpios los datos del pipeline en un proceso impulsado por humanos importan el doble en uno impulsado por agentes. Los agentes no tienen excusas para los datos incorrectos: los amplían a escala. Establezca la gobernanza correctamente antes del 15 de junio, y la capa de orquestación se convierte en un activo genuino de Revenue Operations. Omita esta auditoría, y pasará el verano revisando informes de incidentes.

---

Preguntas frecuentes

¿Debemos deshabilitar la orquestación multi-agente el primer día?

No necesariamente. Pero sí necesita saber exactamente qué agentes en su organización están configurados para pasar el trabajo entre sí antes de que el 15 de junio entre en producción. Si no puede responder esa pregunta hoy, un enfoque conservador es deshabilitar la orquestación para sus campos de oportunidad más sensibles (Etapa, Monto, Fecha de cierre) hasta que haya completado la auditoría del Hand-Off Triplet. Puede volver a habilitarlos de forma incremental a medida que documente cada handoff correctamente.

¿Cuál es la diferencia entre la orquestación multi-agente y un Salesforce Flow?

Un Salesforce Flow es una automatización configurada que ejecuta pasos predefinidos basados en lógica explícita que usted escribe. La orquestación multi-agente es diferente: los agentes toman decisiones basadas en razonamiento sobre cuándo hacer el handoff y qué pasar. Los Flows son deterministas; los agentes orquestados no lo son. Por eso el Hand-Off Triplet importa: no puede leer la lógica de un Flow para entender lo que un agente decidió pasar. Necesita una condición de activación documentada para verificar que el comportamiento del agente coincide con su intención.

¿Dónde aparece Slack First Sales en nuestro registro de auditoría?

De forma predeterminada, los mensajes de Slack no son registros de actividad de Salesforce. Cuando la respuesta de Slack de un representante activa una escritura de agente en Salesforce, esa escritura aparecerá en el historial de campos del registro, pero el mensaje de Slack que la causó no aparecerá automáticamente como una actividad asociada. Necesita la sincronización de actividad de Slack a Salesforce habilitada y configurada para registrar las interacciones de Slack como actividades en el registro relevante. Confirme que esto está activo antes del 15 de junio, o tendrá entradas en el historial de campos sin ninguna justificación legible por humanos.