San Francisco / Berlin — October 29, 2025.

We’re excited to announce that Airy's leadership team is joining Confluent, the world’s leading data streaming platform founded by the creators of Apache Kafka.

From day one, our mission at Airy has been simple but ambitious: to provide the perfect context for AI models at inference by processing data continuously.

We’ve built Schema Intelligence and AI Copilots to translate natural language into Flink SQL — enabling teams and AI Agents to understand, reason about, and act on data in motion.

Joining Confluent marks the next chapter of that journey. Together, we’ll help accelerate the convergence of stream processing and AI, enabling organizations not only to process data continuously but also to make AI Agents context-aware and event-driven — understanding schemas and ontologies, considering data lineage and governance, and making stream processing in Flink much more accessible through natural language.

The future of data and AI is real-time, intelligent, and context-aware — and we can’t wait to help shape it within Confluent.

Confluent's Statement on upcoming AI Features: Data in Motion for AI in Action

In an era where businesses are inundated with a diverse array of data and increasingly reliant on AI, the challenge of effectively managing, analyzing, and extracting insights from structured, semi-structured, and unstructured data has never been greater.

This is where Airy comes in as an open-source app framework to empower developers and data engineering teams to build customizable co-pilot applications for their relevant organizations on their own data with Airy Co-pilot. Thereby, they enable business users and technical stakeholders alike to interact with streaming data in the most simple way: via natural language.

Technical Requirements and LLM Integration

The development of Airy Co-pilot is grounded in several essential technical components:

1. Developing a Frontend Application: Our objective is to craft a user-friendly frontend application under "frontend/co-pilot" that supports real-time data streaming, offering a robust and intuitive interface.
2. Vector Database and CI Integration: We're focused on ensuring a smooth interaction between the frontend, LLM and vector database endpoints, complemented by a reliable continuous integration pipeline.
3. LLM Integration for Enhanced Data Interaction: Integrating LLM technology is a strategic move to boost the application’s capabilities in data analysis and streaming, providing a more dynamic and responsive user experience.

The Solution: Airy Co-pilot

Key Features

• Conversational Data Interaction: The application features a conversational interface, allowing users to engage with data in a more natural and intuitive manner.
• Actionable Insights and Real-Time Data Access: Providing immediate access to data and insights, this feature is designed to support prompt and informed decision-making.
• Data Visualization: With data visualization capabilities, Airy Co-pilot transforms complex data sets into clear and comprehensible visuals, aiding in the interpretation and presentation of data insights.

Benefits for Companies

• Simplified Data Access and Streaming: Airy Co-pilot simplifies data access and streaming, notably with its translation capabilities from natural language into FlinkSQL and Kafka Streams powered applications, making it a valuable asset for businesses.
• Efficient Decision-Making: The application is crafted to streamline access to insights, facilitating efficient and effective decision-making processes.
• Increased Productivity: By easing data streaming and translation tasks, Airy Co-pilot is geared towards boosting productivity and saving valuable time and resources.
• Improved Data Literacy: The application aims to make data analysis more approachable and user-friendly, contributing to enhanced data literacy especially among business users, removing the need to rely on data engineers for simple stream processing tasks.

Conclusion

Airy Co-pilot is a thoughtful response to the complexities of data management and streaming. It's designed to offer businesses a reliable way to navigate their data efficiently. Our commitment is to its ongoing development, focusing on enabling teams to build streaming applications that genuinely enhance their interaction with data.

Apache Kafka is the most popular distributed event streaming platform mostly used for transforming and moving the data between different systems. We can find plenty of use cases for data pipelines, mission-critical event driven systems, data integrations and transformations, but not many platforms use Kafka as a single database. That is why we decided to share our decisions why we choose Kafka to be the single source of truth for Airy, as well as the experiences that we had along our journey.

Airy requirements & concepts

At the start it is fair that we first we exlain our platform requirements and development principles. Four years ago we were fortunate to start working on a completely new streaming platform, determined to transform conversational experiences. As we wanted to connect conversational, business and machine leraning systems in real-time, we had few requirements in place for our platform:

• It should be an event driven system
• There needs to be a microservice architecture & service independence
• The data should be in order and easily re-processable
• There should be a single data storage for all the event data
• We should be able to add business logic in the stream and in real-time
• The platform should be able to scale

Naturaly the choice for the core of the system came to Apache Kafka, as it fits all of these requirements. For adding the business logic in the stream we choose to rely on the Kafka Streams library for building our components. And as an infrastructure where everything should run we opted for Kubernetes as it is a perfect environment for deploying microservices, that are able to scale both horizontally and vertically, with lots of other enterprise-grade features that are independent of any cloud provider.

Single source of truth

As we needed data from different places at the beginning we were really determined to have a single source of truth and avoid having data in different places, not being able to read and process it in a standardized way. But what is all that data that we need to store in a platform like Airy? First is all the conversational data which means all the messages and events that are ingested from the verious conversational platforms such as Facebook, Google, Instagram, Twilio, SMS and so on. In order to design automations and enrich the conversations we need to also fetch data from various business systems, for example Zendesk, Salesforce, purchase data or other customer databases.
The same datastore should also hold configuration settings about the connectors and preferences for the users using the platform. It should be able to also store structured contact data about the contacts that are being ingested and aggregated over different channels.
Last but not least the same data store should hold all the logs and events that are generated by the applications, including metrics, monitoring data and telemetry.

One would legimitely ask: But is Kafka the appropriate data store for all that? We figured out: Yes! We should have all the data on top of which we want to build real-time business logic in Kafka. This way we are flexible with the variety of features and applications we can add on top, while using a standard way to access and process the data. In a way we are able to transparently treat all the data the same, regardless of where it comes from and what should it trigger.

Even though there is an option to combine Kafka with other relational and non-relational databases, that way we would have the same information in multiple places, would be hard to determine which is the source of truth and the unification of the development process would become harder. And to be honest Kafka Streams helped our decision because it is a great library to have stateless and stateful operations on top of the data in Kafka and in real-time.

So, to wrap it up, all data lives in Kafka. Everything goes into the stream and that is where every app reads from to built its own version of reality, a very important principle for having complete service independence. So the data can also be seen as a strongly typed (via Avro) data pipeline. Let's see now how this pipeline powers all the apps and services.

Microservice design & architecture

Airy is built of Kafka Streaming Apps called components. They can be of three types:

• Transformers - Consume data from topics, perform stateful and stateless transformations and write to other topics.
• Services - Consume data from topics, perform transformations, hold the state in internal topics and expose endpoints.
• Connectors - Ingest data from external systems into Kafka and send data from Kafka to external systems.

We choose to build our own Airy connectors and not build on top of kafka-connect because we had the need for:

• Sending and receiving data within the same connector (not to have separate sink and source connectors).
• Add business logic inside the connector and not simply get the data from one place to another.

For example, as illustrated on the image above, a message is injected into Kafka through a microservice in a connector. Afterwards another microservice in the same connector reads this data, transforms it and writes it into another topic. This event is a trigger for other components to do something with this data. Here the true power of Kafka comes into place, as we can have components with higher priority to which we dedicate more resources and also components with a lower priority, but who read the same data on best-efforts workloads.

Every microservice has its own topology which is a representation of the relations between the data that is read and the operations performed on this data. As mentioned above, these operations can be stateful operations such as joins and aggregations and the result from them is stored into internal topics. When the schema for the resulting topics needs to change or we need to change the topology, these Kafka Streaming Apps need to be reset and the data in these internal topics will be deleted. Then the microservice starts to re-process the data again, from beginning, latest or from a specific offset.

One important aspect of our HTTP endpoints of services is that they are built on top of a very useful feature of Kafka Streams called interactive queries. As the stateful operation on multiple topics is performed and the state is stored into internal topics, interactive queries allow this structured data to be exposed to the outside world.

Learnings

Of course everything looks great on the design whiteboard, but unfortunateyl real-time and scalable event-driven platforms don't run on whiteboards.

Here are some of the obstacles that we had along our journey and some of the learnings that we made.

Learning 1: Endpoint performance

The services behind the endpoints need to be fast. As explained before, this data is loaded from the internal topics and that can take time for larger data sets. Fortunately the Interactive queries support local and remote state stores, which means that a local state is kept on the workload in a form a cached version of the data created by the particular topology. To increase the performance, which is particularly important when the microservices start, it is useful to have these workloads as StatefulSets in Kubernetes, provisioning a stateful volume where there is a cached version of the data from the internal topics. As Kafka Streams uses a default RocksDB as a default storage to maintain local state, having this storage persistent will help with improving the endpoint performance.

Learning 2: Changing the schema

The schema holds the structure of the data and when working with Kafka it can be stored in a separate service called the Schema Registry. Changing the schema of the data is inevitable over time. But as the data with the specific schema is already in the internal topics of the Kafka Streams Apps and in the RocksDB cache, thich can be a painful process. If we want to change the schema of a microservice, usually the procedure to do this is:

• Scale down the StatefulSets
• Reset the kafka-streaming-app
• Delete the persistent storage
• Scale up the workloads
• Wait for the reprocessing

But going through this approach will mean that there would be a downtime. And depending on the amount of the data and the time it takes to reprocess it it can be quite significant. To mitigate the downtime we can leverage the service or loadBalancer feature of Kubernetes and deploy a new app that can introduce the new schema while the first app is still working.

The new microservice however needs to have a different name for the consumer group in Kafka because that is how Kafka distinguishes different consumers.

Even through now there is no preasure with reprocessing the data for App v11 as App v10 is still running, there might be a case where we need to fix a bug in the existing app. In this case, it is important that the second app consumes all the needed topics and becomes ready to serve the clients faster. We can achieve this if we use workloads with more CPU and memory only during the period while the data is reprocessed and the Kafka Streams App gets in a RUNNING state. One way to achieve this if creating very powerful compute nodes in the cloud (we call them boost-k8s-nodes) on the fly and joining them to the Kubernetes cluster. Then we need to set more resources and label the App v11 workloads so that they get scheduled on the new nodes. Once the reprocessing of the messages is done, we can scale down the resources for the new app and deploy them of regulat nodes. Important not to forget ot destroy the boost-k8s-nodes because they can lead to large costs.

Learning 3: Unbalanced partitions

