# What to Decide Before You Pick a Microsoft AI Platform

> Use Microsoft's AI Decision Framework to gate the use case, operating model, and action boundary before choosing Copilot Studio, Microsoft Foundry, or a custom agent.

- Canonical: https://www.architecture-logic.com/use-microsoft-ai-decision-framework-before-platform-choice
- Published: 2026-06-08
- Updated: 2026-06-15
- Claims verified: 2026-06-11
- Category: AI Architecture
- Tags: Azure AI, AI Architecture, Microsoft Copilot, Microsoft Foundry

## Revision history

- 2026-06-08 (published): Initial publication.
- 2026-06-09 (revised): Linked the action-authority follow-up article and clarified the framework lens.
- 2026-06-10 (revised): Editorial pass: start-small boundary aside, custom-agent rung, operating-choice flow clarified in the canvas, sentence-case headings.
- 2026-06-11 (revised): Linked and sourced the Copilot Studio and Microsoft Foundry capability claims; tightened the technology-question lead-in.
- 2026-06-11 (verified): Re-checked every claim against the framework and Microsoft Learn; confirmed the Microsoft Foundry rename and the platform-fit claims.
- 2026-06-15 (revised): Temporarily removed visual blocks while the Architecture Logic visual system is redone.
- 2026-06-15 (revised): Removed the inline diagram and ran an editorial pass: sharper framing, cut the redundant layer list, plainer language in the intake and selection sections.

## Sources

