Decision being made
Choose the right builder and operating boundary
Decide whether a configurable low-code agent platform is sufficient or whether the requirement needs a custom Azure AI application with engineering-owned code, models, infrastructure, networking, evaluation, and operations.
Short answer
Start with the requirements, not an assumed upgrade path
Evaluate Copilot Studio for configurable agents that use Microsoft and business data, connectors, tools, channels, and governed low-code authoring. Evaluate Microsoft Foundry when custom code, model choice, Azure architecture, private networking, deeper evaluation, or engineering ownership is a material requirement. One is not automatically a beginner or advanced version of the other.
Intended audience
Who this guide is for
- Leaders comparing a shared agent with a custom AI application.
- IT and security teams defining identity, data, network, and governance boundaries.
- Makers, architects, and engineers agreeing who will own the solution lifecycle.
Relevant evidence
Make the architecture requirements visible
- Define the user, business problem, and channel.
- List required information, connectors, tools, actions, and human approvals.
- Identify model, code, network, data-residency, evaluation, and observability requirements.
- State who owns changes, testing, security review, cost controls, and ongoing reliability.
- Confirm which requirements are truly differentiating rather than preferences.
Recommended capability
Compare the architecture and ownership boundary
| Decision factor | Copilot Studio | Microsoft Foundry |
|---|---|---|
| Primary problem | Create and publish configurable agents and agent flows | Build, evaluate, govern, and operate custom AI applications and agents on Azure |
| Primary builder | Business makers and technical teams working within governed Power Platform boundaries | Developers, AI engineers, data scientists, architects, and platform teams |
| Code and model control | Low-code configuration with extensions and supported model choices | Code-first flexibility, broader model catalog, SDKs, APIs, and custom application architecture |
| Data and actions | Knowledge, connectors, tools, topics, agent flows, and channels | Custom retrieval, tools, agents, data services, application components, and Azure integrations |
| Infrastructure boundary | Managed Copilot Studio and Power Platform environment controls | Azure resource, identity, network, data, deployment, and observability decisions owned by the technical team |
| Evaluation boundary | Agent testing, analytics, and platform governance | Application-level tracing, evaluation, monitoring, model comparison, and engineering controls |
| Consumption question | Copilot Credits, access path, included use, and capacity controls | Azure services, models, tokens, compute, storage, networking, and related resource costs |
Why not the other solution?
More control is useful only when the requirement needs it
Why not Copilot Studio?
It may not be the right boundary when the team needs custom application code, specialized model or orchestration choices, Azure network architecture, or engineering-owned evaluation and operations beyond the managed platform.
Why not Microsoft Foundry?
It introduces an Azure application and engineering boundary. Do not choose it when supported Copilot Studio configuration, connectors, channels, controls, and agent behavior already satisfy the requirements.
When an alternative becomes appropriate
Revisit the choice when a material boundary changes
- Move toward Foundry when custom code, model control, Azure networking, specialized evaluation, or engineering ownership becomes necessary.
- Move toward Copilot Studio when speed of governed configuration, Microsoft 365 context, supported connectors, and managed publishing matter more than custom architecture.
- Compare Agent Builder or Copilot Cowork when the need is a focused personal agent or delegated work rather than a shared platform solution.
- Combine services only when the integration has a clear requirement, owner, security boundary, and measurable value.
Risks and guardrails
Do not hide the operating model
Confirm identity, permissions, data boundaries, human review, model and tool behavior, evaluation evidence, monitoring, incident ownership, and cost controls before a final decision. A prototype does not establish production suitability. The responsible customer, partner, or technical team decides how to execute the work.
Questions to discuss internally
Requirements to confirm
- Does the need require a shared agent or a custom AI application?
- Which users, channels, data, connectors, tools, and actions are required?
- Are custom models, code, networking, deployment architecture, or evaluations material?
- Who owns security review, changes, reliability, monitoring, and cost?
- What evidence would justify the added engineering boundary?
- Which requirements would allow the team to choose the simpler managed boundary?
Public Microsoft sources
Verify the current platform boundaries
Verification date
Check current capabilities before deciding
Source review completed . Availability, models, features, regions, consumption, and governance controls can change and may vary by tenant, subscription, agreement, and release status.
Exact next destination
Clarify the broader agent path
Finished this primer?Optional progress stores only this primer identifier and a completion time on this device.