Red Hat's Automation Orchestrator (coming Q3 2026) runs a 5-step pipeline that starts with alerts from multiple sources landing on one canvas, then hands them to Event-Driven Ansible for deterministic handling before any AI ever sees them. This example focuses on those first two steps only: getting an external alert into an EDA webhook, and matching it in a rulebook.

Step 1-2 config: webhook source plus rulebook

# rulebooks/cve-remediation.yml
---
- name: Ingest Splunk and ServiceNow alerts, trigger CVE remediation
  hosts: all

  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
        token: "{{ EDA_WEBHOOK_TOKEN }}"  # auto-generated API key
      filters:
        - ansible.eda.json_filter:
            include_keys:
              - source
              - alert_id
              - cve_id
              - severity
              - host_group

  rules:
    - name: Instana webhook reports critical OpenSSH CVE
      condition: >
        event.payload.source == "instana" and
        event.payload.cve_id == "CVE-2024-6387" and
        event.payload.severity == "critical"
      action:
        run_job_template:
          name: "cve-2024-6387-remediation"
          organization: "IT Ops"
          job_args:
            extra_vars:
              alert_id: "{{ event.payload.alert_id }}"
              host_group: "{{ event.payload.host_group }}"

    - name: ServiceNow webhook confirms matching incident ticket
      condition: >
        event.payload.source == "servicenow" and
        event.payload.cve_id == "CVE-2024-6387"
      action:
        run_job_template:
          name: "cve-2024-6387-remediation"
          organization: "IT Ops"
          job_args:
            extra_vars:
              incident_number: "{{ event.payload.incident_number }}"

What this does

Step 1 is the sources block: a single ansible.eda.webhook listener exposes one HTTP endpoint that both the IBM Instana webhook and the ServiceNow webhook POST to, each with its own auto-generated API key passed as the bearer token. That matches the Tech Day Netherlands 2026 demo, where two independent triggers — an infra-monitoring alert and an ITSM-side confirmation — fed the same EDA endpoint rather than requiring separate listeners per tool.

Step 2 is the rules block. EDA evaluates every inbound payload against plain conditions — no LLM involved yet. This is the "deterministic automation rulebook" Red Hat describes: given CVE-2024-6387 and severity: critical from Instana, it fires the job template that kicks off the CVE-2024-6387 ("regresshion") remediation workflow. A second rule lets the ServiceNow webhook corroborate the same CVE via its own payload shape, correlating the incident number before the workflow proceeds to inventory correlation and, eventually, the AI analysis and human-approval gates further down the pipeline.

Notes

  • Splunk itself isn't the webhook source here — in the reference demo, Splunk Query, Splunk Alert Search, and Splunk Saved Search are MCP tools the AI agent calls later, in step 3, to correlate hosts. Steps 1-2 only need Instana and ServiceNow to reach EDA.
  • Keep the webhook token in a vault-encrypted variable or your AAP credential store — never hardcode it in the rulebook file.
  • Use include_keys in the JSON filter to strip noisy vendor payload fields before they hit rule conditions; it keeps condition: expressions readable and avoids matching on unstable nested paths.
  • Two rules writing to the same job template is intentional — EDA won't double-run if you scope job template concurrency, but design your job_args so either trigger alone carries enough context to proceed.

Takeaway

Steps 1-2 of the Automation Orchestrator pipeline are just EDA doing what it already does well: one webhook endpoint, deterministic rules, no guessing — the AI only gets involved once a rulebook has already decided the alert is real.

References