Directed Agentic Graphs

July 22, 2026 | Jeremiah Lowin<br>Directed Agentic Graphs<br>Closing the loop

Your browser does not support the video tag.

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...