Argues that traditional orchestrators like Airflow assume the graph is stable and data is variable, but with LLM agents the opposite is true: the prompt is stable and the graph is what the model decides to build. Bolting agents onto LangGraph/Temporal/Prefect pays orchestrator overhead on every model-decided step and constrains the model to a graph a human drew last sprint.
pi-dynamic-workflows makes the bet explicit: workflows are emitted by the LLM as Python or a typed plan, validated, then executed by a thin runtime. The framing treats the planner/runtime split as the right primitive, replacing pre-authored DAGs entirely.
openbrief composes research pipelines on the fly — fetch, summarize, cross-reference — with the model choosing the steps and ordering based on the specific question. The position is that research workflows are too varied to template, so the planner must build them per query rather than choosing among prebuilt flows.
make-pages-interactive lets a model rewrite a page's DOM and event handlers in response to user intent, generating UI workflows on demand. The implicit position is that the same planner-emits-steps pattern works at the interface layer — interactivity itself can be model-decided rather than hand-coded.
The synthesis is that across pipeline orchestration, document research, and frontend interactivity, the word 'workflow' means different things but the shape is identical: a planner emits steps, a sandboxed runtime executes them, and the graph is discarded when the request ends. The convergence across unrelated domains is itself the signal.
In a single trending window, three GitHub repos surfaced that look unrelated until you read the source: Michaelliv/pi-dynamic-workflows (547 stars), tantara/openbrief (356), and paraschopra/make-pages-interactive (329). Different authors, different domains — pipeline orchestration, document research, frontend interactivity — and the same underlying bet.
None of them ship a static DAG. All three generate the execution graph at runtime, from an LLM, per request. pi-dynamic-workflows frames it explicitly: workflows are emitted by the model as Python (or a typed plan), validated, then executed by a thin runtime. openbrief composes research pipelines on the fly — fetch, summarize, cross-reference — with the steps and their order chosen by the model based on what the question is. make-pages-interactive goes one layer further, letting a model rewrite a page's DOM and event handlers in response to user intent, effectively generating UI workflows on demand.
The word "workflow" is doing different work in each repo. But the architectural shape is identical: a planner emits steps, a sandboxed runtime executes them, and the graph is thrown away when the request ends.
For a decade, orchestration meant Airflow-shaped thinking: you write the DAG, the scheduler runs it, retries and observability hang off the edges. That model assumes the graph is the stable thing and the data flowing through it is variable. With LLM agents, it's the opposite — the data (the user's prompt) is stable and the graph is what the model decides to build.
The early-2024 reflex was to bolt agents onto existing orchestrators: LangGraph nodes, Temporal workflows where each activity calls Claude, Prefect tasks that wrap a tool call. It works, but it inverts the cost structure. You pay the orchestrator's overhead — durable state, scheduler hops, serialization — on every model-decided step, and you constrain the model to a graph some human drew last sprint. The trending three are an admission that the constraint isn't worth it for tasks where the model is better than the human at picking the next step.
pi-dynamic-workflows leans on a now-familiar primitive: have the model emit code, not tool calls. Anthropic's own "code-execution-as-tool-use" guidance (and the post-MCP pattern @Top10_dev flagged yesterday — 3–7 hand-curated tools plus a code interpreter, beating 20-tool MCP servers) is the same insight from the other end. A model writing twelve lines of Python that orchestrates four primitives is cheaper, more debuggable, and more expressive than a model emitting twelve sequential JSON tool calls through a graph runtime. openbrief generalizes this to research; make-pages-interactive generalizes it to the browser. Different surfaces, one mechanism.
The community reaction is reading these the same way. The HN and Reddit threads on pi-dynamic-workflows are heavy on comparisons to LangGraph and Inngest, with the consensus uncomfortably close to: "why am I drawing the graph?" That question doesn't have a good answer when the model is better at it.
There is a real cost. Runtime-generated workflows break almost every assumption a senior dev brings to production systems: there's no stable graph to monitor, no compile-time type check across steps, no obvious retry boundary, and the sandbox is now load-bearing security. You trade a known surface for a flexible one. The same trade Kubernetes asked you to make a decade ago, and the same one serverless asked five years ago. The pattern of "flexibility wins, ops invents the missing observability later" is, at this point, the default.
If you're picking an orchestration layer for an AI feature in 2026, the question is no longer "Airflow or Temporal." It's whether you want a planner-emits-code runtime (pi-dynamic-workflows-shaped) or a planner-emits-tool-calls graph (LangGraph-shaped), and the former is winning on token cost, latency, and expressiveness for non-trivial tasks. Pick the graph orchestrator when the steps really are static and the model is only choosing parameters. Pick the runtime when the model is choosing the steps.
Type safety doesn't disappear — it moves. Instead of typing the edges of a DAG, you type the primitives the model is allowed to compose, and you validate the emitted code against that surface before execution. pi-dynamic-workflows does this with Pydantic-shaped contracts; the pattern generalizes. Your test suite shifts too: you stop testing "does this DAG produce X" and start testing "given this prompt, does the runtime refuse to do Y." Property-based testing and adversarial prompts become the regression suite.
Error handling is the part most teams will get wrong first. A static DAG retries a failed node; a runtime-generated workflow has to decide whether to retry the step, re-plan from the failure point, or abort. The good repos surface this as a planner re-entry primitive — the model sees the error and emits a new plan. The bad ones swallow it and silently produce wrong output. If you're evaluating one of these, the first thing to read is the failure path, not the happy path.
The DAG isn't dying everywhere. ETL pipelines, batch jobs, anything with a stable shape will keep Airflow employed for another decade. But the agentic surface of your product — research, drafting, multi-step user flows, anything where "what to do next" is itself the hard part — is migrating to runtime-generated workflows whether your platform team is ready or not. Three repos in one trending window isn't proof, but it's the kind of signal that, in retrospect, marks the turn.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.