Copilot Agents - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What copilot agents are. The copilot on your screen can now do more than answer questions. It can finish the task and that version has a name. A copilot agent is the copilot, you know, with three things added Microsoft ships, some ready to use, and you can build your own without writing a line of code. By the end, you'll know what to hand off to one and what to keep. The first thing to get straight is where almost everyone trips. A copilot agent isn't a smarter chatbot because a chatbot talks and an agent acts. That one difference changes how you'd use it in your day. Ask Plane Copilot how to file an expense report and it explains the steps, which helps, but still leaves the work to you. Ask an agent and it can open the form, pull the numbers off your receipt, fill everything in, and hand it back for your approval. Microsoft describes an agent in a way that's easy to hold on to. It handles conversations and completes tasks. It follows the instructions you give it. It draws on the knowledge sources you connect, and it uses tools to take action. Those four pieces are the whole idea. The word that matters most is action, which is why this topic rewards a little care. A chatbot can be wrong and you lose a few minutes. An agent can be wrong and something really changes, like an email going out or a record getting updated. That isn't a reason to avoid agents, and it's a reason to understand what you're handing them. Microsoft sorts agents across a wide range, from simple, prompt and response at one end to fully autonomous ones that carry a process from start to finish. You don't have to live at the far end. Most useful work happens closer to the middle, where an agent does a narrow job and a person still owns the outcome. This shift is moving quickly, and Microsoft points to research from IDC that predicts one point three billion AI agents by twenty twenty eight. That figure is a forecast, not a fact, and it still tells you where the industry is aiming for anyone building a career right now, knowing what an agent can and can't do is turning into a basic skill the way spreadsheets did a generation ago. You might think this is about technology, and it's really about deciding which of your tasks to hand over. That decision is what we're going to make easier. So the next stop is the parts that make an agent work. How a copilot agent actually works. An agent looks complicated from the outside and underneath it's really a few moving parts. Microsoft reduces those parts to three questions, which are what it knows, what it processes, and what it can do. Every agent you meet is some answer to those questions, and once you can see them, the mystery mostly disappears. One of these pieces causes more trouble than the rest, and it's the one people rush past, so keep an eye out for it. What it knows comes from two places and both are under your control. One is the instructions you write, which work like the agent's job description, and the other is the knowledge you connect, which is the material it's allowed to read. Instructions tell the agent who it is and knowledge tells it what's true. Instructions matter more than beginners expect, because vague ones produce vague answers. Tell an agent to help with HR questions and it will guess at its role and drift. Tell it to answer questions about parental leave using the official policy document, and to admit when the document doesn't cover something. That second version behaves like a careful colleague, and the only thing that changed was the wording you gave it. What it processes is the middle piece, and you can't see it directly. This is the reasoning that decides which knowledge to use and which tool to reach for. It's also why the same agent can feel sharp one day and shaky the next. You can't tune it directly, so you shape it with clear instructions and clean sources. The next piece is what it can do, which is where tools come in. A tool is any action the agent is allowed to take, like sending an email, updating a record, or fetching live data from another system. Knowledge lets an agent answer and tools let it act, which is the difference we keep coming back to. Then there's the trigger, which is simply how the agent knows to start. Most agents begin when someone types a phrase in chat and some begin on their own. When an event happens, such as a new order arriving, Microsoft gives some agents their own account for exactly this reason, so they can work proactively on things like onboarding a new employee or coordinating a recurring meeting for jobs that need a fixed path. You can build a topic which is a scripted conversation. The agent follows step by step. Collecting a name and an email before signing someone up is a good example because the order of those questions matters. Topics give you precise control when a natural conversation would wander. A useful way to hold all of it together is to picture a new teammate joining your team. You'd give them a clear job description, the right reference materials, an access badge that opens only the doors they need, and a process to follow an agent is that same setup, except you configure it once and it never forgets the details. If that sounds a lot like managing a person, that's because it is. One honest warning belongs here because it's the thing that catches people out. An agent sounds just as confident when it's wrong as when it's right. So the grounding you give it is what keeps it honest. Microsoft's own training labs tell makers to turn off web search and turn off ungrounded responses together, since doing both makes made up answers far less likely. When you connect a document, give it a few minutes to finish indexing before you test it. Copilot studio also lets you choose which AI model powers the agent, and a stronger model tends to reason better through messy requests. The trade off is speed and cost, so the right choice depends on how hard the job really is. But where copilot agents live in Microsoft three. Sixty five and Azure, you don't have to build anything to start using agents, because Microsoft three hundred sixty five copilot already ships with several ready made ones. Researcher digs through your work data and the web to pull together a report, while analyst turns a messy spreadsheet into charts and clear answers. Facilitator sits in your team's meetings to take notes and keep things moving and interpreter translates in real time so people can speak in the language they prefer. Learning agent coaches you on new skills and every one of these comes included with a copilot license. Finding one is easy because there's an agent store built into copilot and teams. You browse it the way you'd browse an app store sorted by the job you're trying to get done. When you're ready to build your own. There are three doors and they run from easy to advanced. The simplest is Agent Builder, which lives right inside copilot. You describe the agent in plain language. Connect a few knowledge sources, test it, and share it with your team. You can do all of that without leaving your browser. Agent builder has limits worth knowing since it can't call outside services on its own and it doesn't work in group or one on one teams chats. When you need an agent that reaches into other systems, you copy it into Copilot Studio. The second door is Copilot Studio, which is Microsoft's low code studio for building and managing agents and workflows. It's called low code because you still describe what you want in plain language and drag pieces around. The difference is that you can connect it to far more data and systems. You publish from there to teams, to copilot, to a website or to a mobile app. So the agent lands where people already work. The third door is the pro code path and that's where Azure comes in. This is for teams that want full control over the engine behind the agent. And those custom builds typically run on cloud services like Azure. Microsoft offers tools like Microsoft Foundry for that work, and you'd reach for it only when a simple agent genuinely can't do the job. Microsoft splits custom agents into two types, and the split is worth remembering. A declarative agent borrows Copilot's own engine and models, which keeps it simple and means it inherits Microsoft's security and compliance. A custom engine agent brings its own setup, which makes it far more flexible and lets it act on its own. That flexibility has a price because you own more of the risk. Declarative agents wait for you to ask. While custom engine agents can trigger actions without anyone typing a word. There's a layer underneath all of this that Microsoft calls work IQ. It gives agents the context of your job, your team, and your company so their answers fit your actual work instead of the internet in general. Once agents start multiplying, someone has to keep track of them. And that's the job of Microsoft Agent three hundred sixty five. It's the control plane where it can see every agent in the organization and give each one an identity. It can also limit what an agent can reach and shut down the ones nobody approved. It became generally available in May of twenty twenty six as a paid add on, and it exists because unmanaged agents quietly pile up what copilot agents look like in real work. The pieces only get you so far, so it helps to see what these agents look like on an ordinary work day. None of the examples below are exotic, and that's the point. Picture a new hire on their first day, drowning in questions about where things live. An onboarding agent can answer those questions from the team's own documents and walk the person through their first tasks step by step. The new hire gets an answer in seconds, and the team stops answering the same question five times. The same idea works for internal support. An HR or helpdesk agent can answer policy questions from the official documents, and when it genuinely doesn't know, it hands the conversation to a person. That hand off matters because it means the agent takes the easy, repetitive questions and leaves the hard cases to humans. Meeting follow up is another natural fit. An agent like facilitator can take notes during a team's meeting and turn them into a summary with clear action items that saves the person who always ends up writing them up. You still review the notes and you still decide what gets done. Some agents run entirely on their own. Picture a company that receives orders all day. An agent can wake up the moment a new order arrives and check that the product is available. From there, it can look up the shipping timeline, request approval, and email the customer with the details. Nobody typed a prompt because a trigger started the work. A customer support agent shows the same pattern from the outside. It can answer questions about returns and products from the manuals you give it. Handle hundreds of conversations a day, and pass the tricky ones to a person. Across all of these examples, the shape is the same. There's a narrow job, a clear source of truth, and a human who still owns the result. Notice that each example starts with a task someone already does by hand. The agent just takes over the repetitive part. If you're already thinking about your own job, good, because that's exactly how you should be listening to this. The demos always look smooth and the real value comes from the boring parts being right. If the return policy document is out of date, the agent hands out out of date answers with total confidence. That's why the next part matters. Because building one well is mostly about the details you feed it. How to build one without writing code. Building your first agent is less about technology and more about choosing well. The best first project is a small, repetitive job with a clear right answer, because that's where an agent shines and where you can tell whether it's working. Pick the task that makes you sigh when it lands in your inbox, and keep the first version small enough to finish in an afternoon. Nail this first one and every agent. After it gets easier to build, start by writing the instructions the way you'd brief a new teammate. Say who the agent is, what it should help with, and what it should do when it isn't sure, and keep the language plain. A specific job description is the single biggest lever you have over quality. Next, give it a small set of trusted documents instead of everything you own. A tight set of sources makes it easier for the agent to tell what's true, and it's far easier for you to keep those sources current. If a document changes, the agent follows the new version, so someone has to own that job. Add a tool only if the agent needs to act rather than just answer. If it only needs to explain. Knowledge is enough, and adding tools you don't need widens. What can go wrong when you do Add one. Start with a single action and test it hard before you add another. Testing is the step beginners skip and it's the step that saves you. Ask the agent the questions real people will ask, including the awkward ones, and try the phrasings a confused colleague would use. Then publish it where people work and tell them it exists because an agent nobody knows about helps nobody. The cost is worth understanding before you scale. Usage runs on copilot credits and light use is cheap, while heavy use adds up fast. A simple answer costs about one credit. A generated answer costs two and action costs five, and grounding an answer in your organization's data costs ten. Pay as you go runs about a penny a credit and a prepaid pack of twenty five thousand credits runs two hundred dollars a month. One complex request can quietly burn a dozen credits at once. Microsoft also disables custom agents. If a tenant sales past one hundred and twenty five percent of its prepaid capacity, it pays to watch usage rather than get surprised by it. The mistakes beginners make most agent projects don't fail because the technology is bad. They fail for a handful of predictable reasons, and knowing them in advance puts you ahead of most of the room. Remember the piece I said? People rush past because nearly every mistake on this list comes back to it. The most common one is reaching for the dream agent before the small one. People try to automate a whole department at once, and the project collapses under its own weight before it ships. A narrow agent that does one thing well teaches you more in a week than a grand plan teaches you in a quarter. The vagueness problem comes next, where the instructions say something like, be helpful and nothing else. An agent handed a job with no boundaries will fill the gap with guesses, and then the model takes the blame for a job description. Nobody wrote. Clarity here isn't optional. Connecting everything is another trap, and it feels generous. While it creates confusion when an agent can read ten sources that disagree, it has no way to know which one is right, and its answers get muddier. Not clearer. Fewer, better sources usually win. Access is where this turns serious. If an agent only answers questions about a policy, it probably doesn't need permission to edit the whole site. Least. Privilege is the habit that keeps small mistakes small. Handing over more access than the job needs turns a helpful assistant into a quiet risk. Two more habits round this out. Skipping the test means the first real user becomes the first test, and building an agent without telling anyone means it sits there helping no one. The last one is easy to forget because documents keep changing underneath an agent you've already shipped. The limits you should know about. Every tool has edges and agents have a few you should know before you invest real time in one. The most important is that an agent can be confidently wrong. It sounds just as sure when it's mistaken as when it's correct. Your only real defense is grounding it in sources you trust, and keeping a person in the loop on anything that carries consequences. Cost has an edge, too, and it's sharper than people expect because usage runs on credits. An agent that gets popular can quietly get expensive, and Microsoft cuts off custom agents. Once a tenant runs past the capacity it bought, a busy agent can hit that ceiling and simply stop answering until someone fixes the billing. Licensing adds another layer because the simplest building happens inside copilot, while deeper builds need more. That's a planning detail more than a deal breaker, and it's worth checking what your organization already owns before you buy anything. Governance is the edge nobody warns you about. Gartner warned in twenty twenty six that treating every agent the same, no matter how much freedom it has, tends to lead to failure. It also expects a large share of enterprises to pull back on autonomous agents by twenty twenty seven. Autonomy is a dial rather than a switch, and most beginners are better off keeping a person in the loop. None of that means you should wait. It means you should start small, ground your agent well and treat autonomy as something you earn one step at a time. Those edges are real and they're manageable, which is exactly why it helps to know them before you start. What to remember. And one question for you. If you remember one thing, make it this a copilot agent is just copilot with a job description, your organization's knowledge, and a set of tools it can use to act. That's the whole idea. And everything else is detail. Everything after that comes down to three habits. Start small, grounded in real sources, and keep a human in the loop for the things that matter. Do those and the agent earns its place and the tasks you hand over come back finished instead of half done. My question for you is simple what is the one repetitive task you'd hand off first if you trusted the answer? If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.