Skip to content
Kindo Kindo Docs

Agents

Agents perform routines and processes on behalf of users, either autonomously or semi-autonomously. These routines correspond to Kindo’s use cases and frequently take the form of DevSecOps playbooks, runbooks, ITOps routines, or standard operating procedures.

A workflow agent configured for red team analysis on a SonicWall firewall, showing API request and LLM steps

Kindo agents are unique in that they can understand and utilize natural language when executing tasks. An agent can read a human-written document and use that information to inform its behavior, and can translate natural language intentions into programmatic actions such as API calls.

Types of Agents

Kindo supports three types of agents:

Chatbots

A chatbot is an agent designed to respond to users with information gathered from its AI model and a set of knowledge base data.

Example: 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. Additionally, workflow agents can source data from external sources via API calls and employ external tools to perform actions.

Example: An agent designed to manage and deploy a development 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.

Example: An agent that performs first-order root cause analysis for a platform engineering incident.

Agent Steps

Agents are collections of Agent Steps: atomic operations conducted by Kindo on behalf of the user.

Agent steps showing API requests and an LLM step for sorting vulnerabilities by severity

LLM Step

A step that requests a response from a permitted LLM. LLM steps are typically used for analysis, sorting information, and processing data gathered by previous steps.

Action Step

An operation where the agent takes action. For example, adding a comment to a ticket, changing ticket priority, or reassigning a ticket in an integrated system.

API Action Step

An operation where the agent makes a REST API call to request information or change state in an external system. API requests can be manually configured or generated from a natural language prompt.

Next Steps