The 9.3 Tech Preview introduced the foundation for native automation in Elastic. 9.4 brings it to general availability with production stability and significantly expanded capabilities. Case management gets 25 dedicated automation steps covering the full lifecycle. Human-in-the-loop becomes a first-class Workflow primitive. Natural language authoring moves to Tech Preview. The platform gains more flow-control primitives (while, switch, iteration control), data-transformation steps for working with collections, deeper AI integration with Agent Builder, and broader event-driven triggers. Production-ready automation across Elastic.

Case automation at scale

The biggest addition for security teams is case management. In the Tech Preview, working with cases involved four generic steps: creating, retrieving, updating, and commenting. Anything beyond that required raw API calls.

Now there are 25 dedicated cases.* steps covering the full lifecycle: create, find, find similar, update, close, assign, unassign, add alerts, add observables, add comments, add tags, set severity, set status, and more. Each step is typed, validated, and appears in the YAML editor's autocomplete, which means natural-language authoring can generate them accurately, too.

Here's what a realistic triage workflow looks like. An alert fires. The Workflow checks whether a case already exists for this alert. If not, it creates one, attaches the alert and observables, assigns the on-call analyst, and routes severity based on risk score:

The code below shows an example of a workflow described using YAML:

name: Triage Workflow
enabled: true
triggers:
  - type: alert

steps:
  - name: check_existing
    type: cases.getCasesByAlertId
    with:
      alert_id: "{{ event.alerts[0]._id }}"

  - name: route
    type: if
    condition: "steps.check_existing.output : ''"
    steps:
      - name: update_existing
        type: cases.addComment
        with:
          case_id: "{{ steps.check_existing.output[0].id }}"
          comment: |
            Correlated alert: {{ event.rule.name }}
            Source: {{ event.alerts[0].source.ip | default: "unknown" }}
            Risk score: {{ event.alerts[0].kibana.alert.risk_score }}
    else:
      - name: create_case
        type: cases.createCase
        with:
          owner: securitySolution
          title: "{{ event.rule.name }} - {{ event.alerts[0].host.name }}"
          description: |
            Auto-created from detection rule: {{ event.rule.name }}
            Host: {{ event.alerts[0].host.name }}
            Source IP: {{ event.alerts[0].source.ip | default: "N/A" }}
          severity: high
          tags:
            - auto-triage
            - "{{ event.rule.name }}"

      - name: attach_evidence
        type: cases.addAlerts
        with:
          case_id: "{{steps.create_case.output.case.id}}"
          alerts:
            - alertId: "{{ event.alerts[0]._id }}"
              index: "{{ event.alerts[0]._index }}"

      - name: add_observables
        type: cases.addObservables
        with:
          case_id: "{{steps.create_case.output.case.id}}"
          observables:
            - typeKey: observable-type-ipv4
              value: "{{ event.alerts[0].source.ip }}"
            - typeKey: observable-type-file-hash
              value: "{{ event.alerts[0].file.hash.sha256 }}"
        on-failure:
          continue: true

The Workflow automatically handles deduplication, evidence attachment, observable enrichment, graceful handling of missing fields, and analyst assignment. The analyst opens Kibana and sees a case with all the context already there.

The 25 new cases.* steps include create, find, find similar, update, close, delete, assign, unassign, add/remove alerts, add/remove observables, add/update/delete comments, add/remove tags, set severity, set status, get by ID, get by alert ID, and more for custom fields, user actions, and metrics. Each step is typed and validated. If you're using natural language authoring, the AI can generate them accurately because they're part of the schema.

As Workflows mature, you'll see more domain-specific steps for detection rule management, endpoint response actions, and threat intelligence operations.

Human checkpoints in automated Workflows

Case automation handles the mechanical work, but not every decision should be fully automated. AI can classify an alert and gather context, but the analyst should decide whether to escalate. The question is how much mechanical work happens before they make that call.

waitForInput pauses a Workflow for human judgment. The Workflow runs the investigation, gathers evidence, classifies the alert with AI, and stops. It presents structured findings and waits. The analyst reviews, approves or redirects, and adds notes, and then the Workflow resumes based on their input.

As the following image shows, the automation handles the investigation, but the analyst makes the decision before the automation executes it.

