Building Microsoft 365 Copilot Agents With Agent Builder - What Actually Works

April 28, 2026•9 min read•Michael Ridland

Every Australian business with a Microsoft 365 E3 or E5 licence has a quiet revolution sitting in their tenant right now. Agent Builder ships inside Microsoft 365 Copilot, and most of our clients don't realise they can spin up a declarative agent in about ten minutes without writing a single line of code. The marketing around this is loud, which means a lot of leaders have heard about it. The reality on the ground is more nuanced, and that's what I want to talk about.

We've been rolling out Copilot agents for clients across financial services, professional services and manufacturing since the feature went generally available. The pattern is consistent. Someone in the business uses Agent Builder, gets a working agent in an afternoon, and then immediately hits a wall when they try to scale it across a department. That gap between "I made a thing" and "this thing works reliably for 80 people every day" is where most of the interesting work happens.

What Agent Builder Actually Is

If you've ever tried to build a custom GPT in ChatGPT, the experience is similar but with one big difference. Agent Builder grounds your agent in your organisation's data. SharePoint sites. Outlook emails. Teams chats. Files you upload directly. Connected systems through Microsoft 365 Copilot connectors. The agent isn't just a clever prompt sitting in front of an LLM. It's a clever prompt that knows what's in your tenant.

You access it through Microsoft 365 Copilot. Click "New agent" and you get three paths. Describe what you want in natural language. Configure manually through the Configure tab. Or start from a template. Each path has its place, and choosing the wrong one for the job is one of the most common mistakes I see.

The Natural Language Path

This is the default option Microsoft promotes, and for good reason. You type something like "Summarise my daily emails and include attachments" and Agent Builder works out the rest. It picks knowledge sources. It writes the instructions. It generates starter prompts. The whole thing feels conversational.

For first-time users, this is the right path. It removes the cognitive load of working out what every field means. You describe the outcome you want, and the tool fills in the implementation details.

But here's what I've learned the hard way. The instructions Agent Builder generates from natural language are often too generic for serious production use. They work. They don't fail. But they don't handle edge cases the way a deliberately written instruction set would. If you're building an agent that 50 people will use every day for a critical process, you want to see and edit those instructions yourself.

What we typically do on client engagements is use the natural language path for the first pass, then switch to the Configure tab to harden the instructions. It's faster than writing from scratch and gives you better output than relying on the AI-generated instructions alone.

The Configure Tab - Where Production Agents Live

The Configure tab is where the real work happens. Five fields matter most. Name. Description. Instructions. Knowledge. Starter prompts.

The Description field has more impact than most people realise. Microsoft's large language model uses it to decide when your agent should be invoked. A vague description like "An agent for sales" means Copilot might not pick your agent when a user asks a relevant question. A specific description like "Answers questions about Q3 2026 sales pipeline data from Salesforce and helps draft follow-up emails to prospects" tells the model exactly when to use this agent.

We have a 1000 character limit on Description. Use it. Don't write 50 words when 500 will help the LLM make better routing decisions.

The Instructions field is where you spend most of your time. Microsoft gives you 8000 characters. This is enough for serious behaviour shaping. Good instructions include:

The agent's role and scope (what it should and shouldn't do)
The data sources it should reference and how
The format of responses (length, tone, structure)
Error handling for missing or ambiguous information
Specific examples of correct behaviour

I've seen agents with 200 character instructions and agents with 7500 character instructions. The longer ones are almost always better. Not because length matters, but because thoroughness matters, and thoroughness takes characters.

Knowledge Sources - The Part That Trips Everyone Up

You can attach up to 20 knowledge sources to an agent. SharePoint sites. Specific folders. Specific files. Public websites. And if your users have the Microsoft 365 Copilot add-on licence, you can also pull from Outlook, Teams, and Microsoft 365 Copilot connectors.

The 20-source limit sounds generous until you're working in a large organisation. A finance team I worked with wanted to attach about 60 SharePoint document libraries to their reporting agent. We had to architect a solution that consolidated content into a smaller number of well-organised sources, which turned into a content migration project of its own.

Here's the thing nobody mentions about knowledge sources. Quality matters more than quantity. An agent grounded in 20 well-curated documents will give better answers than one grounded in 200 poorly organised ones. Spend time on the content before you spend time on the agent. We've helped clients with exactly this kind of AI workspace setup work and it's nearly always worth the investment.

