Narrator: Five ideas for AI agents. Where should each one live? If your organisation runs on Microsoft, there are five places to choose from, and most of them have been renamed at least once in the last two years.

Narrator: Perhaps you've been asked to do agents, and to justify where. Someone has said Copilot Studio is the answer; someone else, that the developers should just build it in Python. And you're worried about picking wrong, a bill nobody forecast, something private leaking, and Microsoft renaming the lot next month. By the end, you'll be able to take any agent idea and say where it should live, what it'll cost to run, and what would make you move it. On the way: a map of how the pieces fit, a ladder of the five places, six questions that put each agent on its rung, then hybrids, who runs them, and where code earns its place. Hayley's five notes come with us.

Narrator: One promise first. There's no favourite place in this film. Each of the five suits some agents and not others, and for many agents, code is the wrong call. We'll say which is which as we go. Here's the short answer, which the rest of the film earns. Configure where you can. Code where you must. And build the plug once.

Narrator: Our example: Pritchard Group, an invented company that maintains forty thousand rented homes across the north of England. Twelve hundred staff, Microsoft 365 E3 with some Copilot licences, Azure through an MSP, and Fabric for its reports. Hayley, its head of operations, also invented, wrote the five notes.

Narrator: So what is an agent? It's AI set up to do one job, and every agent has six parts. A brain: the model, such as GPT or Claude, that reads and writes. A brief: its instructions. Knowledge: the documents and data it can look things up in. Hands: tools that let it do things, like opening a ticket or booking a slot. A harness, which we'll come to. And a front door: where people meet it, in Teams, on your website, or nowhere at all when it works in the background.

Narrator: The harness is everything around the model that keeps it on the rails: who it runs as, what it may touch, the rules checked before anything happens, the approvals, the retries, the logs. You'd expect the model to matter most. But in Microsoft's own internal tests of one of its agent tools, changing the model made little difference to how often agents completed their test tasks, while changing the harness made a substantial one. And the more an agent does on its own, from answering, to acting, to running when nobody asked, the more the harness matters.

Narrator: Before the options, a map. Most of the confusion comes from mixing up layers, so picture the Microsoft estate as five, stacked. At the top, the front doors: Teams, Copilot, your website. Then the places an agent is configured. Then the models. Then tools and data. And underneath everything, identity and governance. This film is mostly about the second layer, but every choice there leans on the others.

Narrator: Here are the names that matter, in plain English. Entra is the company directory, formerly Azure Active Directory: every person, app and now agent has an account there, and every service checks it first. An Azure subscription is the bill for what you run in Azure; if your MSP resells it, it may be a CSP subscription, which matters later. Dataverse is the database behind Microsoft's low-code tools. Fabric holds the agreed definitions of your numbers. Foundry is Azure's home for models and agents: yes, the one whose label won't stay stuck. And MCP is an open standard plug that lets any agent use a tool.

Narrator: Identity decides what an agent can see. Microsoft's built-in agents work on behalf of the person asking, so they only see what that person could already open. That's a strength: you don't rebuild permissions. It's also a trap. If your SharePoint permissions are loose, an agent will find what was always technically visible. In a 2024 Gartner survey, forty per cent of IT leaders had delayed Copilot by three months or more over oversharing. An agent with its own identity, like your own code, sees only what it's been granted, so that has to be designed on purpose.

Narrator: Now the five places an agent can live, as a ladder. Every rung supplies the same six parts. The question is who builds them, and above all, who builds the harness. On the bottom rung, Microsoft builds almost everything and you write the brief. At the top, you build it all. Each step up gives more control, asks for more skill and changes how you pay. Foundry and your own code overlap, because Foundry can run your code.

Narrator: Below the ladder sit two options people forget. Don't use an agent: Microsoft's own guidance says fixed steps with strict rules are faster, cheaper and more reliable as ordinary code, and a plain question-and-answer over a fixed set of documents needs only a simple look-up, not an agent that acts. Or buy one: Researcher and Analyst, which come with the full Copilot licence, Fabric's data agents, and the agents in Dynamics 365. Check what your licences include before you build.

