Plan AI-Powered Business Solutions
Domain 1 is where the architect earns their title: deciding whether AI fits, which Microsoft platform should carry it, and whether it pays off. It carries a weight of 25–30% on the outline in effect until November 15, 2026, rising to 35–40% on the upcoming November 16, 2026 outline, which makes it the largest domain on the new exam. Expect scenario questions that hand you a business problem and ask for the BEST or MOST cost-effective approach.
Microsoft’s own adoption guidance repeats one rule: choose the option that meets the requirement with the least customization and the least operational responsibility. Use what exists, then configure, then extend, and only then build. Most wrong answers on this domain are technically possible but over-engineered.
1.1 Analyze requirements for AI-powered business solutions
Decide whether an agent fits the task, judge whether the grounding data is fit for purpose, and shape data so other AI systems can use it.Assess agents for task automation, data analytics, and decision-making
Before you pick a product, classify the work. An agent is a good fit when the task involves language, judgment over unstructured content, or multistep coordination across systems. It is a poor fit when a deterministic rule, a report, or a classic workflow already solves the problem more cheaply and predictably.
| Work pattern | Good agent signals | Red flags (use something simpler) | Typical Microsoft fit |
|---|---|---|---|
| Task automation | Unstructured inputs (email, forms, chat), variable steps, needs to call several systems, human hands off repetitive triage. | Fixed inputs and fixed steps with no interpretation; a cloud flow or business rule is enough. | Copilot Studio agent with agent flows or tools; autonomous agents triggered by events. |
| Data analytics | Users ask ad hoc natural-language questions over governed data; need summaries and explanations, not just numbers. | Same KPI every week for the same audience; a Power BI report is cheaper and auditable. | Copilot in Power BI or Fabric data agents; Microsoft 365 Copilot over shared files. |
| Decision-making | Recommendation with explanation where a human approves; many weak signals to weigh. | High-stakes, regulated decisions requiring full explainability with no human review. | Agent recommends, human approves (human in the loop); predictive models in Foundry or AI Builder for scoring. |
Autonomy level
Map each task to assist (suggests), act with approval (drafts and waits), or act autonomously (executes within guardrails). Higher autonomy demands stronger identity, logging, and rollback.
Measurable outcome
Every candidate task needs a baseline: handling time, error rate, backlog size, or conversion. No baseline means no ROI story later in 1.3.
Risk and reversibility
Ask what happens if the agent is wrong. Reversible, low-impact actions are good first candidates; irreversible financial or legal actions need approvals.
Review grounding data
Generative answers are only as good as the content the agent retrieves. Grounding data review is a requirements activity, not a post-launch fix. The exam lists five quality dimensions; know what each one means and how you would test it.
| Dimension | Question to ask | How you check it | Typical remediation |
|---|---|---|---|
| Accuracy | Is the content factually correct? | Sample documents against the system of record; have subject matter experts validate. | Fix at the source, assign content owners, remove contradicting copies. |
| Relevance | Does it actually answer the questions users will ask? | Build a test question set from real tickets or chats and measure retrieval hits. | Narrow the knowledge scope; exclude unrelated libraries; add missing content. |
| Timeliness | Is it current, and how quickly do changes reach the agent? | Check last-modified dates, refresh or index schedules, and versioning. | Archive outdated policies; set review dates; choose live connections over static uploads when freshness matters. |
| Cleanliness | Is it free of duplicates, noise, broken formatting, and conflicting versions? | Look for duplicate files, scanned images without text, inconsistent terms. | Deduplicate, convert to text-friendly formats, standardize terminology, add metadata. |
| Availability | Can the agent reach it securely, with the right permissions, when needed? | Confirm connectors, authentication, licensing, network paths, and permission trimming. | Use supported connectors; fix oversharing before launch; plan for source outages. |
Microsoft 365 Copilot and SharePoint-grounded agents respect the user’s existing permissions. If a site is shared with everyone, the agent can surface it to everyone. Review permissions and sensitivity labels with Microsoft Purview before broad rollout, not after a leak.
Organize business solution data for other AI systems
Architects increasingly design data once and serve it to many AI consumers: Microsoft 365 Copilot, Copilot Studio agents, Foundry agents, and analytics. Good organization makes data discoverable, permission-aware, and chunkable.
Structure and semantics
- Keep transactional business data in Dataverse or the system of record with clear table and column descriptions; AI uses names and descriptions to reason.
- Unify analytical data in Microsoft Fabric / OneLake and expose curated semantic models.
- Define a shared business glossary so “customer,” “account,” and “case” mean the same thing everywhere.
Access paths for AI
- Microsoft 365 Copilot connectors bring external content into Microsoft Graph so Copilot and agents can ground on it.
- Azure AI Search indexes (chunked, vectorized, with metadata filters) serve Foundry and Copilot Studio retrieval.
- Connectors, APIs, and MCP servers expose live actions and data to agents.
Document hygiene for retrieval
- Prefer text-based formats with headings; break giant documents into topic-sized sections.
- Tag content with owner, product, region, and effective date metadata.
- One authoritative version per policy.
Governance carried with the data
- Sensitivity labels and permissions must travel with the content into indexes.
- Record lineage so you can explain where an answer came from.
- Classify data residency needs early; they constrain region choices later.
“Use AI” is not always the answer. If a scenario describes a fixed, rule-based process, the BEST answer is often a flow or business rule, not an agent.
Do not confuse relevance (does it answer the question) with accuracy (is it correct) or timeliness (is it current). Scenario wording such as “last year’s price list” points to timeliness; “three conflicting versions” points to cleanliness.
Fine-tuning does not fix bad grounding data. Fix the data first.
1.2 Design overall AI strategy
Follow the CAF AI adoption path, pick the right platform for each agent, plan multi-agent designs, and set standards for prompts, models, and the AI Center of Excellence.Cloud Adoption Framework AI adoption process
The Cloud Adoption Framework (CAF) for Azure treats AI as an adoption journey. The current guidance starts with an executive AI strategy foundation, then moves through Plan, Ready, and a combined Govern, Secure, Manage stage. Each step builds on the one before.
| Stage | Core question | Architect deliverables |
|---|---|---|
| Strategy | Where can AI create value, and is it worth it? | Executive sponsorship and an AI charter with business outcomes and decision rights; central ownership of AI policy (for example an AI CoE); approved workforce access paired with training; prioritized use cases; choice between enhancing individual efficiency and automating business functionality; data foundation needs. |
| Plan | How do we move use cases into production? | Skills assessment and gap plan, proofs of concept, delivery roadmap, responsible AI checkpoints, resourcing. |
| Ready | Is the environment prepared? | How AI workloads fit into the Azure landing zone (networking, identity, regions, quotas); Power Platform environment strategy; reference architectures. |
| Govern | What rules apply and how do we enforce them? | Responsible AI policies, risk assessment, Azure Policy and Power Platform DLP, model and agent inventory. |
| Secure | How do we protect AI assets and data? | Identity for agents, threat protection, data protection with Purview, prompt-injection mitigations. |
| Manage | How do we operate it over time? | Monitoring, cost management, model lifecycle and retirement, business continuity. |
CAF also publishes an AI agent adoption series that applies the same thinking to agents across four areas: plan for agents (business plan, technology plan, organizational readiness, data architecture), govern and secure agents, build agents, and manage agents.
CAF guidance says to approve the AI solution that meets requirements with the least operational responsibility: SaaS (Microsoft 365 Copilot, extensibility, Copilot Studio) before PaaS (Foundry, Fabric, Azure Machine Learning) before infrastructure (bring your own model on VMs or AKS). Infrastructure should not be the default.
Strategy for building AI and agents
CAF frames two broad purposes. Enhance individual efficiency: Microsoft 365 Copilot, in-product Copilots (Dynamics 365, Power Platform, Fabric, GitHub, Azure), and role-based Copilots and agents. Automate business functionality: agents built with Microsoft 365 Copilot extensibility, Copilot Studio, or Foundry. A sound agent strategy also defines which teams may build what (makers versus pro developers), which environments they build in, how agents are approved and published, and how success is measured.
Build custom agents vs extend Microsoft 365 Copilot
This is the most tested decision in the domain. Start where the users already work and move right only when a requirement forces you to.
| Option | Orchestrator and model | Choose it when | Trade-offs |
|---|---|---|---|
| Declarative agent for Microsoft 365 Copilot (Agent Builder, Copilot Studio, or Microsoft 365 Agents Toolkit) | Copilot’s own orchestrator and foundation models | Users live in Microsoft 365 apps; you need custom instructions, knowledge (SharePoint, OneDrive, Teams, Copilot connectors), and some actions; you want to inherit Microsoft 365 security, compliance, and responsible AI controls. | No choice of model or orchestration; user-initiated only (no proactive triggers); requires Microsoft 365 Copilot licensing or metered usage. |
| Copilot Studio custom agent | Copilot Studio generative orchestration (managed SaaS) | Low-code business process automation; multiple channels (Teams, web, Microsoft 365 Copilot, contact center); autonomous triggers; agent flows; connectors to Dataverse and 1,000+ services; makers own it. | Billed by usage (Copilot Credits); governed through Power Platform environments and DLP; less control than pro-code. |
| Custom engine agent built pro-code with Microsoft Foundry (Foundry Agent Service) or the Microsoft 365 Agents SDK | Your own orchestration and your choice of models (LLM, SLM, fine-tuned, industry) | Complex business logic, specific or fine-tuned models, multimodal needs, strict latency/scale requirements, external channels, group collaboration in Teams channels or meetings. | You own hosting, security, compliance, responsible AI evaluation, and ALM; needs pro-developer skills. |
“Inside Microsoft 365, use Copilot’s brain” → declarative agent. “Low-code, many channels, business process, autonomous” → Copilot Studio. “Bring my own model or orchestration, full control” → Foundry custom engine agent. A Copilot Studio or Foundry agent can still be surfaced inside Microsoft 365 Copilot and Teams.
Multi-agent solutions with Microsoft 365 Copilot, Copilot Studio, and Foundry
Split work into multiple agents when one agent’s instructions, tools, or knowledge become too broad to orchestrate reliably, when different teams own different domains, or when parts need different models or security boundaries. Do not split just because you can; every hop adds latency, cost, and failure points.
| Pattern | How it works | Microsoft building blocks |
|---|---|---|
| Orchestrator with specialists | A primary agent receives the request and delegates to specialist agents chosen by their descriptions. | Copilot Studio child agents (lightweight, inside the parent) and connected agents (separately published Copilot Studio agents, Foundry agents, Fabric data agents, Microsoft 365 Agents SDK agents, or A2A agents). |
| Front door in Microsoft 365 | Users start in Microsoft 365 Copilot or Teams; specialized agents do the domain work. | Copilot Studio or custom engine agents published to Microsoft 365 Copilot and Teams. |
| Sequential pipeline | Each agent transforms the output of the previous one (intake, enrich, validate, act). | Agent flows in Copilot Studio; workflows in Foundry Agent Service. |
| Concurrent fan-out | Several agents work on the same input in parallel; results are merged. | Pro-code orchestration in Foundry. |
| Handoff | Control passes to the agent (or human) best suited for the next step. | Copilot Studio transfer to agent or to a human in Dynamics 365 Contact Center. |
| Cross-platform collaboration | Agents built on different frameworks or by other vendors cooperate. | Agent2Agent (A2A) protocol: agents discover each other through an agent card and delegate tasks. |
A2A: agent ↔ agent
An open protocol for one agent to discover another (via its agent card), delegate a task, and receive results, regardless of who built it or where it runs. Use it when the other party is an agent with its own reasoning.
MCP: agent ↔ tools and data
Model Context Protocol standardizes how an agent discovers and calls tools, resources, and prompts exposed by an MCP server. Use it when you want to plug reusable capabilities into many agents (Copilot Studio, Foundry, Microsoft 365 Copilot).
When a Copilot Studio agent delegates to an external agent, you are responsible for data flows and data sharing, the external agent’s quality and security, permissions and approvals, and observability, identity, traceability, and human oversight. Write precise descriptions for every child or connected agent; the orchestrator routes based on them.
Use cases for prebuilt agents
Prebuilt agents deliver value fastest because Microsoft owns the model, orchestration, and updates. Check them first in every build-vs-buy discussion.
Microsoft 365 Copilot
Built-in agents such as Researcher (multistep research across work data and web) and Analyst (data analysis over files), plus agents in Teams and SharePoint, cover knowledge work without custom development.
Dynamics 365 and role-based
Sales, customer service, contact center, finance, and supply chain apps include agents for qualification, case handling, knowledge, and supplier communication. Role-based Copilots and agents serve sales, service, finance, and security roles.
Templates
Copilot Studio and Foundry offer agent templates. A template is a starting point you customize and own; it is not the same as a Microsoft-maintained prebuilt agent.
Solution rules and constraints: Copilot Studio, Foundry, Foundry Tools
| Platform | What it is for | Constraints to design around |
|---|---|---|
| Copilot Studio | SaaS low-code agents, topics, tools, knowledge, agent flows, multichannel publishing. | Lives in a Power Platform environment (region, Dataverse, DLP policies, managed environments); usage billed in Copilot Credits; documented limits on orchestration and knowledge sources; connector availability and authentication; ALM through solutions and pipelines. |
| Microsoft Foundry | PaaS for pro-code agents and AI apps: Foundry Models catalog, Foundry Agent Service, evaluations, fine-tuning, model router, content safety. | Azure subscription, RBAC, and networking; model availability differs by region and deployment type; quota (tokens per minute) and throughput planning; you own evaluation, monitoring, and responsible AI testing; pay for model usage and supporting services. |
| Foundry Tools (formerly Azure AI services) | Prebuilt APIs for language, speech, vision, translation, document intelligence, and content safety, plus Azure AI Search for retrieval. | Task-specific, not general reasoning; per-transaction or tier pricing; regional availability; some features need custom training data (for example custom extraction or classification models). |
Generative AI and knowledge sources in Copilot Studio agents
Generative orchestration is the default. The agent picks topics, tools, child or connected agents, and knowledge by their descriptions, can combine several in one answer, and generates questions to fill missing inputs. Classic orchestration routes by trigger phrases to a single topic and uses knowledge mainly as a fallback (the conversational boosting system topic).
Common knowledge sources
- Public websites
- SharePoint sites and OneDrive files (answers are trimmed to the signed-in user’s permissions)
- Uploaded files
- Dataverse tables
- Microsoft 365 Copilot connectors and enterprise systems through connectors
- Azure AI Search and other custom data
Design choices
- Allow or block the model’s general knowledge; block it when answers must come only from approved sources.
- Write clear knowledge descriptions so the orchestrator searches the right source.
- Use authored topics for business-critical, deterministic paths; let generative answers handle the long tail.
- Uploaded files are a snapshot; live sources stay current.
When to create custom AI models
Customize in increasing order of cost and effort. Move to the next rung only when evaluation shows the current rung cannot meet the requirement.
| Approach | Solves | Does not solve | Choose when |
|---|---|---|---|
| 1. Prompt engineering | Tone, format, task framing, simple rules. | Missing or private knowledge. | Always first; cheapest and fastest to change. |
| 2. Retrieval-augmented generation (RAG) | Answers grounded in current, private, permission-aware content with citations. | Consistent style or narrow specialized behavior at scale. | Knowledge changes often or must be cited; the most common enterprise answer. |
| 3. Fine-tuning | Consistent style or schema, better tool selection, shorter prompts, specializing a smaller model to match a larger one. | Fresh facts (training is a snapshot); fine-tuning does not replace retrieval for changing knowledge. | You have quality labeled examples, prompts are bloated with few-shot examples, or latency/cost needs a smaller model. |
| 4. Custom or trained model | Prediction, classification, anomaly detection, or domain tasks no foundation model handles. | Anything a prebuilt service already covers. | Unique data and a non-generative task; use Azure Machine Learning, Fabric data science, Foundry Tools custom models, or AI Builder. |
Customized small language models (SLMs)
| Factor | Small language model (for example the Phi family) | Large language model |
|---|---|---|
| Best at | Narrow, well-defined tasks: classification, extraction, routing, short summaries. | Broad reasoning, open-ended generation, complex multistep planning. |
| Cost and latency | Lower per call; fast. | Higher per call; slower. |
| Deployment | Can run on devices, at the edge, or offline; easier to fine-tune. | Usually cloud-hosted. |
| Typical scenario | Factory-floor assistant with intermittent connectivity; high-volume ticket tagging; on-device privacy. | Contract analysis, research agents, multi-tool orchestration. |
A common pattern is to fine-tune an SLM on outputs from a larger model (teacher–student distillation) so a high-volume task runs cheaper while keeping acceptable quality, then validate against a held-out evaluation set.
Prompt library guidelines
A prompt library turns individual tricks into organizational assets. Treat prompts like code.
What every entry needs
- Clear name, purpose, and business owner
- Target audience or role and the app or agent it is tested with
- Input variables and an example of good output
- Version number, last review date, and change history
- Data sensitivity note (what may and may not be pasted in)
How to run the library
- Approval and review before publishing; retire stale prompts
- Categorize by department and task so people find them
- Retest when models or orchestrators change
- Collect usage and feedback to promote the best prompts
- Share through built-in prompt gallery features and training
Prompt engineering guidelines
| Technique | What to do | Why it helps |
|---|---|---|
| Goal, context, source, expectations | State the task, the background, which data to use, and the desired format and tone (the structure Microsoft teaches for Microsoft 365 Copilot prompts). | Removes ambiguity for end-user prompts. |
| System message or agent instructions | Define role, scope, boundaries, refusal behavior, and tone up front. | Consistent behavior across conversations. |
| Few-shot examples | Show one to a few input/output pairs. | Teaches format without training. |
| Clear structure and delimiters | Separate instructions from content with headings or markers. | Reduces confusion and some injection risk. |
| Decompose the task | Ask for steps in order or chain smaller prompts. | Improves accuracy on complex work. |
| Ground and cite | Instruct the model to answer only from provided sources and say when it doesn’t know. | Reduces fabricated answers. |
| Specify output format | Ask for a table, JSON schema, or word limit. | Makes output usable by people and downstream systems. |
| Iterate and evaluate | Test against a fixed question set and compare versions. | Evidence instead of opinion. |
Microsoft AI Center of Excellence elements
CAF describes the AI CoE as an internal team that prevents fragmented, ungoverned AI adoption and provides business and technical consultation.
Building the team
- Secure executive sponsorship (steering committee, access to leadership)
- Appoint a dedicated AI CoE leader
- Assemble a multidisciplinary team: business leaders, data scientists, ML engineers, governance, security, and AI operations experts
- Decide placement; extend an existing Cloud CoE when one exists instead of creating a silo
- Define the operating model: centralized early, moving to advisory as maturity grows
Responsibilities
- Define AI strategy
- Create intake and prioritization workflows for use cases
- Define and enforce AI standards, including responsible AI
- Lead pilot projects
- Develop AI skills
- Develop reusable assets (templates, patterns, prompt libraries)
- Measure and report outcomes (adoption, compliance, cycle time)
- Optionally manage shared AI services
AI solutions that span multiple Dynamics 365 apps
Cross-app scenarios, such as quote-to-cash or case-to-field-service, need a shared data layer and a coordinated agent design.
- Dataverse is the common data platform for customer engagement apps; finance and operations data can be surfaced through virtual tables and dual-write.
- Use each app’s built-in Copilot and agents first, then add a Copilot Studio agent (or connected agents) to orchestrate steps that cross app boundaries.
- Keep one business glossary across apps so AI interprets entities consistently.
- Plan security roles per app; an agent should never see more than the user or its own identity is allowed to.
- Plan end-to-end testing and ALM across all participating apps (covered in Domain 3).
Declarative agents use Copilot’s orchestrator and models. If the scenario requires a specific or fine-tuned model, custom orchestration, or proactive triggers, a declarative agent is wrong.
A2A connects agents to agents; MCP connects agents to tools and data. Swapping them is a classic distractor.
Fine-tuning is not the way to add frequently changing knowledge; RAG is.
The AI CoE should build on an existing Cloud CoE where possible and evolve from centralized to advisory, not the reverse.
A template is not a prebuilt agent: you own and maintain what you build from a template.
1.3 Evaluate costs and benefits
Build a credible ROI case with full TCO, choose build, buy, or extend, and use model router to balance cost and quality.ROI criteria, including total cost of ownership
ROI = (total benefits − total costs) ÷ total costs, over a defined period. Present payback period alongside it. The most common architecture mistake is counting license price as the whole cost.
Benefits
- Time saved per task × volume × loaded labor rate (only if the time is redeployed)
- Cost avoidance: fewer escalations, less outsourcing, deferred hiring
- Revenue impact: faster response, higher conversion, upsell
- Quality: lower error and rework rates, better first-contact resolution
- Risk reduction: compliance, fewer missed obligations
- Experience: CSAT, employee satisfaction, retention
TCO components
- Licenses (per user) and consumption (Copilot Credits, model tokens, metered usage)
- Azure services: AI Search, storage, networking, monitoring
- Build: design, development, integration, testing
- Data preparation and ongoing content curation
- Change management, training, and adoption programs
- Governance, security, and responsible AI reviews
- Operations: monitoring, evaluation, model upgrades, support
ROI analysis for a business process
- Baseline the current process: volume, handling time, cost per transaction, error rate.
- Define the target state: which steps the agent assists or automates and the expected deflection or time reduction.
- Estimate benefits conservatively, with a ramp-up curve for adoption.
- Estimate TCO for every component above over the same period (often three years).
- Calculate ROI and payback; run sensitivity analysis on adoption and accuracy.
- Pilot and measure real metrics, then update the model before scaling.
Worked example: invoice exception handling
Woodgrove processes 10,000 invoice exceptions per year at 20 minutes each. An agent drafts the resolution and a clerk approves it, cutting handling to 8 minutes. That saves 2,000 hours. At a loaded rate of $50 per hour, gross benefit is $100,000 per year.
Annual TCO estimate: consumption $15,000, Azure services $5,000, build amortized over three years $20,000, operations and governance $10,000, training $5,000, total $55,000.
ROI = ($100,000 − $55,000) ÷ $55,000 ≈ 82% per year. If adoption reaches only 50%, benefit drops to $50,000 and ROI turns negative, which is why sensitivity analysis and a pilot matter. (Numbers are illustrative only.)
Build vs buy vs extend
| Option | Examples | Choose when | Cost and risk profile |
|---|---|---|---|
| Buy (use prebuilt) | Microsoft 365 Copilot and its built-in agents, Dynamics 365 Copilot features and agents, role-based Copilots. | A standard capability covers 80% or more of the need; speed to value matters; the process is not a differentiator. | Lowest build cost and operational burden; licensing cost; limited customization; Microsoft maintains it. |
| Extend | Declarative agents, Copilot connectors, Copilot Studio agents with connectors and tools, customizing Dynamics 365 Copilot. | Prebuilt is close but needs your data, terminology, or actions. | Moderate cost; you maintain the extensions; inherits much of the platform’s security and compliance. |
| Build | Foundry custom engine agents, fine-tuned or custom models, custom orchestration. | The capability is a competitive differentiator, needs unique models or logic, or no product fits. | Highest build and run cost; full ownership of quality, security, responsible AI, and ALM; greatest flexibility. |
Model router: send each request to the most suitable model
Model router in Microsoft Foundry is deployed like a single chat model. It evaluates each prompt (complexity, reasoning need, task type) in real time and forwards it to an underlying model, so simple prompts go to small, cheap models and hard prompts go to larger reasoning models.
| Routing mode | Behavior | Fits |
|---|---|---|
| Balanced (default) | Weighs cost and quality dynamically. | General-purpose workloads; start here. |
| Quality | Favors the most capable models. | Complex reasoning or critical outputs. |
| Cost | Favors cheaper models and escalates only when needed. | High-volume, budget-sensitive workloads. |
Design levers
- Model subset: limit routing to approved models for cost, compliance, or data-zone reasons; new models are not added automatically.
- Automatic failover to the next suitable model; include at least two models in a subset to benefit.
- Azure Policy deployment rules for Foundry models also govern which models a router can include.
Watch-outs
- The effective context window is limited by the smallest model in the pool.
- Responses can vary in style because different models answer; evaluate outputs per mode.
- Monitor routing distribution to confirm the cost savings you promised.
TCO is more than licensing. Answers that ignore data preparation, change management, or operations are incomplete.
Time saved is not money saved unless the time is redeployed or costs actually fall.
“Build” is rarely the MOST cost-effective answer when a prebuilt or extendable product meets the requirement.
Model router balances cost and quality across models; it does not replace content filters, retrieval, or evaluation.
Night-before cheat sheet
The decisions and lists most likely to appear in Domain 1 questions.Grounding data: 5 dimensions
- Accuracy: correct
- Relevance: answers the real questions
- Timeliness: current
- Cleanliness: no duplicates or conflicts
- Availability: reachable with the right permissions
CAF AI adoption
- Strategy (lead, centralize governance, workforce access)
- Plan
- Ready (landing zone)
- Govern, Secure, Manage
- Least operational responsibility wins: SaaS > PaaS > IaaS
Extend vs build
- Declarative agent: Copilot’s model and orchestrator, Microsoft 365 apps
- Copilot Studio: low-code, multichannel, autonomous, Copilot Credits
- Foundry custom engine: your model and orchestration, full ownership
Customization ladder
- Prompt engineering
- RAG (fresh, private, cited knowledge)
- Fine-tuning (style, schema, tools, smaller model)
- Custom trained model (unique, non-generative tasks)
Multi-agent
- Child agent: lightweight, inside the parent
- Connected agent: separate agent (Copilot Studio, Foundry, Fabric, Agents SDK, A2A)
- A2A = agent to agent
- MCP = agent to tools and data
- Routing depends on good descriptions
AI CoE
- Sponsor, leader, multidisciplinary team
- Build on the Cloud CoE
- Centralized first, advisory later
- Strategy, intake, standards, pilots, skills, reusable assets, outcomes
SLM vs LLM
- SLM: narrow, cheap, fast, edge/offline, easy to fine-tune
- LLM: broad reasoning and open-ended generation
ROI and TCO
- ROI = (benefits − costs) ÷ costs
- Baseline, target, benefits, TCO, calculate, pilot
- TCO: licenses, consumption, Azure, build, data, change, governance, ops
- Buy > extend > build unless differentiating
Model router
- Modes: Balanced (default), Quality, Cost
- Model subset for approved models
- Automatic failover
- Context window = smallest model in the pool
Generative picks topics, tools, agents, and knowledge by description and can combine them; classic matches trigger phrases to one topic and falls back to knowledge.