Multi-Agent Coordination Patterns

Complex security operations often require multiple specialized agents working together. Kindo supports two broad styles of coordination: direct subagent invocation (a parent agent calls another agent as a tool, in-process) and indirect coordination through external systems and triggers. This guide covers proven patterns for both, with guidance on when each fits.

Why Multiple Agents?

Not every task needs multiple agents. Use multiple agents when:

Different permission levels — Investigation vs. remediation require different access
Human approval gates — Separate analysis from action with human review
Team boundaries — Different teams own different parts of the process
Schedule differences — Continuous monitoring vs. weekly reporting
Separation of concerns — Simpler, more testable individual agents

A single multi-step agent is simpler and preferred when all steps can run with the same permissions, at the same time, without human review.

Pattern 1: Trigger Chaining via Ticketing System

How It Works

Agent A writes a result to a ticketing system (Jira, ServiceNow) → Agent B triggers on that ticket event.

Architecture

[Agent A: Investigate]           [External System]           [Agent B: Remediate]
  Trigger: SIEM alert     →     Creates Jira ticket    →    Triggers on ticket
  LLM: Analyze finding          with structured findings     assignment to "AutoRemediate"
  API Action: Create ticket      in a JSON custom field      LLM: Parse findings
                                                              API Action: Execute fix
                                                              API Action: Update ticket

Step-by-Step Setup

Agent A (Investigate):

Create a triggered agent monitoring SIEM integration
Add LLM step: analyze the alert, classify severity, identify affected systems
Add API Action step: create Jira ticket with findings as structured JSON
Set ticket assignee to a sentinel value (e.g., “auto-remediate-queue”)

Agent B (Remediate):

Create a triggered agent monitoring Jira
Set trigger condition: Assignee = “auto-remediate-queue” AND Priority = “Critical”
Add LLM step: parse the JSON findings from Agent A, determine remediation steps
Add API Action steps: execute remediation (isolate host, rotate credential, etc.)
Add API Action step: update the Jira ticket with remediation report

Optional: Human Approval Gate:

Agent A creates ticket assigned to a human reviewer
Human reviews findings, changes assignee to “auto-remediate-queue”
Agent B triggers only after human approval

Pros

Full audit trail in the ticketing system
Human approval naturally fits between agents
Each agent is independently testable
Works with any ticketing integration

Cons

Latency: depends on ticketing system webhook delivery
Coupling: agents are coupled through ticket field conventions

Pattern 2: Direct Webhook Chaining

How It Works

Agent A makes an API Action call to Agent B’s direct webhook URL.

Step-by-Step Setup

Create Agent B as a Triggered agent with a Direct Webhook URL trigger
- Save the trigger to mint a webhook URL, then copy it
- Optionally set a natural-language Run Condition to gate when Agent B actually fires
Create Agent A as any agent type
- Final API Action step: POST to Agent B’s webhook URL
- Include the structured output from Agent A’s analysis in the POST body — Agent B receives it as the trigger payload
Agent B evaluates the Run Condition (if set) and fires when satisfied

Pros

Fastest coordination pattern (no external system delay)
No external system dependency
Simple to set up

Cons

No built-in approval gate (fully automated)
No persistent record of the handoff (unless agents write logs)
Webhook tokens must be managed securely

When to Use

Fully automated pipelines where speed matters
Internal agent coordination that doesn’t need human oversight
Chaining lightweight processing stages

Pattern 3: Shared External State

How It Works

Multiple agents read from and write to the same external system (Notion database, Google Sheet, Confluence page) on independent schedules.

Example: Security Posture Dashboard

Agent 1 (Vuln Scanner): Scheduled daily, writes vulnerability counts to Notion
Agent 2 (Compliance Checker): Scheduled weekly, writes compliance status to same Notion DB
Agent 3 (Posture Report): Scheduled monthly, reads all data, generates executive summary

Setup

Create a shared Notion database (or Google Sheet) with defined columns
Each agent uses API Actions to read/write its designated columns
Use timestamps and agent IDs to track provenance

Pros

Agents are fully decoupled (don’t know about each other)
Easy to add new agents to the ecosystem
Persistent, human-readable state

Cons

No real-time coordination (schedule-dependent)
Potential race conditions if agents write concurrently
Requires consistent data format conventions

Pattern 4: Manual Handoff with Structured Output

How It Works

Agent A produces structured output → human copies it → human provides it as input to Agent B.

When This Is The Right Choice

Regulatory requirement for human review before action
Low-volume processes (incident-level, not alert-level)
Initial deployment before automating the handoff

How to Set It Up

Agent A: ensure final LLM step outputs well-structured JSON or markdown
Agent B: define an agent input that accepts the output format from Agent A
Human: run Agent A → review output → run Agent B with output as input

Transitioning to Automation

Start with manual handoff to validate the process
Once confident in Agent A’s output quality, switch to Pattern 1 or 2

