Your Agent Framework Is a Black Box. A DAG Isn’t.

Most agent frameworks run a reasoning loop.

The model receives a task, decides to call a tool, gets a result, decides to call another, accumulates context, and eventually produces an answer.

It works, often impressively.

Then it fails, and you get a failed run and a transcript.

One tool call in twelve returned something unexpected, the model compensated in a way that was reasonable given what it had, and the output is wrong in a manner that is difficult to trace.

The retry restarts the whole thing, discarding the eleven calls that were fine.

Someone asks why the system answered what it did, and the honest response is that it is in the transcript somewhere.

The alternative is not new

The Apache Airflow project has made this argument publicly and in more detail than we will here, in a post titled Agentic Workloads on Airflow: Observable, Retryable, and Auditable by Design .

It is worth reading in full rather than in our paraphrase, and it comes with a working example.

The core move is to express the agentic workload as an orchestrated graph rather than as a loop.

Each model call becomes a named task. A fan-out becomes dynamic task mapping. Synthesis becomes a named task with its inputs recorded. A human review becomes an approval step inside the graph.

What that buys, concretely

Every step is a first-class artifact

Four parallel model calls appear in the UI as four individually named task instances, each with its own log, its own duration, its own retry state, and its own recorded input and output.

This is the same information the agent harness had internally.

The difference is that it is surfaced and queryable rather than embedded in a transcript.

Partial failure doesn’t restart the run

When one branch of a fan-out fails, that branch retries alone.

Completed results are preserved.

On a workload with twelve model calls and a 5% per-call failure rate, the difference between retrying one branch and restarting the run is the difference between a viable system and one that is always halfway through.

“Why did it answer that?” has an answer

The exact input a model received and the exact output it produced are both stored, per task, and can be queried after the fact.

Not reconstructed from logs — stored.

Human approval is a step, not a wrapper

A reviewer sees one decision with its immediate context, mid-workflow, and can approve, edit or reject.

Rejecting discards one step and its downstream rather than the entire run.

Airflow 3.1 added native support for this. The durable pause matters more than it sounds, because a run may wait three days across a weekend and must survive a deployment in the interim.

The full architecture for this type of control is also covered in our human-in-the-loop approval gates pattern .

It runs where your pipelines already run

Same scheduler. Same connections. Same role-based access control. Same on-call rotation.

No second orchestration system to operate, monitor and eventually migrate off.

The obvious objection

Isn’t this just Airflow DAGs?

Yes.

That is the argument, not a concession.

The properties above — named steps, independent retry, stored inputs and outputs, durable pauses and inherited access control — are not novel capabilities that an agent framework lacks by oversight.

They are what a mature orchestrator has provided for a decade, applied to a new kind of task.

A framework whose principal feature is that it is not exotic tends to outlive one whose principal feature is that it is new.

There is a practical version of this argument too.

Your team already runs an orchestrator. They know its failure modes, they have alerting on it, and someone is on call for it.

Adding a second system with its own runtime, its own state model and its own observability story is a real operational cost, and it is usually paid by whoever is on call rather than by whoever chose the framework.

The tradeoff, stated honestly

DAGs are acyclic.

That is in the name, and it is a genuine constraint.

An unbounded critic-to-generator loop — where a reviewer step sends work back to a generator repeatedly until quality clears a bar, with no fixed iteration count — does not express naturally as a DAG.

It has to be wired as explicit branching at authoring time, with a bounded number of rounds.

The Airflow project is direct about this in the post above, and so are we: the acyclicity is what buys the auditability, and you cannot have the second without accepting the first.

Most production workloads have a knowable shape.

Research and exploratory generation fall into the open-ended category more often than back-office document work does.

Anyone telling you one of these approaches is correct for all workloads is describing their product rather than your problem.

Where this leaves the model choice

One useful side effect of naming every model call as a task is that the cost of each one becomes visible per step.

That is what makes tiered routing tractable.

When a workflow’s twelve model calls are twelve named tasks with recorded token counts, you can see which of them actually need the expensive model and which are classification steps that a small model handles identically.

Inside a reasoning loop, that information exists but is not surfaced in a form anyone acts on.

References

• Agentic Workloads on Airflow: Observable, Retryable, and Auditable by Design — Apache Airflow project blog. The primary source for this argument, with a worked DAG and a direct treatment of the acyclicity tradeoff.
  Apache Airflow
• Introducing the Common AI Provider for Apache Airflow — the operator set that makes this practical, covering multiple model providers through one package.
  Apache Airflow
• Orchestrating agentic AI with Airflow 3.1 — a practitioner account of human-in-the-loop gates inheriting the orchestrator’s existing access control and audit logging.
  Medium
• Building human-in-the-loop agentic workflows — equivalent mechanics in LangGraph, including idempotency constraints around interrupts. Useful for comparison if you are not using Airflow.
  Towards Data Science