Classifies incoming alerts with AI, pauses for analyst review and approval, and only escalates approved cases by creating a high-severity incident with context from both the model and the analyst.

name: HITL Example
enabled: true
triggers:
  - type: alert

steps:
  - name: classify
    type: ai.classify
    connector-id: Anthropic-Claude-Sonnet-4-6
    with:
      includeRationale: true
      input: ${{ event.alerts[0] }}
      categories:
        - true_positive
        - false_positive
        - needs_investigation

  - name: approval_gate
    type: waitForInput
    with:
      message: |
        Alert: {{ event.rule.name }}
        Classification: {{ steps.classify.output.category }}
        Rationale: {{ steps.classify.output.rationale }}
        Review the classification and approve to escalate.
      schema:
        type: object
        properties:
          approved:
            type: boolean
            title: Approve escalation
          notes:
            type: string
            title: Analyst notes
        required:
          - approved

  - name: escalate
    type: if
    condition: "steps.approval_gate.output.approved : true"
    steps:
      - name: create_escalated_case
        type: cases.createCase
        with:
          owner: securitySolution
          title: "[Escalated] {{ event.rule.name }}"
          description: |
            Escalated by analyst after AI classification.
            Classification: {{ steps.classify.output.category }}
            Notes: {{ steps.approval_gate.output.notes }}
          severity: high
          tags:
            - escalated
            - analyst-reviewed

Today, waitForInput works through the Kibana execution view and the REST API. Slack, Teams, and email delivery channels are coming so analysts can review and approve without switching context. This is especially important for workflows defined as tools in Agent Builder, where agent-driven investigations benefit from human checkpoints before taking action.

Building Workflows from natural language

With the automation patterns in place, the next challenge is making them accessible. We chose YAML as the Workflow language because it's declarative, reviewable, and portable. But it was also a strategic choice: YAML is structured text, and large language models are very good at generating structured text. A well-typed workflow schema is an ideal target for AI-powered authoring. In 9.4, that bet pays off. Natural language authoring is available in Tech Preview.

Inside the Workflow editor, describe what should happen: "When a malware alert fires, check the file hash against VirusTotal, create a high-severity case, attach the alert and observables, and notify the SOC channel." The AI assistant generates the YAML. You review, refine, and deploy.

The YAML is fully inspectable and editable. If you know what should happen but aren't a YAML expert, this gets you from intent to a working workflow. If you are a YAML expert, you can start in natural language and refine in the editor.

The authoring experience will keep evolving. Visual editing is a complementary mode. Authoring that extends into Slack and other tools your team uses. The goal is to meet security teams wherever they work.

Composable Workflows

As your automation library grows, organization becomes critical. Security automation gets complex fast. You start with a single triage workflow, then realize different alert types need different investigation steps. You add conditionals, then more conditionals, and suddenly your workflow is hundreds of lines with nested logic that's hard to follow and harder to change.

workflow.execute lets you build reusable workflows with typed inputs and outputs. Instead of embedding all your investigation logic in one place, you create focused workflows for specific scenarios and compose them together. Update your malware investigation workflow once, and every workflow that calls it benefits. The logic stays organized, changes stay contained, and your automation scales without becoming brittle.

Here's what this looks like in practice. Classify the alert, then route to the specialized workflow based on the threat type:

steps:
  - name: dispatch
    type: switch
    expression: "{{ steps.classify.output.category }}"
    cases:
      - match: malware
        steps:
          - name: run_malware
            type: workflow.execute
            with:
              workflow-id: ${{ consts.malware_workflow_id }}
              inputs:
                alert: ${{ event.alerts[0] }}
      - match: phishing
        steps:
          - name: run_phishing
            type: workflow.execute
            with:
              workflow-id: ${{ consts.phishing_workflow_id }}
              inputs:
                alert: ${{ event.alerts[0] }}
    default:
      - name: run_generic
        type: workflow.execute
        with:
          workflow-id: ${{ consts.generic_triage_id }}
          inputs:
            alert: ${{ event.alerts[0] }}

Each workflow is independently testable. Most teams start with a single workflow and extract sub-workflows as patterns emerge. Composition is something you grow into.

