CONVA.ai Overview

This gives a quick overview of what CONVA.ai offers and its core concepts

CONVA.ai enables developers to create, maintain, update, and integrate a Copilot into their apps.

It includes 3 core components -

Magic Studio - This is where developers can create, maintain, and update their Copilots.
CONVA.ai SDK - Platform-specific SDKs that offer a simple interface to interact with these Capabilities at runtime and also offer UI components required for building In-App Assistants.
CONVA.ai inference service - The service that runs inside CONVA.ai's cloud that the SDK talks to and does all the AI magic.

Lifecycle of a CONVA.ai developer

The flow of events of a CONVA.ai developer is as follows

Create a Copilot via Magic Studio
Add Capabilities to the Copilot
Publish the Copilot
Integrate the Copilot into the app
Test the Copilot by running the app
If needed, edit the Copilot or the specific Capabilities in Magic Studio and goto Step 3

What is a Copilot?

A Copilot is an AI component that sits inside the app and enables AI-augmented experiences, either via the built-in Conversational Overlay UI or in a headless fashion.

Here are some examples of Copilots that developers can build on top of CONVA.ai.

AI Search Copilot for e-commerce apps that bring AI-powered Search experiences to its consumers, enabling them to find the right product faster and more conveniently.
Navigation Copilot for banking apps that enables customers to easily discover and navigate to the various features offered by the banking app.
Knowledge Copilot for any app that wants users to find answers to their complex queries, which can be about the domain of the app (leveraging the power of the LLM) or something specific to the app (and grounded to the knowledge that the app wants to expose to its users)

While the above are some of the more complex Copilots (and typically exposed to the end-user via the built-in Conversational Overlay UI), developers can also build simpler and localized Copilots too, based on their requirements.

Date Formatter - Takes a string where the date is given in an unstructured and conversational format (say "my date of birth is March 3rd of 2000") and converts it to a structured format ("3/3/2000")
Joke Generator - Takes a topic and generates a joke about it.
String Classifier - Takes an unstructured String and classifies it into one of 10 possible bucket types.

Again, the possibilities are endless about how and where AI augmentation can be applied inside apps.

How to build a Copilot?

The journey of a CONVA.ai developer begins with Magic Studio.

Once u sign up for Magic Studio, you can create a Copilot via the UI in a few simple steps.

The most important step is to create one or more Capabilities that represent the set of tasks that the Copilot can handle.

What is a Capability?

Capability is the foundational unit for a Copilot. Capabilities refer to a specific AI-powered task that the Copilot is supposed to handle. Every Copilot can include one or more Capabilities.

How to create a Capability?

By default, Magic Studio will automatically generate a bunch of Capabilities that are specific to the Copilot being created. Customers can also add more pre-defined Capabilities from the Capability Store or create their custom Capability.

Customers can create Capabilities by just briefly describing the Capability in a couple of lines. Magic Studio will use this outline and generate the actual Capability (which is an internal structure called Capability Config), which can then be edited if required.

Internally a Capability will be converted to low-level prompts (via a multi-agentic system called the Capability Compiler) that finally will be used by an LLM. But all these low-level details are not something that a CONVA.ai developer has to worry about as CONVA.ai abstracts these details from them and lets them focus on their application and the needs of that application, as opposed to worrying about the nuances of the underlying AI system.

Capability Modes

The way apps can consume the Capabilities falls into one of two modes.

Static Mode - Where the developer will specifically invoke a particular Capability at runtime. This is typically used in cases where the developer is triggering an explicit AI functionality at a specific step or page in the app. For example, the developer wants to show a dynamically generated joke every time the user launches an app. Or wants to show a list of recipes whenever the user searches for food items.
Dynamic Mode - Where CONVA.ai will automatically choose the appropriate Capability at runtime. This is typically used in cases where the Copilot is exposed as an In-App Assistant for the end-user to interact with. For example, if the developer is building a Search Copilot (which includes multiple Capabilities like AI-powered Product Search, Navigation Search, and Knowledge Search) and so the response of the Copilot depends on what the user is saying to the Copilot.

