Kindo Agents

Prev Next

Kindo Agents

Example of an gent to perform analysis red team analysis on a SonicWall firewall system

Example of an agent that automatically performs red team analysis on a firewall

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

Agents in Kindo are unique in that they can understand and utilize natural language when engaging in or executing tasks. For example and agent can read a human-written document and use the information there to inform itself on how it should respond or perform a task in a specific way. Agents can even translate natural language intentions into programmatic action such as API calls.

The ability to read natural language, and the intelligence to determine a response or take action, is derived from generative AI LLMs that a User creating or editing an agent has permissions to use. This is where the term “Agent” in Kindo comes from as an Agent in Kindo is a mechanism to conduct and deploy an operation utilizing generative AI.

It is not necessarily an application or installed binary at the edge, though in future iterations of Kindo we will introduce technology to support such edge workflows.

Types of Agents

Kindo supports three types of agents to perform autonomous and semi-autonomous operations on behalf of a user:

  • 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 it has access to.  An example of a chatbot agent is a helpdesk agent designed to answer questions about the setup process for a new company laptop or management of a development environment.

  • WORKFLOW AGENTS – A workflow agent is an agent designed to conduct a set of operations within a system of record. Like chatbots, workflow agents can utilize natural language resource such as knowledge bases, files, and articles and use the knowledge gained in technical operations. But workflow agents can also resource data from external sources via API call and can call 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 criteria for a trigger is met, data from the event can be used by LLMs within the agent for analysis and decision-making.

Agent Steps

Steps for API requests and sorting vulnerabilities by severity in a system.

Agents are collections of Agent Steps: atomic operations conducted by Kindo on behalf of the User. An agent step can take the form of the following:

  • LLM Step: A step to request a response from a LLM permitted by the user to access. LLM steps are typically requested for the purpose of analysis, sorting information, and using the contents of previous data gathered previously by the agent.

  • Action Step: An operation conducted by the agent to take action. For example, with the API Action Step a user can have the agent make a REST API call to request information or change state in an external system.