One more thing that we learned is that it is important to choose the correct keys for the data in Kafka. Since one Kafka broker is responsible for a particular topic-partition, having some keys that receive lots of data will lead to unbalanced partitions and unbalanced load distribution.
For example, if we key messages with organization_id and have some organizations that receive the majority of the data - this can cause performance problems on the broker side. As data for the same key will be written to the same topic-partition, some brokers will need to work very hard when writing and reading the data (for these organizations) and some will be idle. The microservices that need to consume a topic will also be blocked as they consume a topic from different partitions and the response time of the Kafka brokers under load will impact the overall responsiveness of the system.

Learning 4: Webhook events

Our platform uses a webhook component to send events to external systems. As we cannot assume that these systems will be idempotent, these events must be sent only once. However, as the webhook events are read from topics inside Kafka, when there is an outage or during broker upgrades, information about the current offset of these topics can be lost. Even though the webhook component consumes from the latest messages in a topic, if there is an inconsistency in the offsets it can happen that a message is sent multiple times.
This problem can be particularly hard to debug and investigate as we would like to offload the responsibility to Kafka to keep the correct offset for every topic. What we can do to mitigate this problem and avoid such inconveniences, like triggering a CRM system with the same event multiple times, we can add some application logic to the webhook deployment and double-check that a certain event should be sent on the side of the webhook component.

Learning 5: Starting up all at once

Kafka Streams Apps require lots of CPU at startup. At first they go in a REBALANCING state to check the consistency of the data, either in the RocksDB cache or in the internal topics. Once the data is there and broker assignments are completed for looking for new data, these apps go into a RUNNING state and then the CPU usage reduces. At the same time there is a spike of the CPU usage in Kafka as the Kafka brokers need to respond to all of these requests from the apps getting ready to start. If we have hard limits on the total resources that the workloads can consume, when everything starts at once (for example during upgrades or when a pool of Kubernetes nodes die) we can have a problem that the workloads don’t get the needed CPU to get into a RUNNING state.

One way we managed to mitigate this behavior is using init containers in the Kubernetes workloads to look for conditions whether an app can start at all (for example if Kafka is still not ready). We can configure our CD pipeline not to upgrade all the components at the same time, but this will not affect the behavior when some nodes in Kubernetes get replaced and Kubernetes schedules all workloads on another node. In this case, creating (and testing) an auto-scaling configuration for the particular group of Kubernetes resources will be helpful as the workloads can get more resources when they need.

Learning 6: Backup

All the data is in one place, right? So in that sense - backup is easy. As long as we have a backup of Kafka - we are good. Unfortunately it is not so simple.

Let’s assume the most straightforward scenario where we have the data in Kafka in persistent volumes (for example EBS volumes in AWS). We need to make periodical snapshots of these volumes and that is the easy part. But restore is not so easy. If we need to restore the data to a certain point in time we need to: 1) Stop all the Brokers, 2) Restore all of the snapshots from the same backup cycle, 3) Start all the brokers at once, 4) Wait for them to rebalance and get in a running state.

This will restore all the data in Kafka to a certain point in time. But what if we want to restore only part of the data or only one topic? Then this solution doesn’t work anymore. If this is needed it would be best to make use of kafka-connect and stream all the topics independently to external storage. One example is the s3 sink connector that will write all the data in real-time to an S3 bucket. Note that not all connectors support the same ordering of the data, so if this is important you may want to choose a connector that can guarantee that.

Learning 7: Tools

Tooling is very important for maintaining every platform and Airy is not an exception. But as all of the data is in Kafka we need tools that can interact with Kafka and help us with:

• Checking the state of the broker
• Looking into the data in the topics
• Searching for a particular key/value in a topics
• Looking into the state of the consumer groups and check the lag
• Check the status of Kafka connect
• View the schema for a particular topic
• See the rate at which data is written/read to/from Kafka

As a complete turn-key solution - Confluent cloud is very useful for getting a clear insight of the data in Kafka. Clusters can be created and destroyed easily with Terraform, as well as topics, access lists and service accounts. This works however only if you have the Kafka clusters in Confluent.

If you choose to run and manage your own Kafka then the first tool that everyone should have is AKHQ. It can be deployed easily with Helm in Kubernetes, needs access to the Kafka cluster and can offer great insight in the state of the data and the platform.

Apart from these great UIs there, kcat is a great CLI that can be used to interact with Kafka.

The Positive Leranings

Even though it was a bumpy ride and the learning curve is a bit steep, using Kafka as a single source of truth proved to be a great choice for our platform. We achieved an unified development process with great flexibility, speed and agility. All the data is in one place, so it is easy to govern, segment and use.

When the data is in Kafka one cannot just go there and change or delete a record in the database. It is a streaming platform and this forces you to solve data issues programmatically, not allowing shortcuts such as editing the database to fix a data problem. For example, when there is a Null Point Exception a new version of the microservice needs to be created solving the issue.

Another positive learning is that Kafka Streams actually solves lots of issues for distributed processing. Scaling consumers and producers is very convenient and Kafka distributes the workload automatically. When a consumer or a producer dies, all the information is stored in Kafka so they can just restart and continue where they left off. And Interactive queries are a great way to expose structured data in Kafka via HTTP.

Kubernetes has proven very convenient for running Kafka under low and moderate load, even though for higher Kafka loads we would recommend running a dedicated instance for every Kafka broker.

So making the stream the single source of truth is something that we can recommend. Most importantly all data can be accessed and processed in the same way and in real time, which is very important for building a robust event-driven platform.

Data Retention

When using Kafka as a central dataase the data retention question becomes important as usually we don't want to delete events from our single source of truth. But keeping all the data can lead to high disk usage and large volumes, so we need to decide which data is important to keep and which is not.

Fortunately Kafka has a great feature for this called data compaction. We can actually decide that we keep at least the latest value for an unique key that gets written to a topic, instead of deleting it.

Here is a snippet of our scripts for creating the topics:

kafka-topics.sh --create --if-not-exists "${CONNECTION_OPTS[@]}" --replication-factor "${REPLICAS}" --partitions "${PARTITIONS}" --topic "${AIRY_CORE_NAMESPACE}application.communication.contacts" --config cleanup.policy=compact  min.compaction.lag.ms=86400000 segment.bytes=10485760

kafka-topics.sh --create --if-not-exists "${CONNECTION_OPTS[@]}" --replication-factor "${REPLICAS}" --partitions "${PARTITIONS}" --topic "${AIRY_CORE_NAMESPACE}application.communication.messages" --config cleanup.policy=compact min.compaction.lag.ms=86400000 segment.bytes=10485760

kafka-topics.sh --create --if-not-exists "${CONNECTION_OPTS[@]}" --replication-factor "${REPLICAS}" --partitions "${PARTITIONS}" --topic "${AIRY_CORE_NAMESPACE}application.communication.metadata" --config cleanup.policy=compact min.compaction.lag.ms=86400000 segment.bytes=10485760

When it comes down to compaction it is important that all the conditions are created so that compaction kicks in. The data stored in the topic-partitions is stored in segments that are individual files written to the disk. The last segment is the one that Kafka writes to in real-time so compaction is done only from the messages in the previous segments. Having that in mind it is important that we configure the size of the segment in accordance to the amount of messages that that topic is receiving. Because if there is only one large segment - none of the messages will actually be compacted and will still be kept on disk.

It is important to say that campacting the messages removes historical data so we need to be sure that we are good with that. For example we have messages that we key with a messageId. If we compact that topic, then we for sure keep the value or the content of the last message, but historical information about previous versions of the message will be lost.

References

[1] Airy Core Open source repository - https://github.com/airyhq/airy/
[2] Airy design principles - https://airy.co/docs/core/concepts/design-principles
[3] Apache Kafka - https://kafka.apache.org/
[4] Kafka Streams - https://kafka.apache.org/documentation/streams/
[5] Confluent Cloud - https://www.confluent.io/confluent-cloud/
[6] AKHQ - https://akhq.io/
[7] Backup of EBS volumes on AWS - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html

Airy is an open-source data streaming platform offering an integrated solution to automate & personalize customer communication. Developers can build scalable, world-class customer experiences by integrating data from different sources in real-time.

Confluent is a full-scale data streaming platform that enables developers to easily access, store and manage data as continuous, real-time streams. Built by the original creators of Apache Kafka, Confluent expands the benefits of Kafka with enterprise-grade features while removing the burden of Kafka management and monitoring.

Airy and Apache Kafka

Airy's open-source data streaming platform is powered by Apache Kafka, the open-source event streaming standard.

By default, you get a small Kafka deployment when installing Airy on your Kubernetes cluster. While this is a great way to get started and play around, we recommend our enterprise offerings and a hosted Kafka service such as Confluent Cloud for production workloads.

Confluent is the primary maintainer of Kafka and, as such, provides a very mature cloud offering. In this guide, I will show you how to set up your Confluent Kafka cluster and connect it to Airy.

Prerequisites:

• A Confluent Cloud account - Signup here

Follow the next steps to set up Airy with Confluent:

1. Create a Kafka cluster on Confluent
2. Obtain connection configuration
3. Configure Airy to use Confluent
4. Check that everything works 🎉

Step 1: Create a Kafka cluster

Assuming that you already have a Confluent account (signup here), we move on to creating the Kafka cluster by following these instructions. At the time of writing, Confluent provides a free trial that will give you plenty of time and room to explore this setup.

Once you are done, your environments page will show the default view with one cluster running:

Step 2: Obtain connection configuration

To connect Airy to a Confluent Kafka cluster, we need to obtain two parameters: the address of the cluster and the authentication string. Airy supports Confluent's authentication method, which is SASL/PLAIN. You can read more about Confluent's authentication process here.

To obtain these values, click on your cluster in the Confluent dashboard and then select the Java connection option:

This will present you with the screen below. Click "Create Kafka cluster API key" to generate the parameters we need.

Copy/save the address from bootstrap.servers and the SASL configuration line from sasl.jaas.config (starting at "org.apache" up to and including the semicolon), lines 2 and 4 .

Step 3: Configure Airy to use Confluent

Now that we have these values, we can connect your Confluent Kafka cluster to Airy. If you are installing a new Airy instance, follow path A, and if you already have a running Airy instance, follow path B.

A. Confluent on a new Airy Instance via Helm

Follow this guide to set up your Helm installation. By default, Airy ships with its own Kafka cluster. To use your Confluent Kafka cluster from the get-go, you need to include this configuration in your airy.yaml file before running the helm install command.