Pattern 5: Subagent Invocation

How It Works

The parent agent calls another agent as a tool from within its own run. The subagent executes as a separate agent run linked back to the parent — no external trigger, ticket, or webhook is involved, and the parent decides at run time which subagent (if any) to invoke and what to pass it.

To make an agent invokable this way, open its agent builder and turn on Available as subagent in the configuration panel.

Who Can Toggle or Invoke a Subagent

Subagent invocation is a beta capability. Your organization must be enrolled in the beta — until enrollment, the Available as subagent toggle is hidden and parent agents will not discover any subagents.

The same access model gates both flipping the toggle on an agent and invoking it as a subagent from a parent agent. You need Owner access on the agent. You have Owner access if any of the following is true:

You created the agent
You have been granted Owner access on the agent (directly, or via a user group)
The agent’s organization-level role is set to Owner and you are in the same organization
You are an organization admin in the agent’s organization

This means an agent built by one teammate can be exposed and invoked as a subagent by another teammate as long as the second teammate has Owner access. Authorship and ownership are tracked separately — being granted ownership is sufficient.

There is one additional restriction on the agent itself: the toggle cannot be enabled on an agent that has an event or direct-webhook trigger. A scheduled/cron trigger is fine, as is no trigger at all. Agents that react to external events should be exposed via their trigger, as in Pattern 2.

Architecture

[Parent Agent]                                  [Subagent: Investigate]
  LLM: triage SIEM alert                  →     Triggered as a tool call
  → calls investigate_alert(                    Runs as a separate agent run
      hostname: "web-04")                       linked to the parent run
                                                LLM: deep-dive investigation
                                                API Actions: query Splunk, etc.
                                                Returns findings to the parent

Passing Data to a Subagent

Declared inputs — Inputs defined on the subagent become typed parameters the parent agent fills in when invoking it.
Freeform context — The parent agent can also forward a block of freeform text (up to 32,000 characters) alongside the declared inputs, to share any context or inputs it deems appropriate.

Step-by-Step Setup

Subagent (callee):

Build the agent as you would any single-agent setup.
Open the configuration panel and enable Available as subagent.
(Optional) Declare typed inputs for data the parent should pass as structured arguments.

Parent Agent (caller):

Build the agent as you would any single-agent setup.
Eligible subagents — agents marked Available as subagent, with at least one step, that the user running the parent has Owner access to — are automatically discovered and exposed as tools. No manual tool configuration is needed.
For better performance, include explicit instructions in the parent’s system prompt telling the LLM when to call the target subagent and what to pass.

Audit and Visibility

Each subagent invocation creates its own run, linked back to the parent run.
Both the parent and subagent appear in the agent run history with cross-links.
When the parent forwards freeform context, it is shown in a collapsible card above the child run’s first message.

Pros

Lowest latency — no external system in the loop
No ticketing/webhook configuration required
Audit trail in Kindo (parent run ↔ subagent run linkage)

Cons

Both agents run inside the same org and permission scope — not suitable for cross-team boundaries
No built-in human approval gate (parent decides; subagent runs)

When to Use

Investigation/triage handoffs inside a single team
Setups where you want subagent execution audited in Kindo, not in an external ticketing system

Choosing a Pattern

Need	Pattern
Human approval between agents	Trigger Chaining (with approval gate) or Manual Handoff
Fastest automated handoff	Subagent Invocation or Direct Webhook
Agents run on different schedules	Shared External State
Full audit trail	Trigger Chaining (ticketing system) or Subagent Invocation
Simplest setup	Manual Handoff or Subagent Invocation
Maximum decoupling / cross-team boundary	Shared External State

Design Principles for Multi-Agent Systems

Start with one agent, split when needed. Don’t over-architect. Begin with a single multi-step agent and only split into multiple agents when you have clear separation requirements (permissions, schedules, teams).
Use structured output formats. JSON with a defined schema is the lingua franca between agents. Include version fields so you can evolve the format over time.
Make each agent independently testable. You should be able to run Agent B with mock input without needing Agent A. This makes debugging and iteration much faster.
Log everything. Each agent should record what it received, what it decided, and what it did — in the ticketing system or external store, not just in Kindo Terminal.
Plan for failure. What happens if Agent B fails? Design agents to be idempotent when possible (running twice produces the same result as running once).

Limitations

Kindo does not provide a built-in orchestration layer for fan-out, retries, or scheduling across multiple agents. Patterns 1–4 use external systems for that coordination; Pattern 5 keeps the handoff in-process but still leaves orchestration to the parent agent’s LLM.

There is no built-in human-approval gate for Pattern 5 — the parent agent’s LLM decides when to invoke a subagent. If you need a human in the loop between agents, use Pattern 1 with an approval-queue assignee or Pattern 4 (Manual Handoff).

These are architectural constraints of the current platform, not fundamental design decisions.