The template library will eventually move into the product so you can discover and install pre-built workflows directly in Kibana.

Where analysts already work

Workflows are most useful when they're available where decisions get made. The primitives and patterns are in place, but automation only delivers value if analysts can reach it without switching tools. We're investing in making Workflows accessible throughout the security analyst experience, starting with the alerts table and Attack Discovery. Analysts can send alerts or entire attacks directly to a Workflow, triggering the investigation logic they've built without leaving their current context. This integration will continue expanding so that Workflow automation becomes a seamless part of the analyst's daily work, not a separate destination.

"Run workflow" in the alerts table lets you right-click an alert (or select multiple) and trigger a Workflow directly. The alert context passes automatically.

This is the beginning. Workflows will continue expanding into more parts of the security experience, making automation accessible where analysts need it.

More control, more flexibility

Beyond the major features, the Workflow language itself has become more capable. New flow control primitives give you cleaner ways to handle complex logic. while loops let you poll for conditions or wait for external state changes. switch provides multi-way branching so you can route alerts by category without nested conditionals. loop.break and loop.continue give you standard iteration control.

Step-level data transformation steps handle filtering, finding, aggregating, and JSON operations on collections, so you can process alert lists, IOC lookups, and enrichment responses without custom scripting.

The AI steps (ai.prompt, ai.classify, ai.summarize, ai.agent) are more stable and now support structured outputs, making it easier to use AI-generated classifications and summaries in downstream workflow logic.

LiquidJS templating expanded too. You can now set variables and access them throughout the workflow, making it easier to reference computed values across multiple steps.

Reliability and production controls

All of this is useful only if it's reliable. Every step supports on-failure configuration: retry for transient failures, continue when a step isn't critical, and abort when downstream steps depend on the result. Error details are available at steps.<step-id>.error to help route around failures.

Concurrency controls prevent alert storms from spawning hundreds of parallel executions. Loop guardrails prevent runaway execution. Composition depth limits prevent infinite recursion.

Elastic 9.4 introduces event-driven triggers, starting with workflows.failed. When a workflow execution fails, it can trigger a separate handler workflow. Build a notification workflow that alerts your team when automation goes down. More trigger types are coming: case status changes, alert state transitions, and detection rule updates, making Workflows reactive to what's happening across your security environment.

Every execution is recorded in execution history with step-by-step results, including analyst decisions from waitForInput steps. This is your debugging tool and your audit trail.

Workflows is enabled by default in 9.4 with an Enterprise license. Granular RBAC controls who creates, edits, executes, and views workflows. Every management operation writes to the security audit log. Import/export moves Workflows between environments with connector references intact.

Licensing and pricing

Workflows is available with an Enterprise license on Elastic Cloud Hosted and self-managed deployments, and with the Complete tier on Elastic Cloud Serverless for Security projects.

Version 9.4 introduces a unified execution-based pricing model across all deployment types.

Across Serverless, Elastic Cloud Hosted, and self-managed, pricing is based on workflow executions, with volume-based discounts at scale. Each month includes a baseline allocation of workflow executions that are not billed. Usage beyond this allocation is billed per execution, with volume-based discounts applied as usage increases.

Elastic Cloud Serverless begins applying this model on May 1, 2026. Usage beyond the monthly non-billed executions is charged per execution, with discounts at higher volumes. See full pricing details.

Elastic Cloud Hosted and self-managed deployments follow the same pricing model, but are currently in a promotional period with execution charges not yet applied. This allows teams to build and run Workflows, establish usage patterns, and prepare for the transition to execution-based billing in a future release.

Start building now. The Workflows you create today will continue to run as pricing transitions to the unified model.

Getting started

Workflows are enabled by default in 9.4. Open Kibana, navigate to Workflows, and start building.

If you're new to Workflows, the Tech Preview post walks through building your first triage Workflow. The Chrysalis APT workflow shows Agent Builder integration in action. The documentation has the complete step type reference. The Elastic Workflow Library has ready-to-use templates.

Start with the Workflow that would save your team the most time this week. If you can describe it, you can build it.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.

An alert fires. You open it. You read through the details. You gather context from the surrounding activity. You check for related signals across your environment. You decide what it means and what to do next. Sometimes you escalate. Sometimes you close it and move on.

