Agent frameworks¶

This provider is built on Pydantic AI: its operators and decorators create and run Pydantic AI agents. If you already build agents with another framework, you do not have to move them to Pydantic AI to run them in Airflow. Run the agent in a @task as you do today, and use this provider for the parts that need Airflow: models and tools backed by Airflow connections.

Why Pydantic AI¶

An Airflow deployment runs on whichever cloud and model vendor its team chose, and the same Dags often outlive that choice. The provider’s own operators are built on Pydantic AI because it does not tie a Dag to either:

No vendor or cloud to commit to. The same operator reaches OpenAI, Anthropic, Gemini, Vertex AI, Bedrock, Azure OpenAI, Mistral, Groq, DeepSeek and self-hosted OpenAI-compatible servers such as Ollama and vLLM, through an Airflow connection. Moving a Dag to another vendor is a connection change, not a code change. See Supported model providers.
Typed output. output_type makes the agent return a Pydantic model, so the task downstream gets fields to read instead of text to parse. See Structured output and XCom.
Tests that do not call a model. A connection whose model is test runs the Dag against Pydantic AI’s TestModel, and a unit test can script the model’s replies. Neither calls a model provider or spends tokens. See Develop and test AI tasks locally.
A pause before a tool acts. Pydantic AI’s tool approval API is what lets AgentOperator stop in front of a marked tool call until a person approves it. See Approve an agent’s tool calls.

Pydantic AI is the recommendation, not a requirement. For a new agent, start with AgentOperator, which gets the most from this provider. If your team has standardized on Strands, ADK, LangChain, the Anthropic SDK or the OpenAI Agents SDK, keep that framework: the table below shows what this provider gives an agent written in each one.

Supported frameworks¶

A framework is supported when this provider ships code for it and documents it. What that code takes on differs from one framework to the next, so the table says which part is Airflow’s and which part stays yours.

Framework	What this provider gives you	Who runs the agent	Install
Pydantic AI, through `AgentOperator`	`AgentOperator`, `@task.agent`, the `@task.llm` family and every toolset, plus durable replay, human review, approval gates, retry policies and tracing.	The operator	Included
Pydantic AI, your own agent	A model from a connection through `PydanticAIHook`, and every toolset, since they are Pydantic AI toolsets. Guide: Pydantic AI.	You	Included
Strands Agents	The `AirflowTools` plugin gives a Strands agent the tools of `SQLToolset`, `HookToolset`, `ObjectStorageToolset` and the other toolsets, with Airflow’s secret masker applied to every result. Guide: Strands Agents.	You	`strands-agents`
Google ADK	The `AirflowTools` toolset gives an ADK agent the same tools, with the same masking. Guide: Google ADK.	You	`google-adk`
Anthropic SDK tool runner	`AirflowTools` hands the same tools to `client.beta.messages.tool_runner` and makes a tool failure the model cannot fix fail the task. Guide: Anthropic SDK tool runner.	You	`[anthropic]` extra
OpenAI Agents SDK	`AirflowTools` holds the same tools as `FunctionTool` objects for an `Agent`, and makes a tool failure the model cannot fix fail the task. Guide: OpenAI Agents SDK.	You	`openai-agents`
LangChain	`LangChainHook` returns chat and embedding models configured from a connection, and `airflow_toolset_to_langchain_tools()` turns any toolset into LangChain tools. Guides: LangChain models: LangChainHook, LangChain tools in both directions.	You	`[langchain]` extra
LlamaIndex	`LlamaIndexHook` returns language and embedding models configured from a connection, and embedding and retrieval operators build a RAG pipeline from them. Guide: Document and RAG pipelines.	No agent	`[llamaindex]` extra

The Strands, ADK, Anthropic and OpenAI Agents integrations and the tracing helper are experimental: they can change or be removed in a minor release of this provider. The framework-neutral tool interface under them is stable. See Stable and experimental features.

Tested versions¶

