apache-airflow-providers-common-ai¶
The common.ai provider is the vendor-neutral way to put LLM and agent steps in a Dag.
When to use this provider¶
Use case |
Use |
Package |
|---|---|---|
Portable generation, classification, extraction, branching, or a worker-run agent with toolsets |
|
|
A vendor’s native Embeddings, Responses, or Batch API |
The vendor’s own provider |
e.g. apache-airflow-providers-openai, apache-airflow-providers-anthropic, apache-airflow-providers-cohere |
A vendor-managed, server-side agent session (e.g. Anthropic Managed Agents) |
The vendor’s own provider |
common.ai is built on pydantic-ai, so the model vendor
(OpenAI, Anthropic, Google, Bedrock, …) is picked by the connection llm_conn_id points
at — switching providers later is a connection change, not a Dag rewrite. Existing LangChain
tools aren’t locked out either: with the langchain extra installed, they can be wrapped
in LangChainToolset and dropped straight into a common.ai agent (see Toolsets — Airflow Hooks as AI Agent Tools).
The AI step is orchestrated by Airflow: the model calls, the agent loop, and any tools all
run in the Airflow worker, where they get retries, logging, and observability like any other
task.
Use it when a Dag needs:
Generation, classification, summarization, or structured extraction — LLMOperator and @task.llm, with Pydantic-typed output pushed to XCom.
Branching on a model’s decision — LLMBranchOperator.
Agents with tools — AgentOperator runs a multi-turn agent loop in the worker, calling Airflow-defined toolsets (SQL, hooks, MCP servers), with optional human-in-the-loop review and durable step replay — if the task retries after a failure, completed steps are replayed from cache instead of re-executing.
Document pipelines — loading, file analysis, embeddings, and retrieval for RAG (see Common AI Operators).
Use a vendor’s own provider instead when the Dag needs that vendor’s native API surface — a service the vendor runs for you, which no vendor-neutral operator wraps:
apache-airflow-providers-openai — the Embeddings, Responses, and Batch APIs.
apache-airflow-providers-anthropic — the Claude Message Batches API, and Managed Agents sessions where the agent loop runs on Anthropic’s infrastructure rather than in the Airflow worker.
apache-airflow-providers-cohere — Cohere’s own Embed API.
apache-airflow-providers-google — Vertex AI’s Batch Prediction jobs (
CreateBatchPredictionJobOperator), a managed batch service like OpenAI’s Batch API.apache-airflow-providers-amazon — Bedrock’s Batch Inference (
BedrockBatchInferenceOperator), and Bedrock AgentCore’s managed agent runtime (BedrockCreateAgentRuntimeOperator/BedrockInvokeAgentRuntimeOperator), where the agent loop runs on AWS’s infrastructure rather than in the Airflow worker.
As a rule of thumb: if Airflow should run the AI step (and the model should stay
swappable), use common.ai; if the Dag submits work to a vendor-managed service and
waits for the result, use that vendor’s provider.
For example, this LLMOperator call is unchanged whether llm_conn_id points at an
OpenAI, Anthropic, or other pydantic-ai-supported connection:
@dag(tags=["example"])
def example_llm_operator():
LLMOperator(
task_id="summarize",
prompt="Summarize the key findings from the Q4 earnings report.",
llm_conn_id="pydanticai_default",
system_prompt="You are a financial analyst. Be concise.",
)
Choosing extras¶
The provider’s extras split into a few groups:
Model providers —
openai,anthropic,google,bedrock: pick the one matching yourllm_conn_idconnection. Each extra name mirrors the identically namedpydantic-ai-slimoptional dependency group; pydantic-ai supports more model providers than these four, each under its own extra name, so check the pydantic-ai install docs for the full list.Agent tooling —
mcp,skills,code-mode: MCP servers, Agent Skills, and code-mode tool execution.Document loading —
pdf,docx,avro,parquet: file formats for document pipelines.Retrieval / SQL —
sql,common.sql,langchain,llamaindex: RAG and SQL-schema tooling.Git-backed content —
git: pulling Agent Skills or documents from a git connection.
See the Optional dependencies table below for the exact package each extra installs.
apache-airflow-providers-common-ai package¶
AI/LLM hooks and operators for Airflow pipelines using pydantic-ai.
Release: 0.6.0
Provider package¶
This package is for the common.ai provider.
All classes for this package are included in the airflow.providers.common.ai python package.
Installation¶
You can install this package on top of an existing Airflow installation via
pip install apache-airflow-providers-common-ai.
For the minimum Airflow version supported, see Requirements below.
Requirements¶
The minimum Apache Airflow version supported by this provider distribution is 3.0.0.
PIP package |
Version required |
|---|---|
|
|
|
|
|
|
|
|
Optional cross provider package dependencies¶
Those are dependencies that might be needed in order to use all the features of the package. You need to install the specified provider distributions in order to use them.
You can install such cross-provider dependencies when installing from PyPI. For example:
pip install apache-airflow-providers-common-ai[amazon]
Dependent package |
Extra |
|---|---|
|
|
|
|
|
Optional dependencies¶
These extras install optional third-party libraries that enable additional features of the provider. Install them when installing from PyPI. For example:
pip install apache-airflow-providers-common-ai[anthropic]
Extra |
Dependencies |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Downloading official packages¶
You can download officially released packages and verify their checksums and signatures from the Official Apache Download site