You do this dozens of times a day. The steps are almost always the same. The data you need is already in your SIEM. The actions you take are predictable. But the work is still manual.

This is the kind of work that automation should handle. Not because it's hard, but because it's repetitive, and every minute spent on repetitive manual triage is a minute not spent on the alerts that actually need a human.

Elastic Workflows brings that automation into the SIEM itself. No separate tool. No integration to build. Your detection rule fires, and a workflow runs, with direct access to your alerts, cases, and security data.

This blog post walks through building a security playbook with Workflows, step by step. We'll start simple and build up to a workflow that runs when an alert fires, checks threat intel, gathers context, creates cases, notifies the team, and brings in AI when the investigation calls for it.

If you're new to Workflows, the introductory technical deep dive blog and video cover the core concepts of Workflows. This post focuses on applying these concepts in a security context.

Quick orientation

Workflows are YAML definitions that run inside Kibana. You define what should happen, and the platform handles execution. At a high level, a workflow is composed of three main parts: triggers (when it runs), steps (what it does), and data flow (how information moves between steps).

Triggers decide when the workflow runs. An alert trigger runs on a detection. A scheduled trigger runs on a cadence. A manual trigger runs on demand. A workflow can have more than one.

Steps define what the workflow does. They run in order and can use outputs from earlier steps. They can query data in Elasticsearch, update alerts and cases in Kibana, and call external systems like sending a Slack message or scanning a hash on VirusTotal. They can also apply logic such as conditionals or loops, and use AI for tasks like summarizing text, prompting an LLM, or invoking agents when deeper reasoning is needed.

This is the toolkit. With these primitives, you can build workflows that take a signal, gather context, and drive a response.

Building a security playbook

We'll build an alert triage workflow incrementally. Each section adds a capability, and by the end, you'll have a working playbook that handles the full triage loop.

Start with the trigger

Security workflows start with an event. It could be an alert, a case update, a user action, or a scheduled check. The workflow takes that signal, gathers context, and decides what to do next.

We’ll start with alert triage. It’s the most common path, and it shows the full loop end to end. Each section adds a capability, and by the end, you’ll have a working playbook.

Here’s a minimal workflow with an alert trigger:

name: Alert Triage Playbook
description: Enriches alerts, checks threat intel, creates a case, and notifies the team.
enabled: true
tags:
  - security
  - triage

triggers:
  - type: alert

steps:
  # we'll build these out

The alert trigger connects this workflow to detection rules. You link a specific rule to this workflow from the rule's Actions settings in Kibana. When the rule fires, the workflow runs and receives the full alert context through the event variable. That includes event.alerts (the alert documents), event.rule (the rule metadata), and every field on the alert.

From here, you start adding steps.

Check threat intel

The first real step: take the file hash from the alert and check it against VirusTotal. Workflows have a built-in VirusTotal connector, so you don't need to construct HTTP requests or manage API keys in your YAML (connector credentials like VirusTotal API keys or Slack tokens are configured once in the connector under Stack Management > Connectors):

  - name: check_virustotal
    type: virustotal.scanFileHash
    connector-id: "my-virustotal"
    with:
      hash: "{{ event.alerts[0].file.hash.sha256 }}"
    on-failure:
      retry:
        max-attempts: 2
        delay: 3s
      continue: true

Every step in a workflow follows a simple, consistent structure. It starts with a name, which gives the step a clear identity, and a type, which defines the action being performed. In this case, the step calls the VirusTotal file hash scan capability. Because this is a connector-backed action, it also includes a connector-id, which tells the workflow which configured integration to use, including its credentials.

The with block is where you pass inputs into the step. Each step type defines the parameters it accepts. Here, you provide the file hash to scan. Rather than hardcoding values, workflows use a built-in templating engine powered by LiquidJS. The {{ }} syntax lets you reference data from the execution context, so the hash is pulled directly from the alert that triggered the workflow.

Finally, the on-failure block defines how the step behaves if something goes wrong. In this case, it retries twice with a short delay and continues execution even if the lookup fails. This is important in production workflows, where a transient external API issue should not block the entire triage process.

Gather context with ES|QL

