Copilot & Foundry: The Microsoft AI Stack for Small Business · Lesson 5 of 10

How They Fit Together: Architecture Patterns

Time: ~30 min reading + ~15 min worksheet Goal: Learn the three real-world patterns that show all three tiers working together. Internalize the decision tree. Stop treating Copilot Studio and Foundry as either/or.

---

The Core Insight

New consultants treat Copilot Studio and Foundry as competing options. Experienced ones treat them as layers of the same stack.

Microsoft designed them to interoperate. Copilot Studio can call Foundry. Foundry agents can be exposed through Copilot Studio front-ends. Both can share Azure AI Search indexes, both integrate with Purview for governance, both authenticate through Entra.

The real question is never "Copilot Studio OR Foundry?" It's "which parts of this problem belong to which tier?"

The Three Patterns

These three architectures cover roughly 90% of real engagements.

Pattern 1: Copilot Studio Only

The simplest pattern. Everything happens in Copilot Studio. Knowledge sources, topics, actions, connectors — all within the low-code tool.

When to use:

Internal use cases
Knowledge base under 500 docs
Standard integrations covered by Power Platform connectors
Volume fits in Copilot Studio's pricing model
No custom model needed
Governance covered by Purview / Power Platform defaults

Who builds it: A maker or consultant with Copilot Studio skill. No Foundry, no Azure development.

Typical cost:

Build: $5K–$30K
Ongoing Microsoft: Covered by M365 Copilot or modest Copilot Studio capacity

Example: The Northside HVAC helpdesk agent we'll build in Module 8.

Architecture diagram (text version): ``` [User in Teams] ─────► [Copilot Studio Agent] ─────► [SharePoint, Dataverse, Connectors] │ └─────► [Actions: create ticket, send email, etc.] ```

Pattern 2: Copilot Studio Front-End, Foundry Back-End

The most common pattern for serious SMB work. Copilot Studio handles the user experience and basic orchestration; Foundry handles the heavy lifting — serious RAG, specialized model choice, custom logic.

When to use:

Knowledge base above 500 docs
Need a model other than the OpenAI default
Need advanced grounding (Foundry IQ + Azure AI Search)
Need custom evaluation, observability, or safety filters
Want to reuse existing Azure investments
User base lives in Teams/M365 so front-end should feel native

Who builds it: A maker (for the Copilot Studio layer) and a developer (for the Foundry layer). Often the same consultant wearing two hats; sometimes a fusion team.

Typical cost:

Build: $40K–$120K
Ongoing: Azure consumption + Copilot Studio capacity, typically $500–$3K/month

Example: An internal research agent for a law firm. Lawyers chat with it in Teams (Copilot Studio). Under the hood, Foundry + Azure AI Search indexes 20,000 past briefs and serves RAG-grounded answers.

Architecture diagram (text version): ``` [User in Teams] ─────► [Copilot Studio Agent] │ └─────► HTTP/API call ─────► [Foundry Agent] │ ├─► [Foundry IQ + Azure AI Search] ├─► [Chosen LLM from catalog] └─► [Content safety, evaluation] ```

Pattern 3: Foundry Only (with Custom Front-End)

The pro pattern. No Copilot Studio. The agent is built entirely in Foundry, with a custom UI — a web app, a mobile app, or embedded in a product.

When to use:

Customer-facing product (not internal)
Need total control over UX
Integrating into an existing customer application
Extreme scale or latency requirements
Consumer-grade product expectations (custom branding, A/B testing, etc.)

Who builds it: Real software engineering team. Multi-month project with discovery, design, build, test, launch phases.

Typical cost:

Build: $100K–$500K+
Ongoing: Azure + engineering maintenance, typically $2K–$20K/month

Example: An insurance startup's customer-facing claims triage bot. Lives in their mobile app. Expected to handle 100K+ conversations/month. Custom brand, SLAs, full engineering lifecycle.

Architecture diagram (text version): ``` [Customer App/Website] ─────► [Custom UI] │ └─────► [Foundry Agent Service] │ ├─► [Azure AI Search] ├─► [Multiple LLMs orchestrated] ├─► [Custom tools/functions] ├─► [Content safety] └─► [Observability, evaluation] ```

The Decision Tree

