Catalogue › AI Architecture › platform-selection

Platform selection

Selects the Microsoft platform for one solution once suitability is agreed - Agent Builder, Copilot Studio, Power Platform automation, Copilot Code or Microsoft Foundry - weighing audience, data, actions, identity, operability and skills, and records the choice in an architecture decision record. Use when a solution has a pattern but no platform, when makers and engineers disagree where to build, or when a build has outgrown its platform.

Department

AI Architecture

Lifecycle

Envision, Deliver, Improve

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

m365-agents, copilot-cowork, copilot-code, copilot-studio, ai-foundry, power-platform, azure

Editions

starter, scale, enterprise

Reviewers

design-authority, security-privacy

Status

draft

Copilot Cowork

AI Architecture plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Once a solution has passed suitability, someone still has to decide where it is built and who will run it. This skill chooses the Microsoft platform for one named solution, from the options the organisation has approved, and records the reasoning in an architecture decision record that a reviewer can challenge. Selection goes wrong when the platform follows the builder's favourite tool, when the cheapest option to build is chosen without counting the cost to run, or when a pro-code route is taken for a need that a configured agent would meet.

When to use

• A solution has an agreed pattern from suitability and now needs a build platform.
• Makers want Copilot Studio, engineers want Microsoft Foundry, and nobody has written down why.
• A live solution is hitting the limits of its platform and a move is being considered.
• A partner proposes a platform and the organisation needs to test the proposal before contracting.
• A solution combines parts (an agent, a flow, a custom service) and each part needs a home.

When not to use

• Deciding whether AI is appropriate at all, and which pattern - use opportunity-management:ai-suitability.
• Setting the organisation-wide mix of platforms and what is approved - use ai-strategy:platform-strategy.
• Reviewing a platform choice someone else has made, at the design gate - use design-authority:platform-fit-review.
• Choosing a model within Microsoft Foundry - use ai-foundry:model-selection.
• Deciding whether a need justifies a Foundry build in detail - use ai-foundry:foundry-solution-assessment.
• Placing the solution in environments and tenants - use ai-architecture:environment-topology.

Questions to ask first

1. Who will use the solution, through which surface (Microsoft 365 Copilot, Teams, a website, a business application), and how many people?
2. What will it ground on and what must it do in other systems - read, write, send, approve?
3. Whose identity must each action run under, and is any data leaving the tenant?
4. Who will own and operate it after release, and what skills do they actually have today?
5. What does the organisation already license and approve, according to the platform strategy and the CoE's approved list?

Required inputs

• The suitability decision and risk tier, from opportunity-management:ai-suitability and opportunity-management:risk-classification.
• An agent brief or solution brief describing audience, scope, knowledge and actions.
• The approved platform list and principles from ai-strategy:platform-strategy, if one exists.
• The operating team's declared skills and capacity.
• Any non-functional requirements already known, ideally from ai-architecture:ai-non-functional-requirements.

If the approved platform list is missing, record the assumption and mark the decision provisional. Never assume a licence, feature or region is available; mark it "to confirm" against the source records.

Decision framework

Start from the least engineered option that meets the need, and move up only for a stated reason.

Then test the leading option against five gates. A "no" on any gate moves the decision up or down a row, or adds a precondition.

Practitioner approach

Begin by writing the solution in one paragraph without naming a product: who uses it, through which surface, what it knows, what it does and who answers for it. If that paragraph cannot be written, the brief is not ready and the selection will only encode guesses.

List the candidate options that the platform strategy allows. Where no strategy exists, use the decision framework rows as the long list and note that the choice is not yet constrained by policy. Discard options the organisation cannot operate; an elegant Foundry design with no engineering team behind it is a liability, not an option.

Walk the framework from the top. For each option, note the first reason it fails to meet the need. The first option with no disqualifying reason is the leading candidate. Resist the pull of a richer platform "in case it grows": record the growth signal instead, and state the trigger that would justify a move later, such as a second channel, write actions in a line-of-business system, or an evaluation regime the current platform cannot support.

Apply the five gates to the leading candidate. Identity and data usually decide close calls. A configured agent that can only run an action under the maker's connection is a weaker choice than a slightly heavier platform that supports user authentication. Operability is the gate most often skipped: ask the operating team, not the builder, whether they can support the choice at the hours and volumes expected.

