Microsoft AI
Member of Technical Staff- Co-owned Consumer Copilot’s model features as one of seven owners. Serving 100M monthly active users.
- Architected Copilot Tasks’ response layer. Redesigned context management to eliminate $2M+ in monthly inference spend.
Results and context
Copilot Tasks reached 200k daily active users in under a month.
Youngest career hire on Microsoft AI’s core teams. Approved evaluation strategies and mentored senior engineers on agentic features.
One of three owners of Copilot Tasks’ main system prompt, tools, and skills. Its response layer covered system instructions, tool results, context management, and caching. The task-execution agent was later folded into Copilot Cowork for consumers.
One of the lead engineers behind the first unified Copilot app demo. Built and maintained it to secure backing from Microsoft’s executive vice presidents. The full product involved thousands of engineers across Bing, Microsoft AI Copilot, and Microsoft 365 Copilot.
Copilot Tasks product announcement ↗Copilot task planning and execution
Start with an accessibility question
A user asks what an accessibility review should cover. Copilot shows visual examples of keyboard navigation, focus indicators, and form labels. I co-owned the core instructions for image answers and suggested follow-ups.
Turn the advice into work
The follow-up asks Copilot to apply those checks: read the project notes, update the checklist, and draft the team email. I built the chat-to-Tasks handoff for multi-step work like this. It accounted for about 70% of Tasks usage.
Skills and available tools
The request needs connected-file access and writing capabilities. I integrated the shared skill system and defined selection before planning, loading the required tools and procedures before the model committed to a plan.
System prompts and task planning
The loaded capabilities let the model plan file access, a checklist update, and an email draft. I defined the system-prompt rules behind planning and owned the instructions for every Copilot Tasks tool; the planning tool I integrated exposes progress during execution.
Connector consent and authorization
The file-reading step needs permission to access the project notes. I defined structured consent-card schemas and built checks for Google Workspace, OneDrive, Outlook, and other services to obtain the access required for an operation.
Container-side file access
With access granted, code runs in an isolated workspace called an agent container to read the project notes. I defined connector-skill requirements and output rules through implementation reviews, distinguishing routine lookup results from requests to create documents.
Connected data and instruction boundaries
The returned notes supply the checklist content. I defined system-prompt rules requiring confirmation before following instructions embedded in files or web pages, so their contents cannot authorize new actions such as forwarding private data.
Batched browser actions
The notes are applied through the browser because this portal has no editing connector. I changed the browser-tool implementation and action-selection behavior to reduce inference calls: the model chooses click, type, and click together in one browser call.
Context size and cache reuse
Each model call carries recent task history, so large browser results increase processing time. I bounded that history with a sliding window and task notes, and separately fixed cache-breakpoint stability to reuse unchanged input. Cache hit rate rose from about 50% to 80%+.
Loop detection and recovery
The retained working note carries the pending save verification into the next call. I defined recovery rules and corrected tool-result handling to stop repeated work without progress; the model checks the saved page rather than retrying the edit.
Permission to send email
The verified checklist feeds the email draft. When mail sending is disabled, the consent-card contract I defined requires approval separate from file access, leaving the sending decision with the user.
Returned draft and references
After the user declines sending, the result includes a saved checklist and an unsent draft. The result-handling contracts I defined preserve that distinction and the source references.
Model-feature evaluation
I approved evaluation strategies for the full execution path, covering tool selection, permissions, recovery, and returned results.





