The late-afternoon session on day two of Nordic Summit 2026 was “Copilot Studio’s Bigger Brother: Make an AI tooling decision today”, and it was the most opinionated session I sat in on. Nathan Sweeney is Microsoft AI Lead at KPMG, working with UK and international markets, and his job is talking to large organisations about their AI strategy, their technical teams about adoption, and everyone about governance and agent factories at enterprise scale. He was upfront that he prefers Foundry over Copilot Studio and would explain why. This is my recap. The opinions are his, the summary and any mistakes are mine.
Everything is built on Azure, and that matters
His first structural point: everything in the Microsoft ecosystem, modern work, Dynamics 365, Power Platform, is built on Azure, with LinkedIn and GitHub as the exceptions that were on-premises for years. Copilot Studio specifically is built on Foundry. So anything that appears in Foundry eventually becomes available in Copilot Studio, and from there gets enabled in some form in Agent Builder. There is a democratisation pipeline running from developer tooling down to end users, and it runs one way.
His example was concrete. A year and a half ago his team was building a prototype agent for a large UK healthcare provider, and it could not be done in Copilot Studio because the content filters were not adjustable there. He had already built it in Foundry, where he could change them. That is not a criticism of the low-code tool; it is an argument for picking the tool that can produce the outcome.
The conversation that is not about tools
The biggest conversation he is having with enterprises has nothing to do with tooling: it is guardrails. He called it boring and then said it is the most important one, because the right policies are what let teams work at scale without asking permission for everything. When someone operates outside the parameters, that becomes an easy conversation rather than an argument. Understanding what the EU AI Act means for your business, and what you must and must not tell your customers, belongs in that same discussion.
Five questions before you build
The ownership question was the one he pressed hardest, by analogy with Azure architecture. When you build an application landing zone, you name the business unit and the business owner. So why do we not do that for processes? Why hand a financial process to the IT department, when IT has no idea when the regulations change? The owner should be the part of the business that knows the rules.
The cheat sheet
| Pick Agent Builder when | Pick Copilot Studio when | Pick Foundry when |
|---|---|---|
| One person, one task | A team or department uses it | Multi-agent or bespoke logic |
| Knowledge plus light prompts | It needs to act across systems | Custom models or your data |
| No system actions needed | Low-code is enough | Engineering owns it long-term |
| You want it live this week | Governance and lifecycle matter | Production-grade is non-negotiable |
And the listening version, the phrases that tell you the low-code answer has run out:
If you hear this, use Foundry
“We need multiple agents talking to each other.” “We want to bring our own model.” “We need fine-grained RAG over private data.” “It must hit production SLAs.” “Engineering will own this.” “I need to know my costs in real time.” “I want to be able to look at good log files.” That is your signal, he said: stop forcing low-code.
Three arguments underneath those. Models: Copilot Studio offers around eight or nine, Foundry had roughly 11,000 last time he looked, which turns the problem into an evaluation exercise with real trade-offs, one model better at vision than another, and cost per token as an explicit variable. Availability: Copilot Studio is a managed service with a high SLA, but he pointed out that Teams and Outlook have gone down too, and if the business needs more nines than a managed service gives you, you build the infrastructure yourself. Costs: in Copilot Studio they take 24 to 48 hours to appear; in his Foundry demo he was pulling them from the Azure API in real time, broken down per agent.
Nobody can tell you what it will cost in advance
He showed an old OpenAI page and underlined one line: the models do not operate on words or characters but on tokens, units of text somewhere in between. His conclusion follows from the predictive nature of the models: nobody can tell you in advance what a given request will cost. They can tell you afterwards. Anyone promising otherwise is guessing.
Business taxonomies, and the workshop nobody runs
The part I had not heard framed this way was business taxonomies: five levels from the business function down to the task. Finance, then the process group (record to report), then period end closing, then the activity (reconciling bank accounts), then the task. The trap is that people pick a level-two process to fix and do not realise there is a 4.1 underneath it, and a 4.1.1.1.5.7 underneath that. Without breaking it down you never learn what the current process actually is.
Which led to his sharpest observation. He asked how many people run workshops with the business to walk through the process before building a Copilot Studio proof of concept. Almost nobody in the room. His own practice is to ask for the finance SME and their documented process; they arrive proud of a sheet of paper, and in his experience it is never what actually happens. And when he describes it back, the answer is often that the manipulation in the spreadsheet was never needed in the first place.
The demo: 25 agents and a very short employment
The demo was a React front end, an API back end and Foundry underneath, with around 25 agents running the three phases of hiring. Watching it work was the point: a live panel of human-readable narration as the agents handed off, a developer tab showing the raw JSON coming back from each agent and every database mutation, and a cost tab reading the Azure API in real time per agent. He could edit an agent’s definition in the browser and push it straight back to Azure, which he noted you would not hand to HR, but it shows you are producing software rather than configuration.
The live-demo gods did their usual work, and the candidate who had just been hired resigned about thirty seconds later, which triggered the offboarding orchestrator. That turned into the closing trick: in Copilot Studio he added the Foundry orchestrator as a connected agent, and because the orchestrator has the other agents under it, Copilot Studio suddenly had access to the whole set. You build and govern the agents in Foundry, and present them through the tool your makers already know.
Asked where the human sits in all this, his answer was that you design it in: run the workshop, break the process into stages, and mark the points where a human makes the decision rather than the agent. The architecture follows the process, not the other way round.
His last slide: start with the outcomes the business wants, not with the technology. Start with the tech and you end up in a world of pain, and he has the scars.