Procedural Graphs: Self Evolving Execution Structures for LLM Agents
Masonry and Eyre discuss the 'Procedural Graphs' paper, which proposes a self-evolving graph structure to manage procedural knowledge for LLM agents, moving away from flat history logs toward a structured 'what-to-do' map that the agent can refine through trial and error.
Transcript
Masonry Wait, so the whole premise is basically that we've been treating agent memory like a giant, messy scroll of text, and it's just... not working for long tasks?
Eyre Exactly. Most agents just look at a flat log of everything they've done and try to guess the next move. As the history grows, they just... drift. They start repeating the same useless tool call or completely forget the original goal because it's buried under ten pages of logs.
Masonry Right. Which is just a nightmare for anyone actually trying to ship a reliable agent. Like, if it works ninety percent of the time but then just loops on the tenth step, it's a product failure.
Eyre Right, right. Which is why this Procedural Graph idea is interesting. Instead of a knowledge graph that tells you 'what-is', like 'Paris is the capital of France', this is a graph for 'what-to-do'.
Masonry I love that framing. It's like giving the agent a map of the process, not just a diary of its mistakes.
Eyre Exactly. It uses these triplets... procedure, relation, procedure. So it defines nodes as actions or states, and the edges are the permissible transitions. It keeps the 'how-to' knowledge outside the model weights entirely.
Masonry Wait, before we get deeper into the weeds... how's your week been? You sounding a little more... I don't know, 'systems-heavy' than usual today.
Eyre Oh, just spent three hours arguing with a YAML file that refused to indent properly. I'm in a mood. You?
Masonry Ha! I feel that. I've just been staring at some landing pages for agent frameworks, wondering why they all look like they were designed in twenty-twenty-two. Anyway, back to this. So, the agent is just... following the graph?
Eyre Not exactly. It's not a rigid state machine. During the online phase, the system localizes where the agent is in the graph and pulls the surrounding neighborhood. Then, a guidance model translates that subgraph into... well, situational advice. It biases the next action, but the solver still has the freedom to reason.
Masonry Okay, so it's more like a guardrail than a script. That's a huge win for developer experience because you're not hard-coding every single edge case.
Eyre Mm-hm. But the real meat is the offline evolution. After a batch of tasks, a refiner LLM looks at the trajectories that failed and the ones that worked. It then proposes edits to the graph... adding nodes, pruning edges that led to loops, or rewriting the attributes on a transition.
Masonry Oh, that's the part that gets me. It's basically self-correcting its own manual.
Eyre Right. And it has this validation gate. It only commits the edit if it actually improves performance on a held-out set. If it makes it worse, it rejects the edit and remembers that failure so it doesn't try the same bad edit again.
Masonry That is such an Exploring Next take. We're basically talking about an agent that builds its own infrastructure to stop itself from being stupid.
Eyre I mean, it's a lot more honest than just scaling the model and hoping the 'emergent' planning gets better. It's treating the procedure as a first-class object.
Masonry I'm genuinely sold on the product angle here. Imagine shipping a 'skeleton' graph and just letting the system evolve into a high-performance workflow over a week of beta testing. That's a massive shortcut to production.
Eyre I'll be the skeptic for a second. My worry is the 'refiner' loop. If the refiner LLM has the same blind spots as the solver, you might just be encoding those hallucinations into the graph topology. You're just making the errors deterministic.
Masonry Fair, but the validation gate is the safety valve there, right? If the result is worse on the test set, it doesn't ship.
Eyre True. The ground truth of the environment is the final judge. I'll give them that.
Masonry See? You're not always a doom-and-gloom guy. I'm actually thinking about how this connects to the harness engineering stuff we talked about a few months ago. This is basically an evolving harness.
Eyre It is. It's shifting the burden from the model's internal weights to an editable structure. It's the same theme... the control layer is the actual product.
Masonry Exactly. Anyway, I should probably let you go back to your YAML war. I'm going to go look for this paper's repo and see if I can actually break one of these graphs.
Eyre Good luck with that. I'm sure you'll find a way to make it loop in five minutes.
Masonry Oh, absolutely. I'm a professional. Catch you later, Eyre.