Next, query for related alerts on the same host. ES|QL runs directly against your security indices, so there's no API bridging or credential management:

  - name: related_alerts
    type: elasticsearch.esql.query
    with:
      query: |
        FROM .alerts-security*
        | WHERE host.name == "{{ event.alerts[0].host.name }}"
        | WHERE @timestamp > NOW() - 24 hours
        | STATS
            alert_count = COUNT(*),
            rules_triggered = VALUES(kibana.alert.rule.name),
            users_involved = VALUES(user.name)
      format: json

This tells you whether the host has been generating other alerts, which rules triggered, and which users were involved. That context is included in the case description and informs the severity assessment later.

The same approach works for any enrichment that touches data in Elasticsearch: looking up a user's first-seen date, checking how many times a hash has appeared in your logs, or pulling the process tree from endpoint data. If the data is in your cluster, ES|QL can get it.

Branch on findings

Now the workflow needs to decide what to do. If VirusTotal flagged the file as malicious, create a case and respond. If not, close the alert as a false positive:

  - name: check_malicious
    type: if
    condition: steps.check_virustotal.output.stats.malicious > 5
    steps:
      # true positive path: steps below
    else:
      - name: close_false_positive
        type: kibana.SetAlertsStatus
        with:
          status: closed
          reason: false_positive
          signal_ids:
            - "{{ event.alerts[0]._id }}"

The if step evaluates a condition and runs different steps depending on the result. The false positive path closes the alert in a single step. The true positive path continues below.

Create a case

When the alert is confirmed malicious, open a case with context from previous steps:

      - name: create_case
        type: kibana.createCase
        with:
          title: "Malware Detected: {{ event.alerts[0].file.hash.sha256 }}"
          description: |
            Confirmed malicious file detected on {{ event.alerts[0].host.name }}.

            **Detection:** {{ event.rule.name }}
            **User:** {{ event.alerts[0].user.name }}
            **VirusTotal:** {{ steps.check_virustotal.output.stats.malicious }} engines flagged this file
            **Related alerts (24h):** {{ steps.related_alerts.output.values[0][0] }} 
              alerts from {{ steps.related_alerts.output.values[0][1] | size }} rules
          owner: securitySolution
          severity: high
          tags:
            - automation
            - malware
          settings:
            syncAlerts: false
          connector:
            id: none
            name: none
            type: ".none"
            fields: null

Liquid templating pulls data from the alert (event), from the VirusTotal results (steps.check_virustotal.output), and from the ES|QL query (steps.related_alerts.output). Every field from every previous step is available to every subsequent step.

Notify the team

Send a Slack message so the team knows a confirmed case is open:

      - name: notify_team
        type: slack
        connector-id: "security-alerts"
        with:
          message: |
            Malware confirmed on {{ event.alerts[0].host.name }}.
            VirusTotal: {{ steps.check_virustotal.output.stats.malicious }} detections.
            Case created: {{ steps.create_case.output.id }}

Slack is one option. Jira, ServiceNow, PagerDuty, Microsoft Teams, email, and Opsgenie are all supported as connector steps.

The complete workflow

Here's the full workflow assembled:

name: Alert Triage Playbook
description: Enriches alerts, checks threat intel, creates a case, and notifies the team.
enabled: true
tags:
  - security
  - triage

triggers:
  - type: alert

