The 10.00 slot at HELish Summit 2026 had Tero Niemi, Modern Work and AI Specialist at OP Pohjola, talking about a tool most Copilot Studio people walk past: the Agent Builder inside Microsoft 365 Copilot. The session was “Building too many Copilot Agent Builder Agents: Experiments and wild ideas”, and he meant both halves. This is my recap; the ideas are Tero’s, the compression is mine.
He framed it as a book with four chapters: why Agent Builder, what he learned by going too far, the accidental governance project that followed, and three agents that were “the good, the questionable and the experimental”.
Why Agent Builder
Tero described his real role as a translator between the technology and the people who use it, and Agent Builder is where those two meet: everyone with a Microsoft 365 Copilot licence already has it. It lives where work already happens, it is a click away, and the first experiment is cheap. His phrase for it: from idea to agent before the coffee gets cold.
The third reason is the interesting one: the boundaries are educational. Agent Builder cannot do much of what an agent is supposed to do, and Tero said so plainly. But the things you have to learn to make even a limited agent work are the same things you need everywhere else. How to write an instruction that is structured enough without being too long. What a role actually is. Why an agent grounded on one SharePoint page does not know about the pages that page links to. Someone built an agent on a page, it could not answer, and the reason was that a human reads the links on a page and a knowledge source does not. That transfers to any platform.
What he learned by going too far
Tero started with Agent Builder when it appeared, around the end of 2024. His early agents had one paragraph of instructions and he expected them to work. They did not, and the learning came from doing the experiment and finding out why the agent kept steering into the wrong pattern. Good knowledge turned out to matter more than clever instructions, to the point where fixing the agent often meant going back and fixing the SharePoint content it was grounded on.
Then there is the constant change. The tool was called Agent Builder, then Copilot Studio Lite, then Agent Builder again. Code interpreter became “create files and charts” with the same functionality and a name that scares fewer people. SharePoint pages worked as knowledge, then stopped, then worked again the week after his workshop. Every how-to guide with screenshots went stale, which is why he now writes fewer of them and describes more. Custom skills are in preview: one day you see them, one day you do not, depending on whether you open Copilot through Teams or the app. His advice: open the tool five minutes before any training session, because it looked different yesterday.
Even though the agents that we have built with Agent Builder end up in a pile, we learn things that we can use also on those other agent platform tools.
The accidental governance project
Because anyone can create an agent, people did. The maker experience was faster than the admin experience, and by the time agents showed up in the admin center there were already hundreds of them. Nobody deleted anything, partly because the delete function is hidden deep enough that you have to teach people where it is. Congratulations, Tero said, you now have an inventory problem.
Agent 365 improved visibility: you can see which Agent Builder agents exist, how they are shared, how many people use them and how many answers they have given. Not the quality of the answers, but something. With one Agent 365 licence in the organisation you also get the Graph API, and that is where Tero went DIY. He compared it to punk rock: the do-it-yourself ethic, not the music.
His build is deliberately small, so that it can be thrown away when Agent 365 catches up: Graph API to detect new agents, a SharePoint list as the minimum viable backend, Power Automate and Teams adaptive cards to act. A new agent appears, the owner gets a card: have you read the ground rules, have you shared this, what is it for. An agent unused for 60 days, the owner gets another card: delete it or say why not. And when a use case is clearly bigger than Agent Builder, the same conversation is where you tell them to move to the right tool. Governance here is not blocking. It is finding the people who had a good idea and pointing them forward.
The good, the questionable and the experimental
The good one is a use case solution advisor. Grounded on OP Pohjola’s internal Copilot guidance and Microsoft’s own documentation, it recommends the right approach for a question: Microsoft 365, Power Automate, Copilot, or an agent. Tero uses it to double-check his own instinct when a colleague asks how something should be done, and its most valuable answer early on was often “do not build an agent, this already exists in Copilot”.
The questionable one started as eight separate agents with one role each: communicator, marketer, optimist, pessimist, scientist. When Copilot Studio started letting one agent orchestrate others, Tero tried the opposite: one Agent Builder agent with all the roles inside it, addressable in the prompt with @scientist or @internal communicator, and able to mix them. Three experts in one prompt, no one leaves with their identity intact. It worked as a brainstorming starter and he never used it for real work. With an 8,000 character instruction limit, eight roles get messy, and today he would build them as skills rather than instructions.
The experimental one came with a slide of Sylvano Bussotti’s Five Piano Pieces for David Tudor, a graphic score that does not look like music to most people. Tero, who plays experimental synthesizers in his spare time, drew the analogy carefully and with a disclaimer that he is not a software engineer: conventional software is like standard notation, strict about what to play and when. An Agent Builder agent is like a graphic score. The instructions and knowledge are not the outcome, they are the notation, and whoever interacts with the agent becomes the performer. Two people with the same agent get similar but not identical results, and that is the nature of the thing rather than a defect.
The agent behind it generates generative art: an HTML page with an ASCII traffic map, an audio engine that writes its own music, and the microphone enabled so the room affects what happens. Tero switched it on, the room made noise, the map reacted, and he adjusted delay lines and filters live. Not useful for work, and that was the point. Along the way he found that Agent Builder did not accept markdown files as knowledge until he renamed them to .txt, and that much of what he had stuffed into attachments now lives naturally as skills.
What I took home
The talk was honest about a tool that is easy to dismiss. Agent Builder agents mostly end up in a pile. The people who built them do not. They learned what a role is, what grounding means, why an instruction has to be structured, that an agent has an owner and a lifecycle, and that deleting things is part of the job. The pile of agents was the price of that education, and the governance project it forced was, in Tero’s words, not really an accident.