Narrator: Rung one: Copilot Chat, included with Microsoft 365 business and enterprise plans. On its own, it works from the web, its instructions and whatever the user gives it. If your admin switches on pay-as-you-go billing, agents built for it can also read SharePoint, charged per use. The full Microsoft 365 Copilot licence, thirty dollars a user a month, adds each person's own mail, chats and meetings. It's brilliant for personal work, but it can't reliably share a configured behaviour across a team, or act in your systems. Many E3 organisations start here. Pro tip: a shared Copilot Notebook, with standing instructions and pinned files, is the cheapest team agent there is.

Narrator: When do you climb from rung one to two? Picture Shona, a housing supervisor, also invented. Her twelve officers each keep their own copy of the lone-working prompt. Last week, one copy had lost the line about ringing the duty manager after nine at night. Same question, twelve slightly different answers. That's the signal: a team needs the same instructions and the same files, every time. Stay on rung one while it's one person's habit, or while a shared prompt or a shared Notebook covers it.

Narrator: Rung two: Agent Builder. Inside Copilot, someone gives an agent a name, instructions, starter prompts and knowledge, such as a hundred SharePoint files. Microsoft calls these declarative agents: you declare the brief, and Copilot supplies the brain and the harness. It's ideal for the policy helper: fast, owned by the business, and its SharePoint knowledge only shows people what they can already open. Staff with a Copilot licence pay nothing extra; for everyone else, an agent that reads SharePoint is billed per use, which we'll come to. Hayley's lone-working policy question goes here.

Narrator: Know its limits. It can't use tools that change other systems, run sequences of steps, or sit on your website, and files uploaded straight into it are visible to everyone who can use it. Pro tip: write the instructions like a short spec, then test the agent against plain Copilot. If its answers are no better, you've built a very polite bookmark.

Narrator: And from two to three? Gareth runs the IT helpdesk. His Agent Builder agent sorts out 'my laptop won't connect' well, then sends people to the portal to raise a ticket, where they type it all again. Tickets still arrive without the site or the asset number, so his team rings back anyway. Climb when the agent needs to do something in another system, ask its questions in a set order, or start without being asked. Stay on rung two if most questions end in an answer, and a link is enough for the rest.

Narrator: Rung three: Copilot Studio. Think of it as a web designer for agents. You add knowledge; tools, from ready-made connectors to MCP servers; agent flows, which are fixed sequences of steps; and triggers, which start an agent when something happens. It publishes to Teams, Copilot, a website or a contact centre. And here the harness becomes a choice: a standard one where you script guided conversations, the Microsoft Copilot harness, which plans its own steps and bills by usage, and, in preview, one for customer service.

Narrator: It's very good at staff-facing agents that do things, like helpdesk triage that opens a ticket. It's owned by the people who know the process, governed in ways IT already understands, and more testable than its reputation: built-in evaluation since March 2026, and release pipelines from test to live. Hayley's helpdesk triage goes here.

Narrator: Where does it strain? Complex or fast-changing rules, high volume and, practitioners report, latency and little visibility into why an agent did what it did. It's paid for in credits, a cent each: a generative answer is two, and looking it up in your own data adds ten. Staff with the full Copilot licence, using an internal agent as themselves, aren't charged on the standard harness, except when the agent runs on its own. Two traps. Reasoning models, which think in steps first, use far more credits: in Microsoft's own example, one question to a website agent costs about one dollar forty to four dollars sixty. And go a quarter over your prepaid credits, and agents stop mid-conversation, unless pay-as-you-go is linked.