config:
  kafka:
    brokers: "bootstrap.server address from Step 2"
    authJaas: "sasl.jaas.config line from Step 2"
    minimumReplicas: 3
    zookeepers: ""
    schemaRegistryUrl: http://schema-registry:8081

Now you can run these commands to install your cluster:

$ helm repo update
$ helm install airy airy/airy --timeout 15m --values ./airy.yaml

B. Confluent on an existing Airy Instance via the CLI

Note: This guide does not cover migrating existing data to a different Kafka cluster.

To connect a Confluent Kafka cluster to a running Airy Instance, include this configuration in your airy.yaml file.

kafka:
  brokers: "bootstrap.server address from Step 2"
  authJaas: "sasl.jaas.config line from Step 2"
  minimumReplicas: 3
  schemaRegistryUrl: http://schema-registry:8081

Now run airy config apply in your workspace directory to propagate these configs to our streaming apps. The difference to the helm approach is that this does not automatically create the required Kafka topics for us. So our apps will temporarily be in a crashing state until we fix this by re-running the initial topics provisioning job:

$ kubectl get job "provisioning-topics" -o json | jq 'del(.spec.selector)' | jq 'del(.spec.template.metadata.labels)' | kubectl replace --force -f -

For more details about connecting to a remote Kafka cluster and connecting your own schema registry, you can check out our documentation here.

Step 4: Check that everything works

After completing either 3A or 3B, we have to wait for a few minutes for our streaming applications to start back up. Once this is done and all Kubernetes pods are stable, you should see Airy apps in the "Data Integration > Clients" view of your Confluent dashboard:

Finally, you should open up your Airy control center or inbox to ensure everything is working as expected.

Where to go from here

If you are struggling to complete this guide or want to share your journey, please join our developer slack! We'd love to meet you 🥳

And if you're interested in implementing this solution in production and at scale, we'd be happy to help!

With conversational use cases on the rise and Conversational AI becoming more and more relevant,  the need for an open-source Conversational AI platform is clear.

But what is part of such a conversational platform? How do you set it up, host it and run it? How do you connect it to your Conversational AI?

This post will outline how to create a working conversational platform in the cloud, using open source tools running on Kubernetes.

The building blocks of our conversational stack will be:

• Kubernetes - The system which will hold all of the created resources.
• Apache Kafka - Message streaming & queuing framework, as a base for Airy.
• Airy - Our open source conversational platform, responsible for transporting messages, streaming them from and to the different conversational channels.
• Rasa - Open source conversational AI, responsible for analyzing the message content and creating an automated response message.
• A conversational channel: Airy's open source Live Chat plugin - An example conversational channel which is connected to the Airy platform and a live chat plugin that can be embedded into any webpage to chat with website visitors.

By the end of the tutorial you will have a Kubernetes cluster with two namespaces, one each for Airy and Rasa. You will also have a chat plugin as a source for Airy, where people can write you messages and then get customized automated replies. The chat plugin can be tested on its own, but can also be added directly to your website. In the What is next? section, you will be presented with other options to further expand your conversational platform.

Let's first go over some questions on the architectural choices of your conversational platform:

Why do we need a streaming platform?
Fetching messages and conversations from a conversational channel, or source as we call it, can be accomplished in various ways. However, if we want to be able to connect multiple sources, scale the platform in the future as the volume of messages increases, and process the messages in real-time and in a specific order - a streaming platform such as Kafka is the best choice.
This way, we leverage the capabilities of a modern streaming platform to simplify the design and the message processing of our microservices. Instead of them talking to each other, they will communicate exclusively through Kafka.

Why Kubernetes?
All the apps and components we use as building blocks of our conversational stack can be started without Kubernetes. However, using a modern orchestration system, such as Kubernetes, that takes care of scheduling, monitoring and load balancing the services, has huge advantages. Kubernetes eases the challenges of running in production, continuous upgrades, deployments in different availability zones for high-availability, and scaling. An additional important advantage is that it can easily be migrated between different cloud providers.

Airy & Rasa: Why two separate systems and how do they work together?
Both systems do a perfect job in their primary functionality: Rasa the open source conversational AI and Airy as the open source conversational platform. Airy can handle multiple different sources and heavy message loads, while Rasa can be optimized and trained to provide the best possible automated reply, regardless of where the message comes from.

Let's get started!

1. Create a Kubernetes cluster

To begin, you should choose your cloud provider. Airy and Rasa both run on Kubernetes, so it doesn't make any difference which provider you choose in terms of functionality. The only thing you need is to set up a Kubernetes cluster in your provider and gain access to it. We recommend to choose a fully managed Kubernetes cluster offered by one of the major cloud providers, but of course you are also welcome to manage it on your own or use an existing Kubernetes cluster.

Before you proceed, make sure that you have the Helm and Kubectl binaries installed on your local machine.

If you already have a deployed Kubernetes cluster, you can proceed to the next section.

We have prepared brief instructions on how to create a new Kubernetes cluster in different cloud environments:

• Google Cloud Platform
• Microsoft Azure
• DigitalOcean
• Amazon Web Services

1.1. Create a Kubernetes cluster in GCP

To create a Kubernetes cluster in Google Cloud, you can use either the Google Cloud Dashboard or the gcloud command line tool, which is part of the Google SDK.

If you prefer the Google Cloud Dashboard, click on Kubernetes engine -> Clusters -> Create.

If you prefer the command line option, you should first install the Google Cloud SDK and set up your Google Cloud account for a GCP project. Then run the following command to create a Kubernetes cluster:

gcloud container clusters create airy-rasa-conversational-platform --num-nodes=2 --machine-type=e2-standard-4

After a few minutes, the details of the created Kubernetes cluster will be printed on the command line:

The command will also update your kubeconfig file.

For more information, refer to the official Google Guide.

Then you can proceed to the next section.

1.2. Create a Kubernetes cluster in Azure

For creating a Kubernetes cluster on Microsoft Azure, you can use the Microsoft Azure Portal, the Azure PowerShell utility or the Azure CLI.

The simplest way to create the cluster is using the Microsoft Azure Portal. Navigate to the Kubernetes services dashboard and click on Create -> Create a Kubernetes cluster.

On the following screen make sure that you:

• Select the default resource group or create a new one.
• Fill in the name of the cluster (ex. airy-rasa-conversational-platform).
• Select the number of nodes.

After the cluster is created, you can use the az Azure CLI to setup access to the cluster:

az login
az aks list
az aks get-credentials --resource-group DefaultResourceGroup-EUS --name airy-rasa-conversational-platform

The last command will update your kubeconfig file with the proper credentials.

For more information refer to the official Microsoft Guide.

Then you can proceed to the next section.

1.3. Create a Kubernetes cluster in DigitalOcean

A Kubernetes cluster can be created directly on the DigitalOcean dashboard by clicking Create -> Kubernetes. You can leave all the options default, except for the Node plan as the default nodes might be too small for running the Airy Core platform.

After you create the cluster you need to go through a short guided cluster setup.

After you complete the setup you can Download Config File to save the kubeconfig file to your machine (./kube.conf). With the kubeconfig file you can now access the kubernetes cluster.

kubectl --kubeconfig ./kube.conf get pods

For more information refer to the official DigitalOcean Guide

Then you can proceed to the next section.

1.4. Create a Kubernetes cluster in AWS

A Kubernetes cluster can be created on AWS using the AWS Console or the AWS CLI.

For creating a cluster you first need an AWS IAM Role and a VPC. Export your profile and your region:

export AWS_PROFILE=my-aws-profile
export AWS_REGION=my-aws-region

Create a new AWS IAM Role and attach the appropriate policies:

export POLICY='{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"Service": "eks.amazonaws.com"},"Action": "sts:AssumeRole"}]}'

aws iam create-role --role-name airy-rasa --assume-role-policy-document "$POLICY"

aws iam attach-role-policy --role-name airy-rasa --policy-arn \
  "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"

aws iam attach-role-policy --role-name airy-rasa --policy-arn \
  "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"

aws iam attach-role-policy --role-name airy-rasa --policy-arn \
  "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"

aws iam attach-role-policy --role-name airy-rasa --policy-arn \
  "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"

ROLE_ARN=$(aws iam get-role --role-name airy-rasa --query 'Role.Arn' --output text)

Get the default VPC and the public subnets:

VPC_ID=$(aws ec2 describe-vpcs --filters Name=is-default,Values=true --query 'Vpcs[0].VpcId' --output text)

SUBNETS=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=${VPC_ID} \
  --query 'Subnets[?MapPublicIpOnLaunch==`true`].SubnetId' --output text | sed 's/\t/,/g')

You can modify the list of subnets according to your needs, but you must have at least two subnets with the property MapPublicIpOnLaunch set to true.

Then create the Kubernetes cluster with the following command:

aws eks create-cluster --name airy-rasa-conversational-platform --role-arn ${ROLE_ARN} --resources-vpc-config subnetIds=${SUBNETS}

To update your kubeconfig file run:

aws eks update-kubeconfig --name airy-rasa-conversational-platform --alias airy-rasa-conversational-platform

For more information refer to the official AWS Guide.

Then you can proceed to the next section.

2. Deploy Airy

Airy is an open-source, fully-featured, production-ready conversational platform. Airy comes with all the components you need for all conversational use cases, from connectors to different conversational channels and sources, APIs to access your data and UIs from dashboards to an inbox.

To deploy Airy to the created Kubernetes cluster, we will use the Helm installation method.

Deploy Airy with the latest version. You can also configure a specific version.

VERSION=$(curl -L -s https://airy-core-binaries.s3.amazonaws.com/stable.txt)

If you are not using the default KUBECONFIG file (~/.kube/config) make sure you export the correct one before proceeding (in this case ./kube.conf):

export KUBECONFIG=./kube.conf

Install the Airy helm chart:

helm install airy https://helm.airy.co/charts/airy-${VERSION}.tgz --timeout 10m

Once the helm chart installs, you can confirm that all the pods are running correctly with the kubectl get pods command.

By default, Airy only creates a HTTP listener. When you run Airy in a cloud environment outside of just testing it for the purpose of this guide, it is highly recommended to set up HTTPS for your instance. Refer to the next steps section for more information.

Get the IP address of your loadBalancer:

kubectl -n kube-system get service  ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].*}{"\n"}'

After you have created your Airy instance, you can access the web UI through: http://{the-loadbalancer-ip-address}.

