Orchestration in Copilot Studio: Classic or Generative AI

In the fields of Automation and Artificial Intelligence, orchestration is crucial for optimizing processes. Within Copilot Studio, two prominent orchestration methods have emerged: classic orchestration and generative orchestration. Each approach offers unique advantages and challenges, making it essential to understand their differences and applications.

Classic orchestration relies on predefined workflows and rule-based systems to manage tasks and processes. This method is known for its reliability and predictability, as it follows a structured path to achieve desired outcomes. However, it may lack the flexibility to adapt to dynamic and complex scenarios.

On the other hand, generative orchestration leverages advanced AI models to dynamically generate workflows based on real-time data and context. This approach offers greater adaptability and can handle more intricate tasks, but it may introduce unpredictability and require more sophisticated management.

In this blog post, through a practical use case, we will explore how each method operates, highlighting their respective pros and cons. By the end of this article, you will have a comprehensive understanding of which orchestration method best suits your needs and how to effectively implement it in your projects.

Use case

We want to create an agent to handle device requests made by employees. As a backend, we will use SharePoint lists (although we could have used Dataverse) used jointly with Power Automate Approvals feature. For each request we will store device name, device type, price, requester, comments and status, as you can see in the following screenshot:

The agent will basically perform two actions:

• Make a new request: It will allow any (internal) user to request a new device.
• Get status of a request: Using a request identifier, the agent will show what is the status of the request (pending, approved, rejected).

In the following sections we will create two different agents: the first will use classic orchestration, while the latter will use generative one.

Classic orchestration

Classic orchestration refers to a method where the agent responds to user queries by triggering predefined topics based on matching trigger phrases. This approach relies on a structured and rule-based system to manage interactions, ensuring that the agent follows a predictable path to address user requests. Some of the key topics in classic orchestration are:

• Trigger Phrases: The agent selects topics to respond to users by matching their queries with predefined trigger phrases. This ensures that the agent’s responses are consistent and aligned with the specific topics configured.
• Actions: Actions within classic orchestration can only be called explicitly from within a topic.
• Knowledge usage: Knowledge can be used as a fallback when no topics match a user’s query or can be called explicitly from within a topic. This provides a way to handle queries that do not fit neatly into predefined topics.
• User input: The agent uses question nodes within topics to prompt users for any required information.
• Response generation: Responses to users are authored within the topics using message nodes. The agent delivers these predefined messages or calls actions as needed to address the user’s query.

We set up the custom agent to utilize classic orchestration, including a description and detailed instructions to give it proper context.

Therefore, using classic orchestration, we created the topics to handle the two main actions. The topic designed to manage new requests from users would look like the following:

As you can see, as soon as the users enters a phrase like “request a new device”, or “order a new device”, the topic is triggered with the following steps:

1. Prompt the user to to enter device type, device name, price and comments.
2. Call a Power Automate cloud flow to create an item in the SharePoint list.
3. Get the information returned from the Power Automate flow and display a message (request identifier).

In order to check the status of a device request, the topic would be designed like it is shown in this screenshot:

When the user enters a phrase like “check device request” or “status of my device request”, the topic is triggered and the following steps are performed:

1. Ask the user to enter Request Identifier
2. Call a Power Automate flow to search for a SharePoint list item based on the specified ID.
3. Display a message with the information returned from the Power Automate flow.

We highly recommend to follow topic authoring best practices and also optimize trigger phrases and natural language understanding in order to avoid topic overlapping, and create reusable components.

Generative orchestration

In contrast to classic orchestration, generative orchestration allows the agent to dynamically generate responses by selecting the best actions, knowledge, and topics based on real-time data and context. This approach offers greater flexibility and adaptability but may introduce unpredictability. Reviewing the agent activity in real-time during testing, or evaluating its history from past events is a basic task to find problems and opportunities for improvement when using generative orchestration.

In this case, we want to create the same agent we did in the previous section, but using generative orchestration. Therefore, we will not create any topics, and agent behaviour will be defined by:

1. Instructions: Providing concise and clear instructions is fundamental to define agent behaviour.
2. Actions: Each action should be described with its purpose, allowing the agent to use generative AI to generate questions that are required to fill the inputs needed to perform the action.

In the instructions section we specify the agent’s behaviour:

• Step 1: If a users requests for a new device, prompt sequentially for Device Type , Device Name, Price Comments. Store each as a variable and validate none are blank (ask clarifying questions if needed). Finally call the NewRequest action to create the request.
• Step 2: If a user wants to know the status of his/her device request, use GetRequest action to retrieve information from the SharePoint list. Before retrieving the request, you need to ask for the Request identifier. Confirm success with “This is the information I found”.

No need to create any custom topic with trigger phrases, question nodes and messages!

In order to create the actions to make a new request o get the status of an existing one, we have two different options:

• Use a Prebuilt connector action: We can use the SharePoint list create item or get item connector actions, specifying parameters like SharePoint site or list name.
• Use a Power Automate cloud flow, where we have control on all the steps of the flow (and what we used in the classic orchestration agent).

The agent we created is using prebuilt connector actions. In order to create a new request, we need to choose the SharePoint create item action:

We need also to configure the action end user authentication: In this case we are using the current user identity, but then we need to be sure that he or she has permissions to create items into the SharePoint list.

You can read more about end user authentication for actions in this article in our blog.

In the inputs section we specify the SharePoint site URL, SharePoint list and the fields needed to create a new item in the list:

Some of the parameters have a fixed value (like the SharePoint list), while some others are dynamically filled with the best option (according to the conversation context and information given by the user during the conversation).

Finally, we can also select which fields we may use in the output (specific or all):

Those fields can be used by a generated response, or we can also define the message that should be sent after the item is created in the SharePoint list:

Finally, we need to configure another action to get the status of a request, which is based on the SharePoint get item action, and it would follow a similar configuration process.

We found a bug while editing the actions: The first time we create the action, all SharePoint list columns are configured as output parameters. Although we removed the ones that we do not need, as soon as we edit the action, all columns are shown again as output parameters.

FF Device Agent in action

Let’s check what are the differences in the behaviour of classic and generative orchestration agents when requesting a new device. Using classic orchestration, a topic is going to be triggered, and the conversation will be guided by the actions configured within the topic:

It is a really simple topic that gets all information needed and creates the item using a Power Automate cloud flow.

On the other hand, if we use the agent with generative orchestration, we can see some other behaviour:

In this case, the agent is doing the same that the one with classic orchestration. But what happens if the query written by the user is different, and he or she is already writing all the information in a single interaction?

The agent is executing the right action, without the need to ask any other question and parsing the sentence to extract the entities (device type, name, price and comments). Another variation of the conversation is shown in this screenshot:

Therefore, the agent is smart enough to detect which fields are missing before calling the action and is asking the user the proper questions to get those.

In the SharePoint list we have a choice column called Device Type, which has two possible values: Laptop and Phone. Unfortunately, we haven’t been able to use this data type in the New Request plugin action, as it is probably not supported yet.

Conclusions

In this article we showed how we can design the same agent using different approaches: using classic orchestration and generative orchestration. In this table we summarized pros and cons of both approaches:

Classic orchestration is ideal for scenarios where reliability and predictability are paramount, as it ensures that the agent follows a well-defined path to handle user interactions. Due to its structured nature, classic orchestration is highly reliable for straightforward and repetitive tasks. It follows a set path, reducing the likelihood of unexpected outcomes. On the other hand, it may struggle to adapt to dynamic and complex scenarios. It is less capable of handling unexpected queries or situations that fall outside predefined rules.

Generative orchestration leverages advanced AI models to dynamically generate workflows based on real-time data and context. This allows the agent to handle more intricate and varied tasks, adapting to the user’s needs on the fly. Unlike classic orchestration, generative orchestration does not require extensive predefined rules and workflow, and then this reduces the need for constant updates and maintenance. However, implementing generative orchestration can be more complex, requiring a deeper understanding of AI models and natural language processing, as the dynamic nature of generative orchestration can introduce unpredictability in responses.