Narrator: Past rung three, the pain sounds different. Pauline, the finance director, piloted invoice checking in Copilot Studio. Then the auditors asked why one invoice was approved. The transcript showed what the agent did, but the price tolerance was a sentence in its instructions, so nobody could prove it was applied. Six thousand invoices a month made the credits hard to forecast. The signal: a rule that must always hold, a record an auditor can follow, and tests on every edge case. That's code, which Foundry can run for you. If only one step is hard, keep the conversation in Copilot Studio and put that step behind a tool.

Narrator: That's the Microsoft-built half of the ladder. The top two rungs are where you start building the harness yourself, and where models and contracts start to matter. Rung four: Microsoft Foundry, Azure's catalogue of models and its agent service. You can define a prompt agent in the portal with no code, or hand Foundry your own code, packaged up as a container, as a hosted agent, with its own identity, a record of every step it takes, and tests. It suits teams that want Azure's security and monitoring without running servers, and model choice on one bill.

Narrator: Where it strains is churn. The first generation of its agent service retires in March 2027, and its workflows feature on the first of December. Some parts are still in preview. And you pay per token, the word-pieces a model reads and writes, plus compute for hosted agents. OpenAI's everyday model on Azure costs about a dollar per million tokens in, and five out; the top model, ten and fifty.

Narrator: Which models can you use where, and under whose contract? OpenAI's GPT models are the default almost everywhere. In Foundry, Microsoft sells them on its own terms, and they can stay in a European data zone, a group of regions where the processing stays, which UK organisations can choose too, for about ten per cent more. In Copilot Studio the default model updates itself, and pinned models retire quickly: three in October, and five more on the twelfth of November.

Narrator: Claude is the interesting one: it's in both places, under different contracts. In Copilot and Copilot Studio, Anthropic is a Microsoft subprocessor, so Microsoft's terms apply, but it's outside the EU Data Boundary and off by default in the UK and EU until an admin turns it on. In Foundry, Anthropic is the data processor, on Anthropic's own terms, even when it runs on Azure. Its only data zone there is the US, and it isn't available on CSP subscriptions at all. Same Claude, different contract. A legal sign-off for one doesn't cover the other.

Narrator: Rung five: your own application on Azure. Your developers write the agent in Python or TypeScript, with a toolkit, or SDK, from OpenAI, Anthropic or Microsoft. It runs on Azure, behind your website or inside Teams, and usually calls its models through Foundry, so it stays on your Azure bill with no keys in the code. This is where hard rules live. 'Match every invoice to its purchase order, and pay nothing over five thousand pounds without a manager's approval' becomes code that runs every time, not an instruction the model usually follows. A prompt can ask. Code can make sure.

Narrator: Between rungs four and five, the question is the product around the agent. Imran, the digital manager, tried the tenants' repair booking as a Foundry prompt agent. The answers were fine. The hard part was everything else: Pritchard's own pages, live slots from the repairs system, and a booking made exactly once, even when a tenant on a slow phone taps 'confirm' three times. What tips it: the agent is one part of a service you build and run. Stay on rung four if the agent is most of the job, and a tool your developers write can make the booking.

Narrator: Code also gives you approvals, retries and doing things exactly once, built as ordinary software; customer-grade experiences; and the freedom to swap models. The cost is that you own everything Microsoft would otherwise run: sign-in and permissions, security, hosting, monitoring, upgrades, and toolkits that change every month. Hayley's invoice checking goes here, as a hosted agent in Foundry, and so does the tenants' repair booking.

Narrator: So how do you choose a rung? Ask six questions of one agent doing one job: who meets it; what must never go wrong; where its data lives; how much it runs; which model it needs; and who owns it.

Narrator: Who meets it? If it's your staff inside Microsoft 365, start low: they're signed in, permissions come free, and the front door already exists. If it's customers on your website, Agent Builder can't do it, Copilot Studio can, and a product-grade experience usually means code. That's Hayley's repair booking. What must never go wrong? Put judgement in the model, and rules in something that behaves the same every time. If a mistake costs money, breaks a policy, reaches a customer or changes a record, the check belongs in a flow step at least, and in code when the rules are complex or the stakes are high. That's the invoice checking.