Here is a quick example of a code segment to trigger a Capability in dynamic mode and consume it.

// TBD Android Code

conva_client = AsyncConvaAI(
        assistant_id="<COPILOT ID>",
        assistant_version="<version string>",
        api_key="<API KEY>",
)

# dynamic mode 
# The developer is asking CONVA.ai to pick the appropriate Capability from the 
# list of Capabilities in the group called "default" 
response = conva_client.invoke_capability(capability_input="some input query", stream=False, capability_group="default")
async for res in response:
    print(res.model_dump_json(indent=4))
    
# static  mode 
# The developer is asking CONVA.ai to pick a specific Capability and is passing
# the name of it
response = conva_client.invoke_capability(capability_input="some input query", stream=False, capability_name="joke_generator")
async for res in response:
    print(res.model_dump_json(indent=4))

Capability Groups

The way CONVA.ai switches between Static and Dynamic mode is based on whether the developer passes the Capability Group name (aka Dynamic Mode) or the Capability name (aka Static Mode) when invoking CONVA.ai at runtime.

Capability Groups are used to control the list of Capabilities that CONVA.ai will consider when it's in Dynamic mode.

The group that is used, when none is specified, is called "default".

By default, all Capabilities that is created on Magic Studio will get added to the "default" group.

Developers can create their own custom groups and can add/delete Capabilities from it.

# Invoke CONVA.ai with a Group Name (Dynamic Mode)
conva_client.invoke_capability(capability_input="some input query", stream=False, capability_group="default")

# Invoke CONVA.ai with a Capability Name (Static Mode)
conva_client.invoke_capability(capability_input="some input query", stream=False, capability_name="joke_generator")

Parameters of a Capability

The input to the Capability is a String (which needs to be provided by the app in the case of Static Mode and usually by the end-user if it's in Dynamic Mode).

And the output is a JSON that the app can consume.

The output contains some well-defined fields that all Capabilities must adhere to and also some custom fields that are very Capability-specific.

Field	Description	Type
reasoning	The reason behind why the AI system did what it did - why did it pick a particular Capability for a given input, and why did it generate the parameters	String
message	The response message of the Capability generated by the underlying AI system	String
related_queries	The set of related queries to the input String as determined by the underlying AI system	Array of Strings
parameters	The parameters specific to the Capability as defined by the developer of the Capability and generated by the underlying AI system based on the given input	JSON Map

Field

Description

Type

reasoning

The reason behind why the AI system did what it did - why did it pick a particular Capability for a given input, and why did it generate the parameters

String

message

The response message of the Capability generated by the underlying AI system

String

related_queries

The set of related queries to the input String as determined by the underlying AI system

Array of Strings

parameters

The parameters specific to the Capability as defined by the developer of the Capability and generated by the underlying AI system based on the given input

JSON Map

Note that the actual output from the Capability might contain other fields that are internal in nature. Developers are advised to not rely on them as they might change in the future

Capability Knowledge

When building a Capability, sometimes you want to augment it or ground it with specific data.

For example, when building a Capability to answer questions about a company's FAQ, you need to add the FAQ content to the Capability, so that CONVA.ai will refer to it at runtime when answering the users questions.

Or when generating a parameter for a Capability, if you want to limit the parameter to a set of values, you can upload the data source that gives the list of possible values.

Currently CONVA.ai supports two types of knowledge sources

HTML (when you want to ground the entire Capability)
CSV (when you want to ground specific parameters)

Knowledge Grounding Policies

When providing knowledge sources, developers can set one of three Grounding Policies

Strict - This means that CONVA.ai should only rely on the provided knowledge sources when the Capability is invoked.
Best Effort - This means that CONVA.ai should use the knowledge source when possible but also fall back on the underlying LLM's internal knowledge to give the answer.

Now that we have the overview of the key concepts of CONVA.ai, lets jump right in and build a Copilot all the way to integrating it in code.

Let the fun begin!

PreviousAI without the Drama!NextQuick Start Guide

Last updated 15 days ago