Skip to content
Kindo Kindo Docs

Creating and Managing Agents

Agents enable Kindo users to automate workflows including security runbooks, SRE playbooks, DevOps procedures, and ITOps response workflows. This guide covers how to create and manage agents.

My Agents

After signing in, select the Agents tab to see your recently used agents and all agents available to you (both your own and shared).

The Agents list view showing recently used agents with options to filter by type

Filter agents by type using the tabs: All Agents, Chatbots, Workflow Agents, or Triggered Agents.

Each agent supports the following actions:

  • Share — Make the agent available to other users in your organization
  • Delete — Permanently remove the agent
  • Edit — Open the agent for modification
  • Run — Launch the agent

Creating an Agent

Select Create an Agent at the top of the Agents window, then choose the agent type: Triggered, Workflow, or Chatbot.

The agent type selection screen with options for Triggered, Workflow, and Chatbot agents

A Triggered Agent runs in response to an external event. Kindo supports two trigger types, chosen from the Add Trigger dropdown when building the agent:

  • Integration Event — Fires when a connected integration (Jira, ServiceNow, Linear, etc.) emits a matching event. Conditions are defined against typed fields from the integration. Requires the integration to be pre-configured.
  • Direct Webhook URL — Generates a unique URL that any external system can POST to. The trigger fires on every request, with optional natural-language gating against the request payload. Use this when no native integration trigger exists, or when you want to invoke an agent from an arbitrary system or script.

A workflow can have one trigger of either type at a time.

Integration Event Triggers

Configure the Integration

  1. Select the gear icon to open Settings.
  2. Navigate to the Integrations tab.
  3. Select an existing integration or click Connect (or New Connection if you already have connections) to add a new one.

The integrations tab showing existing connections and available integrations

Add Trigger Conditions

Use Add Condition to define the trigger event:

Trigger condition configuration with Field, Condition Type, and Target Value fields

  • Field — The field from the integrated application to monitor
  • Condition Type — How to compare the field to the target value
  • Target Value — The value to compare against (supports wildcards * and ?)

Example: Assignee Name EQUALS John

Click Save Condition, add more conditions if needed, then click Save Trigger.

Direct Webhook URL Triggers

A Direct Webhook URL trigger generates a unique, token-protected URL of the form:

https://api.kindo.ai/webhook/agent/<workflowId>/<token>

(Self-Managed deployments substitute their own API hostname.) Any system that can make an outbound HTTP request — Linear, Datadog, GitHub Actions, a cron job, a curl command — can POST JSON to this URL to trigger the agent. The full request body is forwarded as the trigger payload (see Referencing the Payload from Agent Steps below).

Save the Trigger to Mint a URL

In the agent builder, click Add Trigger and choose Direct Webhook URL. The webhook URL is generated only after you save the trigger — saving creates a cryptographically random secret token that is embedded in the URL. The save button reads Create Webhook for a new trigger and Save Changes when editing.

After saving, the Webhook URL field appears with a Copy button. Treat this URL as a secret — anyone holding it can POST to your agent. To rotate the token, delete the trigger and create a new one.

The same URL can be reused across multiple systems.

Run Condition (Optional)

Direct webhook triggers fire on every incoming request by default. To gate execution, supply a natural-language Run Condition in the editor:

When a ticket is created with high priority

When a request arrives, an LLM evaluates the condition against the entire webhook payload and decides whether to continue. If the condition is not satisfied, the agent does not run and no run record is created. The condition is free-form — it can reference event types (create, update), specific fields, or higher-level intent (“only when the ticket mentions a customer outage”). Whatever the integration sends is fair game.

Fail-open behavior. If the condition evaluator itself fails — for example, no model is available, or the underlying LLM call errors — the agent runs anyway. The failure is captured in the Agent Direct Webhook Condition Evaluated audit event’s Error field, so a user troubleshooting “the agent fired despite my condition” can spot it there.

Active Toggle

The trigger has an Active toggle. When inactive, incoming requests are accepted (and return 200) but the agent is not invoked. Use this to pause a webhook without revoking the URL.

How Requests Are Authorized

The endpoint always returns 200, regardless of whether the token validates or the condition is satisfied — this prevents external systems from retrying on rejected requests. When the agent does run, it executes under the workflow creator’s identity — their permissions, org context, and credits. The external caller is not a Kindo user.

Referencing the Payload from Agent Steps

The webhook payload is given to the agent as context for the run, so every step in the agent can see it. Write step prompts as if the payload is already in front of the model — for example, “Summarize the ticket above,” or “If the priority is High, draft an incident response.”

Auditing and Debugging

Two audit-log events back this flow, viewable in Settings → Security → Audit Log:

  • Agent Direct Webhook Condition Evaluated — Recorded for every evaluation. Shows Condition Satisfied (true/false) and Condition Evaluation Reasoning (the LLM’s explanation), plus an Error field when evaluation itself failed. Use this when an agent did or didn’t fire and you need to know why.
  • Agent Direct Webhook Fired — Recorded when a webhook actually triggers a run.

Security Considerations

Direct Webhook URL triggers are intentionally lighter-weight than Integration Event triggers. They have no source-IP allowlisting, no signature verification, and no per-integration security model — anyone with the URL can submit a payload. This is a deliberate trade-off: the trigger works with any system, but it relies on URL secrecy and the natural-language run condition for safety. Prefer Integration Event triggers when a native integration is available; reach for direct webhooks when it is not.

Add Steps

Once the trigger is saved, build the agent by adding steps one at a time using the + button:

