on_failure_callback that fires the incident commander automatically when any DAG task fails, and a manual CLI trigger for teams who want to invoke triage on demand.
Before You StartParadime
- Your Paradime API endpoint, API key, and API secret — generate these under Workspace Settings → API. Make sure to enable
DinoAI agent APIcapabilities. Requires Admin access.
- Quick Start
- YAML Configuration
- Tools Reference
- Agent-to-Agent Delegation
invoke_agent, notify_parent_session, and child_session_ids — all covered in the Agent-to-Agent Delegation guide.IntegrationsThe following must already be connected in Paradime:- Slack — the orchestrator and sub-agents post to
#incidentsviapost_slack_message
What You’ll Build
By the end of this guide you’ll have:- Four DinoAI agent YAMLs — one orchestrator (
incident-commander) and three specialists (log-analyzer,query-profiler,owner-notifier) - An Airflow
on_failure_callbackfunction that fires the incident commander automatically when any task in a DAG fails, pre-populated with the DAG name, task ID, run ID, and execution date - A manual trigger script for ad-hoc incident triage
What Happens During a Triage
Once the incident commander is triggered:invoke_agent in their tool allowlist, so the graph is exactly two levels deep. This keeps incident response predictable and prevents runaway delegation chains.
The Slack Incident Post
Once all three sub-agents have reported back, the incident commander posts a single structured message to#incidents:
Architecture Overview
1
Create the Agent YAMLs
Create all four agent files. The orchestrator and three sub-agents must all exist in Sub-agent — Sub-agent — Sub-agent —
.dinoai/agents/ before the first trigger.Orchestrator — incident-commander.dinoai/agents/incident-commander.yml
log-analyzer.dinoai/agents/log-analyzer.yml
query-profiler.dinoai/agents/query-profiler.yml
owner-notifier.dinoai/agents/owner-notifier.yml
None of the sub-agents have
invoke_agent in their tool allowlist. This keeps the delegation graph exactly two levels deep — the commander is the only delegator. Sub-agents cannot spawn further children, which makes incident response predictable and prevents runaway chains.2
Trigger Path A — Airflow `on_failure_callback`
This is the recommended path for teams running Airflow. The callback fires automatically when any task in your DAG fails, extracts the task and DAG context from Airflow’s Then attach the callback to your DAG:
context dict, and hands it directly to the incident commander so the triage message is pre-populated with real incident details.Create dags/callbacks/incident_commander.py:dags/callbacks/incident:commander.py
dags/hourly_marts.py
The callback runs in a daemon thread so it does not block Airflow’s task runner while the agent session runs (which can take several minutes). The original task failure is always surfaced normally in Airflow regardless of whether the triage agent succeeds or fails.
To attach the callback to a single task rather than the whole DAG, set
on_failure_callback=trigger_incident_commander on the operator directly. This is useful when only certain high-priority models should trigger a full triage.PARADIME_API_ENDPOINT, PARADIME_API_KEY, and PARADIME_API_SECRET should be stored as Airflow Variables or in an Airflow Connection, not hardcoded. Retrieve them with Variable.get("PARADIME_API_KEY") if you prefer the Airflow Variables pattern over environment variables.3
Trigger Path B — Manual CLI Trigger
For teams not running Airflow, or for ad-hoc incident triage when a failure is spotted manually, create Run it from your terminal:
scripts/trigger_incident.py:scripts/trigger:incident.py
4
Watch Sub-Agents in Flight
Both trigger paths block until the full triage is complete. If you want to stream sub-agent progress in real time as each specialist reports back, use the non-blocking
trigger_run pattern and poll child_session_ids:scripts/watch:incident.py
child_session_ids populates progressively as the orchestrator spawns each sub-agent. The first poll may return an empty list — this is expected. The three child sessions will appear within the first 30–60 seconds as the commander issues its invoke_agent calls.Execution Flow
When the incident commander receives the trigger message:- It calls
invoke_agentthree times in parallel — one for each specialist — passing its own session ID as the callback target - Each sub-agent runs independently, posting updates to the
#incidentsSlack thread as it works - Each sub-agent calls
notify_parent_sessionwith its findings when complete - The commander resumes once all three callbacks have arrived, then composes and posts the unified triage report
Set Your Environment Variables
The callback and trigger scripts require three variables. For the Airflow path, set these as Airflow Variables or in your Airflow environment. For the manual path, export them in your shell.Your Paradime API endpoint, key, and secret are available under Workspace Settings → API. Make sure the key has
DinoAI agent API capabilities enabled.File Structure
Your repository should look like this after completing the setup:Related Docs
- Agent-to-Agent Delegation — how
invoke_agentandnotify_parent_sessionwork - Programmable Agents — Quick Start — getting started with DinoAI agents
- Programmable Agents — YAML Configuration — full reference for agent config options
- Programmable Agents — Tools Reference — all available tools
- Slack Integration — connecting Slack to Paradime
- Paradime API & Credentials — where to find your API endpoint, key, and secret