Narrator: Where does the data live? Documents in SharePoint: the lower rungs handle them natively, permissions intact. Records in Dataverse: Copilot Studio is at home. Numbers in Fabric need a semantic model first, an agreed definition of what 'overdue' means, and then a Fabric data agent you can surface in Copilot. That's Hayley's overdue repairs: use the ready-made data agent, with the Fabric service she already pays for, rather than build one. And data scattered across systems needs a search index you control, or code.

Narrator: How much will it run, and who pays? Developers often say tokens are pennies, so code must be cheaper. Microsoft charges three ways. Seats, a licence per person, pay for people using Copilot all day. Credits pay for conversations with agents: cheap for light internal use, steep with reasoning models or high volume. Tokens pay for the model's work directly. And here's the catch: credits include the model, but tokens don't include the engineering.

Narrator: Take Microsoft's own example: a website support agent handling twenty-seven thousand conversations a month. In credits, that's about two thousand dollars a month. In code, the model costs less, but on our estimates, once you add hosting and a few days a month of upkeep, code costs more, and never pays back a build of thirty to sixty thousand dollars. At two hundred thousand conversations on an everyday model, credits reach thirteen to sixteen thousand dollars a month; code saves about six and a half thousand, and repays its build in five to nine months. Put the top model in the code, though, and the tokens alone can cost as much as the credits. Volume and model choice, not cleverness, move the line.

Narrator: Which model, and on what terms? If the default is fine, every rung works; if you need a particular model, or processing in the UK or EU, check the small print first. And who owns it? A business team that wants to change the wording itself belongs low, inside guardrails IT sets. A development team that tests every change belongs higher up.

Narrator: So, the rule of thumb. Pick the lowest rung that passes all six questions, and climb only when one forces you to: a rule that must always hold; customers rather than staff; volume that makes credits expensive; a model or contract you can't get lower down; or a team that tests every change like software. Microsoft's own advice is similar: when you're torn, give each option a one- to two-week trial, and if the low-code one meets your functional and security requirements, use it.

Narrator: There's an opposite pain, too. Picture Dean, a developer, building the lone-working helper in code, because code is what he knows. Six months on, it has its own security review, its own hosting bill, and someone on call. Each policy change waits for Dean. And staff still ask Copilot first, because that's where they already are. On rung two, the policy would be a file Shona's team updates. The signal for coming down: the people are staff, the job is answers, and the rules are simple. Climbing has a cost, so make each step earn it.

Narrator: That's one agent. Most organisations end up on several rungs at once, and the best designs join them on purpose. The most useful join: when two or more agents need the same ability, build the plug once. Put a business capability, like 'book a repair', behind one MCP server on Azure, secured with Entra, with API Management in front, a gateway like a reception desk. Then Copilot Studio, Foundry, your own code and tools like Claude can all use it: Pritchard's helpdesk agent and the tenants' website can share one 'book a repair' plug. Design it around tasks, not one tool per API call. It's useful whichever platform wins, and it survives a change of mind.

Narrator: The other joins. A Microsoft front door with code behind it: Copilot Studio holds the conversation in Teams, and hands the hard part to an agent you wrote, using the agent-to-agent standard, A2A. The business owns the words; engineers own the logic. Or Foundry for models and identity, and code for the work: one Azure bill, and no keys in the code.

Narrator: And the path most people get wrong. A common assumption is: prototype in Copilot Studio, then rebuild it in code. In our experience, most staff-facing agents can stay where they started, and that's a good outcome. When a reason to move up appears, the next step is usually a hybrid: keep the conversation in Copilot Studio, and move the hard part behind an API, an MCP server or a Foundry agent. A full move into code comes last. And what carries over is what you built outside the platform: your test questions, your tools, and your data work.