steps:
  - name: check_virustotal
    type: virustotal.scanFileHash
    connector-id: "my-virustotal"
    with:
      hash: "{{ event.alerts[0].file.hash.sha256 }}"
    on-failure:
      retry:
        max-attempts: 2
        delay: 3s
      continue: true

  - name: related_alerts
    type: elasticsearch.esql.query
    with:
      query: |
        FROM .alerts-security*
        | WHERE host.name == "{{ event.alerts[0].host.name }}"
        | WHERE @timestamp > NOW() - 24 hours
        | STATS
            alert_count = COUNT(*),
            rules_triggered = VALUES(kibana.alert.rule.name),
            users_involved = VALUES(user.name)
      format: json

  - name: check_malicious
    type: if
    condition: steps.check_virustotal.output.stats.malicious > 5
    steps:
      - name: create_case
        type: kibana.createCase
        with:
          title: "Malware Detected: {{ event.alerts[0].file.hash.sha256 }}"
          description: |
            Confirmed malicious file detected on {{ event.alerts[0].host.name }}.

            **Detection:** {{ event.rule.name }}
            **User:** {{ event.alerts[0].user.name }}
            **VirusTotal:** {{ steps.check_virustotal.output.stats.malicious }} engines flagged this file
            **Related alerts (24h):** {{ steps.related_alerts.output.values[0][0] }} 
              alerts from {{ steps.related_alerts.output.values[0][1] | size }} rules
          owner: securitySolution
          severity: high
          tags:
            - automation
            - malware
          settings:
            syncAlerts: false
          connector:
            id: none
            name: none
            type: ".none"
            fields: null

      - name: notify_team
        type: slack
        connector-id: "security-alerts"
        with:
          message: |
            Malware confirmed on {{ event.alerts[0].host.name }}.
            VirusTotal: {{ steps.check_virustotal.output.stats.malicious }} detections.
            Case created: {{ steps.create_case.output.id }}

    else:
      - name: close_false_positive
        type: kibana.SetAlertsStatus
        with:
          status: closed
          reason: false_positive
          signal_ids:
            - "{{ event.alerts[0]._id }}"

That's the triage loop, automated. Alert fires, threat intel checked, context gathered, decision made, case created, team notified. Every execution is logged and auditable.

This is a starting point. The traditional-triage.yaml in the Elastic Workflows library on GitHub goes further: it isolates the host, looks up the on-call analyst, creates a dedicated Slack channel, assigns the case, and posts a rich incident summary. Same patterns, more steps.

Adding AI to the playbook

The workflow above handles a defined path. If the hash is malicious, do X; otherwise, do Y. That covers a lot of triage work. But not every alert fits a clean branching condition, and not every case description should be a list of raw fields.

Workflows include AI steps that handle the parts where structured logic runs out. There are three, and they work together.

Classify: let AI drive the branching

Instead of branching on a VirusTotal score threshold, use ai.classify to categorize the alert. It considers the full alert context, not just a single number:

  - name: classify_alert
    type: ai.classify
    with:
      input: "${{ event }}"
      categories:
        - malware
        - phishing
        - lateral_movement
        - data_exfiltration
        - false_positive
      instructions: |
        Classify this security alert based on the alert details,
        rule name, and affected entities.
      includeRationale: true

The output is structured: steps.classify_alert.output.category returns a single string like "malware" or "false_positive". That drives the if condition directly. The rationale explains why, and you can include it in the case for audit purposes.

Summarize: write case descriptions that adapt

Rather than templating raw field values into a case description, use ai.summarize to generate a readable overview. Run it once before case creation for the initial description, and once after the agent investigation to update the description with the full picture:

  - name: initial_summary
    type: ai.summarize
    with:
      input: "${{ event }}"
      instructions: |
        Write a one-paragraph overview of this security alert.
        State what was detected, on which host, by which user, and the severity.
        Do not include recommendations. Just the facts.
      maxLength: 300

The summary adapts to whatever fields are present on the alert, so you don't need to account for every possible field combination in your Liquid templates. Use steps.initial_summary.output.content in the case description and the Slack notification.

Agent: investigate what the playbook can't

The ai.agent step invokes an Agent Builder agent. Unlike classify and summarize, an agent has access to tools. It can query your indices, check threat intel, correlate signals across data sources, and reason about what it finds:

  - name: escalate_to_agent
    type: ai.agent
    agent-id: "security-agent"
    create-conversation: true
    with:
      message: |
        Investigate this alert. Search for related activity on this host,
        check for persistence mechanisms and lateral movement,
        and determine the full scope of the incident.
        Alert: {{ event | json }}
        Classification: {{ steps.classify_alert.output.category }}
        VirusTotal: {{ steps.check_virustotal.output | json }}
        Related alerts: {{ steps.related_alerts.output | json }}
    timeout: 10m

The agent processes the input, calls whatever tools it needs, and returns its findings. The workflow waits, then continues with the next steps: adding the investigation to the case, notifying the team, and updating the case description with a concise summary of what the agent found.

Setting create-conversation: true persists the conversation, so the workflow can fetch the agent's reasoning trail and add it to the case as a structured comment with clickable links to each query it ran. And the analyst gets a direct link to pick up the conversation with the agent if they want to dig deeper.