3. Set up the Chat plugin

Next, we will create and test one conversational source.

To create a Chat plugin source, navigate to Channels and click the + button. We will call the source Letstalk.

4. Deploy Rasa

Rasa is an open source machine learning framework for automated text and voice-based conversations.

We will install Rasa open source in a separate namespace, so that there is a clear distinction between the resources created by the two platforms.

To run Rasa alongside Airy we need a specific configuration and an Airy python connector which we will load in Rasa to receive the messages from Airy and send them back to the conversational platform.

Before we run the Rasa deployment we will create some configuration in ConfigMaps, so that we can easily change them on the fly later, without needing to build a specific Rasa image.

Create the rasa namespace.

mkdir rasa
cat <<EOF > rasa/rasa.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: rasa
EOF
kubectl apply -f rasa/rasa.yaml

Now we will checkout the demo repo to load the Airy module and create the proper configuration:

git clone https://github.com/airyhq/rasa-x-demo.git rasa/rasa

kubectl -n rasa create configmap actions --from-file=rasa/rasa/actions/

kubectl -n rasa create configmap channels --from-file=rasa/rasa/channels/

kubectl -n rasa create configmap data --from-file=rasa/rasa/data/

kubectl -n rasa create configmap config --from-file=rasa/rasa/domain.yml --from-file=rasa/rasa/config.yml

We need to tell Rasa where to reply to the messages, therefore we will create a ConfigMap where we will put the Airy endpoint for receiving messages (the replies coming from Rasa to the end customer).

cat <<EOF > rasa/credentials.yml
channels.airy.AiryInput:
  api_host: "http://ingress-nginx-controller.kube-system"
  system_token: "demo"
EOF

kubectl -n rasa create configmap airy-config --from-file=rasa/credentials.yml

We will amend the rasa/rasa.yaml file with the deployment and the service.

cat <<EOF >> rasa/rasa.yaml
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: rasa
  name: rasa
  namespace: rasa
spec:
  serviceName: rasa
  replicas: 1
  selector:
    matchLabels:
      app: rasa
  template:
    metadata:
      labels:
        app: rasa
    spec:
      initContainers:
      - name: rasa-training
        image: rasa/rasa:2.6.3-full
        args:
          - train
        securityContext:
          runAsUser: 0
        volumeMounts:
        - mountPath: /app/data
          name: data
        - mountPath: /app/domain.yml
          name: config
          subPath: domain.yml
        - mountPath: /app/config.yml
          name: config
          subPath: config.yml
        - mountPath: /app/models
          name: models
      containers:
      - env:
        image: rasa/rasa:2.6.3-full
        args:
          - run
          - --enable-api
          - -vv
        securityContext:
          runAsUser: 0
        imagePullPolicy: Always
        name: rasa
        volumeMounts:
        - mountPath: /app/actions
          name: actions
        - mountPath: /app/channels
          name: channels
        - mountPath: /app/data
          name: data
        - mountPath: /app/domain.yml
          name: config
          subPath: domain.yml
        - mountPath: /app/config.yml
          name: config
          subPath: config.yml
        - mountPath: /app/credentials.yml
          name: airy-config
          subPath: credentials.yml
        - mountPath: /app/models
          name: models
      volumes:
      - configMap:
          name: actions
        name: actions
      - configMap:
          name: channels
        name: channels
      - configMap:
          name: config
        name: config
      - configMap:
          name: data
        name: data
      - configMap:
          name: airy-config
        name: airy-config
  volumeClaimTemplates:
  - metadata:
      name: models
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: rasa
  namespace: rasa
spec:
  ports:
  - name: web
    port: 80
    protocol: TCP
    targetPort: 5005
  selector:
    app: rasa
  type: ClusterIP
EOF

Create those resources in your Kubernetes cluster:

kubectl apply -f rasa/rasa.yaml

We are using the a generic rasa docker image, however we have some pre-defined data which we are using for training. The training of the Rasa automatic replies bot is done with an initContainer. We are training the bot to answer a simple scenario where the user would:

• Send a greeting (Hi / Hello)
• Inquire about the working hours (What times are you open?)
• Send a goodbye (Bye / Goodbye)

To configure multiple scenarios and rules, you can edit the data configmap and the domain.yml file in the config configMap.

kubectl -n rasa edit configmap data

kubectl -n rasa edit configmap config

After changing the configuration, the rasa pod needs to be restarted which will trigger a new training.

kubectl -n rasa delete pod -l app=rasa

We are using a StatefulSet workload for Rasa to keep the training data persistent. To see the logs from the training pod run:

kubectl -n rasa logs rasa-0 -c rasa-training

To watch for logs from the Rasa main process run:

kubectl -n rasa logs rasa-0 -f

For a better understanding of how Rasa works, refer to the official documentation.

5. Integrate Airy and Rasa

At this moment both Airy and Rasa should be installed and running. The Rasa platform is aware what messages to expect through the airy channel and knows where to respond to the relevant messages. Next, we need to tell the Airy platform where relay messages to as they come in.

We will use the integration/webhook component of Airy to send the messages to Rasa.

Let's create a configMap to start the integration/webhook component

kubectl create configmap integration-webhook --from-literal=name=webhook --from-literal=maxBackoff=10

The airy-controller watches for componentType-componentName configMaps and will then start the appropriate component. In this case, the webhook pods will start in the Kubernetes cluster. A confirmation that the pods are running can be made with the following command:

kubectl get pods -l 'app in (webhook-publisher,webhook-consumer)'

Now we instruct the webhook component where to send the messages when they come in:

curl -X POST -H 'Content-Type: application/json' http://{the-loadbalancer-ip-address}/webhooks.subscribe --data '{"url":"http://rasa.rasa/webhooks/airy/webhook"}'

Note that Airy and Rasa talk through the internal Kubernetes services, as they are running in the same Kubernetes cluster.

6. Test everything

To test that everything is working properly, we will simulate writing messages to the chat plugin source as if they come from actual end customers.

The URL for the chat plugin client demo can be found at:
http://{the-loadbalancer-ip-address}/chatplugin/ui/example?channel_id={chatplugin_channel_id}

To get the chatplugin_channel_id on the channel which you created, you should go to Channels -> Click on the channel -> Edit -> Install & Customize and then copy the w[n].channelId property as on the next screenshot.

Then write to the channel and you should get automated replies.

For example:

Hello
What times are you open?
Bye

On the following screencast we have opened two screens in parallel: the first screen (on the left) with the Airy Inbox where all the messages from all the channels are coming in and the second screen (on the left) where we have the chat plugin client demo where we can write to the chat plugin as an end customer.

There we can see the automated replies from the Rasa automation.

What is next?

Congratulations! You are a conversational developer now.

• Join the community - Chat with other conversational engineers and stay up to date on the latest developments - join our Slack community.

• Secure your installation - The demo doesn't offer any encryption, so before you connect any actual sources - you should secure your Airy Core installation - https://airy.co/docs/core/getting-started/installation/security

• Connect multiple channels - Airy supports a variety of sources such as Facebook, Google Business Messenger, WhatsApp and SMS. Refer to the Sources documentation page to see how to connect them - https://airy.co/docs/core/sources/introduction

• Expand the capabilities of Rasa - Rasa is a very powerful tool and in one of our previous blog posts we explain how to get the most out of your conversational AI and customer support by having your AI suggest likely responses and then training it on the selection that customer support makes.

Official websites and documentation:

Welcome to Airy! | Airy Documentation

Airy Core is an open-source, fully-featured, production-ready

Airy DocumentationMenuMenu

Introduction to Rasa Open Source

Learn more about open-source natural language processing library Rasa for conversation handling, intent classification and entity extraction in on premise chatbots.

Rasa Open Source Documentation

Production-Grade Container Orchestration

Production-Grade Container Orchestration

Kubernetes

Apache Kafka

Apache Kafka: A Distributed Streaming Platform.

Apache Kafka

Having a Live Chat plugin on your website has become essential. Connect with your website visitors, communicate with them in real time, or use a bot to automate FAQs.

Airy’s Live Chat Plugin comes out of the box fully functioning, and thanks to its open-source nature and React Render Props, you can customize everything about it.

Out of the box Airy’s Live Chat Plugin supports:

• Full customization of look, feel and features
• All message types, including emojis
• Rich Messaging with templates, cards and carousels

How to Create your Personal Airy Live Chat

1. Set up your Airy instance
2. Log into your Airy Core UI via your Airy instance and you will be guided to your Inbox
3. Click the ‘Channels’ button on the left sidebar menu
4. Click the '+' symbol to the right of the Airy Live Chat option

5.   Click the ‘Connect Airy Live Chat’ button

6.   You will be prompted to enter a Display Name and an optional Image URL - these will be used for internal purposes only, meaning that you and your team will be the only ones able to see these optional features

• The display name will be used as the conversation's name and the image URL will be used as the icon within the Inbox UI
• If you do not select an image, one will be assigned to you

7.   Click the ‘Save’ button to save the changes you have made

Customizing your Airy Live Chat

For most use cases, the basic customization will be sufficient for you and your team because it supports the essential options to customize the experience. These customizations can all be made on one screen, which will be shown . However, if you need full control of every aspect of the plugin, we also offer the possibility of advanced customization with Render Props.

Airy’s Chat Plugin allows you to customize based on the needs of you, your team and your contacts. These customizations include, but are not limited to:

• Text displayed on your chat plugin
• Color scheme of your chat plugin
• Icon displayed on the button to open your Airy Chat Plugin on your website
• Welcome Message displayed when contacts open your chat plugin
• Height and width of your chat plugin
• Closing options for your Airy Chat Plugin (basic, medium, full)
• Option to disable your chat plugin for mobile browsers

After you successfully connect Airy Live Chat, you can customize it by clicking on your connected Airy Live Chat.

Once you click the ‘Edit’ link to the right of your connected Airy Live Chat channel, you can navigate to click the ‘Install & Customize’ option.

Here, you are able to customize your Live Chat plugin. You are able to customize several features, such as:

You can see an example of how the code will look once you customize these features in the image below.

Optional: Welcome Template

If you would prefer to begin all conversations with the option of a template with buttons, you must include this code within the <script></script> portion of the code snippet.

An example of the text including a hardcoded Start/Welcome template will look something like this:

