llm-agents A field note by Vikrant Sharma
LLM agents that rewrite their own execution graphs
A new paper shows agents that evolve their control flow at runtime, not just prompt chains.
Most LLM agent frameworks wire up a fixed graph of nodes and edges. You define the flow once: retrieve context, call the model, parse output, loop if needed. The graph is static. The agent runs it. Procedural Graphs flips that. The paper describes agents that modify their own execution structure while running. An agent can add nodes, delete edges, reorder steps, all based on what it learns mid-task. The graph is mutable state, not configuration. The trick is treating the graph itself as data the LLM can read and write. At each step, the agent sees the current graph topology in its context window, decides if the structure is working, and optionally rewrites it. Then it keeps running with the new graph. Think self-modifying code, but for orchestration. The examples in the paper are small: an agent solving a puzzle by dynamically adding verification steps, another one simplifying its own loop structure after redundant calls. The performance numbers are modest. But the idea is strange enough to stick. Most agent libraries assume you design the workflow. This one assumes the workflow is part of the problem the agent solves. I do not know if this scales past toy demos. Self-modifying execution graphs sound like a debugging nightmare. But if you have ever watched an agent spin through the same useless retrieval step twelve times because the prompt chain was hardcoded, you see the appeal. Maybe the graph should not be sacred. The code is not public yet. The paper is dense. Still, it is the first time I have seen someone treat agent orchestration as mutable runtime state instead of declarative config. Worth watching if you build with LangGraph or similar tools.
Source: Procedural Graphs: Self-Evolving Execution Structures for LLM Agents
