Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Pages Menu
TwitterRssFacebook

Posted by on Jan 21, 2025 in Microsoft 365 Copilot

Building Declarative Agents with API Plugins for Microsoft Copilot Part 1 – Introduction

Building Declarative Agents with API Plugins for Microsoft Copilot Part 1 – Introduction

This is the first in a series of 5 blog posts and videos around Declarative Agents for Copilot.

In this blog post I’m going to talk about what Declarative Agents with API plugins are and how they fit in to the Microsoft 365 developer stack alongside other technologies. I’m going to talk about how they work and why you’d use one. I’m going to conclude talking through some potential use cases for these types of Declarative Agent. The aim is to give you a good grounding for the next 4 blog posts.

In part 2 I will cover the pre-requisites required and the work you need to undertake before you can start.
In part 3 I will introduce my demo application, and walk you through it.
In part 4 I will show you how the demo application was built, walking you through the process so that you can build your own Declarative Agent with an API plugin.
In part 5 I’ll cover off the gotchas, tips & other things that I learnt along the way.

What are Declarative Agents with API Plugins?

Announced in May 2024 at Build and originally called Declarative Copilots, it wasn’t until their GA launch in September 2024 that we knew them as Declarative Agents (DAs).

Broadly, a Declarative Agent is an experience that is more specialised than the conversation you might have with Copilot Chat. In this context, you could think of Copilot Chat as “an agent”, or “the agent” for Copilot. By contrast, a Declarative Agent is one that has been pre-populated with a set of instructions to narrow its scope, either of data it can see or subjects it can advise or act on.

So, a DA is an agent that contains a manifest describing its capabilities and the scope of its actions, which is then added by a user (or their admin) to Copilot Chat, and visible in the Copilot Agents collection.

DAs with API Plugins are a specific subset of these Declarative Agents where, in addition to the other information about the agent, a developer can also include information about APIs that can be used by the DA in answering the question.

They are a way of making DAs based around an existing API or APIs. Although they can be very powerful, they are surprisingly simply technically. If you have an existing API, you can “declare” the shape of that API and package it together with a manifest describing the DA and how it will work. When loaded into Copilot, the Copilot orchestration will use the manifest and the declaration of the API to decide when it makes sense to call one the API endpoints, and will do so, passing in any required values and processing the result. This isn’t just restricted to GET methods, Copilot can write data and take other actions via API.

Because of this, they occupy a really interesting space in between low-code Copilot Studio agents and full-on Bot Framework experiences. For many applications, interaction with an API is the “goal” of a bot, meaning that DAs might enable you to quickly get a solution together with ever needing to worry about writing a user flow, or dealing with implementing API calls etc.

Things get really powerful when you consider that, with some tricks, a DA could take information from multiple APIs and combine them together in new and interesting ways. Because none of it is coded in the traditional sense of computer coding, the actual combinations can be decided at run-time based on user questions.

How do they work?

There are really 3 key parts of a Declarative Agent that includes an API Plugin:

  1. OpenAPI schema of an API (or APIs). This is the mechanism by which Copilot “knows” about your API. The OpenAPI schema is a standardized framework for describing and documenting APIs, enabling consistency, automation, and improved collaboration across systems.
  2. An “instructions” document, which asks as the system prompt for the agent. This is where you can instruct the agent how to behave and how to answer.
  3. A Declarative Agent schema that describes the agent, its capabilities and actions. It includes links to both of the files mentioned above.

Sounds simple, right? And it is, but that simplicity hides and abstracts some complexity. Don’t expect to have the same sort of control over how the agent answers or when it calls your APIs as with a more traditionally built bot. However, with the right APIs calls and good instructions, it’s possible to create something that is actually a lot more flexible and able to adapt to a surprising range of user prompts.

Isn’t this just like GPT Actions?

Yes, it is, but using Copilot as the orchestrator. There are several reasons why you’d want to use Copilot agents for your next project though:

  • User Friendly: Copilot agents are right in the user’s flow of work (assuming they are already using Microsoft 365 and Copilot). Further, a DA will look and behave exactly the same as the rest of Copilot Chat, making users more likely to engage with it and not be scared off by it.
  • No additional costs. Once you’ve paid for Copilot you can create and access Declarative Agents and use the models in Copilot for your Gen AI. You don’t need to maintain a subscription to an external service such as Chat GPT. This also means your data stays within Microsoft 365.
  • Your DA will have access to Microsoft 365 data, just like Copilot Chat. That means that you can combine data from Microsoft 365 and an external API, which can be really powerful. For instance, I wrote an agent (back then called a plugin!) to compare the emails I was sending in Microsoft 365 with my manifesto of how I wanted to send emails, hosted externally, and then combine to two in order to keep me honest and call out times I strayed. You can see the video for that here: How to: build and deploy the EASIEST and yet MOST IMPACTFUL plugin for Copilot for Microsoft 365!

Where can this be useful?

I would consider this for any solution where you have a back-end API that users need to interact with. Maybe they’re doing that today with a user interface they hate. Maybe they’re asking for a bot as an alternative. Or maybe you just haven’t got to building an interface for a new project yet. It’s entirely possible that for some use-cases, a DA could be the only user interface that’s needed.

Another place where this could be really useful is in providing a new lease of life to legacy applications, many of which have APIs but outdated UIs.

Finally, have a look at what middleware you have, and what it’s doing. Anywhere that requires manual intervention, approval, or other input, could be a great candidate for this. In any organisation there are business process flows that have built up. Sometimes it’s systems talking to other systems. Quite often it’s people taking data from one system and giving it to another system. Many of these have APIs. Declarative Agents really rip up the rulebook for how you can take a set of API endpoints and have users work with them, without them needing to know how they work.

Once you’ve written one, you’ll start looking for places to put them everywhere!

Next time, we’re going to dig in what you need to do in order to get your development house in order before you can start, covering pre-requisites and API hygiene. We’ll also look at how to create an OpenAPI schema for your API if you don’t already have one.

Written by Tom Morgan

Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.
Buy the book: Building and Developing Apps & Bots for Microsoft Teams. Now available to purchase online with free updates.

Post a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share to Microsoft Teams