Microsoft Copilot Mobile / Project
Copilot Mobile Multi-Agent Development System
I created and shipped a production multi-agent development system for Microsoft Copilot Mobile. It gives contributors a path from scoped product intent to mobile changes while keeping evals, engineering review, and recovery in the workflow.
- Role Original builder, active developer, and product owner for the workflow
- Adoption and production In the first month, PM and Design teammates created and merged production PRs after engineering review
- Next constraint Review capacity led me to build risk-aware auto-review support
This page stays at the level I can discuss publicly. I am not sharing Microsoft internal architecture, prompts, private code paths, review heuristics, customer data, or implementation details that belong to the product.
My role spans product ownership and hands-on development. I was the original builder, set up the eval-driven workflow, and remain an active developer of the system.
What changed
Before this, many useful product and UX changes still depended on an engineer to start, translate, or carry the implementation. That slows down PMs and designers, but it also slows down engineers. An iOS developer may understand the product change and still have to wait on Android context, or the other way around.
The system gives people a reviewed path into Copilot Mobile development. PMs and designers can use it directly, with engineering review. Mobile engineers can use it to move across platform boundaries. The point is not to remove engineering judgment. It is to make more of the work executable, reviewable, and testable.
In the first month, PM and Design teammates created and merged production PRs after engineering review; review capacity became the next constraint.
Public evidence and limits
| Area | Observable public signal | Limit |
|---|---|---|
| Adoption | In the first month, PM and Design teammates created and merged production PRs after engineering review; review capacity became the next constraint. | Exact contributor and PR counts are not disclosed. |
| Production path | Production PRs were created and merged after engineering review. | Internal prompts, code paths, and review heuristics are not disclosed. |
| Next constraint | Review capacity became the next constraint. | Queue size, risk thresholds, and operating details are not disclosed. |
Public workflow shape
This simplified sequence shows the roles and gates I can discuss publicly. It is not a representation of Microsoft internal architecture.
- Contributor PM, designer, or engineer starts from a scoped product change
- Agent development loop Agents help translate intent into mobile implementation work
- Eval gate Workflow checks catch regressions and make behavior observable
- Engineering review Humans keep ownership of quality, risk, and product judgment
- Risk-aware review As review load grew, I built auto-review support that evaluates PR risk and recommends review depth.
- Recovery path Changes stay tied to review, traceability, and rollback thinking
What the system enabled
The clearest shift is that development no longer has to start only with the person who already knows the exact platform, code path, or implementation routine. A PM responsible for measurement can make instrumentation and metrics changes directly. A designer can carry product details closer to the final implementation. An engineer can move faster in an unfamiliar part of the mobile stack.
Engineering review remains part of the product workflow. When review capacity became the next constraint, I built an auto-review layer that evaluates PR risk and recommends the depth of review it needs. That work extended the system beyond code generation into verification, risk, and recovery.
What changed my mind
At first, I was focused on access to implementation. Once PM and Design teammates started creating and merging production PRs after engineering review, review capacity became the next constraint. That changed what I built next: risk-aware auto-review support that recommends how deeply a change should be reviewed.
- Evals made it possible to compare agent behavior on the real workflow.
- Contributor, agent, and reviewer responsibilities needed to remain visible.
- Review capacity became the next constraint after adoption.
- Risk signals helped recommend review depth before a reviewer opened the diff.
- Engineering review remained part of the path to production.
Why eval-driven mattered
I set up the system around evals that shape agent roles, test real workflows, catch regressions, compare approaches, and help decide when a path is ready for engineering review.
That changed the development posture. Instead of asking whether the agent sounded plausible, I wanted to know whether the workflow held up: did the right files change, did the review surface make sense, did the system expose risk, and could a person recover if something went wrong?