Nel resoconto tecnico pubblicato il 2 novembre, Microsoft riferisce che il 21 ottobre nove ingegneri hanno integrato 1.211 pull request nel ramo principale del backend di Copilot Cowork. La squadra descrive un processo basato su specifiche prima del codice, attività parallele affidate agli agenti e controlli umani, oltre al passaggio del runtime da Python a Rust.
Il conteggio del 21 ottobre
Per la settimana iniziata il 12 ottobre, Microsoft riferisce 4.581 pull request integrate nel ramo principale, circa 650 al giorno. Il dato del 21 ottobre riguarda invece una singola giornata e nove ingegneri del backend di Copilot Cowork.
Specifiche e confini per il lavoro degli agenti
Microsoft afferma che ogni modifica doveva partire da una specifica in Markdown: che cosa fare, come verificare il risultato e che cosa non doveva rompersi. Un agente poteva preparare una prima bozza partendo da una descrizione a voce, poi una persona la rivedeva. Gli agenti lavoravano in copie separate del repository, ciascuno su un’attività circoscritta. Il team riferisce di essere passato da un agente a cinque, poi a decine.
Nel modello descritto dall’azienda, l’agente girava in un contenitore senza credenziali utente. Le operazioni di Microsoft 365 passavano da un host fidato esterno al contenitore, che gestiva identità, criteri, approvazioni, strumenti e audit. Il modello poteva pianificare e chiedere un’azione; era l’host a decidere che cosa eseguire.
Verifiche automatiche e revisione umana
Gli agenti di revisione fornivano un primo controllo, ma il team manteneva la revisione umana per le modifiche critiche. In un caso sensibile, i revisori automatici non rilevarono quattro problemi bloccanti, individuati poi dalle persone prima dell’integrazione.
Per evitare che una verifica risultasse superata senza aver controllato davvero il codice, Microsoft introdusse due regole: ogni controllo doveva dichiarare quanti file aveva esaminato e ogni nuovo controllo doveva includere un test progettato per farlo fallire. In questo modo, il team poteva controllare anche il funzionamento dei propri controlli automatici.
Come il team ha confrontato Python e Rust
Microsoft riferisce di aver creato circa 430 fixture, cioè file JSON con risultati registrati eseguendo il codice Python su una serie di input. I test Rust riproducevano quei risultati per confrontare il comportamento dei due runtime.
Le prime fixture non rilevarono un comportamento implicito: Python consegnava alcuni eventi in ordine, ma quella regola non era stata inserita nei test. La prima versione Rust non rispettò l’ordine. Microsoft afferma che il team corresse il problema. Anche il primo componente d’ingresso Rust impiegava circa sei volte più tempo a confermare un nuovo messaggio, perché attendeva il completamento dell’intero prelievo; l’azienda dice di aver corretto anche questo problema.
La migrazione avvenne spostando il traffico un cluster alla volta. Microsoft riferisce che il primo tentativo interno del 23 settembre fu annullato, che Rust servì i primi turni di produzione il 24 settembre, che il runtime Python fu eliminato il 9 ottobre e che l’ultimo cluster passò a Rust il 10 ottobre.
Che cosa misurano i dati sulla latenza
Per motivare il passaggio, Microsoft cita tre problemi osservati nel cluster Python: sotto carico, i blocchi del loop degli eventi arrivavano a 11,9 secondi; il 16,7% delle inizializzazioni di sessione durava esattamente 5 secondi perché scattava un timeout; un processo Python fu terminato 539 volte in una settimana su un singolo cluster.
Nella stessa finestra di 12 ore a fine settembre, Microsoft confrontò il tempo al primo token del primo turno. Il p50 indica la mediana; il p90 è il valore entro cui ricade il 90% delle misurazioni.
| Runtime | p50, secondi | p90, secondi |
| Python | 7,9 | 14,5 |
| Rust | 2,7 | 6,2 |
Il cambiamento comprendeva anche lo spostamento del loop dell’agente fuori dal contenitore e dentro il servizio Rust; Microsoft attribuisce a questo passaggio una parte sostanziale del calo. L’azienda ha aggiunto di non aver misurato adeguatamente il costo per turno e di non avanzare conclusioni su eventuali risparmi.
Dove si inserisce Cowork nei flussi di sviluppo
Un utilizzatore di Power Platform ha raccontato di servirsi di un agente Copilot Studio, con esempi e istruzioni del progetto, per lavorare alle Logic Apps; per completare il flusso doveva ancora copiare manualmente il risultato finale. In un dibattito sui possibili usi di Copilot Cowork, alcuni utenti consideravano sufficienti le funzioni ordinarie di Copilot per riepiloghi e presentazioni con marchio aziendale, mentre altri vedevano un possibile vantaggio nel coordinare più passaggi tra documenti ed email.
