The Orchestrator pattern is a common project structure approach when it comes to a productive virtual agent in Cognigy.AI. The reason for this is very simple:

A clear project structure must be provided in order to find errors as quickly as possible and, if possible, to incorporate new features separately. Because if this order is not maintained, the Cognigy developer quickly loses the overview and the associated control.

How it works

In general, the Cognig.AI wizard creates the basis of the pattern automatically when one uses the guided way of creating a new virtual agent. Such as shown in the figure below, the Main flow plays the role of an orchestrator, admin, or concierge. All incoming user messages, it doesn't matter from which channel they are arriving, are handled by the Main flow.

The flow now decides what to do with this incoming message and forwards it to one of the included use cases. These use cases are reflected by flows as well. In this example, there is a flow for ordering pizza and getting support. These in turn can also contain several sub-flows to handle the user request.

Decide what to do

Talking about making a decision inside the Orchestrator pattern means to use the Lookup node in order to check the triggered intent:

Based on the found intent, the conversation can be forwarded to an expert flow. This expert could be the Support flow that is shown in the first figure. There are two different ways to solve this challenge:

1. Use the Execute Flow node to call a specific flow one time. This could be used if the executed flow works like a function and only has one task -- for example creating a support ticket.
2. Use the Go To node and totally switch the conversation to the expert flow. Now, all incoming messages are handled by the expert flow and not from the Main flow anymore. This is recommended when the entire use case changes.

Providing a global naming convention

In order not to lose the control and overview of an ever-growing project, a global naming convention should be introduced in addition to the flow structure. Accordingly, the flows of a certain use case could have the following names:

• 0 Main
• 1 Support
• 11 Create Ticket
• 12 Handover to Agent

... and so on ...