Feature request: Support workflow, ai_agent, and ai_agent_tool asset types in integration packages

[jamesagarside]

Summary

Request support in elastic-package for building, validating, and testing three new asset types in integration packages:

1. kibana/workflow/ — Elastic Workflow YAML definitions
2. kibana/ai_agent/ — Agent Builder configurations
3. kibana/ai_agent_tool/ — Custom AI agent tool definitions

Related package-spec Change Proposal: elastic/package-spec#1143

Motivation

Elastic Workflows (Preview, 9.3) and Agent Builder (GA, 9.3) are now core stack capabilities, but integration packages cannot ship either. This forces users to manually recreate automations after installing integrations that depend on post-detection workflows or AI-assisted triage.

Concrete use case

We are building an insider threat detection integration that uses semantic_text fields and ES|QL MATCH queries. The integration needs to ship:

• Detection rules (supported today) — ES|QL rules with semantic MATCH queries
• A scheduled workflow (not supported) — Reads threat exemplar phrases from a user-managed index and generates/updates detection rules, so teams can manage exemplars without editing rule queries
• Custom agent tools (not supported) — ES|QL and search tools for exemplar lookup, user risk scoring, correlated activity queries, and case creation
• An AI agent (not supported) — Triggered by an alert workflow, performs initial triage of insider threat alerts using the custom tools, then writes investigation notes to a Security case

Without support for these asset types, steps 2–4 must be manually configured by every user, significantly reducing the integration's value.

What needs to happen in elastic-package

Build support

• Recognise kibana/workflow/, kibana/ai_agent/, and kibana/ai_agent_tool/ directories during elastic-package build
• Include these assets in the built package archive

Validation support

• Validate workflow YAML against a schema (once defined in package-spec)
• Validate agent and tool JSON against a schema
• Validate dependency ordering: tools must exist before agents that reference them, agents before workflows that invoke them

Test support

• elastic-package test should verify that workflow, agent, and tool assets can be installed into a running Kibana instance
• Verify that workflows can be enabled and triggered
• Verify that agents can be invoked with their configured tools

Proposed asset structure

my_integration/
  kibana/
    workflow/
      <package_name>-<workflow_name>.yml       # Workflow YAML definition
    ai_agent_tool/
      <package_name>-<tool_name>.json          # Custom tool definition
    ai_agent/
      <package_name>-<agent_name>.json         # Agent Builder configuration

Workflow asset contents

Standard Elastic Workflow YAML format with name, description, triggers, steps, consts, and inputs sections.

Agent tool asset contents

{
  "name": "tool-name",
  "description": "Description used by LLM for tool selection",
  "type": "esql_query | elasticsearch_search | workflow | connector",
  "configuration": { },
  "input_schema": { },
  "output_mapping": { }
}

Agent asset contents

{
  "name": "agent-name",
  "description": "Agent description",
  "system_prompt": "Instructions for the agent",
  "tools": ["tool-id-1", "tool-id-2"],
  "knowledge_sources": ["index-pattern-1"],
  "llm_connector_ref": "optional-connector-id"
}

Install ordering

Fleet should install assets in dependency order:

1. Tools (no dependencies)
2. Agents (reference tools)
3. Workflows (may reference agents)

Prior art

Recent asset type additions to the package ecosystem:

• alerting_rule_template (spec 3.5.0)
• slo_template (spec 3.5.6)
• esql_view (spec 3.6.0)

This follows the same pattern of extending the tooling as the stack's capabilities grow.