Blog

Insights & ideas

Stay ahead with expert articles, industry trends, and actionable insights to help you grow.

How to build, deploy, and share custom AI agents with Copilot Studio
10 mins read
October 15, 2025

How can I build, deploy, and share custom AI agents with Copilot Studio?

Learn how to build, deploy, and share your own AI agents in Copilot Studio, from defining purpose and prompts to connecting data and publishing for your team. A practical, step-by-step guide to turning ideas into working copilots.

Read more

TL;DR

Copilot Studio makes it possible for IT Ops and business teams to create custom AI agents that can answer questions, run processes, and even automate workflows across Microsoft 365. We recommend a structured approach: define the use case, create the agent, set knowledge sources, add tools and actions, then shape its topics and triggers. But before you dive into building, check your data quality, define a clear purpose, and configure the right policies.  

Before you start setting anything up, stop

It’s tempting to open Copilot Studio and start dragging in tools, uploading files, and typing instructions. But an agent without a plan is just noise.

  • Get your data in order first. Bad data means bad answers, and no amount of clever configuration can save it.
  • Define the “why” before the “how.” Build around a specific use case. For example, sales support, finance queries, service troubleshooting.
  • Don’t build for the sake of building. Just because you can spin up a chatbot doesn’t mean you should. The best agents are purposeful, not experimental toys.  

Think of your agent as a new team member. Would you hire someone without a role description? Exactly.

Building your first Copilot: practical steps

Once you know the “why”, here’s how to get your first custom agent working.

1. Author clear instructions

Clear instructions are the foundation of your agent. Keep them simple, unambiguous, and aligned to the tools and data you’ve connected. Microsoft even provides guidance on how to write effective instructions.

2. Configure your agent

  • Content moderation: In the Agent → Generative AI menu, set rules for what your Copilot should (and shouldn’t) say. For example, if it can’t answer “XY”, define a safer fallback response.
  • Knowledge sources: You can upload multiple knowledge sources, or add trusted public websites so the agent uses those instead of a blind web search.
  • Add tools: Agents/Tools/Add a tool lets you extend functionality. For instance, connect a Meeting Management MCP server so your Copilot inherits scheduling skills without rebuilding them.

You’re not just configuring settings — you’re composing a system that reflects how your organisation works.

3. Validate your agent’s behaviour

As of now, there’s no automated testing of agents, but that doesn’t mean you should skip this step. You can manually test your agent as the author. The Copilot Studio test panel allows you to simulate conversations, trace which topics and nodes are activated, and identify unexpected behaviours. The panel is there to help you spot gaps, so take the time to run realistic scenarios before publishing.

4. Pick the right model

Copilot Studio now offers GPT-5 Auto (Experimental) alongside GPT-4.0 (default). The experimental model can feel sharper, but it may not reliably follow instructions. If stability matters more than novelty — and for most IT Ops rollouts it does — stick with 4.0 until you’re confident.  
(As of 15th October, 2025. Note that model availability and behaviour may change over time).

The difference between noise and value

Rolling out a custom agent isn’t about dropping a chatbot into Teams. Done right, it’s about embedding AI into workflows where it drives real value — answering finance queries with authority, guiding service agents through processes, or combining AI with agent flows for end-to-end automation.

The difference between a useless bot and a trusted agent is preparation. Build with intent, configure with care, and test until you're sure it works properly.

You wouldn’t give a new hire access to your systems without training, policies, and supervision. Treat your AI agents the same way.

Need help automating workflows with Copilot Studio? Get in touch with our experts to discuss your use case.

Soft blue and white gradient background with blurred smooth texture
Filter
Industry
Technology
Solution category
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
How to overcome org-wide writers' block
March 14, 2024
6 min read
How to overcome org-wide writers' block
Read more

Every quarter we have three Objectives that will help us improve as an organisation. This can vary from Software Development practices to improving (or rather: re-hauling) our finance reports, but more will be written on these Objectives later.

This quarter, one of our Objectives is to start and cement having a company-blog. This has been a recurring topic since the beginning of the organisation - although I've consciously put it to rest in the past years as we've been so focused on cementing the core team.

Last year, we started focusing on our marketing efforts and naturally, the topic of the blog has arisen. Initially, I thought that with Judit, our marketing and sales assistant, we can just put our heads together and churn out a bunch of posts, but then realised we need to get the "troops on the ground" to provide inputs - at least the backbone of a post to stand a chance of sounding novel and not just being "yet another corporate blog."

I knew it's not going to be easy to get a bunch of consultants knee-deep in project-work to get their focus and time allocated to writing blogs. What a perfect opportunity to make this a Q1 objective!

