Concepts and Terminology
This is a glossary of concepts and terminology used whenever referring the Kindo platform.
Generative AI Model
A Generative AI Model is a broad term for any ML model that the Kindo platform supports and used as part of a request. Kindo platform functionality today is dominated by LLMs, but other types of models include:
Embeddings Models
These models "tokenize" content into numeric vectors that represent the semantic meaning of the content. Used today for knowledge retrieval across files and large contexts.
Multi-modal Models
These models work with a set of different content types, such as text, audio, images, video, and more. Models are typically constrained to a few types of content.
Future Models
These refer to model types that are not yet supported within Kindo. We will support these formats in the future.
Audio Models: These models specialize in audio related tasks, such as Text to Speech (typically converting written text to a single-speaker narrated voice track), Speech to Text (transcribing single or multi speaker audio feeds, sometimes with diarization). Other tasks include Voice Cloning, which takes in audio and outputs model weights or adapters to use in future text to speech inference. On the frontier are "general purpose" audio models like Suno Bark and DeepMind AudioLM that work with the full spectrum of sound: multiple speakers, non-verbal sounds like laughter or sighing, higher expressiveness, sound effects, and even music. Kindo's underlying system LiteLLM supports some Audio model tasks today.
Image and Video Models: These models specialize in understanding visual media and generation of new visuals. For DevSecOps, useful visual tasks may include parsing images in documents and screenshots, or captioning imagery. As visual generation improves and language transformer layers are added to more diffusion models, we may be able to generate diagrams and other structured information into visuals. Outside of commercial APIs, visual models are typically very specialized and deployed in complex arrangements to achieve diverse goals - see ComfyUI workflows.
VLMs/Computer/Browser Use Models: Models that specialize in understanding images with text will become increasingly important as benchmarks improve for models that navigate GUIs. These models are typically structured as "image-text-to-text", where a screenshot and text are provided to the model, and the model responds with text. A software harness provides the screenshot and text input, and interprets the text output, to autonomously act on a GUI.
Other: A wide variety of models will continue to proliferate as AI permeates general computing, from physical robots to biology. A helpful list of mature task types can be seen on Hugging Face: https://huggingface.co/tasks
Large Language Model (LLM)
This is the collection of User LLMs selectable by a Kindo User. Because Worker LLMs are invisible to users, we commonly refer to these as simply “Models” within the product.
A Large Language Model (LLM) is the fundamental AI model used as part of a request. Examples include: OpenAI o1, Anthropic’s Claude family, and Deepseek R1.
LLMs used within Kindo are typically one of two types:
Worker LLM: This refers to the LLM used within Kindo to manage internal, non-user operations. In Kindo SaaS this is LLama.
User LLM: This refers to the LLM that Kindo users or Agents managed by Kindo users make requests to when operating Kindo. Within Kindo’s user views these are referred to as “Models.”
Self-Managed Model
A Self-Managed Model refers to a generative AI model that Eve (our security/infrasturcutre admin personae) manages herself and configures for Kindo’s use. Eve may have trained and is self-hosting model(s), and/or has configured cloud or on-prem deployments of existing models, like Anthropic models in their AWS Bedrock in GovCloud.
Currently Self-Managed Models only exist as User LLMs. In the future, Self-Managed Models will also be configurable to operate as Worker LLMs.
Kindo Terminal
The Kindo Terminal is the primary user view within Kindo. At the Terminal, a Kindo User makes requests to a User LLM, either directly through a Chat or after the execution of an Agent Run.
Chat
On the left of the Kindo UI are a collection of Chats. A Chat is a collection of requests from a Kindo User to User LLMs through the Kindo Terminal without an Agent. Chats are divided by Memory, enabling the user to communicate with a set of User LLMs with different historical contexts.
Agent
An Agent is a Kindo-managed automation that executes a series of steps or sequential, atomic operations. There are several types of agents.
CHATBOTS – A chatbot is an agent that is designed to respond to human beings with information gathered from its AI model and a set of knowledge base data.
An example of a chatbot is a helpdesk agent that answers questions about the setup process for a new company laptop, or management of a development environment.
WORKFLOW AGENTS – A workflow agent conducts a set of operations within a system of record. Like chatbots, workflow agents can utilize natural language resources such as knowledge bases, files, and articles, and use the knowledge gained in their technical operations. Workflow agents can also source their data from external sources via an API call and can employ external tools and APIs to perform actions.
An example of a workflow agent is an agent designed to manage and deploy a dev infrastructure on a cloud platform.
TRIGGER AGENTS – A trigger agent is a special type of workflow agent that lies dormant while waiting for a specified event to occur, such as a new entry in a ticketing system, before launching a response. When the trigger event is detected, data from the event can be used by LLMs within the agent for analysis and decision-making.
Memory
Memory refers to the historical collection of LLM responses that come from a Kindo User preforming requests. These requests can come from an Agent, a Triggered Agent, a Chatbot, or a Public API interaction between Kindo, the user, and a User LLM. With Memory, a Kindo User can mix and match User LLM responses and enable requests to utilize output from previous responses.
Chats and all types of Agents hold memory. However, some interactions with Kindo may not (e.g. API Calls).
Run
A run is an instance of interaction between a Kindo User and a User LLM that is brokered by Kindo. Runs are the results of communications between a Kindo User and a User LLM through Chats, Agents, Triggered Agents, and Public API calls.
Because Agents/Triggered Agents may have multiple responses within a single run, we describe runs with two types of responses:
Agent Runs: This is the final output of the last LLM Step.
Step Run: This is the individual response of a single LLM Step within an Agent/Triggered Agent.
Users browse Run History to view past interactions with AI on the Kindo Platform.
Kindo API
The Kindo API is the set of REST API endpoints exposed by the Kindo product to Users. There are two types of APIs exposed by Kindo:
Inference API: This is an individual request to a User LLM with no memory.
Agent API: This is a call that results in the output of an Agent Run for a non-Trigger Agent.
For more information on the Kindo API see here.
Target
The target is the output location of an Agent Run or a Step Run(s).
Targets typically refer to the Kindo Terminal, but through Agent Action Steps and the Public API they, can also refer to a ticketing system (e.g. updating a GitHub PR with a comment with the result of a previous LLM Step), an API request, and much more.
Resource
A structured data entity provided by an Integration. Examples include Tickets, Users, Emails, Logs, Metrics, etc.
File
A file that's a part of the Kindo Platform. Files can be uploaded by users, provided by Integrations, or generated by AI Models.
Secret
A sensitive text blob that can be consumed on the Kindo Platform. While a secret is generic, they typically represent API keys, Access Tokens, or environment variables. Secrets are stored in Kindo in the Secrets Vault.
Infrastructure Terminology
This terminology refers to the infrastructure that allows Kindo to run. Some of the terminology is specific to Eve (our security/infrasturcutre admin personae) or only particular product offerings of Kindo (e.g. Environments within Self-Managed Kindo).
Integration
A system external to Kindo that connects to enable receipt of a data flow, and actions to flow out. For example, the Linear ticketing system is an integration that provides Resources to the Kindo platform, and enables actions to be taken from Kindo into Linear, such as adding a Comment to a Ticket.
Environment (Self-Managed Only)
This refers to the deployment platform Eve (our security/infrasturcutre admin personae) runs her Helm Chart on. Examples include cloud-based managed Kubernetes services (e.g. Azure Kubernetes Service or AKS, Amazon Elastic Kubernetes Service or EKS), bare metal Kubernetes, or on-prem/hybrid managed platforms such as RedHat OpenShift or Rancher.
State Database (State DB)
This refers to the backend relational database that holds Kindo’s state for users, operations, chats, etc. Kindo SaaS uses Planetscale for its State DB.
Vector Database (Vector DB)
This refers to the vector database that Kindo’s models use to implement RAG. Kindo SaaS uses PineconeDB for its RAG DB.
Authentication Backend (Auth Backend)
This refers to the component backend that Kindo uses to manage enterprise Single Sign On (SSO) and authentication. Kindo SaaS uses WorkOS for its Authentication Platform. In future versions of Self-Managed Kindo, we’ll use an internally-managed variant that does not require an enterprise license we’ll refer to as “Integrated.”
Sync Backend
This refers to the component that enables Kindo to communicate and sync with a customer’s set of ticketing, cloud storage, and other SaaS stateful services. Kindo SaaS uses Merge for its Sync Platform. In future versions of Self-Managed Kindo, we’ll use an internally-managed variant that does not require an enterprise license we’ll refer to as “Integrated.”
Log Backend
This refers to the location that Kindo’s audit log is streamed to. At the launch of Self-Managed Kindo’s MVP, this is a Syslog server.
Product Offerings
Kindo SaaS
Kindo SaaS is the product that exists as a service managed by Kindo.
Self-Managed Kindo
Self-Managed Kindo is deployed by Admins into an environment they control, such as a public cloud, hybrid cloud, on-prem, etc.