Step type dropdown showing LLM Step, Action Step, and API Action Step options

  • LLM Step — Enter a natural language query for the model
  • API Action Step — Perform an action through an API call (including integration-specific actions like adding Jira comments)

For Direct Webhook URL triggers, every step can see the webhook payload as part of the agent’s context — see Referencing the Payload from Agent Steps above.

Click Generate when finished. The agent will begin monitoring for trigger events.

Agent Configuration Panel

Both Triggered and Workflow agents support the Agent Configuration panel for natural language construction:

  • Name — Give the agent a name (auto-generated if blank)
  • Description — Summarize the agent’s purpose (auto-generated if blank)
  • Instructions — Provide context about the agent’s role, response format, and behavior
  • Knowledge Store — Attach files, URLs, or websites as reference material
  • Do It For Me — Describe the desired behavior in plain language and click Generate

Managing Steps

  • To delete a step, open it and click the trash icon.
  • To reorder steps, drag them into the desired sequence.
  • Each step can be assigned a different AI model.

Version History

Kindo automatically captures a version of an agent’s configuration each time it is saved. Versions let you review prior states and roll back to a previous version if a change broke something. The audit log records every restore as an Agent Restored to Previous Version event.

Opening the Version History Panel

From the agent builder, open the Version History panel via the version-history button in the builder header. The panel lists every captured version, newest first, grouped by day — a TODAY group at the top, followed by groups labeled with the date (e.g. 5/12/2026). Each entry shows the time the version was saved and the email of the user who saved it.

The version currently being viewed is marked with a check icon. The most recent saved version represents the agent’s current state.

Read-Only Version Viewer

Selecting a version from the Version History panel opens it in a read-only viewer at:

/agents/builder/<workflowId>/version/<versionNumber>

The viewer renders the agent in a read-only layout with up to four top-level sections: Agent Name, Agent Steps, and Agent Configuration (description, instructions, knowledge store, flags). If the agent has any triggers, an Agent Triggers section also appears. Each step shows its per-step configuration — model, interaction mode, prompt template, tool servers, and static content for LLM Steps; method, endpoint, headers, parameters, body, and abort-on-failure for API Action Steps. Every field is non-editable, and run controls are hidden. A banner at the top identifies the version and offers a Restore this version action.

Opening the version viewer and listing version history both require EDIT_WORKFLOW permission on the agent. Users with VIEWER-only access cannot open the Version History panel or load a historical version.

Restoring a Previous Version

Restore replaces the agent’s current configuration with the selected version’s configuration. After restore:

  • The agent’s live state matches what the version captured.
  • A new version row is written to history with a marker that it was restored from an earlier version. The source-version reference is stored structurally and surfaced in the audit log event, so the restore itself is auditable.
  • The pre-restore state is captured as its own version too (if it wasn’t already the latest), so nothing is lost — a second restore can roll forward again.

Like the version viewer itself, restore requires EDIT_WORKFLOW permission on the agent.

What a Version Captures (and What It Does Not)

A version snapshots the content of an agent — its definition and the resources it depends on by reference. It deliberately does not snapshot sharing, secrets, or live external state.

Captured:

  • Display name, description, system prompt
  • Steps with all per-step configuration:
    • LLM Steps — prompt template, model selection, interaction mode, tool server configs, static content
    • API Action Steps — method, endpoint, headers, query/body parameters, secret references, abort-on-failure flag
  • Inputs (template variables and their settings)
  • Triggers (Integration Event, Cron, Direct Webhook) and their conditions
  • Knowledge Store attachments
  • Dashboard reference, “available as child workflow” flag, demo-mode flag

Intentionally not captured:

  • Sharing and access controls — org role, public role, user permissions, and user-group permissions are not part of version state. Restoring an old version does not change who can see or edit the agent (Google Docs / Notion model).
  • Direct Webhook secret tokens — restore preserves the token on the live trigger row when the row was never deleted, but never re-issues a token.
  • Cron schedules’ live registrations — schedule and timezone are restored, but the underlying scheduler job is de-registered, so a restored cron trigger does not resume firing on its own.

All triggers land inactive after restore. Integration Event, Direct Webhook, and Cron triggers all come back disabled and must be explicitly re-enabled. This always-disable-on-restore policy is intentional: restoring a months-old agent should not silently resume a webhook listener, integration subscription, or cron job whose downstream side effects may no longer be desired.

File Library

Add files to Kindo’s library from two locations:

  1. From Chat — Click the + button in the query bar
  2. When Creating an Agent — Click Add Knowledge Store

Both methods open the File Library where you can select existing files or upload new ones.

The File Library showing uploaded files with checkboxes for selection

Agent Types Reference

Kindo supports five agent types, each designed for different automation patterns:

TypeTriggerBest For
ChatbotUser messageKnowledge base Q&A, helpdesk, conversational interfaces
Manual WorkflowManual runRunbook execution, one-off reports, on-demand analysis
ScheduledCron scheduleRecurring reports, periodic compliance checks, daily summaries
TriggeredExternal eventIncident response, alert triage, ticket automation
DashboardImplicitData visualization, monitoring displays

Choosing an Agent Type

Start with a Chatbot when you need conversational interaction or knowledge base access.

Use a Manual Workflow when you need to perform a sequence of operations on demand, especially when those operations involve API calls or data processing.

Add a Schedule when the same workflow needs to run repeatedly (daily security reports, weekly compliance scans).

Add a Trigger when the workflow should respond to external events. Use an Integration Event trigger for events from a connected integration (new tickets, security alerts), or a Direct Webhook URL trigger when no native integration exists or when an arbitrary system needs to invoke the agent.

Best Practices

As you move from simple agents to production workflows, consult these guides: