The hard part is not building
a Copilot agent.
It is deciding not to.
Copilot Studio made agent building low-code on purpose. That is genuinely good, and it is why an organization that had zero agents in January can have 60 by autumn, most of them built by people who have since moved to another team.
Microsoft documents how to build them better than anyone, and I am not going to repeat that here. This page is about the layer nobody documents: which agents are worth building, which ones quietly become a liability, and who is responsible for them in 12 months.
The gap the numbers describe
Deloitte surveyed 3,235 IT and business leaders across 24 countries for its 2026 State of AI in the Enterprise report. Only 21% said their organization has a mature governance model for agentic AI.
Put next to how fast agents are actually being created, that is the whole story. Creation is frictionless. Everything after creation is not: ownership, review, cost, access scope, and knowing the thing still does what it did on the day it was built.
4 questions before you build any agent
I ask these in the same order every time. If the first two do not have clear answers, the rest does not matter.
01 Does this task actually repeat?
Agents earn their keep on things that happen weekly, not on things that happen impressively once. If you cannot say how many times a month this runs, you are building a demo.
02 Who owns it in a year?
Not who is building it. Who is accountable when it breaks, when the source data moves, or when the person who built it changes roles. An agent with no named owner is a future incident with a delay timer on it.
03 What can it reach, and does it need all of that?
Connectors get scoped generously during the build because it is faster. That scope tends to stay. Decide what the agent genuinely needs before it works, not after.
04 Would a good prompt have done the job?
This one kills more proposed agents than the other 3 combined, and that is a good outcome. A saved prompt costs nothing to maintain. An agent is a small piece of software your organization now owns.
Where agents genuinely pay off
The pattern that holds up: narrow scope, one clear job, a data source that does not move much, and a person whose week is measurably lighter because of it.
The ones that keep working a year later tend to be unglamorous. An agent that answers the 30 questions a support team gets every week from a document set that is actually maintained. An agent that takes a standard intake form and turns it into the structured summary the next team needs. Boring, repeated, owned by someone specific.
And where they do not
Agents built to demonstrate that the organization is doing AI. Agents that need 5 systems to agree on a data format that they do not currently agree on. Agents built on a document set nobody has cleaned in 3 years, which will confidently return the 2023 policy.
Also worth saying plainly: an agent built on top of loose permissions inherits those permissions. Copilot only surfaces what the user could already open, and the same principle applies here. If that is unresolved, fix it first. See Copilot, GDPR and EU data residency.
The ownership problem, said out loud
The most common thing I find in an organization 9 months into agents is a set of them still running, still connected, that nobody in the room can fully account for. Not because anyone was careless. The person who built it moved on, and nothing in the process required a handover.
The fix is not a product. It is a rule agreed before the building starts: every agent has a named owner, a stated purpose in one sentence, and a review date. Organizations that write that down first end up with fewer agents and considerably less anxiety about them.
How I usually approach this with a team
Two different needs come up and they are worth separating.
Teams that want to build their own
A hands-on session where we go through the 4 questions above on their real candidate list, then build 1 or 2 agents that survive the filter. Most of the value is in the list that gets cut. Hands-on sessions are capped at 25 participants so people who get stuck actually get help.
Organizations that want something built
I build agents for clients too. Same filter applies first, because a well-built agent for a task that does not repeat is still waste.
Leadership that needs to decide a policy
A shorter session on what to allow, who owns what, and where to draw the line between a saved prompt and a built agent. Lectures have no participant cap and can run for the full organization.
Questions I get about agents
Should we let anyone build agents, or restrict it?
Restricting it entirely tends to push people toward worse workarounds. What works better is letting people build within a clear boundary: named owner, stated purpose, review date, and a defined set of connectors that do not need a separate approval. Boundaries free people up. Vagueness paralyzes them.
How many agents should an organization have?
Fewer than it will end up with. I have never walked into an organization and thought the problem was too few agents.
Do we need Copilot Studio, or is Microsoft 365 Copilot enough?
For a large share of teams, Microsoft 365 Copilot plus good prompting covers the work, and Copilot Studio is a step they do not need yet. That is worth checking honestly before it becomes a budget line.
Can you help if we have already built a lot of them?
Yes, and it is a common starting point. The work is inventory first, then deciding what to keep, hand over, or retire. It is less exciting than building and usually more valuable.
Do you deliver this remotely?
Yes, live in English over Zoom, for teams across Europe and elsewhere. Remote is the default for most of the teams I work with.
Not sure whether you need agents or better prompts?
That is a good question to bring to an intro call. 30 to 45 minutes, we go through what you are actually trying to automate, and you get a straight answer about whether this is a Copilot Studio problem or not.