A Microsoft engineering post describes how a small team took Copilot Cowork, an agentic execution layer for knowledge workers, from a first commit on 13 January to worldwide general availability on 16 June, then moved its runtime from Python to Rust while the product was live. Bas Brekelmans, a partner software engineer at Microsoft, published the account on 2 November.
On 21 October, he writes, nine engineers merged 1,211 pull requests into the main branch of the Copilot Cowork backend. Agents wrote most of the code. Engineers remained responsible for defining the work and judging the results, and for review of higher-risk changes, production impact, and cases where checks or reviewers disagreed.
“Agents could propose changes, but they could not decide what was allowed to happen.”
— Bas Brekelmans, in the Microsoft post
Copilot Cowork is meant to run multi-step workflows on a user’s behalf, with Work IQ, Microsoft 365 security and governance, cloud execution and Microsoft’s multi-model architecture. The team launched it to a first set of enterprise customers in Microsoft’s Frontier programme on 30 March, and reached general availability about four and a half months after the first commit, with several models and 16 plugins.
Merged pull requests into main rose from 257 in January to 2,754 in May, and the busiest week before general availability had 783, according to a chart in the post. The bottleneck, Brekelmans says, was often not the agent but “not knowing exactly what we wanted.” The team adopted a standing rule of no code without a markdown spec written first, covering what the change does, how they’ll know it works, and what it must not break. Many specs start out spoken, with an agent drafting them and a person editing.
Each agent works in its own copy of the repo, on one task, from one spec. In Copilot Cowork itself, the model runs in a container without user credentials. A trusted host outside the container handles identity, policy, approvals and tools, and every Microsoft 365 operation goes through the host. “The model can plan and ask for anything, and the host decides what actually happens,” Brekelmans writes. That defined interface later let the team replace the host when it moved to Rust, without changing the agent.
With agents writing most of the code, human review was becoming the slowest step. Several engineers each built review bots, which competed and gained rules from misses; each has been through at least 10,000 generations, the post says. A useful first review usually arrives within several minutes of a pull request being opened, with a median of about four and a half minutes on a sample of recent merged PRs, followed by slower specialised passes. Agent review stayed the first check, with at least one human check for critical changes. In one case, reviewer agents missed four blocking issues in a sensitive part of the product that people on the team then found and fixed before the change merged.
The team also tightened its automated checks after finding some that couldn’t fail. A size-limit check was piped through a command that always returned success, so the pipeline stayed green after the limit was exceeded. Other checks passed after being handed an empty list of files. The rule that followed is that every check reports how many files it checked, and every new check comes with a test that makes it fail on purpose. “Agents keep working until the checks pass, so if a check can pass without testing anything, an agent will eventually find that path,” Brekelmans writes.
From August, the team put standing rules into the repo so each agent session wasn’t starting from scratch. There are about 30 rule files now. It also reshaped the Rust workspace after the main runtime binary had grown to about 290,000 lines: every crate is a contract, a kit, an implementation or a binary, and implementations may not depend on one another. Implementation-to-implementation dependencies on an exception list went from 216 on 22 August to zero on 7 October, the allowed dependency depth from 10 to three, and the number of crates from 86 to about 176. Build-time gains were smaller than predicted, the post says, because a compile cache was already hitting about 99% of the time on pull request builds.
More work now runs as automated loops with a measurable target, a limit on attempts, and a list of actions that still need a person, including production deploys and configuration changes. A test-speed harness has merged about 300 pull requests since mid-September, taking the touched test files from roughly 17,700 seconds of CI time to about 1,700. A newer harness, which the team calls the factory, turns production signals into work items without a model raising the alarm, and follows merged fixes into a release to see whether the signal dropped. In the week of 12 October, 4,581 pull requests merged into main, about 650 a day, “and a growing share of them came from the factory.”
Python, Brekelmans says, got the team to general availability quickly. At later scale it caused event-loop stalls of up to 11.9 seconds, a hidden timeout that made 16.7% of session setups take exactly 5.000 seconds, and memory pressure that killed the Python process 539 times in one week on a single cluster. The team recorded Python behaviour as fixtures — about 430 of them — and required the Rust tests to match them exactly, then moved traffic one cluster at a time, behind flags that could switch back.
The first internal attempt, on 23 September, was rolled back. Rust served its first production turns the next day. The Python runtime was deleted on 9 October, about 8,000 files and 4.9 million lines, including tests and generated code, and the last cluster moved on 10 October.
| Runtime | p50 | p90 |
|---|---|---|
| Python | 7.9 s | 14.5 s |
| Rust | 2.7 s | 6.2 s |
The event-loop stalls and the five-second setups are gone, the post says. Not all of the timing gain comes from Rust: the same change moved the agent loop out of the container, which was slow to start, and into the Rust service. Microsoft hasn’t measured cost per turn properly yet, and isn’t making a claim about cost. Two problems showed up in the cutover — event ordering that Python had been preserving without anyone specifying it, and a first Rust front door that took about six times longer to acknowledge a new message — and both were fixed.
The lesson, Brekelmans writes, isn’t to aim for the team’s pull-request count. Most of the engineers’ time now goes into what to build, where to draw the boundaries, which test proves a change works, and whether a passing check means what it appears to mean.
Discover more from Sulat AI & Tech News
Subscribe to get the latest posts sent to your email.
