Build, Buy, or Extend

The cheapest agent is the one you do not build

Prebuilt agent sources

Before building anything, check what already exists:

Source	What You Get	Examples
D365 prebuilt AI	Ready-to-use AI features embedded in Dynamics 365 apps	Sales forecasting in D365 Sales, sentiment analysis in D365 Customer Service, cash flow predictions in D365 Finance
M365 Copilot agents	Built-in agents available to all Copilot-licensed users	Researcher (deep web research), Analyst (advanced data analysis), Facilitator (meeting follow-up)
Copilot Studio templates	Pre-configured agent templates you can customise	IT helpdesk, HR FAQ, employee onboarding, customer support
ISV and partner agents	Third-party agents from AppSource and partner marketplace	Industry-specific agents (healthcare scheduling, legal document review, financial compliance)

The decision matrix

Build vs buy decision matrix

Feature	Use Prebuilt	Extend M365 Copilot	Build in Copilot Studio	Build in Foundry
Time to value	Hours to days	Days to weeks	Weeks to months	Months
Cost	Included in licence	Licence + minor dev effort	Licence + moderate dev effort	Licence + significant dev + compute
Customisation	None to minimal	Moderate — plugins, connectors, prompts	High — full agent design within low-code	Full — model, tools, orchestration, UX
Maintenance	Microsoft handles everything	Shared — Microsoft platform, your extensions	Shared — platform updates, your agent logic	You own model ops, drift, retraining
Technical skill	Admin or end user	Power user or developer	Citizen dev with pro-code escape	AI engineer, data scientist, developer
Data access	Native D365/M365 data only	M365 Graph + custom connectors	Dataverse + connectors + custom APIs	Any Azure data source, Fabric, external
Best for	Standard features that fit as-is	M365 productivity needs + org-specific data	Customer-facing agents, process automation	Complex reasoning, custom models, multi-agent

The five-step decision hierarchy

Work through these steps in order. Stop as soon as a step meets the requirement:

Step 1: Does a prebuilt agent or feature already exist? Check D365 embedded AI, M365 Copilot agents, Copilot Studio templates, and ISV marketplace. If the prebuilt feature covers 80%+ of the requirement, use it.

Step 2: Can you extend M365 Copilot? If users need AI assistance within their M365 workflow and the gap is data access or a specific action, extend Copilot with a declarative agent, Graph connector, or API plugin.

Step 3: Should you build in Copilot Studio? If you need a standalone agent with channel support (web, Teams, phone), process automation, or customer-facing interaction — and the logic does not require custom models — build in Copilot Studio.

Step 4: Should you build in Foundry? If you need code-first orchestration, custom model hosting, multi-agent coordination, or access to Azure-scale compute and data — build in Foundry.

Step 5: Do you need a custom AI model? Only if general-purpose models cannot handle your domain after prompt engineering and RAG have been tried. This is the most expensive and maintenance-heavy option.

Platform constraints to know

Platform	Key Constraints
Copilot Studio	Message size limits (variable by channel). Canvas topics limited to ~200 nodes. No native model hosting — calls external models via HTTP. Data must be in Dataverse or accessible via connector. Environment-level DLP policies apply.
Microsoft Foundry	Compute quotas per subscription (TPM limits by model and region). Model deployment requires approval for certain models. Network isolation requires private endpoints for production. Cost scales with usage — no flat-rate pricing for compute.
M365 Copilot (extensions)	All data access goes through Microsoft Graph — no direct database queries. Declarative agents limited to instructions, knowledge, and actions. API plugins must follow the OpenAPI spec. Tenant admin must approve third-party plugins.
D365 Embedded AI	Features are per-app — no cross-app AI orchestration natively. Configuration only, no custom logic. Availability varies by D365 licence tier. Model retraining is not user-controlled.

When custom AI models are justified

Do not jump to custom models. Follow this escalation path:

Approach	When to Use	Example
Prompt engineering	Standard text generation, summarisation, classification with a general model	Summarise customer service cases using GPT-4o with a well-crafted system prompt
RAG (Retrieval-Augmented Generation)	Domain knowledge needed but the model’s reasoning is sufficient	Agent that answers questions about internal policies by retrieving from a SharePoint index
Fine-tuning	Domain terminology, tone, or patterns that prompts and RAG cannot capture	Medical coding agent that must use precise ICD-10 codes consistently
Train from scratch	Truly novel domain with no transfer learning benefit, or edge/embedded inference	Custom defect detection model for a specific manufacturing process using proprietary sensor data

💡 The RAG-before-fine-tune rule

This is a critical exam concept. Before investing in model customisation, exhaust the cheaper options in order:

1. Prompt engineering — Refine the system prompt, add examples (few-shot), structure the output format. Cost: near zero. Time: hours.
2. RAG — Ground the model with retrieved documents from Azure AI Search, Fabric, or Dataverse. The model reasons over your data without being retrained. Cost: search index + retrieval compute. Time: days to weeks.
3. Fine-tuning — Train the model on your domain-specific data to adjust its weights. Needed when the model consistently misuses terminology, misses domain patterns, or requires a specific output style that prompts cannot enforce. Cost: training compute + ongoing retraining. Time: weeks.
4. Train from scratch — Only when no pretrained model transfers to your domain. Extremely rare for business solutions. Cost: massive compute + large labelled dataset. Time: months.

