The agent ladder: what you actually building when you say ‘agent’ in Copilot
I get asked quite often to create agents when actually what they want is a prompt.
It’s an easy mix-up. “Agent” has become the word everyone reaches for the moment they want AI to do something useful, regardless of what that something actually is. Some of the time what they need is one good prompt. Some of the time they need that same prompt on a regular basis, so they save it somewhere sensible and reuse it. And some of the time they genuinely need an agent, they just haven’t worked out yet which kind, or how much effort that’s actually going to take.
These three things get called an “agent” almost interchangeably. They’re not the same thing, and knowing which one you actually need saves you from over-building small problems and under-building big ones.
Prompt, prompt library, or agent
A prompt is an instruction. You write it, you send it, you get an answer, it’s gone. Next time you want the same thing, you either remember roughly how you phrased it, or you write it again from scratch.
A prompt library entry is the same prompt, saved somewhere you and your team can find it again. You use it often, maybe weekly, maybe daily. It saves you the effort of rewriting it. But look closely at what’s actually happening each time you use it: you’re still doing the legwork. You’re pasting in the email thread, attaching the document, typing up the meeting notes, then running the prompt over the top. The prompt hasn’t changed, and neither has your job. It’s just filed somewhere handy.
This is the bit people get wrong most often: repetition alone doesn’t make something an agent. A prompt you use fifty times a week is still a prompt if you’re still doing the fetching and pasting fifty times a week. It’s a well-organised prompt library, and that’s a genuinely useful thing to have. It’s not an agent.
A prompt becomes an agent at the point it stops needing you to hand it fresh material every time. That’s the actual threshold, not how often you use it, not how clever the wording is, but whether it’s grounded in something live, a Sharepoint site, a mailbox, a data source, and can go and fetch its own context rather than waiting for you to paste it in. The moment you’re no longer the one gathering the input, you’ve crossed from prompt into agent.
A simple decision path
Run any “can you build me an agent” request through this, in order, before you touch anything:
-
- Is this a one-off question? Write a good prompt. Don’t build anything. Move on.
- Will you ask a version of this often but you’re still supplying the content by hand each time? That’s a prompt library entry, not an agent. Save it somewhere sensible and reuse it. You’re done.
- Does it need to answer multiple sequential questions while pulling content from somewhere live? Now you’re genuinely into agent territory.
- Does it need to do something, not just answer, update a record, send something, carry out a task? You’ve moved past the simplest form of agent.
- Does it need to run without anyone asking it, on its own schedule or the moment something happens? You’re looking at a different kind of agent, and a different conversation about who’s watching it.
- Does it need to operate somewhere a chat window can’t reach, an old piece of software with no way of connecting to it directly? You’re at the edge of what’s simply configurable.
Where you land tells you exactly what you need. Most “can you build me an agent” requests I get end up don’t go past step 1 or step 2. That’s not a failure of ambition, that’s the framework doing its job properly.
The ladder: once you know you need an agent, how do you create it in Copilot?
Assuming you’ve made it past the decision path and genuinely need an agent, here’s the full range of what “building an agent” can mean, from simplest to hardest. The easiest way to picture it: you’re taking on a new member of staff and gradually giving them more responsibility. Same person, same relationship, just trusted with more at each rung.
1. Describing it in a sentence
Think of this as someone’s first day. You hand them a proper induction pack, point them to where everything’s kept, and tell them who to sound like. They can answer questions confidently and look things up for you. What they can’t do yet is act on anything, they haven’t been signed off for that.
This is Agent Builder, sitting inside Copilot Chat. You describe what you want in plain English and it builds itself around your description, grounded in files, a site, or instructions you give it. No configuration screens to learn, no code. It answers and retrieves brilliantly. Doing something is the next rung.
Good for: answering the questions people ask you again and again.
2. Adding actions
Same person, a few months in. They’ve proven themselves, so you extend a bit of authority, they can approve a small expense, log a request, update a record themselves, without checking with you first every time.
In Copilot terms, this is where you start adding actions, small defined jobs the agent’s allowed to carry out on your behalf: raising a ticket, updating a spreadsheet, sending a specific type of update. Still no need for you to code anything, as this is built through Copilot Studio’s simpler view or the Agents Toolkit, but now you’re deciding exactly what you’re comfortable letting them do unsupervised.
Good for: small, well-defined tasks you’d otherwise do yourself out of habit.
3. A proper build
The one person has grown into a small team. Each has their own set of tasks, one deals with a particular type of enquiry, another handles something else, and they pass work between themselves. When something comes up that’s outside anyone’s expertise, they know who outside the team to bring in.
This is Copilot Studio proper. Instead of one instruction, you’re defining topics, a set procedure the agent follows for a specific kind of request, much like a team member following a set process for a particular enquiry. You can give the agent tools, specific jobs it can call on to get something done. And you can connect it to specialist help built entirely outside Microsoft, using an open standard called Model Contex Protocol (MCP), think of it as a shared qualification that lets any outside specialist plug straight into your team, rather than you training each one from scratch. Where the task is bigger still, one agent can hand the whole thing to another agent built by someone else entirely, in a different department or a different organisation altogether.
Good for: anything that genuinely needs more than one specialism to get done properly.
4. Working without being asked
This member of the team now has standing instructions for when nobody’s around. If a particular thing happens, they act on it themselves, no one needs to notice it and ask them to.
This is an autonomous agent. Rather than waiting to be asked, it’s set off by something happening, an email landing, a certain time of day, a record changing, and carries the whole task through unsupervised. Worth knowing, the agent acts under the authority of whoever built it, so it’s worth being deliberate about what you’re comfortable letting it action without you needing to trigger it.
Good for: the genuinely routine stuff, where waiting for a human to notice is the only thing slowing it down.
5. Given a pair of hands
This member of the team can now sit down with an old bit of machinery that’s never going to be modernised, and operate it exactly as a person would, because there’s simply no other way in.
This is computer use. The agent operates an actual computer, clicking, typing, moving between screens, for the handful of older systems that were never built to connect to anything else via APIs or MCPs. Still set up within Copilot Studio, still no code required from you, but it’s now acting on a real machine, so proper oversight matters more here than anywhere else on the ladder.
Good for: the one stubborn old system everyone’s been working around for years.
6. Built from scratch
At this point you’ve stopped training an existing member of staff altogether. You’re commissioning a bespoke piece of equipment, engineered and built from the ground up by someone qualified to do it.
This is pro-code, built using tools like Azure AI Foundry and Semantic Kernel, written in a language like Python. It’s proper software development, with everything that comes with it: design, testing, and upkeep. It’s where an organisation’s most complex, most bespoke needs end up, once nothing off-the-shelf will quite do.
Good for: the requirement so particular that nothing configurable will ever fit it.
Nobody needs to climb this whole ladder for one requirement. The skill is knowing which rung the problem needs, not which rung sounds most impressive when you describe it back to someone.
So where do you go next?
Take the next “can you build me an agent” request that lands on your desk, and run it through the decision path above. Pay particular attention to steps 2 and 3. You’ll likely find more of your “agents” are actually well-used prompts than you thought, and that’s a good outcome. Not every task needs an agent.