With the rapid development of Machine Learning and Natural Language Processing technologies, conversational AI has attracted huge attention in recent years. More and more conversational AI applications such as virtual assistants, smart speakers, and customer support chatbots have been developed to help people in their daily lives.

At Airbnb, we have developed multiple conversational AI products to enhance our host and guest experience. Examples include our chatbot systems, which support users through in-app messaging or automated phone calls, our task-oriented ML framework for issue detection and automatic problem solving, and various on-trip support products to proactively help guests improve their experience while they are on trip.

In this blog post, we introduce the Intelligent Automation Platform (AP), a generic enterprise-level platform developed by Airbnb to support a suite of conversational AI products. From this point forward, the Intelligent Automation Platform will be referenced as “AP”.

By modeling Conversational AI products as Markov Decision Process (MDP) workflows, AP provides a unified representation of workflows and actions to facilitate workflow consolidation and action reusability. Additionally, the platform offers a GUI development tool to enable drag-and-drop workflow creation, facilitate fast iteration of products, and empower non-technical teams to build conversational AI products.

1. Platform Architecture

Figure 1 shows the high-level architecture of AP, which consists of 4 main components:

1. Event Orchestrator, the event orchestration layer of the platform. It translates input/output messages between clients and Workflow Engine, to ensure that workflows on AP can be built and executed in a generic way.
2. Workflow Engine, the “brain” of the platform. It is responsible for managing and executing all the workflows powered by the platform.
3. Action Store, the action execution engine of the platform. It supports action requests during workflow execution. Action Store is an open platform for developers to create new actions or reuse existing ones. By using actions in the Action Store, we standardize task execution based on different systems and backends, and ensure consistent user experience across different products.
4. Flow Builder, the workflow creation GUI tool of the platform. It’s a collaborative, drag-and-drop interface that simplifies creation and management of workflows. The output of Flow Builder are workflows that can be loaded and executed by Workflow Engine.

Figure 2 shows an example of a demo “Q & A” workflow on AP. The demo workflow, configured via Flow Builder, can answer users’ questions from different channels (such as messaging or phone).

When the platform receives a request for the “Q & A” workflow, it triggers:

1. Event Orchestrator to normalize the request and find the corresponding workflow session if it exists (a workflow session is a single instance of the workflow), and then forward the request to Workflow Engine.
2. Workflow Engine to restore the previous state of the workflow or create a new one from the start node (state), and then execute the workflow: a) Execute the actions defined for the current workflow state. b) Move the workflow to the next state based on the action results or other conditions. c) Pause the workflow and wait for the next input if needed.
3. Action Store to execute all the actions required by Workflow Engine.

2. Key Components of Intelligent Automation Platform

2.1 Event Orchestrator

One of the design principles of AP is to provide channel-agnostic problem solving capabilities (channels represent the source of requests, such as in-app chatbot or phone). Workflows and Actions are intended to be channel-agnostic, focusing on the core of the problem no matter which channel users choose to contact us via to resolve their issues.

Event Orchestrator is the event orchestration layer of AP. It normalizes the input and output of the platform to ensure that conversational workflows can be built and executed in a channel-agnostic way. Figure 3 provides the architecture of Event Orchestrator, which contains 3 layers: orchestration layer, context data layer, and workflow request layer.

The orchestration layer handles all the requests and responses. It currently supports 3 types of input:

1. Channel message. These are messages delivered from different channels, such as phone, email or in-app messaging.
2. Async events. These are async events (such as Kafka events) generated by different Airbnb internal systems, like cancellation events.
3. Internal service requests. Event Orchestrator also provides a few endpoints to handle workflow requests from other Airbnb internal services directly.

Context data layer stores all contextual information related to the platform requests. Before creating a workflow request to the Workflow Engine, context data layer: a) Identifies whether the request is about a new workflow session or an existing one, by looking up the session mapping tables. b) Restores critical contextual information for workflow execution by reading from session data tables.

Workflow request layer prepares the request to Workflow Engine for workflow execution and processes the response from Workflow Engine. It makes sure that platform requests from different sources are converted into the same Workflow Engine requests so that Workflow Engine can handle all workflows in a generic way.

2.2 Workflow Engine

Workflow Engine is the “brain” of AP, responsible for executing and monitoring all the workflows powered by the platform.

Figure 4 shows the overall architecture of Workflow Engine, which consists of 4 main components:

1. Session Manager. Session Manager manages the lifecycle of entire workflow execution. After receiving a workflow execution request, it will restore the previous state of the workflow (if a workflow is resumed) or create a new workflow from the start state (if a new workflow is created). When workflow needs to pause and wait for user response, Session Manager will store the current state and all workflow variables into the database, to be restored by the next request of the same session.
2. Schema Loader. Schema Loader loads the workflow schema generated by Flow Builder, the workflow creation UI tool of AP. A workflow schema is a JSON schema file automatically generated by Flow Builder (see more details in the Flow Builder section).
3. Workflow Executor. Workflow Executor executes the workflow based on the workflow schema, starting from the current state of the workflow. It processes the action defined in the current state by sending a request to the Action Store, handles the response, and saves the variables to the Variable Manager. After that, it moves the workflow to the next state according to the transition conditions and starts processing the next workflow state. The Workflow Executor will keep repeating the process until the workflow needs to be paused (and waiting for user response), or until it reaches the end of the workflow.
4. Variable Manager. Variables are the data supporting workflow execution. Variable Manager manages all the variables and is accessible by Workflow Executor to read and update variables during workflow execution.

2.3 Action Store

Action Store is the action execution engine of AP, supporting action execution requests from Workflow Engine. It is also an open platform for developers to create new actions or reuse existing ones. All actions in the Action Store are available on Flow Builder for creating workflows.

As shown in figure 5, all actions in the Action Store implement a common interface, so that they can be processed in the same way during action execution (by Workflow Engine) and workflow creation (by Flow Builder). An action can be as simple as fetching a user’s reservation data or as complicated as issue prediction, which might involve multiple machine learning models and feature generation pipelines.

Figure 6 shows the high level Architecture of Action Store, which contains 3 main components:

1. Action Executor. Action Executor supports action execution requests. When receiving a request, Action Executor will load the action implementation from Action Manager based on the action type and invoke the execution function defined in the implementation. Many actions rely on external services to finish the execution, and the Action Executor will be responsible for sending those external requests and processing the response.
2. ActionInfo Handler. ActionInfo Handler supports Flow Builder for workflow creation by serializing all the action information (e.g., metadata, payload, results, etc.) to Flow Builder to render the actions on the UI and support action configuration when creating workflows. More details are available in the Flow Builder section.
3. Action Manager. Action Manager registers and manages all the actions created in the Action Store. It provides action implementation to Action Executor and ActionInfo Handler based on the action type.

2.4 Flow Builder

Flow Builder is the workflow creation UI tool of AP, supporting drag-and-drop workflow creation. It integrates with Action Store to retrieve all action information and sends the generated workflow schema to Workflow Engine during workflow execution.

Figure 7 illustrates the UI of Flow Builder when configuring actions in workflow. On the left is the Action Panel, which lists all available actions in the Action Store and supports searching by action name or description. Workflow creators can drag and drop any actions in the workflow panel and then configure the action payload by clicking the action node.

Figure 8 shows the UI when configuring the workflow graph. Workflow creators can create transitions between workflow nodes (each node can be viewed as a step or state of the workflow) by creating links between nodes and configuring the transition conditions. After all the workflow nodes and links are configured, the workflow is ready to be tested and published.

Figure 9 is the high level architecture of Flow Builder. It contains two major components:

1. The frontend layer, which is built with a third-party library React-diagrams, supports the UI and all operations on the UI.
2. The backend layer, Workflow Management service, which is responsible for: a) Getting all action information from the Action Store and passing to the frontend layer. b) Generating workflow schema that can be executed by Workflow Engine from the configured workflow graph on the UI. c) Serving the workflow schema to Workflow Engine during workflow execution.

Figure 10 gives an example of an auto-generated workflow schema that can be executed by Workflow Engine.

3. Conclusion

In this post, we introduced our Intelligent Automation Platform, a generic and business friendly enterprise platform to support a suite of conversational AI products at Airbnb including chatbots for customers, on-trip support products, and agent automations. With Intelligent Automation Platform, we can simplify and speed up conversational AI product development, democratize AI technology to business teams, and scale up more and more intelligent solutions to improve the Airbnb customer experience.

Acknowledgements

Thanks to Danny Deng, Xirui Liu, Zixuan Yang, Xiang Lan, Keyao Yang, Changhui Liu, Wenbin Zhang, Hengyu Zhou, Stephanie Pang, Jack Chen, Bart Bu, Carter Appleton, Shahaf Abileah, Mariel Young, Shuo Zhang, Wei Ji, Jiayu Liu, Kevin Jungmeisteris, Pratik Shah, Xiaoyu Meng, Michael Zhou, Haoran Zhu, Jon Sandness and Conor D’Arcy for the product collaborations.

Thanks to Tina Su, Andy Yasutake, Joy Zhang, Raj Rajagopal, Navjot Sidhu, James Eby and Julian Warszawski’s leadership support for the Intelligent Automation Platform.