Framework	Version	Notes
Strands Agents	1.56.0	Pins `mcp` below 2.2, so installing it downgrades `mcp` if a newer one is installed.
Google ADK	2.9.1	Pins OpenTelemetry at 1.42.1 or lower, below the version in Airflow’s constraints file. Airflow itself accepts 1.42.1.
OpenAI Agents SDK	0.20.0 and 0.23.1	0.21.0 and later require `openai>=3`, while Airflow’s constraints file pins `openai` below 3, so installing with that file gives 0.20.

These are the versions the adapter tests have been run against. Strands and ADK cap packages below the versions in Airflow’s dependency lock, and current OpenAI Agents SDK releases need openai 3, so CI runs their adapter tests in a job of their own, one framework at a time. Pull requests test each framework against the versions in Airflow’s CI image, which for the OpenAI Agents SDK means the newest release that accepts openai 2.x; scheduled runs test each framework’s newest release with its own dependency pins.

Choosing a route¶

Start from the agent you already have:

An existing Pydantic AI agent: keep it, give it a model with PydanticAIHook and pass Airflow’s toolsets to it. See Pydantic AI.
An existing Strands agent: keep it, and add Airflow’s toolsets with the AirflowTools plugin. See Strands Agents.
An existing ADK agent: keep it, and add Airflow’s toolsets with the ADK AirflowTools toolset. See Google ADK.
A loop written on the Anthropic SDK: keep it, and pass the tools of AirflowTools to its tool runner. See Anthropic SDK tool runner.
An existing OpenAI Agents SDK agent: keep it, and add Airflow’s toolsets to its tools with AirflowTools. See OpenAI Agents SDK.
An existing LangChain agent: build its model with LangChainHook and add Airflow’s toolsets with airflow_toolset_to_langchain_tools.
No agent yet, or no preference: use AgentOperator or @task.agent. That route is the only one with step-level durable replay across task retries and a built-in human review step, because both are implemented on top of Pydantic AI.

Any other framework¶

Every framework can run inside a @task, and every framework can call an Airflow hook from one of its own tools, so a framework that is not in the table above still has a route. Before you depend on it, check that its dependencies resolve alongside the provider versions your deployment uses: some frameworks pin versions of packages Airflow also depends on, such as OpenTelemetry or a vendor SDK.

To give such a framework Airflow’s toolsets rather than hand-written tools, build on the framework-neutral interface in airflow.providers.common.ai.tools, which is what the Strands, ADK, Anthropic and OpenAI Agents integrations are written against:

AirflowTool is one operation: a name, a description, a JSON Schema for its arguments and an async function. Call it through AirflowTool.call, which applies the secret masker to what the tool returns. A failure the model can correct comes back as an error result; any other failure raises ToolCallError, which should end the run.
ToolResult is what a call returns: JSON-compatible content and an explicit is_error flag for failures the model can correct.
ToolProvider is anything with an airflow_tools() method returning AirflowTool objects. Every toolset this provider ships that reads from a connection implements it, except MCPToolset and the Agent Skills toolset. MCPToolset works in Pydantic AI agents and through the LangChain bridge; for Strands, ADK and other frameworks, connect the framework’s own MCP client to the server.

An adapter maps these onto the framework’s own tool type and error status, and makes sure a ToolCallError ends the run rather than reaching the model, as the Strands plugin does. collect_tools() turns the toolsets and tools an adapter is given into one list, as the Strands, ADK, Anthropic and OpenAI Agents adapters do.

Blocking hook calls, such as a SQL query, run one at a time in the task’s process, so an agent that calls two database tools at once gets its answers one after the other.

Run a Strands, ADK or OpenAI Agents SDK agent inside agent_framework_tracing() to keep its spans tied to the task, and free of prompt text unless [common.ai] capture_content is on; see Observability (OpenTelemetry tracing). For an OpenAI Agents SDK agent, also register AirflowTraceProcessor.