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
tokenin a vault-encrypted variable or your AAP credential store — never hardcode it in the rulebook file. - Use
include_keysin the JSON filter to strip noisy vendor payload fields before they hit rule conditions; it keepscondition: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_argsso 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.
Related Articles
- Ansible Orchestrator Example: Adding a Human Approval Step to a Workflow
- Ansible Orchestrator Example: Closing an ITSM Ticket from a Workflow
- Ansible Orchestrator Example: Reading a Workflow Execution Timeline
- Ansible microsoft.scom Module Example: Alert Routing to EDA