A reality check

I naively thought it'd be sufficient to call out the Q1 objective and have a brainstorming session about our social media usage and post ideas and off we go: blog posts will be sprouting left and right.

Six weeks later, the end of the quarter is nearing, and we have 0 posts.

So what can I do to get our smart and eager colleagues to exert discretionary effort to create a blog post - let alone, get into the habit of writing and maintaining a blog.

I resorted to the following basic management (leadership?) tactics in yet another Dojo agenda point. (Dojo: The forum held weekly for the development of our internal operations.)

Start with why

We talked with the team about what's the purpose of writing a company blog and why it matters in the professional services industry:

It's so easy for anyone to say they are experts in a particular topic but what speaks volumes is if we provide insight into our expertise.

Plus, it also makes it possible to create more meaningful "noise" on LinkedIn and social media.

Not the least, we maybe help fellow Power Platformers, consultants and end-users alike by publicly sharing knowledge bites that proved to be useful for us.

Provide context and address concerns

After having talked about the why, I showed an example of what good looks like (eg. https://www.ycombinator.com/blog/how-to-maintain-engineering-velocity-as-you-scale or https://www.faire.com/blog/) and asked the team if they have any questions, concerns.

The main message here was:

don't worry too much, just get started, we are not writing War and Peace here

Make it easy to start

Next, we talked about how we "don't need to start from scratch", a lot of what we do is documenting, so why not use those as a starting point for blog posts.

We have the following areas to go to for inspiration and starting points:

Wiki

Last year we started making good use of our Azure DevOps wiki sites and it's increasingly becoming an internal go-to resource. Why not just use some of the more useful entries to turn them into external-facing material?

Internal Comms

Not as often, but we do rely on written internal comms - such as our strategic goals, one-pager vision statement, competencies. We can turn these into blog posts that talk about us as an organisation, how we work and where we are heading.

Our clients are increasingly looking for "cultural fitness" when selecting a partner, so I'll be happy to share this openly. This may even help with recruitment and on-boarding.

Ways of Working

We are extensively using Azure DevOps, GitHub and generally the whole Microsoft eco-system to manage our work. I appreciate it's not straight-forward to design the toolkit at our disposal in a way that makes it ergonomic for every member of an organisation. We have lots of lessons learned in this place and our current Ways of Working is pretty well documented.

When we built our internal systems, it would have been great to understand like-minded companies' architecture. The toolkit we use definitely shapes us as an organisation (think: socio-technical complex systems), hopefully gives us a competitive edge, but sharing our good (and sometimes not-so-good) practices may benefit others with similar challenges.

Knowledge Sharing Sessions

We regularly hold knowledge sharing sessions, internal demos - lot of which is already documented - with a little effort and obfuscation, these can be easily turned into external-facing materials.

These will provide great insight into what are the areas that interest us and what challenges we face as a team in our projects.

Brainstorm

Prior to the Dojo, I asked that each PO is present or delegates a team member so we have the right coverage. I asked each team to gather post ideas based on the above and take them back to the team and select one which they will work into a full-fledged post in the coming two weeks.

Lead with example

I had to admit, I wasn't comfortable writing blogs myself (I had one attempt when taking a gap-year and travelled to India). Those that worked closely with me, know I'm not much of a writer.

But I had to be the "tip of spear that will break the ice", so here I am writing the inaugural blog post.. :)

Where to next?

Accountability and Follow-up

Hopefully, by now the message has landed with the team that this is something, we'll crack on with and asked the team whether they can get behind this. The jury's still out to see how many posts will be written by the end of the month.

We've put in a check-in for next to see how the teams are progressing with the single selected topic and see if we can help them overcome and doubts or concerns, they may have.

What we didn't do

Carrots or sticks

We quite consciously avoid tying performance evaluation or bonuses against our quarterly objects (very much in line with OKR principles) - hence we will not mandate a blog quota or tie it to any bonuses. I'd much rather have a few of our team members produce quality posts, then have everyone write poor ones out of sheer necessity

Emphasize how writing improves structured thinking and deep understanding

In hindsight, we could have talked about how writing helps improve one's understanding, and this is a great way to deepen one's knowledge.

So you may ask, why blogs? Why not YouTube videos and/or Podcasts? Don't worry, we'll get there eventually :)

Sorry, no items found with this category

Ready to talk about your use cases?

Request your free audit by filling out this form. Our team will get back to you to discuss how we can support you.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Stay ahead with the latest insights
Subscribe to our newsletter for expert insights, industry updates, and exclusive content delivered straight to your inbox.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.