Here's how to pick. Read top to bottom; stop at the first "yes."

Is this a single-user productivity task (email, doc drafting, meeting summary)?

→ M365 Copilot. Don't overbuild.

Is there existing SaaS that already does this (AP automation, meeting transcription, clinical documentation)?

→ Buy it. Not a Microsoft stack question.

Is it an internal agent, simple-to-moderate scope, sub-500 docs, M365-grounded?

→ Copilot Studio only (Pattern 1).

Does it need more than Copilot Studio can do — large KB, non-OpenAI model, advanced RAG, custom evaluation?

→ Copilot Studio + Foundry (Pattern 2).

Is it customer-facing, scale-sensitive, or embedded in a product?

→ Foundry only (Pattern 3).

Does the client have strict on-prem / data residency requirements?

→ Foundry with Foundry Local in whichever pattern fits.

Uncertain?

→ Start with Copilot Studio. You can always add Foundry later. You rarely can easily step back from a full Foundry build.

Agent-to-Agent (A2A) and Orchestrator Patterns

Once you have more than one agent, they can collaborate. This is called agent-to-agent (A2A) or multi-agent orchestration.

The orchestrator pattern: A "front door" agent receives every request, decides which specialist agent should handle it, and routes.

``` [User] ─► [Orchestrator Agent] ─┬─► [HR Specialist Agent] ├─► [IT Specialist Agent] ├─► [Finance Specialist Agent] └─► [Sales Specialist Agent] ```

This is the right answer when a client asks for "one bot for everything" (see Module 3's trap). Orchestrator = single entry point, specialists = actual intelligence.

A2A pattern: Agents call each other directly when they need help. More flexible, more complex to govern. Better for autonomous workflows than user-facing ones.

Both patterns are supported across Copilot Studio and Foundry. The choice of where each agent lives follows the decision tree.

The Governance Overlay

Whichever pattern you pick, Purview sits above it all:

Applies sensitivity labels across data sources
Enforces DLP policies on what agents can send/receive
Logs all interactions for audit
Supports DSPM for AI (posture management)
Enables data lifecycle management (retention, deletion)

For regulated clients, this is not optional. Budget for Purview configuration time in any real engagement — typically 10–20% of total build time.

How to Pick in Real Life

When you're sitting across from a client, use this mental checklist:

How many users will interact with the agent?
How many documents in the knowledge base?
Internal or customer-facing?
Standard M365 flows or custom business logic?
Existing SaaS alternatives they've considered?
Any regulatory/data residency constraints?
Budget comfort zone?

Two minutes of those questions and you can pick the pattern. Ten minutes of follow-up and you can scope the engagement.

The Graduation Pattern

One last mental model. The right approach for many SMBs is:

Year 1: M365 Copilot + a Copilot Studio agent or two. Low cost, prove value, build trust.

Year 2: Expand Copilot Studio — more agents, more connectors, maybe Power Automate flows with AI steps.

Year 3: First Foundry project. A real customer-facing use case, or a regulated-data project that graduated past Copilot Studio's ceiling.

Most SMBs will never need year 3. That's fine. The ones who do will need it because of an actual demand, not because a consultant sold it to them prematurely.

---

Key Takeaways

Three tiers are layers, not alternatives. Microsoft designed them to work together.
Pattern 1: Copilot Studio only. Most common for internal SMB agents.
Pattern 2: Copilot Studio front-end + Foundry back-end. The workhorse pattern for serious work.
Pattern 3: Foundry only with custom UI. Customer-facing, scale-sensitive, product-grade.
Orchestrator agents are the right answer to "we want one bot for everything."
Purview sits over all patterns as the governance layer.
Start simple, graduate deliberately. Year 1 Copilot Studio, Year 3 maybe Foundry.

---

Next up: Module 6 — Pricing, Licensing, TCO. The part that gets glossed over and kills deals.

---

Time: ~15 min Goal: Drill the decision tree until it's reflexive.

---

Exercise 1: Pick the Pattern (8 min)

For each engagement, pick Pattern 1 (Copilot Studio only), Pattern 2 (Copilot Studio + Foundry), or Pattern 3 (Foundry only with custom UI). Give one-sentence justification.

40-person construction firm. Internal bot for safety questions from a 60-page handbook. Deployed to Teams.