<script>(function(w, d, s, n) {
       w[n] = w[n] || {};
       w[n].channelId = "your instance’s Airy Live Chat unique channelID";
       w[n].host = "https://OURCOMPANY.airy.co";
       w[n].config = {
         headerTextColor: "#474545",
         primaryColor: "#91B668",
         accentColor: "#91B668",
         backgroundColor: "#E9E8E8", 
         showMode: false,
         headerText: "COMPANY Chat",
         bubbleIcon: "https://www.OURCOMPANY.com/site/img/logo.png",
         welcomeMessage: {
           fallback: "Welcome to OUR COMPANY! How can we help you today?",
           richCard: {
             standaloneCard: {
               cardContent: {
                 media: {
                   height: "MEDIUM",
                   contentInfo: {
                     altText:
                       "Welcome to OUR COMPANY! How can we help you today?",
                     fileUrl: "https://airy-platform-media.s3.amazonaws.com/CHANNEL-ID",
                   },
                 },
                 title:
                   "Welcome to OUR COMPANY! How can we help you today?",
                 description: "I have a question about:",
                 suggestions: [
                   {
                     reply: {
                       text: "Before Visiting Our Store",
                       postbackData: "COMPANY-beforevisit",
                     },
                   },
                   {
                     reply: {
                       text: "Live Shows & Livestreams",
                       postbackData: "COMPANY-shows-livestreams",
                     },
                   },
                   {
                     reply: {
                       text: "Customer Service",
                       postbackData: "COMPANY-customerservice",
                     },
                   },
                   {
                     reply: {
                       text: "News, Offers & Discounts",
                       postbackData: "COMPANY-news",
                     },
                   },
                 ],
               },
             },
           },
         },
       };
       var f = d.getElementsByTagName(s)[0],
       j = d.createElement(s);
       j.async = true;
       j.src = w[n].host + "/chatplugin/ui/s.js";
       f.parentNode.insertBefore(j, f);
     })(window, document, "script", "airy");</script>

If you choose to begin with this template, it can look something like this:

Where to Put the Code

You will copy all code within <script></script> and paste it in the head of your website.

This release lays the foundation for future improvements to your Airy instance, as well as facilitating an easier way to secure your Airy Core installation. It also adds some flare to the user experience within the UI by enabling emoji reactions to messages from Facebook users.

Reorganizing Helm Charts

So far during the setup of Airy Core, we had our own helm container image, where we also bundled the helm charts for the installation. In the latest release, we changed this approach in a way that we are now using a generic alpine/helm image and publishing the individual helm charts in an S3 bucket.

This approach will help us with several infrastructure features, which we will continue to work on for the next few releases:

• Creating a generic helm installation tutorial for people who have their own Kafka cluster, have their own Kubernetes cluster and/or would like to use their own Kubernetes ingress controller
• Make it possible for people to create multiple Airy Core installations in a single Kubernetes cluster
• Create the airy upgrade command which will take care of upgrading an existing installation of Airy Core

HTTPS inside Kubernetes

When deploying Airy Core on AWS or in the cloud in general, using HTTPS is a must. Previously, we provided a way in our docs to add your own certificate to the AWS Certificates Manager and patch the service and ingress controller in your Airy Core in order for the LoadBalancer to use the certificate.

In the latest release however, we have included an optional ingress controller which has Let's Encrypt functionality bundled. With this option, valid HTTPS certificates are created and renewed automatically.

There are two prerequisites for enabling Let's Encrypt in your Airy Core instance:

• The fully qualified domain name (FPDN) or the public hostname on which Airy Core will be accessible
• An e-mail address, required by Let's Encrypt in order to generate the certificate

When a new Airy Core instance is created, you can add these parameters to the airy.yaml file and then follow the Airy Core documentation on how to complete the installation and the setup.

Adding Facebook emoji reaction metadata

This release introduced an exciting feature for Airy users who have Facebook Business Pages connected to their instance: adding Facebook emoji reaction metadata. With this improvement, we are informed when Facebook users react to messages with emojis; for example: a heart or thumbs up emoji. This feature can be used to optimize our connection with customers and get real-time feedback.

Enjoy and stay tuned for the highlights from Release 0.29.0!

Your conversational experiences are up and running. The livechat on your website is buzzing with chats, your chatbot answers requests in your app and your customer service agents switched from answering phone to answering chats.

The data is flowing. But how do you visualize it?

First you need to chose your Standard and Value Metrics and get your dashboard up and running, for example with Airy’s Conversational Dashboard, it will look something like this:

As you can see we chose our standard metrics: Number of Conversations, Active Conversations by Day and Source, Channel Count and the most active hours.

Same as our dashboard yours should be extendable, so you can add metrics on the fly and value metrics once you identified them.

Stack & technical setup

A dashboard is only as good as the data and the systems powering it. To make your dashboard extendable and flexible, as you will learn and adapt it over time, you need to make it powerful.
For a powerful dashboard, you will need to set up a good data pipeline and storage system.

As far as data pipelines and storage go, it depends on which channels you have running, which metrics you want to track, and which data you want to store.

Learning from storing and utilizing millions of conversations our choice for conversational data solutions is data lakes.

At Airy we build our data pipeline on AWS, storing conversations, messages and metadata in S3, using Parquet for compression and AWS Glue for schema management.

For the conversational dashboard above we are using Metabase, for us the fastest and easiest way to visualize the analytics.

As another Open Source solution it also helps keeping your data secure and data control and ownership clear.

Benefits of using Airy’s Conversational Dashboard

- Easy to host
Our enterprise edition is easy to host. You can run it in your own cloud, no matter if it is AWS, Google Cloud or Azure.

- Extendable and flexible
As we have seen there are many possible metrics you want to track, and your tracking and dashboard will change over time. Airy’s Conversational dashboard is set up exactly for this challenge.

- Easy to set up
Airy’s analytics are easy to set up. Either run through our guide or schedule a call with our solutions engineers to get you up and running.

Conversational interfaces are everywhere. Your website visitors use your live chat to ask questions and inform themselves before they buy, your app users use the support chat to get help and your conversational commerce experiences guide potential customers to purchase the right product, one message at a time.

But how do you measure this new conversational world?
Every time a new channel is added to your channel mix and technical stack, the question comes to metrics: what do you measure, how do you measure it and how do you visualize it?

Of course, you can start with simple channel analytics - which channels are connected and how many conversations and messages go through every day. But this is too high level for the many questions to ask and metrics to answer them: does the app chat support perform better than Whatsapp support, what is used more - by number of conversations but also by number of average user conversations. How do the channels differ in usage - for example what the most active hours per channel are.

All these questions lead to real decisions: how many support agents do you need to hire or retrain for each channel, when do they need to be most active, how does the channel compare to other channels you have running - does it make sense to invest more in conversational channel A or conversational channel B?

And we haven’t even started looking at operating metrics: NLP analytics like most common intents, phrase clustering or analysing conversation paths with flowcharts. Last but not least don’t forget about business metrics like Merchant Response Rates, response times or CSATs. They define how well your conversational experience is actually adopted on the business side.

Conversational Metrics 101

There are many conversational metrics to look at and a whole new world of analytics to track, store, and explore. And everybody with analytics experience knows: with great choice comes great responsibility.

The choice is an important one, thankfully the answer is straight forward:
Conversational interfaces are just that: a new type of interface, a useful and universal one. Perhaps the future of universal interfaces. Perhaps soon all your interfaces will be conversational, at least partially, staffed by Conversational AI and human agents, talking to your users like friends and family.

For this vision to arrive, conversational interfaces need to proof their value first.
So for your conversational tracking you should focus on 2 metrics:
- Standard Conversational Metrics: to keep track of this new channel and improve it
- Value Metrics: to prove the ROI of this channel, focus on the value it brings

An overview of conversational metrics

But first, let's look at the standard conversational metrics. For an overview of Conversational Metrics and their definitions, check this handy list of possible metrics:
https://airy.co/docs/enterprise/analytics/introduction

We divided them into 5 major categories:

Setup & Channel Analytics
Everything you want to know about the conversational channels you have

Conversational Analytics
Metrics for Messages, Conversations and everything in between

NLP Analytics
Intents, Top In & Out Messages and more

Demographics
Understand where your users come from and which languages they speak

Business Analytics
Business Metrics from MRR to CSAT

Out of these, you choose the standard metrics you want to track. In a second we will show you which ones we chose for our standard analytics setup.

Value Metrics

Value metrics explain themselves with their name: what value comes from this channel? They go one step further than the metrics above and try to capture the ROI of the conversational experience.

The trick here is that conversational experiences are often multi-intent: Your website visitors use your live chat to ask pre-purchase questions on a product, and are helped by your sales agents.
A while later they come back after purchasing something to ask customer service questions, answered by an automated FAQ.

So is the livechat a sales channel or a customer service channel? Both in this case. But if it is both then you need to track the value metrics for both: The revenue generated through the answering of sales related questions, and the cost savings through the automated FAQs.

For value metrics thus keep it simple: Track how much revenue is generated if the conversational experience is sales related.
If the experience is customer service related, track how many costs are saved, for example by “fully automated conversations” or “questions deflected”.

Next steps: Storing and visualizing data

Now that you know what you want to track and have chosen your standard metrics & your value metrics, it is time to make working with them a reality.
First you need to make sure that you have a data pipeline up and running, for example a conversational Data Lake. Read our guide on conversational data lakes to learn more about how we solved this particular problem.

Once you have the data and it is readily available you need to find an easy way to visualize it: A conversational dashboard is needed.

Continue your path to conversational analytics mastery by learning how to build your conversational dashboard.

Today we will learn how your chatbot can help your customer support agents and how they can feed your bot with new training data; all of this while providing a best-of-class experience to your users.

Background

Natural language chatbots in 2021 still follow a simple model: When a user writes a message a machine learning model reduces the message to a small set of preconfigured user intentions (short: intents), which are used to predict the next action. This is great, because machines still struggle with the fuzziness of human language, but work really well with deterministic input.

But what to do in case of multiple intents? It's not uncommon that, well-aware of how much context matters, users open a conversation with a wall of text about how they got into their predicament and what they should do next. This stops any intent-based bots dead in their tracks. Therefore it's become a common pattern to forward requests like these to human support agents. But those agents usually have to spend lots of time catching up on conversations and writing responses. And when they do it's hard to incorporate the solutions reached in these human to human conversations back into the response model.

