Why Flux

One Python framework for durable workflows and first-class AI agents.

Flux combines two things that usually live in different tools: durable execution (workflows that survive crashes, retries, restarts) and an agent framework (LLM calls, tools, memory, planning). Both are in the same Python API.

The mental model

Write your work as tasks (functions decorated with @task) composed inside workflows (functions decorated with @workflow). Flux records every task call, retries failures, pauses on demand, and resumes hours or days later from the last checkpoint. The execution model is the same as Temporal.

Then add agents (built with agent() from flux.tasks.ai) that live inside workflows. They call LLMs, run tools, hold memory across turns, and survive crashes. An agent is just another durable Flux primitive, not a separate runtime or a separate framework.

from flux import task, workflow, ExecutionContext
from flux.tasks.ai import agent

@task
async def fetch_user(user_id: str) -> dict:
    return await db.get(user_id)

@task
async def search_web(query: str) -> str:
    ...

@workflow
async def daily_user_report(ctx: ExecutionContext[str]):
    user = await fetch_user(ctx.input)

    summarizer = await agent(
        "Summarize the user's recent activity.",
        model="anthropic/claude-sonnet-4-5",
        tools=[search_web],
    )
    summary = await summarizer(str(user["events"]))

    await send_email(user["email"], summary)

The task and the agent share the same durability primitives: each call is recorded to the event log. That code survives a process crash, a worker restart, an LLM rate-limit, and your laptop closing. Flux records each step, so a resume starts after the last completed call, not at the top.

The same model scales down and up. Durability is per-workflow: high-frequency agent-to-agent hops can opt into durability="transient" and skip task-level persistence when replay isn’t worth the write volume. In production, each execution runs in its own credential-less subprocess by default — a crash or OOM in one workflow can’t take down its neighbors — and server replicas coordinate through PostgreSQL, so there’s no single server to keep alive.

How Flux compares

A capability-by-capability summary of what each tool covers. The point isn’t to rank; it’s to describe what you’d be combining if you didn’t use Flux.

Temporal. Durable execution at scale, polyglot SDKs (Java/Go/TypeScript first, Python more recent). No agent primitives; LLM workflows are user code on top. If you live in Python and want agents in the same framework, Flux is the more direct fit. If you need polyglot or already have a Temporal investment, Temporal is the more direct fit.

Prefect. Scheduled data pipelines with strong observability. Workflow durability is best-effort, not Temporal-class. No agent primitives. Flux’s durability semantics are closer to Temporal, and the agent framework is built in.

Dagster. Asset-centric, so workflows describe data artifacts that should exist. Strong typing. Flux is execution-centric, so workflows describe operations that should run. For “produce these tables” pipelines Dagster fits well. For “execute this graph reliably and call LLMs along the way” Flux is the more direct fit.

CrewAI, LangChain, LangGraph. Agent frameworks running on synchronous Python. A process crash mid-run loses state. Flux records each step to a durable event log, so an agent that crashes mid-run resumes from the last completed step.

Celery and plain Python. Celery is a task queue with at-least-once delivery, no replay, no determinism guarantees, and no agent primitives. Flux records the full execution graph and supports replay from the event log. If “did this complete and what state is it in” is a question you need to answer, Flux’s event log is what you’re looking for.

Where Flux isn’t the right fit

A few honest disqualifiers:

Next

Ready to write code? Quickstart gets you running in five minutes.