Narrator: One last question before the answer: who runs all this once it's live? In most organisations like Pritchard, the MSP already runs what every agent depends on: licences, environments, data-loss policies, the subscription. So ask them first. Who can build agents, and with which connectors? Who can share an agent with everyone? Is the subscription CSP, which rules out Claude in Foundry? And will they support an agent built in code, or only its hosting?

Narrator: Wherever an agent lives, a few habits decide whether it works. Write thirty to fifty real test questions with agreed answers before you build, and run them on every change. Ask a person before anything that can't be undone. Treat what agents read as untrusted: in 2025, a flaw called EchoLeak showed one crafted email could make Microsoft 365 Copilot leak data, with nobody clicking anything. It's fixed, but the lesson stands. And give every agent an owner, an identity and a place in the register, which is what Agent 365 is for.

Narrator: Two governance pro tips. If you can't fix every SharePoint permission before launch, a setting called Restricted Content Discovery hides your riskiest sites from Copilot without changing who can open them. And a pay-as-you-go budget only sends an email; the spending reads it and carries on. Set a limit on each agent too.

Narrator: Before the answer, the fair case for the top of the ladder. Code earns its place when these pains sound familiar. You need to prove a rule ran, not hope it did. You want the experience to feel like yours, not like a chat window someone else designed. You want your data in your own environment, with your own logs, your own retention, and permissions down to a single field. You want to choose your model, swap it when a better one arrives, and know what each conversation costs. And you want every change tested before anyone sees it. That's what the extra cost of code buys.

Narrator: And it's rarely all or nothing. Often the best answer is part code. Take one business area, like repairs scheduling, and build it in code with its own data: the jobs, the rules about which trade goes where, and a record of every booking. Then expose it through an MCP server. The agents stay where people already are, in Copilot Studio, Teams or the tenants' website. But whenever one of them books a repair, it goes through your code. That code is the harness for that ability: it checks the rules, guards the data and keeps the log, whichever agent asks.

Narrator: So, back to Hayley's board. The lone-working policy: Agent Builder. The helpdesk triage: Copilot Studio. Overdue repairs in Leeds: a Fabric data agent she can use rather than build. The invoice checking, with hard rules and approvals: code, run as a hosted agent in Foundry. And the tenants booking repairs online: code, with an MCP server for the booking system, which the helpdesk agent uses too. Five agents, four places, one plug. The quickest wins are at the bottom of the ladder. The code sits where the rules and the volume are.

Narrator: Where should your AI agent live? Every rung had the same six parts; the only question was who builds them. So put an agent where its people already are, with its rules where they can't be broken, and its abilities where every agent can reach them. Configure where you can: for staff inside Microsoft 365, Microsoft's own tools are faster, cheaper at modest volume, and already governed. Code where you must: when rules have to hold, customers are involved, volume is high, or the model and its terms matter. And build the plug once, so every agent, on every rung, can use it.

Narrator: What to do this quarter? Tidy your SharePoint permissions. Agree with your MSP who may build and share agents. Then pick two agents from the bottom rungs, and one candidate for code, and give that one a two-week trial. And Microsoft's Ignite conference, from the seventeenth to the twentieth of November? Expect new names and new prices. Not a new way of deciding.

Narrator: This film is based on Scorchsoft's guide, Where should your AI agent live?, with every source and the full cost workings, at scorchsoft.com.

Narrator: And if you'd like a hand with your own ladder. If you're working on the upper rungs, Foundry, your own code, or the plug that joins them, book a consultation call with Scorchsoft. If your team is finding its feet on the bottom rungs, much of the work is in the habits underneath, and that's what The AI Stairway™ teaches: turning good chats into shared skills, agreeing team rules, connecting AI to your files with controls you choose, and deciding which rules need code. It's tool-neutral, so it applies to Copilot and beyond, and the first module is free.

Narrator: Configure where you can. Code where you must. And build the plug once.