So imagine instead of having to type an answer the bot could present you with a list of best guesses that you only have to choose from. That way you save agents time and can re-train your bot on the response selection. In this post we will explore how to do this using Rasa X and the Airy conversational platform using the following seven steps:

1. Install Airy
2. Install Rasa X
3. Configure Rasa
4. Deploy the action server
5. Deploy the Airy connector
6. Point Airy at Rasa
7. Doing a test run

Step 1: Install Airy

To get started we need a running Airy and Rasa X installation. The fastest way to get setup with Airy is to install the CLI and then run

airy create --provider minikube my-app

to install a local development environment of Airy. This requires >8Gb of available RAM so if you want you can also jump ahead and get setup for production immediately by following our guides.

The output of this command will look something like this:

You can now open the inbox UI, where we will be responding to user messages, at http://airy.core/ui/

Step 2: Install Rasa X

To get set up with Rasa X we will follow their Server Quick Install Guide. You can use any cloud provider or already running server you like, but for this example we created a Ubuntu 20.04 VM instance on Google cloud. Be sure to check that your system fulfils the minimum requirements before installing.

Next we execute the following command on our running VM:

curl -s get-rasa-x.rasa.com | sudo bash

This will install an embedded Kubernetes cluster with Rasa X running as a Helm chart. Take note of the login information!

Step 3: Configure Rasa

If you want to follow along and tweak things you can check out the Rasa code here: https://github.com/airyhq/rasa-x-demo

Whenever the bot is faced with a message it does not understand, we want Rasa to call a special action suggest_replies that passes a set of messages to Airy so that they can be displayed in the inbox.

The recommended way to configure Rasa X is to connect it to a git repository. This way the following changes to your configuration files will be synced whenever you push to your version control server. You can either create a new repository by running rasa init or by forking the demo repository.

First we need to teach Rasa to handle messages that have ambiguous intents. By adding the FallbackClassifier to the NLU pipeline, we can make Rasa predict an nlu_fallback intent whenever that is the case.  We also add the RulePolicy to catch any messages with a low prediction confidence and a static rule that predicts suggest_replies whenever the intent fallback occurs.

pipeline:
  # ...
  - name: FallbackClassifier
    threshold: 0.7

policies:
  - name: RulePolicy
    core_fallback_threshold: 0.7
    core_fallback_action_name: "action_suggest_replies"
    enable_fallback_prediction: True

- rule: Suggest replies to agent as a fallback
  steps:
  - intent: nlu_fallback
  - action: action_suggest_replies
  - action: action_listen

Step 4: Deploy the action server

At this point the bot will fail whenever the action_suggest_replies action is triggered, because we still haven't hosted that action with our custom action server. To do we can configure our running Rasa X instance to use the pre-built image with our action code by setting:

export ACTION_SERVER_IMAGE="ghcr.io/airyhq/rasa-x-demo/rasa"
export ACTION_SERVER_TAG="latest"

Now when we run:

curl -s get-rasa-x.rasa.com | sudo -E bash

the -E option will pass our variables to the Rasa X init script, which will configure the existing cluster for us.

Step 5: Deploy the Airy connector

In order for the rasa-production deployment to receive messages from Airy we need to deploy the same image tag we used for the action server to rasa-production and configure the credentials file.

Since the get-rasa-x script does not allow us to configure the image we manually edit the deployment by running:

kubectl edit deployment rasa-production

and replacing the image tag with ghcr.io/airyhq/rasa-x-demo/rasa:latest .

Next we need to ensure that Rasa can call your Airy API to send suggested replies. Since the default airy.core domain is only locally accessible we will exchange that domain for the default tunnel that ships with Airy. To do so run the following command on the machine that is running Airy:

echo "https://$(minikube -p airy-core kubectl -- get cm core-config -o jsonpath='{.data.CORE_ID}').tunnel.airy.co"

This should yield a URL like https://kz0vto4fss.tunnel.airy.co . Next we run

kubectl edit ingress airy-core

and replace the host part with an asterisk * to match traffic from the tunnel. Finally we want to tell Rasa about this URL by running the following command on the Rasa machine:

kubectl edit cm rasa-rasa-configuration-files

and then updating the config map so that it looks like so:

apiVersion: v1
data:
  rasa-credentials: |
    rasa:
      url: http://rasa-rasa-x-rasa-x.rasa.svc:5002/api

    channels.airy.AiryInput:
      airy_host: https://kz0vto4fss.tunnel.airy.co
# ...

For this change to take effect we now need to delete all rasa-x and the rasa-production pods. This will cause them to restart and fetch the new configuration. Lastly we need to ensure that our Rasa pod is accessible from the outside so that Airy can call its webhook. We do so by exposing its service as a load balancer:

kubectl expose service rasa-rasa-x-rasa-production rasa-production-load-balancer --type LoadBalancer --port 5005 --target-port 5005

Now your Airy Rasa webhook should be publicly available at http://your.vm.ip.address:5005/webhooks/webhook/airy. NOTE: Check your firewall rules on an instance and on a provider level to make sure that your VM can send and receive requests at port 5005

Step 6: Point Airy at Rasa

Now that our Rasa instance is ready to send and receive events to and from Airy we need to point our Airy webhook to it. To do so we call the webhook subscribe endpoint like so:

curl --request POST \
  --url http://airy.core/webhooks.subscribe \
  --header 'Content-Type: application/json' \
  --data '{"url": "http://your.vm.ip.address:5005/webhooks/webhook/airy"}'

Where the url part of the payload is the Rasa webhook url we exposed in the previous step. Once this is done your Airy instance should forward all its messages to Rasa.

Step 7: Doing a test run

You can test this setup by sending an example message to the Airy website ChatPlugin. If you are new to Airy the fastest way to do so is by following our Chat Plugin quickstart guide. Once you have sent a message, the bot should reply and the message should show up in Rasa X.

Now in the screenshot above I have sent a greeting to which the Rasa bot replied. Next I've sent an example message aimed at generating ambiguous intents. As you can see there is now a suggestions box right above the input bar. When I click that I'm being presented with the suggested replies that the bot generated.

If you know open your Rasa X installation you should see the conversation appearing in the conversations tab. Here you can now copy and modify the user story and use it to train a new model.

Benefits

To recap: You now have a tool that when your bot needs to fallback on customer support it can, in most cases, provide them with response suggestions.

Save customer support time

Catching up on the context of a conversation and crafting a high quality, grammatically correct response is very time consuming. With this approach your agents can simply moderate many of their conversations.

Get more labelled training data

Usually when we hand over to customer support the ensuing conversation is hard to decipher and map back to a desired bot model. By using response selections you get an entirely new dataset of real conversations to train on.

Greatly improve user experience

By training the bots on the response selection of the user given the user message you are in essence "filling the gaps" of your bots coverage. This means faster and more accurate responses for future interactions.

This interaction pattern also implements a new paradigm in chatbot design: Conversation Driven Development (CDD), in which you start with a very simple bot and rapidly iterate using real world data to get a better experience both faster and cheaper.

Limitations

• Currently replies are only suggested during the handover.
• Depending on your NLU engine intent ambiguity can be hard to train for, since Rasa for instance tends to give a stark confidence contrast between predictions.
• Fairly complex deployment.

Where to go from here

If you are struggling to complete this guide or want to share your journey, you can join our Developer slack!

And if you're interested in implementing this solution in production and at scale, we'd be happy to help you!

What are Data Lakes?

Essentially, data lakes are a place to store all of your data for analytical purposes, much like a data warehouse. The easiest way to differentiate the two, is that a data lake does not include the means to do any sort of calculations with it. It is nothing more than a very reliable and infinitely scalable object store. The benefit of that, is that you only pay for the storage you use. Unlike a data warehouse, where you either pay for empty hard disks or idling server resources.

Meanwhile with a data lake, where storage and compute is decoupled, you can leverage the unstructured nature of data lakes and import data in any shape, volume or form.

Furthermore, you can choose to enable crucial features by ticking a few boxes, like encryption and data livecycle policies, for when you want to save even more money on less frequently accessed slices of your data.

But, because storage alone doesn’t provide any insights, data lake providers have worked hard to integrate well with the existing analytics solutions out there, enabling customers to use the tools they are already familiar with, like SQL and Apache Spark.

What makes Conversational Data special?

At Airy, we have been processing conversational datasets for many years and have seen the exponential growth of this new domain for customer-business conversations. With the shift to messaging, more and more customer interactions, from pre-purchase questions to customer service requests, become conversational.

The data itself has a high signal vs noise ratio, since inside of the data you can find answers to all sorts of questions, from findings about bottlenecks in internal company processes to preferences of customers.

Unfortunately, conversational data is currently highly siloed: customer service chats are often exclusively stored inside the customer service database, or pre-purchase related questions stay within the tools that social media teams use to engage with people on social media channels.

Because there are a multitude of different messaging providers that structure their data differently, it is hard to aggregate this data in a way that enables economical storage and still provides the ability to do powerful analytics in a variety of tools.

Conversational AI, spearheaded by teams like Rasa and Dialogflow by Google, aims to automate many conversational use cases. Finely grained real conversational data makes it possible to train models in real time.

We have seen entire customer service departments overhauled, as conversational data has been successfully used to train models in order to automate FAQs, freeing agents to tackle more complicated requests, further improving response times and customer satisfaction.

Airy’s Conversational Data Lakes on AWS

On AWS, conversational data can be stored in Amazons S3, providing for a cheap storage option for massive amounts of data. To optimize for performance when querying data, raw AVRO formatted conversational data is converted into compressed Apache Parquet files.

To eliminate manual schema management, we also provide schema information with our AWS Glue data catalog integration. With this, you can get a clear overview of all conversational data, down to the last column, and query it instantly with AWS Athena.

From here, it's very easy to integrate in all the standard tools that the data science and analytics communities love.

Encrypted by default

For regulatory compliance and data protection it is often required to encrypt data at rest. We handle this with Amazon S3-managed encryption keys which means your data is secured with AES-256 block cyphers before it is written to disk. Arguably even more important is to also encrypt your data in flight because it then leaves your infrastructure and is sent to S3. For this case we support SSL/TLS encryption to prevent anybody from eavesdropping on your traffic.

Future-proof for advancements in conversational experiences

Conversational providers such as WhatsApp and Facebook Messenger are constantly innovating, varying their feature sets and offering different use cases. To stay on the leading edge our engineers have developed a data model achieving symbiosis of structured and semi structured data.

