Procedural Graphs: Self-Evolving Execution Structures for LLM Agents

I wonder if the graph part is a distraction (data representation / syntax), and once you step back, if/how this relates to the wider concept of 'durable task lists' used in this kind of structured dynamic planning.

Ex: Durable task lists generally use more textual representations, eg, a hierarchical text list that supports named references -- so a graph. Likewise, they're mutable, contain statuses, etc. They're fairly popular and AI models at this point have internalized them at this point.

Maybe I missed in when scanning the paper, but did they compare to a simple self modifying harness, e.g. instructing Pi to update some code or skill docs based on the results?

Okay how are Add nodes created? Does an LLM come up with the name, guidance and edges for each node or is it a bespoke transformer model?

No idea what this site is. Paper is here: https://arxiv.org/abs/2609.09153

The distinction between a procedural graph and a static workflow seems important: self-editing topology can capture reusable strategy, but it also makes regressions harder to localize. I’d be curious whether the refinement loop treats a successful trajectory as sufficient evidence, or uses counterexamples and held-out tasks to avoid encoding a brittle shortcut. A practical evaluation might report graph churn and rollback frequency alongside task success, since a graph that keeps growing could be trading inference cost and auditability for a small gain. The explicit entity–relation–procedure representation also seems like a promising place to attach permissions or provenance to tool calls.

[flagged]