How does Kubiya work?

In this document you can read:

• How Kubiya classifies actions
• How Kubiya triggers actions
• How to customize Kubiya to your needs

How Kubiya classifies actions

When a user sends a message, we take this message through a classification process.

Classification is a common practice in large language models, especially when you want to create multi term conversations since they can ask for all kinds of stuff. The classification in our case is responsible to classify the incoming user query to one of one of two paths.

• Query - A user is asking a question and this question results in a query against a cloud resource or multiple cloud resources.

• Action - A user wants to trigger an action such as creating a deployment, updating a config file, making a pull requisition, triggering a job etc. 

How Kubiya triggers actions

Actions agent

We use an action agent which is responsible for understanding the user context in order to determine the relevant action that the virtual assistant should execute. In order to execute this action of course, there are some parameters that need to be collected from the user.

It is the responsibility of the actions agent to identify the required parameters and collect them from the user, possibly allowing the user to context switch to get context that maybe doesn't have. We use actions, which are pedantic models giving the user inputs on the required parameters.

For example if a user wants to restart a Kubernetes deployment, the agent identifies that it needs additional parameters such as the namespace and the deployment name. For the deployment name, maybe the user needs a list of deployment in a given namespace hence he needs to context switch to find the right deployment.

In summary the action agent is also responsible for this kind of user questions and dialogues.

Enforcer agent

Once the action agent has all of the required parameters in order to execute the action, it needs to confirm if the specified user has the relevant permissions in order to do so.

Kubiya gives the ability to define access control policies by users and groups.

The enforcer agent is responsible to confirm prior to executing an action, if the user has the permission to actually execute the action that he wanted to.

Once confirmed, we can now go ahead and query the relevant cloud provider or even execute an action.

Output agent

Finally, it is the responsibility of the output agent to convert any raw output, which might be in a long JSON, raw text or some other format, into something which is human readable.

How to customize Kubiya to your needs

Kubiya provides an SDK. Using this SDK, organizations can transform simple actions, or functions, into intelligent conversations that you can have with Kubiya. Kubiya’s Action agent is able to collect all of the relevant context in order to execute this action.

Kubiya uses pedantic models. The function gets a model as an input and based on the model, the AI is able to understand and query for the relevant parameters. These parameters can be optional strings, or of the specified types in the programming language. Default values or close options can be defined.

Below is an example of of the pull request action:

For more information about action stores click here.

For more information about the usage of LLMs, embeddings and pre-trained models - Click here.

Ready to give Kubiya a try - Signup here.

‍