Our highly scalable ingestion platform, based on Kafka, streams the data into our system where the conversational data from all providers is resolved into uniform schemas of channels and messages.

We also support unstructured metadata throughout our system for when additional information is required. An example of this metadata would be internal open-done states, clearly showing in a UI if a conversation needs a human response.

Integrating into your existing Data Lakes and Warehouses

The real value of your conversational data becomes apparent when you merge it in real time with your existing data, creating a more complete model of your customers.

If you have a lot of existing data, your Airy Data Lake integrates seamlessly with analytics tools like Apache Spark for powerful analytics at any scale.

The Power of Conversational Data Lakes

Understanding your conversational data better is essential for providing your customers with the best possible service. From identifying patterns in your customer support cases and analysing customer preferences to training your Conversational AI model with Rasa or Dialogflow, it all becomes easily accessible with a data lake.

In a recent case with one of our large retail customers, their Airy Conversational Data Lake has enabled them to do a deep dive on their Google Business Messaging data to improve their customer satisfaction rating.

By combining the results of the Customer Satisfaction Score (CSAT) with the source data on a per conversation basis, it is possible to pinpoint exactly which kind of conversations are leading to lower scores. With these insights, solutions can be precisely designed and implemented, leading to greatly improved customer satisfaction and reduced customer churn, all with minimal cost and effort from the company’s side.

Visualization is also just a query away: This simple breakdown shows CSAT by the day of the week. It’s immediately clear that the majority of negative scores are reported for conversations beginning towards the end of the week. The customer service department of this particular company is comparatively understaffed over the weekend, leading to increased customer waiting times for a response. Percentage wise, dissatisfaction is at its highest over the weekend.

Using a simple visualisation like this, one can glean that a few more service agents on duty on Saturdays could improve CSAT dramatically.

Key Benefits of Conversational Data Lakes

Setting up a Conversational Data Lake now (or integrating conversational data in your existing data lake) sets your company and data teams up for a future where most customer and business interactions are conversational and automated by Conversational AI. Having your own conversational data lake leads to:

• Much lower costs for data storage (compared to most data warehousing solutions)
• Immediate insights into customers' preferences and behavior
• Reduced engineering times for data scientists
• Readiness for the exponential growth of conversational data & your own conversational AI models

Get started today!

Airy’s Conversational Data Lakes is available to all Enterprise Customers. Get started today with our Quickstart Guide.

Hi, my name is Liz from Airy, and I want to take the next few minutes to talk about Airy's conversational platform, what it does and how it can help you. Conversational solutions are everywhere, whether it be on your website as live chat, on app as an app chat, or on social platforms that you use every day, like Facebook, Google, or WhatsApp.

Although they're everywhere, conversational experiences tend to be siloed and fragmented, especially once you integrate with your existing tools and business systems. However, with Airy you can store, structure and utilize all conversational data. So you can connect sources to Airy such as website and app chat, Google, Facebook, WhatsApp, or custom sources.

And once you connect these sources, you can build different conversational use cases. So first is conversational AI, where you can train your models with conversational data via Rasa or Dialogflow. You can enhance your business systems by integrating with your CRM, such as Salesforce or help desk like Zendesk. And you can store data in data warehouses like Snowflake or Amazon Redshift.

Airy is super easy, meaning that with these two commands, the whole platform is already up and running. Airy comes with many components, including blazing fast APIs, you can access your platform programmatically, via graphical user interfaces, and pre-built integrations into all of your systems.

It's possible to connect all major conversational sources like Facebook, Google, or WhatsApp to Airy, but we also brought you an open-source chat plugin, which you're able to customize yourself. The live chat that we give you is already a part of Airy and we have even more SDKs that are coming. In terms of how to access your Airy instance, you can do it with:

• APIs where you can view conversations, messages, users, and more
• WebSocket where you can power real time applications
• Webhook where you can listen to, or subscribe to events, and react accordingly

You can participate in conversations programmatically, or integrate your Airy instance with a custom platform.

We know that sometimes code is not enough, so we've created UIs for you. You can see all conversations and messages from all connected sources, you have a fully functioning inbox with features such as a channel UI, tags and templates.

As a conversational platform, Airy also cares a lot about conversational AI. So we support all conversational AI providers like Rasa, Dialogflow, and IBM Watson. Even in the inbox, you can see what your conversational AI would suggest with Suggested Replies. Airy runs on Kafka, so you can scale it as much as you want to, meaning that there are no limits.

So for example, in our own instance, we have millions of conversations. You could also host it anywhere, whether it be Airy cloud, your own AWS account or whichever hosting provider you have. And in addition to this, everything that you see is open-source.

You can install the CLI with one command, and then you're able to do anything to create or control or administrate your area instance.

You can test it locally on your own machine, or you can deploy it on the cloud, whether it be with us on Airy cloud or on your own AWS, Azure, or Google cloud. As you can see, an instance was created on AWS on the right hand side, just while I was explaining this to you. So join our Slack to get community support, and in addition, we also have a dedicated enterprise support team. Start a conversation with us on airy.co and we look forward to hearing from you.

0. Make sure you have the latest versions of the AWS CLI, Airy CLI & jq running on your local machine

You should already have a configuration on your local machine for which the following things were true - or should have completed the following steps:

• The AWS CLI should be installed and properly configured on your local machine.
• Download and install the Airy CLI, in case you haven't done so yet. If you are on Mac using Homebrew, just run the following in Terminal:

brew install airyhq/airy/cli

• In Terminal, check if you have the latest airy version of the Airy CLI that will install the corresponding version of Airy on AWS in the next step.

airy version

• We also recommend to install the latest version of jq, which will be required during the installation process. Using Homebrew on a Mac, run the following in Terminal:

brew install jq

1. Create a new remote Airy instance

• First, create or choose the directory on your local machine that you want to use to manage your remote Airy instance.

mkdir airy-aws
cd airy-aws

• Then, remotely create a new Airy instance by running the following command in Terminal:

airy create --provider aws

This command will set up a Kubernetes cluster using AWS EKS, and will give you our recommended two c5.xlarge EC2 instances in the relevant region that your AWS profile is configured for by default. Please check the relevant pricing applicable for your region before continuing here. The overall costs for our recommended configuration might amount to about $300-350 per month in most regions.

You can customize the deployment e.g. by using different instance types (e.g. c5.large for a less powerful configuration for your Airy instance), or deploy Airy to an existing Kubernetes cluster, as outlined in the relevant section of our documentation.

Please stay patient once you run the command. The script needs to install quite a lot of infrastructure, so this might run for about 20-30 minutes. Have a coffee in the meanwhile! ☕

The installation script created three files for you in the directory you chose before on your local machine:

• airy.yaml: The configuration file for your Airy instance
• cli.yaml: The configuration file for your local Airy CLI
• kube.conf: The configuration file for your remote Kubernetes cluster

You can verify that everything has been installed correctly by looking the pods of the remote Kubernetes cluster. Just type in the following command in the relevant directory on your local machine:

kubectl get pods --kubeconfig ./kube.conf

This will return a list of all the pods currently running on your remote cluster:

2. Configure HTTPS for your Airy instance

We strongly recommend to activate and configure HTTPS for your Airy instance as you should only send and receive conversational data securely. Most conversational sources such as Facebook Messenger also require you to activate HTTPS and no longer support sending or receiving messages via HTTP only.

We assume you have already acquired a SSL certificate for the domain name you intend to use for your Airy instance from your domain name registrar or provider - or you might already be in possession of a Wildcard Certificate for your domain name. As you might be aware, there are also free alternatives available such as Let's Encrypt to manage and obtain SSL certificates for the domain name you intend to use with your Airy instance.

Import your SSL certificate into Amazon Certificate Manager (ACM)

Run the following command in Terminal, specifying the SSL certificate and the private key file, as well as the certificate chain bundle file as the case may be. Please make sure to include fileb:// before the path to each file on your local machine.

aws acm import-certificate --certificate fileb://_CERTIFICATE_FILE_ \
      --certificate-chain fileb://_CERTIFICATE_CHAIN_BUNDLE_FILE_ \
      --private-key fileb://_PRIVATE_KEY_FILE_ 

Configure the Ingress service

Run the following command in Terminal, copying and replacing  _YOUR_CERTIFICATE_ARN_ with the value of CertificateArn from the previous step:

kubectl -n kube-system annotate service traefik "service.beta.kubernetes.io/aws-load-balancer-ssl-ports=443" "service.beta.kubernetes.io/aws-load-balancer-ssl-cert=_YOUR_CERTIFICATE_ARN_" --kubeconfig ./kube.conf

Then run the following command in Terminal:

kubectl -n kube-system patch service traefik --patch '{"spec": { "ports": [ { "name": "https", "port": 443, "protocol": "TCP", "targetPort": 80 } ] } }' --kubeconfig ./kube.conf

Start with exporting the Host URL that you want to use for your Airy instance that should correspond to the URL (or in case of a wildcard certificate a URL) that your certificate is issued for:  

export HOST=airy.example.com 

Now, update the hostnames configmap and update the Ingress extensions by running the following commands in Terminal:

kubectl --kubeconfig ./kube.conf -n default patch configmap hostnames --patch '{"data": { "HOST": "https://${HOST}"} }'
kubectl --kubeconfig ./kube.conf -n default get ingress airy-core -o json | jq '(.spec.rules[0].host="${HOST}")' | kubectl --kubeconfig ./kube.conf apply -f -
kubectl --kubeconfig ./kube.conf -n default get ingress airy-core-ui -o json | jq '(.spec.rules[0].host="${HOST}")' | kubectl --kubeconfig ./kube.conf apply -f -

Finally print the hostname of the Ingress service in Terminal by running this command:

kubectl -n kube-system get service traefik -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' --kubeconfig ./kube.conf

Now, head over to your domain name registrar or provider - respectively where you manage the name servers for your domain. Please add a new CNAME entry for the relevant domain name you intend to use with your Airy instance and point it to the hostname of the Ingress service as the destination as printed above, for example:  

CNAME airy.example.com -> 
"abcdefgh0123456789.elb.us-east-1.amazonaws.com"

Wait for a certain time until the name servers should have been updated and DNS servers populated with the new information across the internet. You should then be able to reach your Airy instance by accessing https://<YOUR_DOMAIN>/ui from any modern web browser.  