Split composite solutions into parts and choose for each. A common and healthy shape is an agent for conversation, a flow for deterministic actions and an existing system of record for data. Record where each part lives and how they connect, and hand the connections to ai-architecture:ai-integration-patterns.

Check volatile facts at the time of decision. Feature availability, regional support, licensing and limits change often; cite the source record you checked and the date. Licensing conclusions belong to the Microsoft licensing guide or a licensing partner, never to this record.

Write the architecture decision record: context, options considered, decision, consequences, the triggers for revisiting, and who decided. Share it with the business owner and the operating team, then take it to the design gate from risk tier 2. A good record lets a reviewer disagree with the reasoning rather than guess at it.

Outputs

• An architecture decision record on the architecture-decision-record template: context, options, gates, decision, consequences, revisit triggers and decision owner.
• A one-paragraph platform rationale for the agent brief or solution brief.
• A list of preconditions and volatile facts to confirm, each with the source record to check.

Microsoft platform considerations

Agent Builder, Copilot Studio, Power Platform, Copilot Code and Microsoft Foundry differ in authoring model, authentication options, channels, lifecycle tooling and evaluation support, and Microsoft moves capabilities between them. Declarative and custom engine agents have different trade-offs described in ms-agents-compare. Check ms-agents-extensibility, ms-agent-builder and ms-foundry-models for current capability before deciding, and never state availability, limits or licensing from memory.

Adoption considerations

The chosen platform shapes who can maintain the solution. A business-owned knowledge agent built in Agent Builder can be kept current by its owner; the same agent in Foundry depends on engineers. Tell the business owner what the choice means for their part in upkeep.

Knowledge considerations

Each platform grounds differently. Record which knowledge sources the solution needs and whether the chosen platform can reach them with permission trimming intact. Detailed grounding design goes to ai-architecture:grounding-patterns.

Security and privacy considerations

The identity and data gates are security questions. Note any action that cannot run under user identity on the chosen platform, any data leaving the tenant and any connector outside policy, so the security-privacy review starts with facts rather than discovery.

Responsible AI considerations

Platform choice affects how much control the organisation has over model behaviour, content filtering and oversight. For uses that inform decisions about people, prefer the option that makes human review and logging easiest, and flag the case to the responsible-ai reviewers through risk classification.

Evaluation requirements

State how the chosen platform will be evaluated before release and after change: built-in testing, an evaluation set or an automated harness. If the risk tier needs evaluation the platform cannot support, the selection fails the lifecycle gate.

Value measures

Track, at portfolio level, the proportion of solutions that stay on their original platform for their first year, the number of costly re-platforming moves and the time from brief to platform decision. The AI solution architect owns these measures, with the baseline taken from decisions made before this skill was adopted.

Scale notes

Starter

Most solutions land in Agent Builder, Copilot Studio or simple automation. Record the decision on one page and use a partner's view before committing to Foundry or a pro-code build.

Scale

Keep a library of past decision records so similar solutions are placed consistently, and align every record with the approved platform list. The design gate reviews tier 2 and above.

Enterprise

Publish reference decisions per pattern through ai-architecture:ai-reference-architecture, and let business-unit architects decide standard cases, with the central architecture team deciding novel or tier 3 and 4 cases.

Hand-offs

• To ai-architecture:environment-topology to place the solution in environments and tenants.
• To ai-architecture:ai-integration-patterns and ai-architecture:ai-identity-design for connections and identities.
• To copilot-studio:studio-agent-design, ai-foundry:foundry-solution-assessment or copilot-code:code-solution-brief to start the build.
• To design-authority:platform-fit-review at the design gate.

Reviewer gates

From risk tier 2 the decision record goes to design-authority for platform fit, and the identity and data gate answers go to security-privacy. Below tier 2 the CoE lead records the decision and any challenge on the record.

Failure modes

• The platform is chosen for the builder's skills, and the operating team inherits something it cannot support.
• A heavier platform is chosen "for future growth", and the solution costs more to run than it returns.
• An action that needs user identity is built on a route that only supports maker credentials.
• A feature assumed from memory is unavailable in the organisation's region or licence, discovered after build starts.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Select a platform before suitability has been decided and recorded.
• State licensing conclusions; route them to the Microsoft licensing guide or a licensing partner.
• Choose an option the named operating team cannot support.
• Leave the decision unrecorded, or record only the winner without the options rejected.