Qué pasa al publicar un agente de Copilot Studio
· AI Agents · 8 min de lectura
By Juan Pedro Márquez
Publicar un agente de Copilot Studio no es desplegarlo. Es empujar el contenido actual a todos los canales conectados a la vez, sin versiones por canal, sin grupo piloto y sin botón de vuelta atrás. Y en Teams el usuario puede seguir viendo la versión antigua hasta una hora después.
Esa última frase explica la mitad de las incidencias que llegan los lunes.
Un compañero publica una corrección, la prueba en Teams dos minutos después, ve la respuesta vieja y vuelve a publicar. Y otra vez. Al final de la mañana hay cinco publicaciones y nadie sabe cuál está viva ni qué cambió en cada una.
No estaba roto el agente. Estaba viva la sesión.
¿Qué hace exactamente el botón Publicar?
Toma el estado de autoría del agente —temas, herramientas, conocimiento, configuración— y lo convierte en la versión activa en todos los canales conectados de forma simultánea. La documentación lo dice sin matices: la publicación se aplica a todos los canales asociados al agente.
Lo que ocurre al confirmar:
- El contenido publicado pasa a servirse en las sesiones nuevas de cada canal.
- Se aplica cualquier cambio pendiente de autenticación. Los cambios de autenticación solo surten efecto al publicar.
- El estado y los códigos de error quedan en la propia página de publicación.
Lo que no ocurre:
- Las conversaciones en curso no se cortan ni se migran.
- No hay una versión anterior a la que volver desde esa pantalla.
- No existe "publicar solo en Teams".
Publicar es una difusión, no un despliegue
Mi opinión, y es la que defiendo en cada reunión de plataforma: el botón Publicar no puede ser tu control de versiones. Es una sincronización de contenido con efecto inmediato en producción. Si lo único que separa un tema sin probar de todos tus usuarios es quién tiene permiso para pulsarlo, no tienes proceso de entrega: tienes un botón compartido.
La barrera va en la frontera del entorno. Lo desarrollo más abajo.
¿Por qué el usuario sigue viendo la versión antigua?
Porque el contenido publicado solo llega cuando empieza una sesión nueva. En la mayoría de canales la sesión termina tras 30 minutos de inactividad, así que quien ya estaba conversando sigue con la versión con la que empezó. En canales de conversación persistente —Microsoft Teams, Omnicanal para Customer Service— puede tardar hasta una hora.
Hay un atajo poco conocido: escribir start over en la conversación reinicia la sesión y coge el contenido recién publicado.
Ponlo en tu guion de pruebas. Convierte una hora de dudas en una comprobación de cinco segundos, y corta en seco el bucle de republicaciones que describía al principio. Cada publicación redundante es un cambio más que luego nadie sabe atribuir.
Un matiz importante: ese retardo no es una caché que puedas vaciar a nivel de tenant. Es por conversación. "Publicado y verificado" solo significa algo si lo verificaste en una sesión nueva.
¿Qué se rompe la primera vez que publicas en Teams?
La autenticación, casi siempre. Los agentes se crean con Autenticar con Microsoft activado, que configura Microsoft Entra ID para Teams, Power Apps y Microsoft 365 Copilot sin trabajo manual. El problema aparece cuando alguien lo cambia por una razón que tenía sentido la primera semana.
Tres patrones que se repiten:
"No requiere autenticación" para desbloquear una demo. Esa opción permite conversar con el agente a cualquiera que tenga el enlace, y además impide que el agente use herramientas que requieren credenciales del usuario. La demo funciona; el caso de uso real deja de funcionar en silencio. Los dos síntomas aparecen con una semana de diferencia.
El cambio guardado pero no publicado. La configuración de autenticación no se aplica hasta que publicas. Es el origen más habitual del clásico "en el panel de pruebas funciona, en Teams no".
Cambiar de modo de autenticación con temas ya escritos. Si tus temas usan User.AccessToken o User.IsLoggedIn y pasas a Autenticar con Microsoft, esas variables quedan como desconocidas y los temas dan error hasta que los corriges. Esta decisión se toma antes de la primera publicación, no después del piloto.
En el canal de Teams y Microsoft 365 la elección de autenticación es la que abre o cierra la puerta. Conviene tratarla como una decisión de arquitectura, no como un ajuste.
¿Qué puede bloquear tu administrador antes de que publiques?
Más de lo que espera la mayoría de creadores. El administrador puede controlar qué canales están disponibles para los agentes desde los canales de acceso en el centro de administración de Power Platform. Un canal que existe en el producto puede no existir en tu entorno.
Las directivas de datos hacen algo parecido: si una directiva exige autenticación, la opción "sin autenticación" desaparece de la configuración de seguridad del agente. Es un buen control. También es una sorpresa para quien sigue un tutorial público que da por hecho que la opción está ahí.
Y el sitio de demostración no es un canal de producción. Existe para que tú y tus interlocutores probéis el agente antes que nadie. Compártelo con tu equipo, nunca en un correo a cliente.
¿Cómo se construye una puerta de entrega real?
Con entornos, soluciones y canalizaciones, que es donde Power Platform guarda su modelo de promoción de verdad. El patrón es poco vistoso y funciona:
- Un entorno por etapa. Desarrollo, pruebas y producción separados, con permiso de publicación solo en los dos primeros. Dentro de un entorno, publicar no tiene control: haz del entorno la frontera.
- Agente dentro de una solución. Así se mueve entre entornos como una unidad, con sus dependencias, en vez de rehacerse a mano.
- Promoción con canalizaciones. Aquí está el paso auditable con aprobación que Publicar no es.
- Publicar al final, en producción y a conciencia.
Es la misma disciplina que desarrollé en Copilot Studio en producción: entornos, soluciones y pipelines. Cuesta montarlo. También es la diferencia entre un cambio que puedes explicar y uno por el que solo puedes pedir disculpas.
Dos controles que no me saltaría:
- Compartir no es publicar. Publicar pone el agente en vivo; compartir decide quién lo encuentra. Publica primero para ti, verifica, y luego ábrelo.
- Cada canal nuevo amplía el consumo. Y el consumo es la factura. Lo conté en el coste oculto de los agentes de Copilot Studio.
¿Qué revisar en la primera hora?
Cuatro cosas, en este orden.
Si la publicación terminó bien. Los fallos traen código de error y casi siempre apuntan a una dependencia que existe en desarrollo y no en el destino: un flujo, un conector, una fuente de conocimiento.
Si una sesión nueva trae el comportamiento nuevo. Abre conversación nueva o escribe start over. Nunca valides en la ventana que tenías abierta mientras editabas.
Si la autenticación se comporta en el canal real. Prueba en Teams, no solo en el panel de pruebas.
Si los números se mueven como esperabas. La analítica de Copilot Studio muestra interacción, resolución y escalados. Una publicación que rompió un tema suele verse antes como un pico de escalados que como un ticket.
Si el agente toca datos sensibles, la revisión de seguridad y gobernanza va antes de publicar. Mi checklist está en seguridad de agentes en Copilot Studio.
Preguntas frecuentes
¿Publicar afecta a todos los canales a la vez?
Sí. La publicación se aplica a todos los canales conectados al agente y todos se actualizan juntos. No se puede publicar en uno y retener otro. Si necesitas exposición por fases, sepárala con entornos y promociona entre ellos.
¿Cuánto tarda un cambio publicado en llegar al usuario?
Las sesiones nuevas lo reciben de inmediato. Las que ya estaban abiertas mantienen la versión anterior hasta que terminan, normalmente tras 30 minutos de inactividad. En canales persistentes como Teams puede tardar hasta una hora, salvo que el usuario escriba start over.
¿Se puede deshacer una publicación en Copilot Studio?
No desde la página de publicación: no hay vuelta atrás en un clic. Recuperar significa restaurar el contenido anterior desde una exportación de solución o una etapa de la canalización y volver a publicar. Por eso aquí las soluciones y las canalizaciones importan más que en otras cargas de Power Platform.
¿Publicar y desplegar son lo mismo?
No, y confundirlos es el origen de la mayoría de incidencias de entrega. Publicar sincroniza contenido a los canales en vivo dentro de un entorno. Desplegar mueve un agente probado entre entornos. Necesitas los dos, y solo uno es un botón.
En corto
Publicar es una sincronización con efecto en producción y sin red. Llega a todos los canales, surte efecto en la siguiente sesión y no se deshace desde la pantalla donde lo pulsaste.
Monta la puerta alrededor —entornos, soluciones, canalizaciones— y publicar se convierte en un último paso aburrido. Sáltatela y ese botón será lo único que separe un tema sin probar de todos tus usuarios.