Hello everyone, Following up on today's Dev call, Shubham will share a proposal document soon detailing our discussion from yesterday. However, I wanted to outline the idea here first to clear up a few misconceptions that arose during brief conversations on Slack and with PMC members. If agreed upon, this might eventually become an AIP.
*TL;DR: I propose experimenting with dogfooding Airflow deterministic + agentic workflows to handle our triaging and security issue handling* *Current State* We currently use agentic automation via "Magpie" SKILLs ( https://magpie.apache.org/) for both areas, with varying success: - Security issue handling: Working well, processing over 60 issues monthly (a 10x increase over six months ago). - PR triaging: Partially effective (e.g., filtering bad PRs, with potential to automate closing large PRs from inexperienced contributors). *The Problem* Currently, these workflows require a "push" model where I (in Claude CLI) initiate actions, confirm proposals, and approve decisions. Regularly. I initiate them regularly. Others might also initiate actions, but very few people have done so. This creates a Single Point of Failure (SPOF). IMHO - we need to shift to an "automated pull" model to eliminate this SPOF and allow more community members to act as Human-In-The-Loop (HITL) reviewers without needing manual initiation. This would also allow more people to contribute to and review those workflows. *The Proposal* Instead of relying on local CLI pushes, we can translate these learnings into Airflow DAGs. Roughly 60%–80% of triage actions are deterministic and require no human intervention. For the rest, the automated workflow would run in the background and trigger "pull" notifications (e.g., Slack alerts) when bulk human decisions are needed. *Key Benefits & Features:* - Shared UI: A cloud-hosted Airflow UI allows multiple maintainers to review and approve decisions. - Community-Driven Workflows: Workflows can live in a new Airflow repo (e.g., airflow-agentic-workflows), allowing anyone to modify DAGs via pull requests. - No External Dependencies: While Magpie SKILLs can still be used for local testing or syncs if preferred, using Magpie will not be required for PMC/Dev team members. - They workflows **might** by somewhat synced with Magpie in either way (and likely I will start by transplanting parts of the process from Magpie to Airflow Dags (and implement some features for that in Magpie) . But there will be exactly "0" Magpie components in Airflow Agentic Dags. - Dogfooding: Managing Airflow with our latest Helm chart provides direct operational feedback for the community—feedback that we currently miss. - We could make this a "use case" demonstrating how Airflow Agentic workflows helped solve our problem, which could confirm that Airflow is ideally suited for these kinds of workflows. *Note on Workflow Architecture (Addressing Vikram's feedback):* Regarding REACT vs. REPL: Triage and security handling fit the REACT pattern (Reason -> Act -> Iterate) due to the continuous stream of incoming PRs and issues. It's literally -> get issues, evaluate them, make actions (with or without human) and go back to the beginning. REPL relies more on immediate code-execution loops for task implementation, whereas our needs align with REACT's iterative reasoning over time. Let's discuss further in this thread. Looking forward to your comments and feedback. Best regards, Jarek
