Skip to main content

​
Overview

In this architecture the agent runs an Airflow Dag through a tool call. The tool calls the Airflow REST API, so it can trigger any Dag and use its result. This pattern works both for agents inside a task and for agents in a local harness such as Claude Code. Often the Dags that are used as tools are built based on existing AI skills. Many skills describe a multi-step workflow you want the agent to follow as diligently as possible. Rewriting the skill as a Dag ensures the steps run with the right dependencies and use deterministic code whenever possible. This also saves tokens, because the agent stops regenerating the code for those steps on every invocation. Take an employee onboarding skill: create an account in the identity provider, wait for confirmation, create matching accounts in a chat system, source control, and payroll, create role-specific accounts, retry anything that fails, then send a personalized welcome email. The agent re-creates all of that code each time, including the waiting and the retry logic, which are already available as Airflow features. Only the last step needs any AI involvement at all to generate the welcome email. Once the workflow has been translated into a Dag-as-a-tool, the skill file only needs to contain two steps: run the onboard_employee Dag with the new employee’s ID, then use the returned account details to write the welcome email.
For more on converting agent skills into Airflow Dags, see Skills vs. Pipeline: Two Ways to Build the Same AI Workflow by Vikram Koka.
For general information on how to orchestrate agents with Airflow, see Agent orchestration with Apache Airflow®.

​
Architecture

Dag-as-a-tool reference architecture diagram. An incoming opportunity email is extracted, an agent on any AI harness drafts outreach using product and customer data through tools and MCP servers, and calls a separate deterministic Dag as a tool that extracts features, engineers them, runs a regression model, and returns a revenue prediction. Agent-in-the-loop and human-in-the-loop steps verify the draft before it is sent to the prospect.
This architecture consists of two Dags, with one being started by a task in the other:
  • The agent Dag: A sales assistant agent drafts outreach for an incoming opportunity email. It queries product information and customer history through tools and MCP servers, and its draft goes through AI-as-a-judge and human-in-the-loop verification before being sent to the prospect.
  • The Dag used as a tool: A fully deterministic pipeline that extracts AI and traditional features, engineers them with one-hot encoding and normalization, runs a trained regression model, and returns a prediction of potential revenue from the prospect.
Expected revenue from the opportunity helps the agent determine which product tier and features to highlight in the outreach email. Predicting a continuous value is a regression problem, which a specialized traditional machine learning model handles. So when the agent decides it would benefit from a revenue estimate, it runs the prediction Dag through the Airflow REST API for that opportunity and gets the number back as a tool result. The Dag used as a tool does not have to be deterministic. Any Dag works, including ones with LLM or agent tasks of their own. The same sales assistant could call the product localization Dag to translate a reply for a foreign-language inquiry, which has the additional benefit that the outreach email then uses the same localized terms as your product documentation.

​
Airflow features

  • Airflow REST API: The interface the agent’s tool uses to trigger a Dag run with parameters and read the result.
  • @task.agent: Orchestrates the sales assistant agent. The tool that triggers the prediction Dag is one of its toolsets, alongside the product and customer data tools.
  • Toolsets: Give the agent access to both the data sources and the Dag trigger.
  • Human-in-the-loop: The verification task that waits for a human to confirm that the outreach draft is ready to be sent to a prospect.

​
Considerations

  • Avoid accidental cycles. If Dag A contains an agent that can start Dag B, Dag B must not contain an agent that can start Dag A.
  • Use this pattern for work deterministic code can do. A regression model, a forecasting model, or an existing transformation pipeline is more reliable and less expensive than a language model doing the same work.
  • Use Dag params in your Dag-as-a-tool. A Dag can be run with different configurations determined by the AI agent using Dag params.
  • Return a result alongside relevant context. For the AI agent to interpret results correctly, it needs to know what the Dag returned, for example which prospect the revenue prediction is for, in which currency, according to which financial metric, and with what confidence interval.
  • Limit the tool to safe actions. A Dag-as-a-tool should only allow the AI agent to run a specific Dag or set of Dags with defined params.

​
Next steps