Microsoft explica cómo desarrolló Copilot Cowork con agentes y controles humanos

Microsoft atribuye el ritmo de desarrollo de Copilot Cowork a tareas definidas con especificaciones, agentes trabajando en paralelo y controles humanos. El 21 de octubre de 2026, nueve ingenieros integraron 1.211 pull requests en la rama principal del backend, según el relato técnico de Microsoft. El recuento mide cambios integrados ese día; la empresa también comunicó 4.581 pull requests durante la semana del 12 de octubre, una cifra con un periodo distinto.

Cómo acotó Microsoft el trabajo de los agentes

Antes de escribir código, cada tarea debía tener una especificación en Markdown que describiera qué debía hacer el cambio, cómo comprobar el resultado y qué no debía romper. Los agentes podían preparar un primer borrador a partir de una descripción oral, pero una persona lo revisaba. Para trabajar en paralelo, cada agente recibía una copia independiente del repositorio y una tarea vinculada a una especificación.

Microsoft también describe una separación entre el agente y las operaciones de Microsoft 365: el modelo se ejecutaba en un contenedor sin credenciales de usuario, mientras un host de confianza gestionaba la identidad, las políticas, las aprobaciones, la ejecución de herramientas y el registro de actividad. Todas las operaciones de Microsoft 365 pasaban por ese host.

La revisión automática servía como primer filtro, pero Microsoft mantuvo la revisión humana para los cambios críticos. En un caso sensible, los agentes revisores pasaron por alto cuatro problemas que después detectaron las personas. El equipo también pidió que cada comprobación indicara cuántos archivos había examinado y que las nuevas comprobaciones incluyeran una prueba deliberadamente fallida. Así podía detectar controles que parecían correctos aunque no estuvieran poniendo a prueba el código de forma efectiva.

Cómo comprobó el comportamiento al migrar de Python a Rust

Para comparar las dos implementaciones, el equipo ejecutó Python con entradas definidas y guardó sus salidas en archivos JSON. Después, las pruebas de Rust reproducían esos resultados. Microsoft informa de unas 430 fixtures de este tipo; una prueba comprobaba además el número de casos antes de reproducirlos, para que un archivo vacío no pudiera dar un resultado satisfactorio.

La primera tanda de fixtures no recogió un comportamiento implícito: Python entregaba ciertos eventos en un orden concreto, aunque ese requisito no estuviera especificado. La primera versión en Rust no conservó ese orden. Microsoft dice que corrigió el problema; también afirma que ajustó una primera recepción de mensajes en Rust que tardaba unas seis veces más porque esperaba a que terminara toda la recogida.

La migración se hizo por etapas. Microsoft sitúa el primer intento de cambio, que se revirtió, el 23 de septiembre de 2026; Rust atendió turnos de producción al día siguiente y el último clúster pasó al nuevo entorno el 10 de octubre.

Qué indican las cifras de latencia

En una comparación de 12 horas de finales de septiembre, Microsoft registró el tiempo hasta el primer token del primer turno en un clúster Python y otro Rust. El p50 es la mediana; el p90 es el valor que alcanzó o quedó por debajo el 90 % de las observaciones.

Microsoft dice que el bucle del agente también se trasladó fuera del contenedor y que ese cambio contribuyó de forma importante a las cifras de Rust. La comparación, por tanto, refleja una migración con cambios de arquitectura además del cambio de lenguaje. La empresa informó asimismo de pausas del bucle de eventos de Python de hasta 11,9 segundos bajo carga y de que el 16,7 % de las configuraciones de sesión alcanzaba exactamente los 5 segundos cuando se activaba un tiempo de espera. También comunicó 539 finalizaciones forzadas de procesos Python en una semana en un clúster.

Microsoft afirma que las pausas y los casos de tiempo de espera desaparecieron tras la migración. La empresa dice que no ha medido adecuadamente el coste por turno y no atribuye a la migración una reducción de costes.

Qué dudas plantea su uso en flujos de programación

Un usuario de Power Platform contó que un agente de Copilot Studio le ayudaba a preparar Logic Apps con ejemplos e instrucciones del proyecto, pero que después tenía que copiar manualmente el resultado final. En otra conversación, usuarios discreparon sobre cuánto aporta Cowork frente a tareas que, en su opinión, ya puede resolver Copilot con una instrucción sencilla. Algunos describieron el interés de encadenar trabajo entre documentos y correo; son experiencias y valoraciones individuales, no una comparación técnica del producto.