Highveld Provincial e-Services, a fictional provincial service platform, had two AI proposals on the same agenda. The first came from Highveld's economic development policy unit: an assistant that would help officials find and summarise the province's own policies, circulars and standard operating procedures, inside Microsoft Teams. The second came from the e-services product team: an assistant on the public website that would help citizens find the right service, check what documents they need and track the status of an application.
Each team had already chosen a platform. The policy unit had built a working prototype in Copilot Studio over two weeks. The e-services team had a prototype in Microsoft Foundry. Both prototypes worked, and both teams argued their platform was "the strategic one". Lerato, Highveld's lead architect, asked a different question of each: when this assistant gives a wrong answer in eight months' time, who will notice, who will fix it, and who will explain it?
The answers decided the platforms better than any feature comparison. This article explains why, and gives a way to make the choice from the operating model rather than from the prototype.
What each platform is, as Microsoft documents it
Product facts below were checked on Microsoft Learn on 5 November 2026. Microsoft renames and restructures these products often, so check again before relying on them.
Microsoft Foundry is the current name of what was previously Azure AI Studio and then Azure AI Foundry. Microsoft's What is Microsoft Foundry? page says so explicitly, and lists the classic portal and hub-based projects as the previous model. Foundry is an Azure platform service. It offers prompt agents that Foundry hosts, hosted agents that run your own code and framework in a container with a managed endpoint, a large model catalogue, and platform capabilities such as tracing, evaluation, Entra ID, role-based access control, network isolation and Azure Policy, some of them in preview.
Microsoft Copilot Studio is described in Microsoft's overview as a graphical, low-code studio for building and managing agents and workflows, connected to organisational data through prebuilt or custom connectors, and published to channels such as Microsoft Teams, Microsoft Copilot and websites. It includes analytics, evaluations with test sets, and administration features such as an agent inventory. Its agents run on one of several "harnesses", and the harness chosen affects capabilities and billing.
Microsoft's Cloud Adoption Framework has a page on planning the technology for AI agents (dated 1 December 2025) that frames the choice in a useful order. First ask whether a ready-made software-as-a-service agent meets the requirement. If not, choose a build path based on the organisation's technical capabilities, timeline and control requirements, with Foundry as the platform-as-a-service option, Copilot Studio as the software-as-a-service low-code option, and containers on Azure infrastructure as a third option. It also describes using Copilot Studio with Foundry models as a combined approach, and recommends time-boxed experiments of one to two weeks per candidate before committing.
That is a sound starting point. The gap is that "technical capabilities" and "control requirements" are easy to answer optimistically during a prototype. The operating model makes them concrete.
Five operating-model questions
1. Who will change it, and how often? An assistant's instructions, knowledge sources and tools change after launch. If the people who understand the content are business staff who will make weekly changes, a low-code studio they can use themselves is a strong fit. If changes come through a product team's release process, a code-first platform fits that process.
2. Who will operate it? Someone must watch quality, cost and failures, and respond. Microsoft documents, for agents on its standard harness, that Copilot Studio agents are created inside Power Platform solutions in an environment. They land in a default solution, and moving them between environments by export, import or pipelines needs a custom solution. Foundry resources sit in an Azure subscription, operated like other Azure workloads in a workload landing zone. Choose the platform whose operating team already exists, or budget to create one.
3. What does it need to reach, and how privately? Citizen-facing services that integrate with case-management systems, need private network paths or must follow the platform's Azure guardrails sit naturally in Azure. Internal assistants that mostly read Microsoft 365 content and run inside Teams sit naturally in the Microsoft 365 and Power Platform estate.
4. How will quality be proven? Both platforms document evaluation features. The question is who builds and maintains the test set, who reviews results, and where evidence is kept for audit. That work needs an owner regardless of platform.
5. Who answers for it? For an internal policy assistant, the accountable person is the head of the policy unit. For a citizen-facing assistant, it is the service owner, and the answers become part of the province's public record. Accountability does not change with the platform, but the platform should let the accountable person get the evidence they need.
How Highveld decided
The officials' policy assistant went to Copilot Studio. The policy unit owns the content and will update it every week as circulars are issued. The users are officials already in Teams. The knowledge is mostly documents in the province's Microsoft 365 tenant. The policy unit has two staff who can maintain the agent, and the province's Power Platform administrators already run environments, data policies and solution-based deployment for other apps. The architecture conditions were: a dedicated production environment, deployment through a custom solution rather than editing in production, data policies limiting connectors to approved ones, and a monthly review of the evaluation test set by the policy unit.
The citizen assistant went to Foundry. The e-services product team already runs the public platform in Azure, releases through pipelines and owns the on-call rota. The assistant needs to read application status from the case-management system over private connectivity, must stay inside the platform's Azure policies, and will be exposed to the public, so it needs the same web application firewall, rate limiting and monitoring as the rest of the platform. Citizens never call the Foundry agent directly. They reach the website through the platform's public entry point and web application firewall, and the website's API tier calls the agent server-side using a managed identity. The Foundry project sits in the e-services workload landing zone and uses the standard setup with private networking; Microsoft's Cloud Adoption Framework notes that the basic setup, intended for prototyping, lacks network isolation. The agent reaches the status API with read-only permissions and is released through the same pipeline as the website.
The shared elements were as important as the split. Both assistants use Entra ID. Both send telemetry that the platform team can see. Both have a named content owner, a test set and an evaluation schedule. And both are listed in the province's AI register with their owner, purpose and data sources, so that a question from an auditor or a member of the public can be answered regardless of which platform an assistant runs on.
Common mistakes
Choosing by prototype speed. Copilot Studio prototypes are often faster, and Foundry prototypes often look more impressive to engineers. Neither tells you who will run the assistant in a year.
Treating the platform as the governance. A platform provides controls. It does not decide who reviews answers, who approves new knowledge sources or what happens after a complaint. The platform is not the product separates the AI platform from each AI product and its owner; the same separation applies here.
One platform for everything. Mandating a single platform for every use case usually forces either business teams into release pipelines they cannot use, or public-facing services into a tool outside the platform's network guardrails. Most organisations of Highveld's size will run both, deliberately. Business teams that build their own agents still need the guardrails and expert review that Citizens build and its public-sector companion, Public-sector AI, describe.
Ignoring the model access layer. Wherever the agents run, model access, keys, quotas and logging need a design. The model gateway is not the AI platform explains what a gateway does and does not govern.
Forgetting identity. An agent that calls internal systems needs its own identity and the narrowest permissions that work. Identity before intelligence covers this in depth, and Private by design sets out the network paths an Azure-hosted agent should use.
A decision table
| If... | Lean towards | Conditions |
|---|---|---|
| Business staff own frequent content changes, users are in Microsoft 365 | Copilot Studio | Production environment, solution-based deployment, data policies, named content owner |
| A product team owns releases, the agent integrates with Azure workloads privately | Microsoft Foundry | Workload landing zone, managed identities, pipeline releases, platform monitoring |
| Business teams build, but the agent needs stronger models or tools hosted in Azure | Both, with Copilot Studio as the front end | Clear ownership of each part and of the interface between them |
| A ready-made Microsoft 365 or in-product agent already does the job | Neither; adopt the existing agent | Check data access and licensing first |
| The workload needs its own models on dedicated infrastructure | Containers on Azure, if justified | Only with the skills and budget to run them |
Key points
- Choose between Foundry and Copilot Studio by asking who will change, operate and answer for the agent, not by prototype speed.
- Microsoft Foundry is the current name for what was Azure AI Foundry; check product names and capabilities against current Microsoft documentation.
- Follow the Cloud Adoption Framework's order: check for an existing agent first, then choose a build path by capabilities, timeline and control needs.
- Internal assistants owned by business teams often fit Copilot Studio; public, integrated assistants owned by product teams often fit Foundry.
- Whatever the platform, require a named owner, a test set, an evaluation schedule, shared identity and monitoring, and an entry in an AI register.
This is the final part of Azure Architecture Without the Poster. For the deeper Foundry design, continue with The platform is not the product.
How CloudNala can help
CloudNala helps organisations decide where each AI agent should run before the prototypes harden into commitments. We work through the operating-model questions with your business and platform teams, run time-boxed comparisons on your real use cases, and set the conditions each placement needs, from environments and landing zones to identity, evaluation and ownership, so that the platform choice matches the people who will live with it.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Azure Architecture Review or write to us at consult@cloudnala.co.za