Permissions inheritance is the other gotcha. If you reference a SharePoint site as a knowledge source, the agent respects the existing permissions on that site. Users can only retrieve information they already have access to. This is correct behaviour from a security standpoint, but it means your agent might give different answers to different users. Test this with multiple user accounts before rolling out broadly.

Templates - Useful for Learning, Limited for Production

Agent Builder ships with templates. AI Learning Advisor. Career Coach. Corporate Communications Crafter. The full list covers common use cases.

Templates are great for understanding what a well-built agent looks like. Open one. Read the instructions. Look at how it structures starter prompts. You'll learn more about agent design in 15 minutes of poking at templates than you will from a week of reading documentation.

For actual production use, templates are starting points. The Career Coach template assumes a generic context that won't match your organisation's HR processes. The Corporate Communications template doesn't know about your brand voice. You'll customise everything, which is fine, but don't expect templates to be drop-in solutions.

Capabilities - Code Interpreter and Image Generator

Agent Builder lets you add capabilities. Code interpreter runs Python in a sandbox, which is genuinely useful for data analysis tasks. Image generator creates images from prompts.

The code interpreter is the more interesting one. We've built agents for finance teams that use code interpreter to perform reconciliations on uploaded Excel files. The agent receives the file, runs Python to compare values across sheets, and returns a summary of discrepancies. This kind of workflow used to require custom development. Now it's a 30-minute configuration job.

Watch out though. The code interpreter has limits. It can't access external systems. It can't make API calls. It's a sandbox for computation, not an automation engine. If your use case needs to update a CRM record or send a Teams message, you'll need to look at Copilot Studio or agentic automation for the action layer.

What Goes Wrong in Practice

A few patterns I see repeatedly when reviewing client agent deployments:

The agent gets ignored. A team builds a great agent, deploys it, and nobody uses it. Usually because Copilot's router doesn't know when to invoke it. Fix the Description field. Make it specific about when the agent should be used.

The agent hallucinates despite having knowledge sources. This happens when instructions don't tell the agent to prioritise grounded data over its general training. Add explicit instructions like "Always base your answers on the provided knowledge sources. If the information isn't in the knowledge sources, say so rather than guessing."

The agent works for the builder but not for users. Permissions issue. The builder has access to all the SharePoint content. Users don't. Test with a user account that has typical permissions before rolling out.

Performance degrades over time. As people add more knowledge sources, response times increase. We've seen agents go from 3-second responses to 15-second responses after a team added too many sources. Be ruthless about pruning sources you don't need.

When Agent Builder Is The Right Choice

For internal-facing tools that need to be built quickly, grounded in M365 content, and used by people who already live in Teams or Word or Outlook, Agent Builder is excellent. The total cost of ownership is low because there's no infrastructure to manage. Updates roll out automatically. Users access agents through the Copilot interface they already use.

For customer-facing tools, complex workflows that touch multiple systems, or use cases requiring tight performance control, you'll outgrow Agent Builder pretty quickly. That's when you move to Copilot Studio, Microsoft AI Agent Framework, or a fully custom agent build depending on your requirements.

Most organisations need a mix. A handful of Agent Builder agents for everyday productivity. A few Copilot Studio agents for cross-system workflows. Occasionally a custom build for the high-value, differentiated use cases. Working out which approach fits which problem is most of the value we provide in advisory engagements.

The Honest Take

Agent Builder is good for what it is. It's not going to replace serious custom development for hard problems. It will replace a lot of the basic chatbot and knowledge retrieval work that organisations used to spend six-figure budgets on.

The biggest mistake I see is treating Agent Builder as either too capable or too limited. Treating it as too capable leads to disappointment when you discover the constraints. Treating it as too limited means you miss out on quick wins that could be delivered in days rather than months.

Get hands-on with it. Build something small. Use it for a week. You'll understand its shape much better than from reading any blog post, including this one.

For teams looking to build agent capabilities seriously across an organisation, the technology choice is usually the easy part. The harder problems are governance, content strategy, user adoption, and integration with existing workflows. We work with Australian organisations on exactly these problems and you can read more about our approach to Copilot deployments or reach out to discuss your specific situation.

Reference: Build agents by using Agent Builder in Microsoft 365 Copilot