The exam will present scenarios where a candidate might jump to fine-tuning. The correct answer is almost always “try RAG first.” Fine-tuning is justified only when RAG is demonstrably insufficient.

🏛️ Adrienne’s credit risk agent — a hybrid architecture

Adrienne Cole (VP Enterprise Tech, Vanguard Financial Group) needs an agent that assesses credit risk for commercial loan applications.

Step 1: Prebuilt? D365 Finance has credit management features but they are rule-based, not AI-powered. Not sufficient for the nuanced risk assessment Vanguard needs.

Step 2: Extend M365 Copilot? The agent needs to access financial models and external credit bureau data — not M365 data. Copilot extensions do not fit.

Step 3: Copilot Studio? The agent needs custom model inference (risk scoring) that Copilot Studio cannot host natively. However, the user interface — where loan officers interact with the agent — is a great fit for Copilot Studio.

Step 4: Foundry? Yes. The risk scoring model lives in Foundry, with access to Azure SQL (historical loan performance), external credit bureau APIs, and a Fabric lakehouse of market indicators.

Step 5: Custom model? Adrienne’s team tries RAG first — retrieve historical loan decisions and let GPT-4o reason over them. It works for 80% of cases but struggles with Vanguard’s proprietary risk weighting methodology. Dev Patel (AI platform engineer) fine-tunes a model on 100,000 historical risk assessments. The fine-tuned model achieves 94% agreement with senior analysts.

Final architecture:

• Front-end: Copilot Studio agent in Teams — loan officers submit applications and receive risk assessments
• Back-end: Foundry-hosted fine-tuned model performs risk scoring, orchestrated by a Foundry agent that retrieves data from multiple sources
• Integration: Copilot Studio calls Foundry via HTTP connector. Results written back to D365 Finance for the loan record.

Marcus Webb (CISO) adds guardrails: all risk scores above “high” require human analyst review before the recommendation reaches the loan officer. Yuki Tanaka (compliance) ensures every assessment is logged with full explainability for regulatory audit.

Key terms

Question

What is the five-step decision hierarchy for AI component selection?

Click or press Enter to reveal answer

Answer

1. Use prebuilt (D365/M365/ISV). 2. Extend M365 Copilot (declarative agents, plugins, connectors). 3. Build in Copilot Studio (low-code custom agents). 4. Build in Foundry (code-first, custom models). 5. Create custom models (fine-tune or train from scratch). Stop at the first step that meets the requirement.

Click to flip back

Question

What is the RAG-before-fine-tune rule?

Click or press Enter to reveal answer

Answer

Before investing in model customisation, exhaust cheaper options in order: prompt engineering, then RAG (retrieval-augmented generation), then fine-tuning, then training from scratch. Fine-tuning is only justified when RAG demonstrably cannot handle domain-specific terminology, patterns, or output requirements.

Click to flip back

Question

When is a custom AI model justified over using a general-purpose model with RAG?

Click or press Enter to reveal answer

Answer

Custom models are justified when: the domain has proprietary patterns that general models cannot learn from prompts or retrieved documents, precise terminology is critical and RAG retrieval introduces inconsistency, edge or embedded inference requires a small specialised model, or the task has no transfer learning benefit from pretrained models.

Click to flip back

Question

What are the key constraints of building agents in Copilot Studio vs Microsoft Foundry?

Click or press Enter to reveal answer

Answer

Copilot Studio: no native model hosting, data must be in Dataverse or via connector, topic node limits, environment DLP policies. Foundry: compute quotas per subscription (TPM limits), model deployment approvals, cost scales with usage, requires private endpoints for production. Copilot Studio is configuration-first; Foundry is code-first.

Click to flip back

Knowledge check

Knowledge Check

A D365 Customer Service team wants an AI agent that summarises case history and suggests next best actions using data already in Dataverse. No custom model is needed. Which approach is correct?

ABuild a custom agent in Microsoft Foundry with a fine-tuned modelBExtend M365 Copilot with a Graph connector to D365 dataCBuild an agent in Copilot Studio that uses Dataverse data and a general-purpose modelDUse the prebuilt D365 Customer Service AI features without customisation

Check Answer

Knowledge Check

Adrienne's team tried RAG for the credit risk agent but it struggles with Vanguard's proprietary risk weighting methodology. What should they do next?

AImprove the RAG retrieval with better chunking and re-rankingBTrain a custom model using the proprietary financial data and assessment patternsCAdd a domain-specific classification layer on top of the existing RAG pipelineDFine-tune a model on historical risk assessments

Check Answer

Knowledge Check

A company wants to add a 'query our product catalogue' capability to M365 Copilot so employees can ask questions about products in natural language. The catalogue lives in a third-party PIM system. What is the simplest sufficient approach?

ASet up a Graph connector to index the PIM data, then create a declarative agentBBuild a custom Foundry agent that queries the PIM APICBuild a Copilot Studio agent with an HTTP connector to the PIM APIDFine-tune a model on the product catalogue data

Check Answer

---

🎬 Video coming soon

Next up: Generative AI and Prompt Design — design effective prompts and understand how generative AI fits into your business solution architecture.