On October 21, nine engineers merged 1,211 pull requests into the Copilot Cowork backend’s main branch, Microsoft says. That daily count is separate from the 4,581 pull requests Microsoft reports for the week of October 12. Both numbers describe a fast-moving project; the engineering practices behind them show how the team tried to keep agent-written changes reviewable and bounded.
What Microsoft’s pull-request milestone counts
The October 21 figure is a count of merged changes to the backend’s main branch. Microsoft says agents wrote most of Copilot Cowork’s code, while engineers set requirements and architecture, established security boundaries, reviewed critical changes and made production decisions.
How the team bounded agent-assisted work
Microsoft says each coding task began with a Markdown specification covering the intended behavior, how to judge success and what must not break. An agent could draft a specification from a spoken description, but a person edited it before implementation. Agents worked in separate copies of the repository, each on one task tied to one specification. The team says it grew from one agent to five and then dozens.
The team also described a boundary between the model and Microsoft 365 operations. The model ran in a container without user credentials. A trusted host outside the container handled identity, policy, approvals, tool execution and audit; Microsoft says every Microsoft 365 operation passed through that host. In this setup, the model could plan and request actions, while the host determined what happened.
Microsoft says agent reviewers provided an early pass, with human review retained for critical changes. In one sensitive case, people found four blocking issues that reviewer agents had missed. The reported median time to a useful first review was about 4.5 minutes in a sample of recent merged pull requests. Each reviewer agent had undergone at least 10,000 generations.
The team also tried to make misleadingly green checks harder to miss. Checks had to report how many files they examined, and each new check needed a test that deliberately made it fail. That addressed cases where a check could pass without testing anything useful, such as a formatter receiving an empty file list.
How Microsoft checked the Python-to-Rust migration
Microsoft says it generated about 430 JSON fixtures by running the Python implementation on defined inputs and recording its outputs. Rust tests replayed those fixtures. One example fixture contained 48 cases, and its test checked the case count before replay so an empty set could not pass unnoticed.
The first fixtures still missed an implicit behavior: Python had delivered certain events in order, although that ordering was not specified. The initial Rust version did not preserve it. Microsoft says the team corrected the issue. It also says the first Rust front door took about six times longer to acknowledge a message because it waited for the entire pickup, a problem the team fixed.
The migration moved through production in stages. Microsoft says an initial cutover attempt was rolled back on September 23, 2026, and Rust served its first production turns on September 24. The company says it deleted the Python runtime on October 9, covering about 8,000 files and 4.9 million lines, including tests and generated code. The last cluster moved to Rust on October 10.
What the latency comparison shows
Microsoft compared Python and Rust clusters over the same 12-hour window in late September. p50 is the median measurement; p90 is the 90th percentile.
| Runtime | p50 first-turn time to first token | p90 first-turn time to first token |
| Python | 7.9 seconds | 14.5 seconds |
| Rust | 2.7 seconds | 6.2 seconds |
Microsoft says moving the agent loop out of the container and into the Rust service also contributed substantially to the lower times. The comparison therefore reflects both the runtime migration and an architectural change. The company says it has not properly measured cost per turn and makes no claim that the migration reduced costs.
Microsoft also reports that, under load, Python event-loop stalls reached 11.9 seconds and 16.7% of session setups took exactly 5 seconds because a timeout fired. The team says those stalls and timeout cases were gone after the migration. Microsoft separately reported 539 Python process kills in one week on a single cluster.
What developers say about coding workflows
One Power Platform user described using a Copilot Studio agent with project examples and instructions to help develop Logic Apps, then manually copying the finished Logic App into place. Another commenter suggested keeping plans and specifications in Markdown and running scripts in VS Code. These are individual workflow reports; the manual handoff was part of the first user’s process.
Users also disagreed about where multi-step orchestration might help. Some said ordinary Copilot could already handle tasks such as summarizing emails or making branded decks; others saw potential in coordinating work across documents, email and analysis. Those comments describe users’ views, not a comparative test of Copilot Cowork.