Putting it together

In the full version of this workflow, the three AI steps work in sequence:

1. Classify the alert to drive the triage decision
2. Summarize the alert for the initial case description and Slack notification
3. Agent investigates the full scope: persistence, lateral movement, IOCs, affected systems
4. Summarize again, this time distilling the agent's findings into a concise, updated case description

The case starts with a clean factual overview and evolves into a comprehensive summary as the investigation completes. The agent's full analysis and reasoning trail live as case comments for analysts who want the details.

The complete workflow, including the AI investigation pipeline with reasoning trails, clickable Discover links, and follow-up Slack notifications, is available in the Elastic Workflows library on GitHub.

Workflows as agent tools

The integration between Workflows and Agent Builder works in both directions. Workflows can call agents (as shown above). And agents can call workflows.

When you expose a workflow as a tool in Agent Builder, an agent can invoke it during a conversation. The agent decides what needs to happen, and the workflow handles the execution reliably and repeatably.

This is the pattern demonstrated in the Chrysalis APT blog post: a two-step workflow hands the entire Attack Discovery to an agent, and the agent calls workflow-backed tools to verify malware hashes, search logs, check the on-call schedule, create a case, and spin up a Slack channel. The workflow is the trigger and the safety net. The agent is the brain.

Agents reason. Workflows execute. Together they cover the full range from judgment to action.

Open by design

Not every team starts from zero. Some already have automation running in Tines, Splunk SOAR, Palo Alto XSOAR, or another platform. Workflows don't ask you to replace any of your existing tools.

The idea is straightforward: use Workflows for the parts of your automation that are native to Elastic. Alert triage, enrichment from your own indices, case management, and alert status updates. These touch your Elastic data directly, and a native workflow will always be simpler and faster than an external tool making API calls back into Elastic.

For everything else, connectors bridge the gap. We have native connectors for Tines, Resilient, Swimlane, TheHive, D3 Security, Torq, and XSOAR. A workflow can kick off a Tines story, push an incident to Resilient, or trigger any external system via HTTP. Your existing tools handle cross-platform orchestration. Workflows handle what's native. As the capability grows, you can consolidate at your own pace. Nobody's forcing a migration.

What's here and what's next

Workflows is available today. Here's what you can build with it today:

• Alert triggers connect workflows to detection and alerting rules
• Case and alert management through named Kibana steps (kibana.createCase, kibana.SetAlertsStatus, kibana.addCaseComment, and more)
• Direct data access via Elasticsearch search and ES|QL
• 39 workflow-compatible connectors covering threat intel (VirusTotal, AbuseIPDB, GreyNoise, Shodan, URLVoid, AlienVault OTX), ticketing (Jira, ServiceNow), communication (Slack, Teams, PagerDuty, email), SOAR platforms (Tines, Resilient, Swimlane, TheHive, and others), and AI providers
• AI steps for classification, summarization, prompts, and Agent Builder invoking Elastic Agents/Skils
• YAML authoring with autocomplete, validation, and step testing in Kibana
• 50+ example workflows on GitHub, including security-specific templates for detection, enrichment, and response

What's coming:

• Visual workflow builder for drag-and-drop authoring
• In-product template library to browse and install workflows directly in Kibana
• Human-in-the-loop approvals that pause workflows for human input via Slack, email, or the Kibana UI
• Natural language authoring where AI helps translate intent into working workflows

Today, authoring is YAML-based. If you've written detection rules or configured CI/CD pipelines, the learning curve is gentle. The editor has built-in autocomplete, validation, and step testing, and the example library gives you templates to start from. A visual builder is coming to make this accessible to a wider audience.

Get started

Elastic Workflows is available now. To start building:

1. Start an Elastic Cloud trial or enable Workflows in your existing deployment under Stack Management > Advanced Settings
2. Explore the Workflows documentation
3. Browse the Elastic Workflow Library on GitHub for security templates you can adapt
4. Read the introductory technical deep dive for core concepts
5. See the Chrysalis APT blog for a complete Attack Discovery + Workflows + Agent Builder walkthrough

Start with the workflow that would save you the most time tomorrow.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.