Copilot & Foundry: The Microsoft AI Stack for Small Business · Lesson 9 of 10
Adding Foundry: When and How
Time: ~30 min reading + ~20 min worksheet (conceptual + architecture work) Goal: Recognize when Copilot Studio hits a ceiling, understand what adding Foundry looks like, and work through the pattern on Northside's agent.
---
Let's fast-forward. Six weeks after launch:
- The agent is handling ~25 questions/week
- Deflection rate: 72%
- Rachel's time saved: 6–8 hours/week (her self-report)
- User satisfaction: 76%
By the original success metrics, this is a win. Mike and Lisa are happy. They want to extend.
And then — some signs that v1 is approaching its ceiling.
Signal 1: The knowledge base is growing
Rachel has been adding content. Not just answering questions — turning each escalation into a handbook update or a new knowledge doc. The knowledge folder is now at 180 documents and growing by ~15/week.
At ~500 docs, Copilot Studio's relevance quality will visibly degrade. We're 3 months away from that, maybe 4. Time to plan.
Signal 2: Technicians ask more complex questions
Field techs are finally using the agent. Their questions are different. Not "what's the PTO policy" — questions like:
> "I'm at a customer's site and their boiler is a Burnham Series 8 from 2008. Our records show we serviced it in 2016. What did we do last time?"
These questions want to span across 20 years of ServiceTitan job history. Thousands of job records. Tens of thousands of technician notes. The current agent can't do this — it doesn't have the data, and even if it did, Copilot Studio's RAG isn't designed for this kind of document-volume retrieval.
This is a real, recurring request. Mike has been dreaming of this capability for years.
Signal 3: A compliance question
Lisa is thinking about a customer-facing use case: a quote-generation agent customers could interact with on their website. Before she commits, she's asked her insurance broker — there's a clause about data handling for anything customer-facing. They want to see the architecture before anything ships.
Customer-facing + data handling review = we're leaving Copilot-Studio-only territory.
Signal 4: Mike wants on-prem for one data set
Some of Northside's larger commercial customers require that vendor systems handling their service data stay in the US and meet specific audit requirements. Mike has a concrete deal at stake — a national retail customer asking about this.
Pure SaaS Copilot Studio might not satisfy their procurement requirements. Foundry + appropriate Azure regions + Purview governance provides a real answer. Foundry Local is on the table for specific data sets.
Any one of these is a legit reason to plan the Foundry addition. Together, the case is overwhelming.
Apply the decision tree again with the new information:
- Internal agent, moderate scope, sub-500 docs, M365-grounded? Partially — but we're about to blow past the 500-doc ceiling.
- Large knowledge base, non-OpenAI model, advanced RAG, custom evaluation? YES. 20 years of service history = RAG-heavy.
Decision: Pattern 2 (Copilot Studio front-end + Foundry back-end) for a new capability: a service history research agent that lives alongside the original helpdesk agent.
Note: we're not replacing the Copilot Studio helpdesk agent. It works great at what it does. We're *adding* a Foundry-powered specialist alongside it. The helpdesk stays Pattern 1. The service history agent is Pattern 2. Users will be routed to one or the other based on their question.
This is the graduation pattern in action.
Let's walk through the pieces. This is not a full build tutorial (that's a developer course) — it's what you need to know to scope, price, and explain to the client.
Step A: Design the architecture
Sketch out the new system:
``` [User in Teams] │ └─► [Copilot Studio orchestrator] │ ├─► [Helpdesk topic/agent] (unchanged, Pattern 1) │ └─► [Service History topic] │ └─► API call ─► [Foundry Agent] │ ├─► [Foundry IQ + Azure AI Search indexed over ServiceTitan data] ├─► [Chosen LLM — probably GPT-5 for quality] ├─► [Content safety] └─► [Observability] ```
The orchestrator routes questions. "How do I request PTO" → helpdesk topic (existing). "Service history for 456 Main Street" → Foundry service history agent (new).
Step B: Set up the Azure foundation
This is real IT work:
- Azure subscription (client's or reseller's)
- Resource groups, naming conventions
- Entra identity and RBAC
- VNet / private endpoints (especially if regulated data is involved)
- Purview integration
- Azure OpenAI access (may require provisioning/quota request for certain models)
- Monitoring and alerting
For an SMB this is typically a 2–3 week setup project. It's not particularly exciting, but getting it right up front prevents pain later.
Step C: Get the data indexed
The big engineering piece. ServiceTitan's job history needs to be continuously synced to Azure AI Search.
Options:
- Use ServiceTitan's API, build a scheduled sync
- Use a middleware platform (Fivetran, Azure Data Factory) to move data to Azure SQL / ADLS, index from there
- For a first pass, bulk-export, index, then figure out ongoing sync
The data gets:
- Cleaned — standardize date formats, handle address variants, etc.
- Chunked — broken into searchable pieces (per-job, per-note)
- Embedded — converted to vectors using an embedding model
- Indexed — stored in Azure AI Search with appropriate metadata (customer ID, equipment type, dates, technician)
Expect this phase to be 4–8 weeks of real engineering.
Step D: Build the Foundry agent
Inside Foundry:
- System prompt tuned for this use case (tech-in-field, cite specific records, include dates and technicians)
- RAG configuration pointing at the service history index
- Tool functions for any real-time lookups (current inventory of replacement parts, etc. — if you want to go further)
- Content safety filters (avoid giving technicians unrelated customer data)
- Evaluation test set (50–100 example questions with known good answers)
This is another 2–4 weeks of work.
Step E: Wire it into Copilot Studio
Back in Copilot Studio:
- New topic in the orchestrator agent for service history questions
- Action that calls the Foundry agent's API endpoint
- Passes context (user identity, question, session)
- Returns the Foundry response back into the Teams conversation
Step F: Test, pilot, roll out
Same pattern as Pattern 1, more complex:
- Pilot with 3 field techs for 2 weeks
- Gather feedback, tune prompts and RAG configuration
- Expand to 10 techs
- Full rollout to all 30 techs
Step G: Governance uplift
Apply across the new stack:
- Sensitivity labels on any customer data classified as confidential
- Purview DSPM for AI monitoring
- DLP policies to ensure Foundry data doesn't leak through other connectors
- Audit logging enabled for all Foundry interactions
Foundry changes the economics. Let's update the TCO.
New one-time build cost
- Architecture + Azure foundation: $18K
- Data sync pipeline: $25K
- Foundry agent build: $20K
- Copilot Studio integration: $5K
- Testing, pilot, rollout: $12K
- New build total: $80K
Plus the original $22K Copilot Studio engagement = $102K cumulative invested.
New ongoing costs (annual)
- M365 Copilot licenses (unchanged): $17K
- Azure consumption for new system:
- Azure AI Search (for the service history index): ~$500/month
- Azure OpenAI token costs: ~$800/month
- Compute, networking, storage: ~$300/month
- Total Azure: ~$19K/year
- Ongoing managed service (higher now): $2.5K/month = $30K/year
- Annual recurring: ~$66K
Three-year cumulative (counting from project start)
- Year 1 (original Copilot): $22K build + $17K licenses + $0.5K Azure + $6K managed = $45K
- Year 2 (adding Foundry): $80K build + $17K licenses + $19K Azure + $30K managed = $146K
- Year 3: $17K licenses + $19K Azure + $30K managed = $66K
- 3-year total: $257K
The value story
For Mike, the pitch is:
> "Year 1, we save Rachel's time and pay for itself. Year 2, we add a capability that lets every technician carry 20 years of institutional knowledge in their pocket. That's a competitive advantage. Your techs are faster, more accurate, and less dependent on the senior guys. That's worth a lot more than $80K additional build cost. And Year 3 we see the ongoing return."
If Northside's average service call is $500 and the agent saves 15 minutes per call by eliminating "let me get back to you" moments, on 5,000 annual service calls that's 1,250 hours of tech time. At $60/hr loaded, $75K/year. Plus the competitive win of the large commercial deal Mike mentioned. Pays for itself in year 2.
A few important shifts when Foundry enters the picture:
The client now has an Azure subscription
If they didn't before, they do now. That's a real relationship. Someone has to own it, monitor it, handle cost spikes, renew. Set up who's responsible clearly. Usually: you as the IT partner/consultant, with the client owning the subscription.
Engineering dependencies
A Copilot Studio agent is something a skilled maker can maintain. A Foundry agent has actual engineering dependencies — code, pipelines, APIs. If you leave, client needs another engineer. Document everything. Keep it in the client's Azure tenant where they can hand it to anyone capable.
Different monitoring rhythms
Copilot Studio usage is daily/weekly. Azure cost and performance monitoring is daily. Set up alerts. Nobody wants to discover a $5K month because a prompt loop ran wild.
Higher governance rigor
Foundry with customer data requires more disciplined governance than a Copilot Studio HR bot. Purview, DLP, audit reviews — these become real activities, not checkboxes.
---
- The graduation is a process, not an event. Northside's agent working well in Copilot Studio earns the right to add Foundry for the next use case.
- Pattern 2 is an addition, not a replacement. Keep what works; add what you need.
- The four big signals: large knowledge base, complex cross-source questions, customer-facing requirements, data sovereignty needs.
- Adding Foundry is a real project — Azure foundation + data pipeline + Foundry agent + Copilot Studio integration + governance uplift.
- Cost steps up significantly — typical incremental build of $60K–$120K, plus Azure consumption.
- The client now has an Azure subscription and real engineering dependencies. Plan for it.
---
Next up: Module 10 — Shipping, Measuring, Iterating. How to close out the project, do the capstone, and plan what comes next.
---
Time: ~20 min Goal: Practice recognizing the graduation moment and scoping the Pattern 2 addition.
---
For each signal, decide: Yes, graduate to Foundry now / Not yet, stay in Copilot Studio / Need more info. One-sentence why.
- KB has grown to 450 docs and relevance is still good. Growth rate is ~10 docs/week.
→ ______________
- Client wants to expose a customer-facing version of their existing internal agent.
→ ______________
- Client is asking for more trigger phrases and better fallback messages.
→ ______________
- An insurance broker has asked for an architecture review because of a new customer-data use case.
→ ______________
- Users are asking questions that need to search a 40,000-document legal archive.
→ ______________
- Deflection rate is 65%; client wants to push it to 85%+ through better answer quality.
→ ______________
- Client wants to deploy the agent behind a firewall, with no outbound calls to Microsoft's public APIs.
→ ______________
- A new business line was acquired with their own document set and processes.
→ ______________
A client wants to add a new capability to their existing Copilot Studio helpdesk agent: a contract review assistant that searches 8,000 past contracts (PDFs in SharePoint), extracts specific clauses, compares to a template, and flags issues. Internal use only. Users ask via Teams.
Sketch the architecture. Include: UI, Copilot Studio, Foundry components, Azure AI Search, any model choices, governance.
Your architecture: ```
```
The client in Exercise 2 has already paid $25K for the Copilot Studio helpdesk. Now they're hearing you want $80K more for this Foundry-based contract review capability. They balk.
Write a 90-second response that reframes the investment.
Your response: ```
```
---
Exercise 1:
- Not yet — 450 is high but not yet degraded. Plan for the graduation, but don't start the Foundry build yet. Revisit at 500 or when quality issues appear.
- Yes, graduate. Customer-facing = real reliability, governance, evaluation needs. Pattern 2 or 3 depending on UX requirements.
- Not yet. This is iteration on the existing agent, not a ceiling. Fix it in Copilot Studio.
- Need more info. What are they concerned about? If it's BAA, Foundry with BAA can help. If it's about general architecture, maybe a review satisfies them. Don't rebuild unless you have to.
- Yes, graduate. 40K docs = Foundry IQ + Azure AI Search. Copilot Studio can't do this well.
- Not yet. 65% to 85% is usually a content / topic / prompt tuning problem, not an architecture one. Exhaust Copilot Studio optimization first.
- Yes, graduate — specifically to Foundry Local. Firewall / no-public-API = on-prem inference. Foundry Local is the answer.
- Not yet. Adding new content to an existing agent is a Copilot Studio extension, not a Foundry project. Unless the new content is also at 500+ docs or has special requirements, stay in Pattern 1.
Exercise 2 — sample architecture:
``` [User in Teams] │ └─► [Copilot Studio Orchestrator Agent] │ │ │ └─► [Original Helpdesk topics — unchanged, Pattern 1] │ └─► [Contract Review topic] │ └─► HTTPS API call ─► [Foundry Agent — Contract Review] │ ├─► [Foundry IQ + Azure AI Search] │ │ │ └─► [Index of 8,000 contracts │ with metadata: date, │ counterparty, contract type, │ key clauses pre-extracted] │ ├─► [GPT-5 (for reasoning)] │ [+ specialized clause-extraction │ prompts / tools] │ ├─► [Content safety: legal privilege filter] │ └─► [Observability: log every query, flagged findings, citations]
[Governance across all of above: Purview sensitivity labels on contracts (privileged, confidential, etc.); DLP policy prevents Foundry outputs from being posted to non-business connectors; audit log of who asked what] ```
Key architectural notes:
- Contracts stay in SharePoint as source of truth; they're indexed in Azure AI Search for fast retrieval, not duplicated permanently
- Pre-extracting common clauses (indemnification, term, limitation of liability, etc.) at ingest time makes query-time performance much better
- Citations are critical — every answer links back to specific contract pages
- The orchestrator keeps the user experience unified in Teams while the backend is completely different
Exercise 3 — sample response:
> "I get it — $80K on top of the $25K already spent feels like a lot. Here's how I'd frame it. The $25K Copilot Studio agent solved a specific problem — internal helpdesk for handbook-type questions. It does that very well, and it's paid for itself already in Rachel's time. What we're now talking about is a different problem. Searching 8,000 contracts with semantic understanding, extracting clauses, flagging issues — that's not an extension of what we built. It's a new capability that needs different architecture. And it's worth more to the business: every contract review your legal team does faster or more accurately is direct value. One missed clause in a contract can cost more than this entire engagement. The $80K funds a system that pays back in the first 6–12 months of contract review cycles. If the value isn't there, we can scope it smaller — a $40K version that only handles your top 3 contract types. But rebuilding it on top of the existing Copilot Studio agent would be pouring money into a platform that wasn't designed for this. Does that land?"
Why this works: validates the number-shock honestly, separates the two investments (solved problem vs. new problem), sizes the value, offers a smaller option, frames "rebuild in Copilot Studio" as the actual bad decision.
---
Check yourself: Can you look at a client situation and cleanly articulate whether (and why) Foundry belongs in the picture, with a working sketch of what the architecture looks like? Ready to ship in Module 10.
Previous: Build It in Copilot Studio (Step-by-Step) · Next: Shipping, Measuring, Iterating