Built an AI knowledge agent on SharePoint giving Excel designers instant, cited answers on craft, process, accessibility, and handoffs. Cut onboarding by 40%, saved 3hrs/week per designer, and hit 87% query resolution with 90% team adoption in a 4-week pilot.
Liked this project?
Let's talk about what we can build together.
Introduction
Outcomes at a glance: ~40% onboarding time cut, 90% team adoption, 2,147 sessions in 4-week pilot, 87% query resolution rate.
Key Outcomes
Design knowledge at Microsoft was everywhere. Which meant it was nowhere.
The Excel design team, 10+ people split across Redmond and IDC, worked on one of the most complex productivity apps on the planet. Their institutional knowledge lived in SharePoint portals, OneDrive folders, Loop workspaces, Figma file comments, Teams channels, meeting recordings, PowerPoint decks, Word docs, and Azure DevOps tickets. You want to know how Excel handles accessibility in charts? Good luck. Start digging.
I built something to fix that. A Copilot-powered knowledge agent, grounded on a structured SharePoint knowledge base, that gives designers instant cited answers on craft, process, accessibility, onboarding, and handoffs. We ran a 4-week pilot. 9 out of 10 designers used it weekly. Onboarding dropped from 5 weeks to 3.
Onboarding Time Reduction
Team Adoption Rate
Sessions in 4-Week Pilot
Query Resolution Rate
Context
Design knowledge at Microsoft was scattered across 12+ systems. The agent was built to give designers one place to ask anything.
The Copilot EXCEL Wiki agent is a purpose-built AI assistant designed to streamline the daily workflow of Excel designers. It centralizes knowledge, automates information retrieval, and proactively guides designers with actionable insights, references, and next steps—making them more efficient and up to date with Excel features and best practices.
The Excel Design team at Microsoft operates across multiple geographies (Redmond, IDC) with 10+ designers working on one of the most complex productivity applications in the world. Design knowledge was scattered across:
Pain Point
💬 Designer Friction Points (from 1:1 interviews)
- "I spend 20+ minutes just finding the right Figma library for my feature."
- "Every time there's a new hire, I become the human wiki for a month."
- "I know we've solved this problem before, but I can't find where we documented it."
How might we enable Excel designers to instantly access the right knowledge, resources, and guidance—without disrupting colleagues or searching through scattered systems?
Background & Motivation
Before the agent, there was a directory. Understanding how — and why — the approach evolved explains every decision that followed.
The journey began with a simple directory of links—portals, files, presentations, Loop pages, Figma files—intended to help Excel designers quickly find resources. However, this approach was static, required heavy manual maintenance, and was dependent on others for updates. Recognizing these limitations, the vision evolved:
Initial Attempts:
Key Insight:
Designers needed more than a directory—they needed an intelligent, context-aware agent that could answer nuanced questions, surface the latest resources, and reduce manual searching.
Brainstorming & Iterative Development
Three failed attempts before landing the right architecture — each one taught us something the next iteration used.
Research:
Conducted 1:1 and whiteboarding sessions with designers to gather real-world questions and expectations.
Collected and categorized prompts into five main buckets (e.g., design craft, process, handoff, accessibility, onboarding).
Pain Points Identified:
Existing Wiki was hard to maintain, lacked excitement, and didn’t scale.
Manual updates to SharePoint and Loop were tedious.
Solution Evolution:
Rebuilt the Wiki structure in SharePoint for compliance and scalability.
Hard-coded tables, links, and authored how-to guides for key workflows (icon creation, bug bash, research, etc.).
Iteratively fine-tuned the agent’s responses for clarity, relevance, and actionable output.
Key Insights
The research surfaced three findings that fundamentally reshaped the agent's scope and response format.
Designers spent significant time preparing for reviews and LT presentations. The need wasn't just "where are templates" but "which past presentations landed well with stakeholders like Venkat?"
Senior designers wanted to reference how problems were solved before. This shifted the agent from a "link finder" to a "design memory" system.
Designers would only trust agent answers if they could verify the source. This informed the TL;DR + Citations response format.
Development Phases
Three quotes from 1:1 interviews with designers:
"I spend 20+ minutes just finding the right Figma library for my feature."
"Every time there's a new hire, I become the human wiki for a month."
"I know we've solved this problem before, but I can't find where we documented it."
Nobody said "we need more documentation." The knowledge existed. The problem was that finding it cost more than just asking someone. So people asked someone. Senior designers became interrupt-driven lookup tables. New hires spent their first month making those interruptions.
The question I was working with: how do we give designers one place to ask anything and get a trustworthy, sourced answer in under a minute?
| What | Excel spreadsheet with categorized links to resources |
| Why Failed | High maintenance burden; dependency on others to update; not searchable |
| Learning | Designers need answers, not links. The cognitive load of navigating links was the original problem. |
| What | Copilot's AI Notebook feature with ~20 reference documents |
| Why Limited | 20-reference ceiling was too restrictive for our knowledge base; couldn't cover all 6 theme areas |
| Learning | Need a more powerful grounding solution—Copilot Studio with enterprise connectors. |
| What | Created structured Wiki in Loop workspace, hoping to ground agent on it |
| Why Blocked | Copilot Studio did not support Loop workspace as a grounding corpus due to compliance/feature limitations—only SharePoint accepted |
| Learning | Platform constraints matter. Had to migrate everything to SharePoint—a week of re-work. |
Agent Capabilities & Instructions
I want to be specific about what didn't work, because the failures shaped every decision that followed.
Attempt 1: Link directory. An Excel spreadsheet of categorized links to portals, Figma files, Loop pages, and presentations. Maintained manually. Required someone to own it. Became stale within weeks. Designers still had to click through to find the actual answer. This solved nothing. It just moved the friction one step earlier.
Attempt 2: AI Notebook in Copilot. Loaded ~20 reference documents, used Copilot's Notebook feature for grounded Q&A. Hit the ceiling fast. 20-reference cap couldn't cover our six knowledge theme areas. It was good enough to prove the concept, not good enough to ship.
Attempt 3: Loop workspace as grounding corpus. Built a structured Wiki in Loop, planned to ground the Copilot Studio agent on it. Compliance and feature limitations blocked it entirely. Copilot Studio only accepted SharePoint as a grounding source at the time. One week of re-work to migrate everything.
The lesson from attempt 3 isn't "test platform constraints earlier" (though yes, do that). It's that I was so focused on the knowledge architecture that I delayed the boring infrastructure question: what does Copilot Studio actually support? That's a mistake I'd reverse.
Response Formatting:
- TL;DR summary.
- Numbered action steps.
- References table (Title, Owner, Last Updated, Link).
- Platform-specific notes (Win/Web/Mac/Mobile).
- Inline citations and proactive next steps.
- **Tone & Style:**
- Friendly, concise, and designer-centric.
- Uses bullets, tables, and short paragraphs for clarity.| Feedback | Action Taken | Result |
| Responses too verbose | Refined prompt instructions; added TL;DR requirement | Response time ↓34% |
| Missing accessibility docs | Authored 5 new a11y guides; added to knowledge bank | A11y queries resolved ↑ to 91% |
| Can't verify citations | Added clickable hyperlinks in references table | Trust score ↑ (qualitative) |
| Need Figma file search | Explored MCP/API integration (see Section 7) | Parked for future (technical constraints) |
Figma Integration: MCP or API?
I ran 1:1 sessions and whiteboarding exercises with designers to map real-world questions before writing a single line of prompt instructions. Two findings surprised me.
Presentations were a bigger pain point than expected. Designers weren't just asking "where are the templates." They were asking "which past presentations landed well with Venkat?" That's a retrieval problem with memory and social context attached. It shifted my thinking about what the agent needed to be.
"Find prior art" was the hidden superpower. Senior designers wanted to know how problems had been solved before. Not a link to a page. An answer with context. That changed the agent's scope from link-finder to design memory.
Trust requires citations. Designers wouldn't act on agent answers they couldn't verify. The response format had to surface sources, not just answers. This became non-negotiable.
Those three findings shaped the final response format: TL;DR summary, numbered action steps, references table with owner, date, and link, platform-specific notes, and inline citations. Every design decision in the agent's prompt instructions traces back to something a designer told me in those sessions.
- "Find the Checkout flow file and summarize recent comments"
- "What components are used in the Dashboard redesign?"
- "Show me files updated in the last week in the Charts project"
| What It Is | Figma's official MCP server (Dev Mode) for design-to-code workflows |
| Primary Goal | Extract CSS/React props from a user-provided file link |
| Tools Exposed | get_design_context, get_variable_defs, get_code_connect_map |
| Critical Limitation | Link-based only. Cannot browse team files or search projects. User must provide specific file URL first. |
| Missing Capabilities | No list_team_projects, search_files, or get_file_comments tools |
| What It Is | Power Platform custom connector wrapping Figma REST API with OAuth 2.0 |
| Available Endpoints | GET /v1/teams/:team_id/projects, GET /v1/files/:file_key/comments, etc. |
| Advantages | Can browse team files, search projects, read/post comments, list components |
| Blocking Constraints | Requires HTTPS-hosted MCP server with valid certificate; rate limiting concerns for team-wide queries; OAuth app registration with MS org compliance review |
| Capability | Official MCP | Custom Connector |
| Find files by name/search | ❌ No | ✅ Yes |
| Browse team projects | ❌ No | ✅ Yes |
| Read/post comments | ❌ No | ✅ Yes |
| Design-to-code context | ✅ Yes | ⚠️ Limited |
| Setup complexity | Low | High |
| Meets our use case | ❌ No | ⚠️ Possible but complex |
Impact & Value
The agent runs in Copilot Studio, grounded on a structured SharePoint knowledge base. The knowledge is organized into six areas: design craft, process, handoff, accessibility, onboarding, and references.
Source prioritization, in order: curated SharePoint knowledge bank, then enterprise sources (OneDrive, Figma, Teams/Loop, ADO), then the org-wide Azure AI Search index.
The agent summarizes only from retrieved evidence. It explicitly flags when information is missing or conflicting. It doesn't hallucinate a confident answer and it doesn't bury uncertainty in hedged language.
We tuned response format across multiple rounds based on direct feedback:
| Metric | Before Agent | After Agent |
| Onboarding time (new designer) | ~5 weeks | ~3 weeks (↓40%) |
| Weekly active users | N/A | 9/10 designers (90%) |
| Total pilot sessions | N/A | 2,147 sessions |
| Query resolution rate | N/A | 87% |
| Est. time saved per designer/week | N/A | ~3 hours |
| Avg. response time | N/A | <40 seconds |
Challenges & Lessons Learned
Designers consistently asked for one more thing: the ability to search Figma files directly through the agent. Find the latest chart specs. See recent comments on a design file. Surface what changed in the last week.
I explored two paths. Figma's official MCP server is link-based only. You hand it a URL and it gives you design-to-code context. It can't browse team files or search projects. No list_team_projects, no search_files, no get_file_comments. It covers design-to-code workflows well. It doesn't cover what we needed at all.
The other option: a custom Power Platform connector wrapping the Figma REST API with OAuth 2.0. This could actually do what designers wanted. Browse team files, read comments, list components. But it required an HTTPS-hosted MCP server with a valid certificate, OAuth app registration through Microsoft's compliance review process, and rate limit management for team-wide queries. Realistic timeline to implement properly: 4-6 weeks.
Given that the SharePoint-grounded agent was already delivering strong results, I parked Figma integration for the next phase. Not shelved. Parked. The plan is to run a proof of concept using Cursor or Lovable to build the custom connector before committing to full implementation.
Future Vision
Four-week pilot with the full 10-person Excel design team.
| Metric | Before | After |
|---|---|---|
| Onboarding time (new designer) | ~5 weeks | ~3 weeks (-40%) |
| Weekly active users | N/A | 9/10 designers (90%) |
| Total pilot sessions | N/A | 2,147 |
| Query resolution rate | N/A | 87% |
| Time saved per designer per week | N/A | ~3 hours |
| Average response time | N/A | <40 seconds |
Beyond the numbers: senior designers report fewer interruptions for routine questions. The team now contributes to the SharePoint knowledge base more actively, because they can see it feeding into answers directly. Other Office app teams have asked about replicating the model.
Near-Term
Medium-Term
Long-Term Vision
"How is my day looking?"
The ultimate vision: a designer asks this one question and receives a synthesized brief including:
Conclusion
Earlier platform research. I would have tested Copilot Studio's grounding source requirements in week one, not week four. Loop-to-SharePoint migration was avoidable.
Baseline metrics. I estimated the 40% onboarding reduction from before/after interviews rather than a measured comparison. It's directionally accurate but I'd want a cleaner number.
Parallel Figma exploration. The MCP evaluation could have run alongside the core agent build. It didn't need to wait.
Near term: expand the knowledge base with 12+ docs in the pipeline, roll out to the Redmond-based designer cohort, add a thumbs-up/down feedback loop for quantitative quality tracking.
Medium term: Figma integration PoC, meeting transcript search (compliance permitting), prompt library based on the most common query categories.
The longer-term vision is a morning brief. A designer asks "how is my day looking?" and gets: key emails and mentions, today's meetings with prep docs, Figma files updated overnight with unread comments, ADO work items needing design input, suggested priorities based on deadlines. One agent, one question, no switching between tools.