Peter Steinberger asked a simple question this week: “Are we still talking loops or did we shift to graphs yet?”
It set off a frenzy of conversation (and cynicism) about graphs and agent orchestration.
Nearly two months ago, in my PyData London keynote, I introduced Directed Agentic Graphs as a new way to orchestrate agents.
It was the first time I’d discussed the idea publicly, and I told the room I wasn’t sure people were ready to talk about it yet.
I’m delighted that the zeitgeist has decided we are.
Agentic workflows
I spent the last year asking companies about their agentic workflows: how they think about them, what intuitions they lean on, what abstractions they reach for. Almost without exception, they describe their agents in terms of the outcomes and side effects they expect. The agent should investigate an incident and file a report, review a claim and recommend a decision, update a customer record, open a pull request, or issue a refund. So knowing whether the agent did its job turns out to be the same as knowing whether the expected outcome came true.
Those are the same operational questions companies asked about their data pipelines ten years ago. Did it run? Did it produce the expected result? If something went wrong, where did it go wrong, and how do we fix it?
So automation hasn’t changed, but the thing being automated has. Ten years ago the most valuable thing a company could automate was the movement and transformation of its data; today it’s the work its agents perform. The primitives carry over, since we’ve spent decades making and correcting the same mistakes, but the material is new, and because an agent chooses its own implementation and can’t tell you in advance what it’ll do, the graph it runs in needs a different organizing principle: the outcome.
That’s the idea behind Directed Agentic Graphs: high-level orchestration graphs whose nodes are measurable outcomes and whose edges are the decision lineage between them. Because they describe what the work achieves rather than how the agent achieves it, they sit a level above the frameworks that graph an agent’s individual tool calls and branches, up at the altitude a business actually cares about.
Why a graph matters
A graph is valuable because it’s reasonable, not because it’s technical. That is, it lets you reason about a workflow as something more than a series of text instructions. It’s the same leap LLMs took when they learned to return structured objects instead of unstructured text: the words were always there, but suddenly software could reason about them, check them, and build on them. A graph does that for a workflow, turning a run you could only read into a structure you can reason about.
Most agentic systems don’t work this way yet. The state of the art in agentic workflows is still a skill, a handful of MCP tools, and hope: hope that the agent follows its instructions, uses the tools well, and stops when it should. That holds up right until the actions turn sensitive, destructive, or irreversible, at which point hope stops being a strategy, because a skill is really nothing more than a polite note that the agent is free to ignore.
A graph is what replaces the hope. Once the workflow is an explicit data structure, it becomes reproducible, auditable, and observable, and every boundary between its nodes turns into a place where control returns from the agent to the orchestrator, which can check the outcome, enforce a policy, bring in a person, or decide where the work goes next.
That last option, choosing where the work goes next, also answers a common objection that I hear to introducing these deterministic boundaries: that drawing a path for an agent strips away the autonomy that makes it so powerful in the first place. The opposite is true. Because control comes back at each node, and a node can be drawn tight or left wide open, the graph becomes a dial for that autonomy. Scope a node narrowly, with a couple of tools, and you’re keeping the agent on a short leash; leave it open, with many tools and real latitude, and you’re handing it room to improvise; and because both kinds of node live in the same graph, you can tighten one step and loosen the next. Control and autonomy stop being a single global setting and become something you tune with fine precision.
All of this rests on a single requirement: a node can’t end just because the agent decides it’s done, only by producing an outcome the surrounding system can check. Those verifiable outcomes are the core unit (and arguably, the only novel orchestration primitive) of a Directed Agentic Graph: the agent owns how the work gets done, and the outcome is how it proves the work is finished.
This is easiest to see in something concrete, like the refund agent a support team might actually deploy today. You write a skill that lays out the refund policy, connect a handful of MCP servers for customer lookup, order history, the payments API, and email, and turn it loose on each request. It reads the message, works the problem in whatever order it likes, calls whatever tools it needs, and eventually reports that it’s finished. Often this works well. But look at what sits on the table from the very first step: the tool that moves money is right there beside the one that looks up an email address, and the only thing between a misread request and a wrongful refund is the agent’s own judgment. From the outside the run has just two visible states, running and finished, while everything that actually happened, the identity check, the policy reading, the decision to pay, stays buried in a transcript you’d have to reconstruct after the fact.
Draw the same work as a graph and it changes character. The states the business cares about become nodes, each depending on the one before: the customer is identified, eligibility is determined, the refund is approved, the money moves, the customer is notified. Eligibility can’t be decided before the customer is known, and money can’t move before both a decision and an approval exist. The refund tool stops being ambient, appearing only at the node that issues the refund and only once the graph has reached an approved state, so what used to rest on the agent’s discretion becomes a property of where the graph is. And because the graph is an explicit structure, it can tell you before a run what could happen, during a run where you are, and afterward exactly which path was taken.
Underneath, that scoping is mechanical rather than advisory. At each boundary the orchestrator assembles the harness the next node will run in, choosing the tools it can call, the context it can see, and the actions it’s allowed to take, which is why the refund tool can be absent for an entire run and present at a single node. In many cases this is what a Directed Agentic Graph really is: harness orchestration, the programmatic assembly of an agent’s capabilities step by step, instead of one harness handed everything at once.
Nodes
Orchestration tools like Prefect treat a node as an action: run this function, query that table, submit this job. The graph spells out the implementation, and the outcome stays implicit, whatever happens to be true once the code has run. Our friends at Dagster made the case years ago that this is backwards, at least for data, and that a pipeline reads far better when each node is defined by the asset it should produce than by the task it runs. A Directed Agentic Graph carries that same inversion into agentic work: a node is defined by an outcome that has to become true, and the agent is left to work out how.
Those outcomes are the boundaries of the graph, the points where control returns to the orchestrator, and everything between them belongs to the agent. Inside a node, its behavior is arbitrary: it can reason however it likes, call whatever tools it holds, and spin up whatever processes it needs, staying in its own loop until it pulls one of the levers that ends the node. The graph never watches that work; it waits for the outcome, and only then takes control back.
A node is more general than one agent in a loop. It can offer several outcomes rather than one, finishing as eligible, ineligible, or needs_review; it can start other nodes; and it can be deterministic code, where the steps are known and reliability matters more than latitude, or represent a person, where human-in-the-loop judgment is required. The one thing every node shares is the contract: an outcome the rest of the system can actually check.
In the refund graph, the first node, Identify customer, hands an agent the request and a set of search tools and asks for one thing in return: a verified customer ID, with the evidence used to choose it. Whether the agent gets there by email, order number, address, or a clarifying question is its own affair. The next node, Determine eligibility, takes that customer, the order history, and the policy and returns a structured decision backed by evidence; the route might be trivial for a recent unopened purchase and winding for an ambiguous exception, and both satisfy the same outcome. That’s what keeps the agent autonomous: the graph fixes the boundary and the standard for done, and leaves everything in between alone.
Because the outcome has a known shape, the node can be checked instead of trusted. The customer ID has to exist, the cited order has to belong to that customer, the policy version has to be current, the evidence has to be there, and a domain-specific evaluator can weigh the quality of the judgment itself.
The result is a durable unit of progress. The system knows which outcome was attempted, what evidence supported it, and whether it passed, and it can compare two runs on the same outcome even when the agents took completely different paths there. Measure a fleet of these and the numbers that matter fall out: how often customers are identified correctly, how many eligibility decisions survive review, how many workflows reach a valid resolution.
A Directed Agentic Graph is therefore a graph of outcomes in both senses: outcomes define its structure, and outcomes are its unit of measurement.
Edges
An outcome records what happened, and it usually determines what happens next.
The Identify customer node can return several results, and each points somewhere different: identified moves on to eligibility review, ambiguous asks for clarification, and not_found leads to a response explaining that the order couldn’t be located. Determine eligibility can return eligible, ineligible, or needs_review, and each activates a different path.
Those edges are decision lineage.
In a data pipeline, lineage explains which upstream data contributed to a downstream asset. In an agentic workflow, decision lineage explains which outcome caused the process to enter its next state. The refund was issued because a particular order was found eligible under a particular policy, and because a particular approval followed. The customer got an explanation because the eligibility decision was negative. A human got involved because the agent returned an ambiguous result. The edge carries that reason forward.
This matters because the path through an agentic process is often as important as the final answer. Two customers may both receive refunds, one down the ordinary policy path and one through an exception a manager approved. The side effect is identical. The decision lineage is not, and the business needs to keep it.
Decision lineage also makes failure intelligible. If an ineligible customer receives a refund, the graph separates causes a single trace would blur together: the eligibility node may have judged wrong, the edge may have routed a needs_review result to approval, an approval may have been granted against policy, or the payment action may have ignored its input. Each lives at a specific node or transition, with a bounded set of evidence to inspect. The question stops being “why did the agent do that” and becomes “which outcome was wrong, and which edge trusted it.”
Edges can also form cycles. A human reviewer might return needs_revision and send the eligibility decision back with more context. An evidence-gathering node might return insufficient_evidence and try again. Directed Agentic Graphs keep the familiar DAG abbreviation and swap acyclic for agentic, because agentic graphs can absolutely contain cycles. In truth nothing ever prevented cycles in classical orchestration either, only the limitations of the software doing the orchestrating.
A graph of work
Once nodes are defined by outcomes, each one can use whatever implementation best produces its result.
An agent identifies the customer, because the inputs are messy and the right search strategy depends on the request. Another agent evaluates eligibility, because the decision may require interpreting natural-language policy and assembling evidence from several systems. A human approves exceptional refunds, because the organization wants a person to own that judgment. Deterministic code issues the payment, because the action is already well specified. An existing workflow updates the downstream accounting systems. Another agent writes a clear explanation for the customer.
All of these nodes belong to the same graph because they share the same contract: produce a declared outcome, attach the required evidence, and return control to the orchestrator. That makes a Directed Agentic Graph a graph of work, with agents, people, functions, and existing workflows all contributing to one process.
Agentic systems don’t get better when every function is replaced with a model. Deterministic code is still the right choice when the steps are known and reliability matters more than flexibility. A human is still the right choice when policy demands accountability. The graph gives every part of the process the appropriate executor while preserving one coherent model of state and lineage.
And the graph only has to expose the decisions the business cares about. A low-risk research task might need a single node with one measured outcome: a final report. A financial process might represent every material judgment and side effect on its own. Each node you add introduces another measurable outcome and another explicit decision boundary, so the graph grows in proportion to the cost of a decision going wrong or unexplained.
Peter’s question has a satisfying answer. An agent loop is already a graph, though not the smallest one. The smallest is a single node: one bounded run whose iteration stays implicit, with a single edge leading out. A loop is that same node with a cycle added, a continue edge that re-invokes it until a done edge lets it leave. Either way you’re already holding a graph, and the moment the work contains another outcome worth measuring, or another decision worth preserving, it grows into a bigger one.
Directed Agentic Graphs
A Directed Agentic Graph is a high-level orchestration graph for work performed by agents, software, and people.
Each node is defined by an outcome that can be measured and verified, each edge is the decision lineage that outcome produces, and inside a node the executor has whatever autonomy the work calls for while the graph records when the outcome is met and what becomes possible next.
You could call this a state machine with LLM nodes, and at the level of boxes and arrows you’d be right. But anyone who has spent long enough in automation knows the graph was never the hard part. The hard part is finding an abstraction that fits the way people actually want to work with a particular technology, and if a state machine with LLM nodes were enough, we’d already have it; the pattern would be endemic in every tool. It isn’t, so something is still missing. My belief is that the missing piece is a declarative set of outcomes governed by a fully implicit, dynamic, goal-seeking set of behaviors: you declare what has to become true, the agent is left to reach each outcome however it can, and the graph holds only the outcomes and the lineage between them.
This has been my work for the last year, and for the last six months the Prefect team has been building the next generation of automation aimed squarely at it: outcome-driven decision lineage graphs, backed by fully dynamic, durable compute. Our recent acquisition of Dagster only deepens our confidence that we can deliver it. We’re showing it to design partners now, and if you think you should be one of them, we’d love to talk.
Autonomy made agents possible. Graphs make them accountable.