- [Microsoft AI Decision Framework](https://microsoft.github.io/Microsoft-AI-Decision-Framework/docs/decision-framework.html) (verified 2026-06-11)
- [Microsoft AI Decision Framework — Complete Decision Flow explorer](https://microsoft.github.io/Microsoft-AI-Decision-Framework/explorer/?flow=complete-decision) (verified 2026-06-12)
- [Overview - Microsoft Copilot Studio](https://learn.microsoft.com/en-us/microsoft-copilot-studio/fundamentals-what-is-copilot-studio) (verified 2026-06-11)
- [What is Microsoft Foundry?](https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry) (verified 2026-06-11)

---

Do not let the first AI platform meeting become a product debate. Make the team prove the use case, the experience, the data boundary, the action boundary, and the owner before anyone argues for Copilot Studio, Microsoft Foundry, or a custom agent.

That is the best use of Microsoft's [AI Decision Framework](https://microsoft.github.io/Microsoft-AI-Decision-Framework/docs/decision-framework.html). It calls itself an intake playbook, and the delay is the point: hold the decision until the organization can say what the AI system is allowed to do and who will operate it.

The framework will not choose the platform for you. It will make a premature platform choice easier to spot.

## Gate the use case before the platform

Microsoft's framework starts with three intake questions: what business outcome changes, what user experience delivers that outcome, and whether an existing tool already solves the problem. If the team cannot answer those questions, the framework says to stop before anyone picks a tool.

That gate is useful because most weak AI proposals hide behind a tool name. "Build an agent" sounds like a plan until someone asks what result changes, who uses it, and why a standard product feature is not enough.

For an architecture review, I would add a fourth, so the intake becomes:

1. What business result changes?
2. Where does the user meet the AI?
3. What existing capability must fail before we build?
4. Who owns answer quality, access, cost, and the stop condition?

The fourth question turns the discussion from experimentation to ownership. If no one owns answer quality or cost, the work is still a prototype even if it has a production-looking interface.

## Choose the smallest layer you can operate

Start with existing tools, move to configuration only when the standard tool fails, and go pro-code only when configuration hits a real wall. That sequence is the framework's discipline.

Microsoft 365 Copilot fits when the work belongs in the Microsoft 365 surface and tenant trust boundary. [Copilot Studio](https://learn.microsoft.com/en-us/microsoft-copilot-studio/fundamentals-what-is-copilot-studio) fits when the organization needs managed orchestration, governed connectors, and maker velocity. [Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry) fits when the team needs deeper runtime control, custom grounding, evaluation, tool execution, private networking, or a software delivery lifecycle. A fully custom agent sits past Foundry; take that rung only when the team can own the runtime, evaluation, and security stack Foundry would otherwise carry.

Those are not maturity levels. They are operating models. More control gives the team more responsibility. Less control moves faster but narrows the shape of the solution.

> **Boundary:** Start-small holds only while the requirements are unproven. When the use case already demands private networking, custom grounding, or autonomous action, starting two layers up is rework, not discipline. Go to Foundry and write the record there.

Run that sequence as a pressure test. Each stop is legitimate when the evidence, owner, allowed actions, and revisit trigger are written down. Reaching Foundry is not a prerequisite; it is where operating responsibility gets heavier and the fully custom question begins. A team that wants to skip the gates and argue the platform name first does not have a decision yet. It has a preference.

## Separate experience, data, and action

Past intake, the framework's technology questions sort into three concerns: where the experience lives, what the system can know, and what it is allowed to do. Those questions should not become a checklist people fill out after the product choice. They should shape the product choice.

Experience decides where the AI belongs. A companion inside Teams has different adoption, permission, and support concerns than a headless workflow that reacts to a system event. The wrong surface can make a good model useless.

Data decides what the system can know. Microsoft Graph, Azure AI Search, Fabric, databases, and custom retrieval paths create different access, freshness, retention, and indexing problems. The review should name who controls each source and what happens when retrieval fails.

Action decides the blast radius. Draft-only help, human-approved execution, and autonomous action do not share a control model. If the system can change records, send messages, approve work, or trigger downstream systems, the team needs audit, approval, and rollback design before launch.

Treat those as separate decisions. A team can choose a managed surface and still need a serious data boundary. A team can build in Foundry and still keep humans in the approval path. The architecture gets clearer when those choices do not collapse into one product name.

## Write the operating choice before the demo wins

Intake ends with a platform choice for that one scenario. That is the right point to write the operating choice down, before the demo becomes the default answer.

Capture the evidence in a small table. Do not write a long strategy memo. Write the minimum record another architect can challenge.

| Field | What the team must state |
| --- | --- |
| Outcome | The business result or problem the AI changes. |
| Experience | The surface, trigger, and human approval path. |
| Data boundary | The sources the system can read and where that data travels. |
| Action boundary | The actions the system can take without a human. |
| Platform owner | The team that owns quality, cost, security, and rollback. |
| Revisit trigger | The condition that forces the team to change layers or redesign. |

If a field is blank, the team has an experiment. That may be fine. It should not be called a platform decision.

## Hand off to production architecture

The decision framework stops at selection. Production work starts after that.

The framework's complete selector keeps drawing the path anyway: platform choice is one gate, and grounding, deployment, and operations still stand between it and production. Read that as a count of the decisions left after the platform argument ends, not as a promise that they are small.

### How the path runs

1. **Intake gates.** Prove the use case, the owner, and the boundaries before anyone names a platform. A proposal that cannot clear this gate is not ready to choose anything.
2. **Platform choice.** Pick the smallest operating model the work can run on. This is the gate the meeting fixates on, and it is only the second of five.
3. **Grounding.** Decide what the system is allowed to know, then name who owns each source and what happens when retrieval fails.
4. **Deployment.** Decide where the system ships and runs: the surface, the network boundary, and the release path.
5. **Operate and govern.** Stand up cost, safety, evaluation, and rollback before launch, and keep them owned after it.

Two details in the framework are worth carrying into the review. Several of the services it routes to are still in preview as of June 2026; treat those as revisit-on-GA decisions, not foundations. And its local and edge path (Microsoft Foundry - Windows) never reaches the grounding question, so if an edge workload needs custom data, the framework leaves you to design that boundary yourself.

Once the team chooses a direction, the next review should cover identity, network boundary, source permissions, content safety, evaluation, transcript retention, budget alerts, telemetry, incident response, and rollback. The more autonomous the system becomes, the more those controls matter.

Use Microsoft's framework to force the first decision into the open. Then write down the owners and boundaries. The AI idea becomes architecture only when the team can say what it will build, what it will not let the system do, and who has to answer when it fails.