3.  Secure your new Airy instance 🔐

Your Airy instance comes without pre-configured security settings to make it easy for you to run Airy on your local machine or in a safe environment. However, if you run your Airy instance in a place that is publicly reachable from the internet, like any cloud provider such as AWS, the first thing you should do is to properly secure your Airy instance.

⚠️Warning️️️: The Airy Core API as well as the Airy Inbox UI running at YOUR_PUBLIC_AIRY_URL/ui will be publicly accessible unless you implement the following steps. Please make sure to properly secure your Airy instance before you connect conversational sources or stream actual customer conversations to your Airy instance. ⚠️

Open airy.yaml with an editor of your choice and add a system token via a new systemToken parameter as well as an authentication provider of your choice by specifying an Open ID Connect configuration via the oidc parameter. We support any authentication provider that follows the Open ID Connect standard.

For example, if you decided to use Github as an authentication provider, you would need to implement the following steps:

• Look up the public URL of your Airy instance by running the command airy api endpoint in Terminal.  
• Create a Github OAuth App with an Authorization Callback URL in the form of <YOUR_PUBLIC_AIRY_URL>/login/oauth2/code/github  
• Edit the the relevant section of your airy.yaml file by copying the relevant values for Github Client ID and Github Client Secret from the previous step. Additionally, specify the required parameter allowedEmailPatterns by giving a list of email addresses or a pattern of email addresses of Github users such as *@example.com, so not every Github user will be able to access your Airy instance. The security section of your airy.yaml file could, for example, look as follows:

security:
  allowedOrigins: '*'
  jwtSecret: <SOME_SECRET>
  systemToken: <SOME_SUPER_SECURE_TOKEN>
  oidc:
  	allowedEmailPatterns: "*@example.com,john@example.com"
    provider: "github"
    clientId: "<YOUR_GITHUB_OAUTH_CLIENT_ID>"
    clientSecret: "<YOUR_GITHUB_OAUTH_CLIENT_SECRET>"

• Finally, apply the configuration by running the following command in Terminal:

airy config apply

• Try out to query the Airy Core API by sending the following request in Terminal:

curl --request POST \
  --url <YOUR_PUBLIC_AIRY_URL>/conversations.list \
  --header 'Authorization: Bearer <SOME_SUPER_SECURE_TOKEN>' \
  --header 'Content-Type: application/json'

• You can also try out to access the Airy Inbox UI in any modern web browser at <YOUR_PUBLIC_AIRY_URL>/ui/ which should lead you successfully to the Github OAuth flow and forward you back to your Airy instance upon successful authentication.

4. Connect your Conversational Sources and start to utilize Conversational Data

You are now ready to connect conversational sources such as Facebook Messenger, Google Business Messages, WhatsApp, etc. to your Airy instance.

Please read the relevant documentation on how to configure conversational sources, so you can start to connect channels and stream conversations and messages to your new Airy instance.      

This release significantly expanded the capabilities of your Airy Chat Plugin. Prior to this release, the possibility to end the chat and begin a new one was not available. In addition to this, quick replies became easily accessible and the behavior of the Chat Plugin when a contact resumes a conversation improved.

End Chat Option

The End Chat option was introduced to the Airy Chat Plugin mostly for security and privacy reasons. Without this feature, conversation history (and possibly personal data) would be readily available, including on a public or shared computer. However, contacts are now able to end the current chat session and exit the website, or simply create a new chat immediately after.

With the End Chat option, contacts do not have to worry about any personal data being accessible by any third party members of the conversation. They can opt to have their conversations saved, or they can start a new one every time they enter the website.

Quick Replies for Chat Plugin

This feature makes it easy for both contacts and system users to quickly reply to a question posted by the other person. The quick replies only display when the associated message is the most recent message within the conversation. Once one has been chosen and sent, the row of quick replies disappears until another message contains quick replies.

These suggestions (buttons) are displayed horizontally below the plain text that prompts them. As a guideline, you can have a maximum of 13 suggestions with a maximum of 25 characters each.

Expanded Chat Plugin by Default

With Airy Live Chat, contacts are able to resume conversations, if they choose to do so, at a later time with a resume token. To make it more convenient, we decided to expand the Chat Plugin by default when continuing that conversation. In addition, contacts are already in the input bar of the chat, so they do not need to navigate anywhere, but instead can start typing immediately.

🚀 Features

• [#929] Implement the option to end chat (#1508)
• [#1110] Add basic and advance customization to chatplugin docs (#1494)
• [#1290] Prometheus Metrics about Spring apps (#1479)
• [#1473] Make release process more quiet (#1501)
• [#1004] Enable quickreplies for chatplugin (#1478)
• [#572] Cleanup senderType code (#1490)
• [#1474] Added showmode flag that blocks functionality in chat plugin (#1475)
• [#572] Simplify senderType (#1458)

🐛 Bug Fixes

• [#1521] Import ChatPlugin header component assets from library (#1522)
• [#1438] Fix logout when a user sends a message to a conversation from a disconnected channel (#1457)

📚 Documentation

• [#1408] Add missing tag gifs (#1496)
• [#1422] AWS Docs Revamp (#1487)

🧰 Maintenance

• Remove empty payloads (#1509)
• Bump css-loader from 5.2.0 to 5.2.1 (#1514)
• Bump webpack from 5.31.0 to 5.31.2 (#1513)
• Bump eslint from 7.23.0 to 7.24.0 (#1512)
• Move back components to the mono repo (#1506)
• Bump @babel/preset-env from 7.13.12 to 7.13.15 (#1498)
• Bump @babel/core from 7.13.14 to 7.13.15 (#1499)
• Bump eslint-plugin-react from 7.23.1 to 7.23.2 (#1500)
• [#1466] Follow up on extract model (#1493)
• Bump cypress from 7.0.0 to 7.0.1 (#1481)
• [#1466] Extract model lib from httpclient (#1488)
• [#1476] Remove components (#1485)
• Bump core-js from 3.10.0 to 3.10.1 (#1484)
• Bump webpack from 5.30.0 to 5.31.0 (#1483)
• Bump @bazel/typescript from 3.2.3 to 3.3.0 (#1482)
• Bump copy-webpack-plugin from 8.1.0 to 8.1.1 (#1469)
• Bump emoji-mart from 3.0.0 to 3.0.1 (#1507)
• Fix hot module replacement (#1480)

Airy CLI

You can download the Airy CLI for your operating system from the following links:

MacOS
Linux
Windows

This release focused strongly on the Airy Live Chat Plugin and evolving its available features. Suggested Replies became widely useful, especially with the possibility of supporting more types of replies other than simple text. We also gave system users the power to customize their entire Airy Live Chat Plugin, whether it be in regards to text, colors, or icons.

Add More Types of Suggested Replies

Prior to Release 0.16.0, the typing of Suggested Replies only marked text as supported type. However with this release we now support text, images, Rich Cards, and Rich Card Carousels.

Display Lightbulb Icon for Previously Suggested Replies

Suggested Replies were introduced to the Airy Live Chat Plugin with Release 0.14.0. However, in addition to more types of Suggested Replies being rendered, this release also created the option of using Suggested Replies for previous messages as well. Normally, we can show the Suggested Replies on top of the input bar if one of the last 5 messages has Suggested Replies. If none of the last 5 messages contain Suggested Replies, we will only show the lightbulb icon.

The best part of this is: this feature is not limited to a certain amount of messages within a conversation, but rather all messages that contain Suggested Replies are affected. As seen in the image above, a small lightbulb icon appears next to the older message because it is affected. The suggestions above include text, images, and Rich Cards.

Live Chat Plugin Customization Options

This release greatly increased the customization options of your Airy Chat Plugin. In the first few releases, customization was extremely limited.

It is our pleasure to introduce the new customizable aspects of the Chat Plugin, including but not limited to:

• Background color
• Chat Plugin icon (used as the button to open the Chat Plugin)
• Header text (visible on the top of your expanded Airy Chat Plugin)The best part of this feature is that once you have customized your Chat Plugin to your needs and wants, you can copy the code directly from the left hand side into the <head> of your website.

🚀 Features

• [#1111] Customize Chat Plugin (#1456)
• [#1384] Add more types suggested replies (#1420)
• [#1293] Add Prometheus doc (#1448)
• [#1244] Display lightbulb icon for previous… (#1424)

🐛 Bug Fixes

• [#1310] Airy CLI sha changes after the release (#1443)
• [#1452] Show tags in contact info column (#1454)
• [#1455] Configure lucene so queries are case insensitive (#1463)
• [#1304] Wait for core components during create (#1442)
• [#925] Fix examples (#1441)
• [#1413] expand chat plugin by default (#1436)
• [#1450] Fix conversation counter (#1451)

📚 Documentation

• [#1422] Add section for kubectl (#1445)
• [#1406] live chat docs quickstart (#1440)
• [#1404] added intro to sources (#1444)
• [#1439] Update release process with hotfix doc (#1449)
• [#1403] CLI Docs Revamp (#1426)

🧰 Maintenance

• [#1164] Document and improve message upsert endpoint (#1468)
• Readme - now with nice graph-ical improvements (#1377)
• [#1466] Prepare the codebase for lib extraction (#1467)
• Bump cypress from 6.8.0 to 7.0.0 (#1461)
• Bump @typescript-eslint/parser from 4.20.0 to 4.21.0 (#1460)
• Bump @bazel/ibazel from 0.15.6 to 0.15.8 (#1464)
• Bump webpack from 5.28.0 to 5.30.0 (#1459)
• Bump @typescript-eslint/eslint-plugin from 4.20.0 to 4.21.0 (#1462)
• Bump @typescript-eslint/eslint-plugin from 4.19.0 to 4.20.0 (#1446)
• Bump eslint from 7.22.0 to 7.23.0 (#1447)
• Remove Airy init and restructure cli (#1414)
• Bump @typescript-eslint/parser from 4.19.0 to 4.20.0 (#1434)
• Bump core-js from 3.9.1 to 3.10.0 (#1435)
• Bump @bazel/ibazel from 0.14.0 to 0.15.6 (#1433)
• Bump @babel/core from 7.13.10 to 7.13.14 (#1432)
• Bump webpack-cli from 4.5.0 to 4.6.0 (#1431)

Airy CLI

You can download the Airy CLI for your operating system from the following links:

MacOS
Linux
Windows