Papers
Topics
Authors
Recent
Search
2000 character limit reached

Procedural Graphs: Self-Evolving Execution Structures for LLM Agents

Published 8 Sep 2026 in cs.AI, cs.CL, and cs.MA | (2609.09153v1)

Abstract: LLMs are increasingly deployed as agents that plan over long horizons and act through external tools. Most agents select actions through unconstrained generation over an accumulating history, leaving implicit the procedural knowledge of what to do, in what order, and under which conditions. As trajectories lengthen, agents can lose track of their objectives, invoke tools out of order, and repeat unproductive actions. We introduce the Procedural Graph: just as a knowledge graph organizes factual knowledge into (entity, relation, entity) triplets for what-is questions, a Procedural Graph organizes procedural knowledge into (procedure, relation, procedure) triplets for what-to-do questions. At each decision step, the framework localizes the agent's active node, and a guidance model translates the surrounding subgraph into step-level situational guidance that biases the solver's next action without dictating it. The graph is self-evolving: an LLM refiner contrasts failed trajectories with successful ones and edits the graph's topology and attributes, committing edits that preserve or improve held-out validation performance while retaining rejected ones to discourage repetition. Starting from a minimal skeleton, the loop builds graphs that match or surpass hand-designed ones. It can also repair a flawed expert prior. Across multiple datasets, task types, and LLMs, the Procedural Graph delivers consistent gains over memory-based baselines, and self-evolution further improves performance without manual engineering.

Summary

  • The paper introduces Procedural Graphs (PGs), a novel method that includes explicit, editable procedural structures to enhance the performance of Language Learning Model (LLM) agents in long-term tasks. This structured and localized approach improves execution accuracy and reduces token overhead compared to traditional methods.
  • PGs show that self-evolving procedural graphs, iteratively refined through validation-gated acceptance, achieve higher benchmark results and better long-horizon financial decision-making outcomes. These structured graphs prevent failures like repeated observations and invalid tool ordering by guiding actions conditionally.
  • The method's superiority is evident through significant improvements in benchmarks like GDPval and BFCL v3, outperforming baseline methods on various LLMs and reducing procedural drift on long-term tasks.

Problem formulation and motivation

“Procedural Graphs: Self-Evolving Execution Structures for LLM Agents” (2609.09153) addresses a specific weakness of long-horizon LLM agents: procedural knowledge is usually represented only implicitly in model parameters, prompts, or flat trajectory histories. In a conventional ReAct loop, the solver must infer which actions remain valid, which prerequisites have been satisfied, and when an apparently plausible action should be deferred. This creates failure modes including trajectory drift, invalid tool ordering, repeated observations, premature termination, and loops caused by incomplete state tracking.

The paper distinguishes procedural knowledge from factual knowledge. A knowledge graph represents entities and relations to answer what-is questions; the proposed Procedural Graph (PG) represents procedures and permissible transitions to answer what-to-do questions. The central claim is that procedural structure should be explicit, externally inspectable, locally retrievable, and editable from execution feedback, while still leaving final action selection to the LLM.

Figure 1

Figure 1: Knowledge graphs encode factual relations, whereas Procedural Graphs encode state-conditioned transitions between procedures.

The contribution is therefore not merely the use of a graph for tool retrieval. PG combines three properties: attributed transitions between actions and reasoning states, localization of the agent’s current procedural state, and iterative graph refinement subject to validation-based acceptance. This combination is intended to provide stronger control than episodic memory while avoiding the rigidity of a manually specified workflow.

Procedural Graph representation and inference

A PG is a directed, attributed graph G=(V,R,E,Φ)\mathcal{G} = (\mathcal{V}, \mathcal{R}, \mathcal{E}, \Phi). Nodes represent tool actions, reasoning steps, skills, or task statuses. A directed triplet (u,r,v)(u,r,v) states that procedure vv is admissible after procedure uu under relation rr. Each edge carries textual attributes describing its condition, recommended guidance, and pitfalls. The representation can consequently encode both positive procedural knowledge and negative constraints.

For example, an edge from a cash-flow forecast to a fundraising request can specify that the request should be made when projected runway falls below a safety buffer, that financing should be initiated early because capital delivery is delayed, and that a second request must not be submitted while another request remains pending. The edge is thus more expressive than a bare transition: it represents a conditional policy fragment together with execution hazards.

At inference time, the graph is frozen. The system matches the most recent action or procedure in the live trajectory to a graph node, retrieves its outgoing neighborhood—normally up to two hops—and passes that localized subgraph, the task query, and a recent trajectory window to a guidance LLM. The guidance model verbalizes the relevant transition structure into situational advice. The solver then receives this advice as an additional prompt component and selects its own next action.

Figure 2

Figure 2: PG inference localizes the active node, retrieves a connected neighborhood, generates situational guidance, and leaves the final action decision to the solver.

This architecture deliberately uses soft rather than hard control. PG does not constrain decoding to a formally valid action set and does not deterministically execute the graph. The solver can therefore reason outside the graph, but its decision is biased toward graph-supported transitions. This design is important for tasks whose procedures contain branches, exceptions, or underspecified states. It also introduces a dependence on successful node matching: when matching fails, the framework falls back to the full graph, weakening localization and increasing prompt cost.

The paper’s ablation supports the use of localized generative guidance rather than raw graph injection. On fixed Gemini 3.5 Flash subsets, localized generative guidance achieves MultiChallenge accuracy of $89.31$, GDPval rubric score of $63.99$, and ALFWorld success of $81.53$. These values exceed the no-graph baseline by $2.0$, $6.8$, and (u,r,v)(u,r,v)0 points, respectively. Full-graph generative guidance performs substantially worse on ALFWorld, with success falling to (u,r,v)(u,r,v)1, while consuming (u,r,v)(u,r,v)2 average tokens compared with (u,r,v)(u,r,v)3 for localized guidance. Localization therefore functions as both a performance mechanism and a prompt-budget control.

The cost is nontrivial. Although localized guidance reduces solver steps on GDPval from (u,r,v)(u,r,v)4 to (u,r,v)(u,r,v)521.84(u,r,v)(u,r,v)618.80, total token use remains (u,r,v)(u,r,v)7 and (u,r,v)(u,r,v)8 above the no-graph baseline. PG reduces execution length without eliminating the additional inference call needed to synthesize guidance.

Self-evolution and graph editing

The second component is an offline self-evolution loop. Starting from either a hand-designed graph or a minimal (u,r,v)(u,r,v)9 skeleton, the system repeatedly executes training tasks, records successful and failed trajectories, and asks an LLM refiner to propose graph mutations. Mutations can add nodes and edges, delete failure-inducing structures, or revise edge attributes. Attribute revisions are implemented by deleting and re-adding an edge with new textual fields.

The acceptance mechanism is central. A candidate graph is first checked for structural validity, including valid endpoints and reachability to a terminal node. It is then evaluated on a held-out validation set. A candidate is retained only if its validation score is at least that of the currently retained graph. Rejected candidates and their outcomes are stored as negative evidence for subsequent refiner calls. This prevents the refiner from repeatedly proposing known failures and, more importantly, separates the retained graph from transient candidates that perform well only on the current training batch.

The validation gate does not guarantee monotonic improvement on unseen test data, particularly because the validation set is repeatedly consulted during evolution. The paper explicitly reports this distinction in the EnterpriseArena experiment: the best intermediate checkpoint reaches vv0 test survival, but the returned graph reaches vv1. The latter is reported because selecting the best test checkpoint would constitute test-set selection. With only vv2 episodes per split in this evolution study, individual acceptance decisions can depend on one or two episodes; the results should therefore be interpreted as an engineering trace rather than a high-powered statistical estimate.

Figure 3

Figure 3: Self-evolution improves validation performance through accepted and rejected graph mutations, while the returned checkpoint remains distinct from the best intermediate test result.

The graph changes are interpretable. In EnterpriseArena, the first accepted mutation creates a sequential backbone that audits cash, forecasts runway, saves notes, checks market conditions, and only then makes a financing decision. A later mutation adds note recall at the beginning of each monthly cycle, externalizing working memory. Subsequent edits prune a “do nothing” branch and add an administrative bypass after fundraising requests. These changes are not simply parameter updates: they alter the agent’s admissible procedural topology and the textual conditions attached to transitions.

Figure 4

Figure 4: The CFO graph evolves through additions, pruning, and restructuring of transitions between monthly financial procedures.

The construction experiments provide evidence against the assumption that human initialization is always beneficial. Starting from the hand-designed expert graph lowers MultiChallenge overall success from the unguided baseline’s vv3 to vv4. A one-time static update makes the result worse, at vv5. Iterative validation-gated evolution recovers performance to vv6, a vv7-point improvement over the flawed expert initialization. Starting from the minimal skeleton and evolving online reaches vv8 on MultiChallenge and achieves vv9 F1 on HotpotQA, compared with uu0 for the unguided baseline.

These results support the paper’s stronger claim that a procedural prior can be learned from execution traces and that iterative refinement can repair an unsuitable expert prior. They do not establish that automatically generated graphs are generally superior to expert graphs: on MultiChallenge, the evolved expert initialization reaches uu1, slightly above the scratch-evolved configuration’s uu2. The result instead indicates that initialization quality and refinement protocol interact substantially.

Main benchmark results

The principal evaluation covers HotpotQA, MultiChallenge, GDPval, ALFWorld, uu3-bench, and BFCL v3, using Claude Sonnet 4.6, Gemini 3.1 Pro, Gemini 3.5 Flash, and Grok 4.1 Fast. All methods use the same ReAct solver and differ in their memory or procedural artifact. The comparison includes unstructured summaries, retrieved trajectories, distilled insights, conditional guidelines, workflows, and textual action-transition rules.

PG ranks first or joint first in uu4 of uu5 model–benchmark combinations. Against the strongest baseline in each setting, it records uu6 wins, two ties, and three losses; excluding ties, the reported one-sided exact binomial sign test gives uu7. The largest margins occur on BFCL v3 with Gemini 3.5 Flash, where PG reaches uu8 versus uu9; GDPval with Gemini 3.1 Pro, where it reaches rr0 versus rr1; and rr2-bench with Gemini 3.1 Pro, where it reaches rr3 versus rr4.

Benchmark and model PG Strongest baseline Margin
BFCL v3, Gemini 3.5 Flash rr5 rr6 rr7
GDPval, Gemini 3.1 Pro rr8 rr9 $89.31$0
$89.31$1-bench, Gemini 3.1 Pro $89.31$2 $89.31$3 $89.31$4
ALFWorld, Gemini 3.1 Pro $89.31$5 $89.31$6 $89.31$7
MultiChallenge, Claude Sonnet 4.6 $89.31$8 $89.31$9 tie
HotpotQA, Gemini 3.1 Pro $63.99$0 $63.99$1 $63.99$2

The gains are not uniform. HotpotQA margins range from $63.99$3 to $63.99$4 points, indicating that PG offers little advantage when the principal difficulty is answer retrieval rather than sustained procedural control. Conversely, the largest improvements occur on tasks involving multi-turn constraints, tool sequencing, professional workflows, or function-call state transitions. The implication is that PG’s benefit depends on procedural dependency structure rather than on graph augmentation alone.

A notable result is PG’s consistently strong performance on GDPval and BFCL v3: it outperforms every baseline under all four evaluated LLMs on both benchmarks. On MultiChallenge, it ranks first or joint first for every model. These cross-model patterns reduce the likelihood that the observed gains arise solely from compatibility with one solver family, although the guidance model, refiner, and solver always share the same underlying LLM. Transfer across heterogeneous solvers is therefore not tested.

Long-horizon financial decision making

EnterpriseArena evaluates monthly financial decisions over as many as $63.99$5 months, with delayed financing delivery, strict liquidity constraints, and three undisclosed macroeconomic crises. The task exposes a procedural dependency that is poorly represented by a flat history: financing must be requested before cash depletion because capital arrives after a stochastic delay of one to six months.

PG improves full-horizon survival for Claude Sonnet 4.6, Gemini 3.1 Pro, and Grok 4.1 Fast. Survival increases from $63.99$6 to $63.99$7 for Claude, from $63.99$8 to $63.99$9 for Gemini 3.1 Pro, and from $81.53$0 to $81.53$1 for Grok. For Gemini 3.5 Flash, no configuration achieves full-horizon survival, but PG increases mean lifespan from $81.53$2 to $81.53$3 months and raises average capital received from $81.53$40.00$81.53$5$81.536M.</p><p><imgsrc="https://images.emergentmind.com/paper−images/2609−09153/combinedensemblecashcomparison.png"alt="Figure5"title=""class="markdown−image"loading="lazy"></p><p><pclass="figure−caption">Figure5:PG−guidedagentsmaintainhighersurvivalandmorestablecashtrajectoriesacrossseveralLLMs,althoughtheweakestsolverremainsunabletocompletethefullhorizon.</p></p><p>Themechanismisanticipatoryratherthanmerelyconservative.PG−guidedagentsarepromptedtoforecastrunway,inspectmarketconditions,initiatefinancingearly,andadvancethesimulationwhilewaitingforcapitaldelivery.Thispreventsthecommonfailureofrequestingfinancingonlyafterliquidityhasbecomecritical.Inthereportedtraces,unguidedagentssubmitasecondrequestwhileanearlierrequestispending,whereasthegraph−guidedagentpreservesthesingle−pending−requestconstraintandusesmonthlytransitionstoawaitdelivery.</p><p>ToolcountsshowthatPGchangesactiontimingandcompositionratherthansimplyreducingtooluse.ForGemini3.5Flash,PGreducesinformation−toolcallsfrom6M.</p> <p><img src="https://images.emergentmind.com/paper-images/2609-09153/combined_ensemble_cash_comparison.png" alt="Figure 5" title="" class="markdown-image" loading="lazy"></p> <p><p class="figure-caption">Figure 5: PG-guided agents maintain higher survival and more stable cash trajectories across several LLMs, although the weakest solver remains unable to complete the full horizon.</p></p> <p>The mechanism is anticipatory rather than merely conservative. PG-guided agents are prompted to forecast runway, inspect market conditions, initiate financing early, and advance the simulation while waiting for capital delivery. This prevents the common failure of requesting financing only after liquidity has become critical. In the reported traces, unguided agents submit a second request while an earlier request is pending, whereas the graph-guided agent preserves the single-pending-request constraint and uses monthly transitions to await delivery.</p> <p>Tool counts show that PG changes action timing and composition rather than simply reducing tool use. For Gemini 3.5 Flash, PG reduces information-tool calls from 81.53$7 to $81.53$8 per month while improving lifespan and capital raised. For Claude and Gemini 3.1 Pro, tool calls increase from $81.53$9 to $2.0$0 and from $2.0$1 to $2.0$2 per month, respectively, while survival also improves. The relevant effect is therefore procedural sequencing: additional checks can be beneficial when they occur before a financing decision, whereas repeated redundant queries are harmful.

The ten-round evolution study is particularly informative. Validation survival rises from $2.0$3 for the skeleton baseline to $2.0$4 after the first round and $2.0$5 after the second. Later accepted edits raise validation survival to $2.0$617.23$2.0$73.08$2.0881.8%881.8\%2.0985.0%985.0\%6.800.0%00.0\%6.81p=2.6×10<sup>−81p = 2.6 \times 10<sup>{-8}6.8$220$ episodes per split and performs repeated validation-based search, the test result is strong in this configuration but should not be interpreted as a general estimate of deployment reliability.

Limitations and open questions

The method depends on several assumptions that constrain interpretation. First, all guidance and refinement calls use the same LLM family as the solver and greedy decoding. The experiments therefore do not establish whether a PG learned or refined by one model transfers to another model, nor whether guidance generated by a separate model changes the results.

Second, the graph is tied to exact procedure matching. If the most recent action cannot be matched to a node, the system exposes the full graph, which can increase context length and reduce the advantages of localization. The paper does not report systematic match-failure rates or sensitivity to paraphrased tool names, newly introduced tools, or changes in tool interfaces.

Third, PG guidance adds inference and token overhead. The best-performing localized configuration still consumes substantially more tokens than the no-graph baseline on GDPval and ALFWorld. The paper identifies selective or reusable guidance as a possible mitigation, but does not evaluate caching, amortization, or adaptive guidance frequency.

Fourth, the validation gate is score-based and does not provide formal safety guarantees. A candidate can be structurally valid while encoding semantically incorrect conditions, and acceptance by a finite validation set can favor stochastic or dataset-specific behavior. The authors’ distinction between the best intermediate test checkpoint and the returned graph is methodologically appropriate, but the small episode counts in the evolution study make individual mutation decisions statistically unstable.

Finally, the experiments establish improvements relative to memory and workflow baselines, but not whether the same gains could be obtained by a carefully engineered state machine, constrained decoder, or stronger planning prompt with comparable inference cost. The paper also leaves open how PGs should transfer across task distributions, whether graph edits can be verified independently of an LLM refiner, and how to handle environments whose valid transition structure is nonstationary.

Conclusion

The paper presents PG as an explicit procedural-memory mechanism for LLM agents. Its distinguishing design is the combination of attributed state transitions, localized neighborhood retrieval, generative situational guidance, and validation-gated graph evolution. Across six benchmarks and four LLMs, PG ranks first or joint first in $6.8$3 of $6.8$4 settings, with especially large gains on function calling, professional tasks, and policy-constrained interaction. In long-horizon financial simulation, it improves survival and induces earlier, constraint-compliant financing behavior.

The results support the narrower claim that externally represented, editable procedural structure can improve LLM-agent execution beyond flat memory artifacts. They also show that iterative refinement can recover from a harmful expert prior and construct useful graphs from minimal initialization. The remaining empirical questions concern transfer across solvers and interfaces, robustness to imperfect localization, and whether the performance gains justify the additional token and inference costs.

Whiteboard

Explain it Like I'm 14

1. What is this paper about?

This paper introduces a new way to help LLM agents make better decisions.

An LLM agent is a computer program powered by an AI LLM. It can do more than answer questions: it can use tools, search the internet, call computer programs, or make a series of decisions to complete a task.

The problem is that these agents can get confused during long tasks. They might:

  • Forget the main goal
  • Use tools in the wrong order
  • Repeat actions that do not help
  • Skip important steps
  • Fail to prepare for future problems

The researchers propose a system called a Procedural Graph (PG). It works like a map of the steps an agent should usually follow.

2. What questions are the researchers asking?

The paper mainly asks:

  1. Can a graph help an AI agent remember what it should do next?
  2. Can the graph help the agent avoid mistakes, repeated actions, and incorrect tool use?
  3. Can the graph improve itself by studying which attempts succeeded and which failed?
  4. Can a graph built from almost nothing perform as well as, or better than, one designed by human experts?
  5. Can the system repair a badly designed set of instructions?

The researchers are especially interested in long tasks where actions depend on one another. For example, a business-planning agent might need to:

  1. Check how much money is available.
  2. Predict how long the money will last.
  3. Decide whether more money is needed.
  4. Request funding early enough for it to arrive.

Skipping step 1 or 2 could lead to a bad decision.

3. How does the method work?

A graph for actions

A normal knowledge graph connects facts. For example:

1

Paris → is the capital of → France

A Procedural Graph connects actions and steps:

1
2

Check cash → leads to → Forecast runway
Forecast runway → may lead to → Request funding

Here, each point in the graph is called a node. A node might represent:

  • A tool action
  • A reasoning step
  • A task situation
  • A business decision

The arrows between nodes show which actions can reasonably come next. Each arrow also includes extra information, such as:

  • Condition: When should this action be used?
  • Guidance: How should it be carried out?
  • Pitfalls: What mistakes should be avoided?

For example:

1
2
3

Condition: Money is expected to run out soon
Guidance: Request funding early because it takes time to arrive
Pitfall: Do not make another request while one is still pending

Using only the relevant part of the graph

The agent does not always read the whole graph. Instead, the system tries to locate the agent’s current position and shows it the nearby part of the graph.

This is similar to using a GPS. If you are driving in one city, you usually need a map of nearby streets, not a map of the entire world.

The system then uses another LLM, called the guidance model, to turn the nearby graph information into simple advice, such as:

“You have checked the current cash level. Now forecast how long the money will last before deciding whether to request funding.”

The main agent receives this advice but is not forced to follow it exactly. This is important because the agent still needs freedom to reason about unusual situations.

Learning from successes and failures

The graph can also improve over time. The system follows four basic steps:

  1. Run the agent on tasks. The researchers record what the agent did and whether it succeeded.
  2. Compare successful and failed attempts. An LLM studies the records to find useful patterns and repeated mistakes.
  3. Suggest changes to the graph. It might add a missing step, remove a harmful step, or rewrite advice attached to an arrow.
  4. Test the new graph. The change is kept only if it performs at least as well on separate validation tasks.

This is like testing a new set of rules in a practice game before using it in an important competition. If a change makes things worse, it is rejected. The system remembers rejected changes so it does not keep trying the same bad idea.

4. What did the researchers find?

The researchers tested the Procedural Graph on several types of tasks, including:

  • Answering questions that require searching for multiple facts
  • Following instructions across long conversations
  • Completing professional tasks
  • Performing household actions in the correct order
  • Using computer tools correctly
  • Making financial decisions over many months

They compared the graph-based system with several other methods, including systems that simply store past experiences or written advice.

Better performance across many tasks

The Procedural Graph performed best or tied for best in 21 out of 24 model-and-task combinations.

Compared with the strongest competing method in each test, it had:

  • 19 wins
  • 2 ties
  • 3 losses

The improvements were especially noticeable in tasks involving professional work, function calling, and policy-controlled tool use.

However, the improvement was not equally large everywhere. On some question-answering tasks, the graph helped only a little.

Better performance on long-term financial tasks

The paper also tested agents that acted as company financial managers. These agents had to make decisions over as many as 132 months, including unexpected economic crises.

The graph helped agents survive longer and make better financial choices. For example, one model’s survival rate increased from 6% to 34% when using the Procedural Graph.

One important improvement was that the graph encouraged agents to request funding before a crisis. This mattered because the money took between one and six months to arrive. Without this reminder, some agents waited until they were almost out of money.

The graph could improve itself

The self-evolution system was also successful.

In one experiment, the starting graph had no useful guidance, and none of the test companies survived the entire simulation. After repeated improvements, the final graph reached an 85% survival rate on the test set.

The system also worked when starting from a flawed human-designed graph. In one case:

  • The flawed expert graph scored 58.93%
  • A simple update made it worse, at 53.57%
  • The repeated self-evolution process improved it to 92.86%

This suggests that the system can find and fix problems in human instructions instead of blindly following them.

Local guidance was better than showing the whole graph

The researchers found that showing the agent only the nearby part of the graph was usually better than showing the entire graph.

The local version:

  • Improved accuracy
  • Used fewer tokens than full-graph guidance
  • Reduced the number of unnecessary steps on some tasks
  • Helped the agent focus on what mattered immediately

However, the guidance system still used extra computer tokens because another model had to create the advice. This made the method more expensive, even when it reduced the number of actions.

5. Why are these findings important?

The paper shows that giving an AI agent a structured plan can be more useful than giving it a large pile of past conversations or general advice.

A normal LLM often has to figure out the correct order of actions from a long history. A Procedural Graph makes important connections clearer:

1

Current situation → possible next step → later step

This can help prevent mistakes such as:

  • Using a tool before checking something important
  • Forgetting a required step
  • Repeating the same failed action
  • Waiting too long to prepare for a future event

The graph is also stored outside the model itself. This means people can inspect and edit it without retraining the entire AI model.

Conclusion and potential impact

The main idea of the paper is simple: AI agents may work better when they have an editable map of procedures, not just a memory of past experiences.

The Procedural Graph gives an agent:

  • A clearer idea of what to do next
  • Information about which steps depend on one another
  • Warnings about common mistakes
  • A way to learn from failed attempts
  • The flexibility to make its own decisions when needed

In the future, this approach could make AI assistants more reliable for tasks such as customer service, computer automation, research, household robots, and business planning.

There are still challenges. The system uses extra computing resources to create guidance, and the researchers need to test whether graphs learned for one AI model or tool system work well with others. Even so, the paper suggests that organizing how to act in a graph can make AI agents more careful, effective, and able to improve over time.

View Paper Prompt  View All Prompts 

Knowledge Gaps

Knowledge gaps, limitations, and open questions

  • Limited causal attribution of performance gains: The experiments do not isolate how much improvement comes from graph topology, edge attributes, localization, generative guidance, rejection memory, or the additional LLM call.
  • Incomplete ablation of self-evolution components: The paper does not separately evaluate the effects of the refiner, validation gating, rejection memory, cycle repair, training-batch composition, and candidate-edit restrictions.
  • Unclear reliability of exact action-to-node matching: Online localization uses exact matching between the previous action and a graph node, but the paper does not quantify matching failures, robustness to paraphrased or malformed tool calls, or performance when actions do not correspond cleanly to predefined nodes.
  • No systematic comparison of neighborhood parameters: The choice of a two-hop neighborhood and a three-step trajectory window is fixed; the effects of varying hop depth, trajectory-window size, graph size, and adaptive retrieval are not established.
  • Insufficient analysis of localization failures: When matching fails, the system exposes the full graph to the guidance model, but the consequences of this fallback—such as increased distraction, token cost, or incorrect guidance—are not measured.
  • Unresolved scalability to large and heterogeneous graphs: The experiments do not determine how guidance quality, latency, and cost change as graphs contain thousands or millions of nodes, many relation types, branching procedures, or multiple overlapping tasks.
  • No formal treatment of graph correctness or completeness: The paper does not define metrics for whether a graph contains all necessary transitions, excludes unsafe transitions, correctly represents prerequisites, or remains semantically consistent after repeated edits.
  • Potentially unsafe deletion of valid procedures: The evolution loop can delete nodes or edges that correlate with failures, but it does not examine whether rare yet essential transitions are removed because of sparse observations or distributional imbalance.
  • Validation-gate sensitivity to stochastic evaluation: Acceptance is based on non-decreasing validation scores, sometimes with only a small number of episodes. The paper acknowledges that one or two episodes can determine decisions but does not provide confidence-aware gating, repeated-rollout estimates, or statistical correction for sequential selection.
  • Risk of validation overfitting across evolution rounds: Repeatedly evaluating candidates on the same validation set may cause the graph-search process to overfit validation tasks, even though the final test score is reported separately.
  • Limited evidence for rejection-memory effectiveness: Rejection memory is presented as a safeguard, but no ablation establishes whether it improves convergence, prevents cycles in edit proposals, or introduces excessive memory and context costs.
  • Unclear behavior under non-stationary environments: The framework is tested with scheduled crises and delayed feedback, but its ability to update procedures safely when tool APIs, policies, task objectives, or environment dynamics change is not evaluated.
  • Weak assessment of transfer across task domains: Although multiple benchmarks are used, the paper does not test whether a graph learned in one domain can transfer to a related domain, new tool set, new organization, or unseen task family without extensive re-evolution.
  • No transfer across solver and guidance models: The conclusion identifies this as future work, but the experiments always use the same underlying LLM for solver, guidance model, and refiner. Consequently, model-specific versus representation-level benefits remain unclear.
  • Unexamined dependence on proprietary and frontier models: The evaluation does not establish whether the method works with open-weight, smaller, locally hosted, or substantially weaker models, nor how model capability affects graph usefulness.
  • No evaluation of graph portability across tool interfaces: Procedures may encode tool-specific names, formats, and action semantics. The paper does not test whether the same graph can be adapted to equivalent tools with different APIs or argument schemas.
  • Limited robustness to adversarial or misleading observations: The framework does not evaluate prompt injection, corrupted tool outputs, deceptive environment feedback, malicious users, or observations designed to trigger inappropriate graph transitions.
  • No safety guarantees despite explicit transition structure: Graph edges are described as admissible transitions, but the system remains a soft guidance mechanism and the solver can ignore them. The paper does not quantify invalid-action rates or provide guarantees that unsafe or policy-violating actions are prevented.
  • Unclear interaction between guidance and solver reasoning: The paper reports outcome improvements but does not analyze when guidance is ignored, misunderstood, over-followed, or causes the solver to suppress a better novel plan.
  • Potential restriction of exploration and creativity: Because the graph biases the solver toward existing transitions, the effect on discovering genuinely novel strategies or handling tasks outside the graph’s coverage remains unexplored.
  • No explicit uncertainty representation in graph attributes: Edge conditions and guidance are textual and appear deterministic, with no confidence, provenance, applicability probability, or uncertainty estimate for conflicting or weakly supported procedures.
  • Lack of conflict-resolution mechanisms: The paper does not specify how the guidance model handles contradictory edges, mutually incompatible conditions, duplicate nodes, cyclic alternatives, or multiple procedures applicable at the same time.
  • Insufficient analysis of graph-edit quality: The refiner’s proposed edits are generated by an LLM, but the paper does not report edit precision, semantic validity, redundancy rate, frequency of invalid edits, or how often accepted edits are actually responsible for the observed improvement.
  • No human or expert evaluation of learned graphs: Performance scores are used as the primary criterion, leaving unresolved whether evolved graphs are interpretable, faithful to domain procedures, auditable, or understandable to practitioners.
  • Limited reproducibility of graph construction: The paper provides high-level construction modes but does not fully specify all prompts, initial graph contents, edit constraints, graph-normalization rules, and randomization procedures needed to independently recreate the reported graphs.
  • Potential benchmark contamination and task-specific tailoring: The extent to which graph initialization, prompts, attributes, or evolution procedures were customized to individual benchmarks is unclear, making it difficult to determine how much of the performance reflects generality versus task-specific engineering.
  • Unequal baseline implementation burden: Although the baselines share a solver, their adaptation and implementation details may differ substantially. The paper does not establish that all baselines receive comparable prompt optimization, retrieval tuning, trajectory budgets, or computational resources.
  • No comprehensive cost-benefit analysis: Guidance increases token consumption substantially on some tasks, but the paper does not report end-to-end monetary cost, latency, energy use, throughput, or the cost of offline evolution relative to the performance gains.
  • Unclear long-term maintenance cost: The paper does not study graph growth, attribute staleness, rejection-memory accumulation, edit conflicts, or the need for periodic pruning and version management over many evolution rounds.
  • Limited sample sizes for several conclusions: Some reported evaluations use small numbers of episodes, particularly EnterpriseArena evolution and survival experiments, which limits confidence in fine-grained comparisons and rare-event estimates.
  • Incomplete statistical analysis across benchmarks and models: The sign test aggregates heterogeneous tasks and models, while the paper does not report paired per-example significance tests, correction for multiple comparisons, effect-size distributions, or variance across independent runs.
  • Insufficient evaluation of rare and catastrophic failures: Aggregate accuracy, success, and survival scores may obscure whether PG reduces severe failures, unsafe tool calls, irreversible financial decisions, or long repetitive loops.
  • No analysis of performance degradation from incorrect guidance: The paper reports average improvements but does not characterize worst-case failures when graph attributes are wrong, outdated, incomplete, or misleading.
  • Unresolved dependence on expert-designed schemas: Although the graph can be initialized from scratch, the attribute schema, relation vocabulary, structural checks, and cycle-repair rules are configured manually. The extent of human effort required for new domains remains unknown.
  • Limited support for parallel, conditional, or partially ordered procedures: The formalism uses directed transitions and local outgoing neighborhoods, but its handling of concurrent actions, optional branches, loops with state-dependent termination, temporal constraints, and resource dependencies is not demonstrated.
  • No explicit state-estimation mechanism: Active-node localization is based primarily on the latest action rather than a principled estimate of the agent’s latent task state. The impact of ambiguous progress, failed tool calls, retries, and externally induced state changes is not evaluated.
  • Unclear handling of multi-agent or multi-user settings: The experiments focus on a single solver trajectory. Coordination among multiple agents, shared graphs, conflicting users, permissions, and agent-specific procedural states remain unexplored.
  • No study of graph poisoning or malicious evolution: Because execution traces influence graph edits, an attacker or faulty data source might induce harmful transitions or suppress valid ones. The framework lacks an evaluation of poisoning resistance, provenance tracking, or rollback guarantees.
  • Open question about when soft guidance should become hard control: The paper does not establish criteria for deciding which transitions should merely be recommended and which should be enforced through action masking, type checking, or formal workflow constraints.
  • Unresolved generality beyond tool-use trajectories: Most evidence concerns tool calls, structured actions, or benchmark workflows. It remains unclear how effectively Procedural Graphs represent open-ended reasoning, writing, research, negotiation, or tasks whose procedures cannot be discretized into stable nodes.
View Paper Prompt  View All Prompts 

Practical Applications

Immediate Applications

The paper’s results support deployment of Procedural Graphs as an external, editable control layer for existing LLM agents. These applications can be implemented without retraining the underlying model, provided that the agent has identifiable tools, observable execution traces, and an evaluable task objective.

  • Reliable enterprise workflow agents — software and business operations. Organizations can add a Procedural Graph to agents that execute multi-step workflows such as invoice processing, procurement, customer onboarding, IT support, compliance checks, and report generation. Nodes can represent tools or workflow states, while edge attributes encode prerequisites, conditions, formatting requirements, and known pitfalls. The graph can be inspected and updated by process owners rather than embedded in model weights. Dependencies: stable tool names or action schemas, access to execution logs, domain-specific evaluation metrics, and safeguards preventing unauthorized tool calls.
  • Policy-compliant customer-service and operations agents — finance, telecommunications, insurance, and government services. A graph can encode permissible transitions such as identity verification → account lookup → eligibility assessment → action request. The agent would receive local guidance about which step is valid and which actions are prohibited. This is particularly relevant to the paper’s results on τ\tau-bench-style policy compliance and multi-turn instruction retention. Dependencies: policies must be represented accurately and versioned; high-risk actions still require deterministic validation or human approval because generated guidance does not guarantee compliance.
  • Function-calling and API orchestration — software engineering and cloud services. Tool providers can create graphs describing API dependencies, for example: authenticate → retrieve resource → validate parameters → execute mutation → confirm result. Local subgraph retrieval can reduce irrelevant tool descriptions and discourage repeated or out-of-order calls. A practical product would be a Procedural Graph middleware layer placed between an LLM planner and an API gateway. Dependencies: tools must expose machine-readable schemas, action matching must reliably map calls to graph nodes, and graph updates must be tested against backward compatibility.
  • Embodied household and industrial robot control — robotics and automation. Robots can use graph transitions to represent action orderings such as locate object → verify graspability → pick up → transport → place → confirm state. The ALFWorld results suggest that localized guidance is more useful than injecting a full workflow into the model, especially when action order is strict. Dependencies: accurate state estimation, reliable perception-to-node matching, low-latency inference, and a separate safety controller for collision avoidance and physical constraints.
  • Long-horizon financial planning assistants — finance and treasury operations. The graph can encode procedures such as monitor cash → forecast runway → check market conditions → request financing early → track pending funds. The EnterpriseArena findings specifically suggest that procedural guidance can encourage anticipatory fundraising and reduce redundant observations. This could support CFO dashboards, cash-management copilots, or internal treasury decision support. Dependencies: access to timely financial data, calibrated forecasting models, explicit risk limits, regulatory review, and human authorization for borrowing, investment, or payment decisions. The simulator results should not be interpreted as evidence of autonomous real-world financial competence.
  • Adaptive incident-response assistants — cybersecurity and IT operations. A graph can encode incident procedures such as detect alert → enrich evidence → assess severity → isolate affected asset → preserve logs → remediate → verify recovery. Failed traces can identify missing verification steps or actions that create loops. Rejection memory can prevent repeatedly trying known-unsuccessful remediation sequences. Dependencies: trustworthy telemetry, strict permissions, rollback mechanisms, and isolation of the self-evolution process from production systems. Changes should first be validated in a staging environment.
  • Documented and auditable AI workflows — regulated industries and governance. Because the graph is explicit and editable, organizations can use it as an auditable representation of how an agent is expected to act. Reviewers can inspect nodes, transitions, conditions, and pitfalls, while validation gating provides a measurable criterion for accepting revisions. This can complement model cards, standard operating procedures, and internal controls. Dependencies: graph versions, mutation histories, validation datasets, access-control policies, and independent audits. An editable graph improves transparency but does not by itself establish formal explainability.
  • Educational planning and tutoring systems — education. A tutoring agent can represent procedures such as diagnose misconception → provide prerequisite explanation → ask a targeted question → evaluate response → select next exercise. The graph can be adapted from student interaction traces while retaining teacher-authored constraints. Multi-turn instruction retention makes the approach relevant to tutoring sessions that must preserve goals and learner preferences. Dependencies: pedagogically valid graph design, protection of student data, teacher review, and evaluation based on learning outcomes rather than conversational fluency alone.
  • Personal productivity assistants — daily life. Consumer assistants could use procedural graphs for recurring tasks such as travel planning, moving house, filing expenses, preparing tax documents, or managing appointments. The graph would help preserve dependencies—for example, checking cancellation rules before booking a replacement—and avoid repeated searches or actions. Dependencies: user confirmation for consequential actions, up-to-date external services, privacy-preserving storage, and recovery when real-world conditions differ from the graph.
  • Academic research and laboratory automation — academia and science. Research assistants can encode reproducible workflows such as search literature → screen papers → extract variables → validate citations → run analysis → archive outputs. Laboratory agents could use graphs for sample preparation, instrument setup, quality control, and result logging. Failed experimental traces could suggest missing controls or verification steps. Dependencies: domain experts must define valid procedures, scientific results require independent verification, and self-evolution must not silently alter experimental protocols or data-processing assumptions.
  • A practical development workflow for agent improvement — AI engineering. Teams can deploy the following cycle immediately: initialize a minimal or expert graph, log successful and failed trajectories, propose graph edits with an LLM, evaluate candidates on held-out tasks, retain only non-degrading candidates, and store rejected edits as negative evidence. This offers a lower-cost alternative to retraining for adapting an agent to a new tool environment. Dependencies: sufficiently representative validation sets, deterministic or statistically controlled evaluations, protection against leakage between training and validation tasks, and monitoring for stochastic score fluctuations.

Long-Term Applications

The following applications are plausible extensions of the paper’s findings but require broader validation, stronger guarantees, or significant systems development before deployment in high-stakes settings.

  • Cross-domain procedural knowledge libraries — general-purpose agent platforms. A platform could maintain reusable graph modules for common procedures such as authentication, payment, escalation, verification, and exception handling, then compose them for new tasks. This would turn procedural knowledge into a portable artifact that can be reused across models and applications. Dependencies: research is needed on graph transfer across different solvers, tool interfaces, vocabularies, and environments—the paper explicitly identifies this as future work. Semantic alignment and version compatibility are major unresolved issues.
  • Self-evolving agents for dynamic business processes — enterprise automation. Agents could continuously discover new procedural branches from execution feedback as organizations change policies, software, or market conditions. Validation gating and rejection memory could provide a conservative mechanism for accepting improvements while avoiding known failures. Dependencies: offline evaluation may not represent rare or adversarial conditions; non-decreasing validation performance does not ensure safety, fairness, or robustness under distribution shift. Human approval and formal policy constraints would be necessary for consequential changes.
  • Safety-certified procedural control for autonomous robots and vehicles — robotics. Procedural Graphs could serve as a high-level task planner above formally verified motion and safety controllers. The graph might encode allowable mission stages while deterministic modules enforce physical constraints. Dependencies: the current method relies on LLM-generated guidance and approximate action matching, which are insufficient for safety certification. Future work would need formal transition verification, uncertainty handling, real-time guarantees, and rigorous testing in rare-event scenarios.
  • Healthcare care-pathway and clinical coordination agents — healthcare. A graph could encode patient-care procedures such as triage → collect history → order appropriate tests → review results → escalate or follow up. It could also coordinate administrative workflows across clinicians, laboratories, and insurers. Dependencies: clinical deployment requires validated medical content, privacy protection, regulatory approval, calibrated uncertainty, integration with electronic health records, and mandatory clinician oversight. The paper does not evaluate medical safety or diagnostic accuracy, so this is a long-term research direction rather than an immediate autonomous use case.
  • Public-sector policy execution and benefits administration — government and policy. Government agencies could represent eligibility rules, documentation requirements, appeals, and escalation pathways as inspectable procedural graphs. This could make service agents more consistent and expose where policy transitions produce bottlenecks or contradictory instructions. Dependencies: legal rules must be encoded precisely, exceptions and due-process requirements must be preserved, and graph updates need legislative or administrative authorization. Fairness audits and accessible human appeal channels are essential.
  • Multi-agent organizations with shared procedural memory — enterprise and distributed systems. Several specialized agents could share a common graph while operating different tools—for example, a planner, researcher, finance agent, and compliance agent. Graph edges could define handoffs, required evidence, and completion criteria between agents. Dependencies: research is needed on concurrency, conflicting updates, provenance, access control, and responsibility assignment. Shared graphs could amplify a single erroneous procedure across many agents unless updates are strongly isolated and reviewed.
  • Continuous learning for scientific discovery and engineering design — academia and R&D. Self-evolving graphs could capture experimental strategies, failed branches, validation procedures, and instrument-use sequences. Over time, they might help laboratories identify which procedural choices lead to reliable results rather than merely storing textual notes. Dependencies: success metrics must distinguish genuine scientific progress from benchmark optimization; causal attribution, reproducibility, negative-result preservation, and protection against experimental confounding remain open problems.
  • Energy and infrastructure management — energy, utilities, and climate systems. Long-horizon graphs could guide grid maintenance, demand-response actions, battery dispatch, outage restoration, or industrial energy procurement. The EnterpriseArena findings suggest that explicit anticipation of delayed consequences may be valuable in such settings. Dependencies: real-time telemetry, validated physical models, robust handling of uncertainty, cybersecurity, and deterministic fail-safe controls are required. LLM guidance should remain advisory until reliability is demonstrated under extreme events.
  • Financial risk and investment operations — finance. Graphs could encode risk-review sequences, liquidity safeguards, portfolio-rebalancing prerequisites, and escalation rules. Self-evolution might identify recurring failure patterns in simulated or historical decision traces. Dependencies: financial markets are nonstationary and adversarial; simulator performance may not transfer to live markets. Regulatory compliance, model-risk governance, stress testing, explainable decision records, and human approval would be mandatory.
  • Procedural Graph compilers and formal verification tools — software infrastructure. A future toolchain could compile graph nodes and edge attributes into multiple execution forms: LLM prompts, deterministic workflow code, API policies, test cases, and monitoring rules. Candidate graphs could be checked for unreachable states, unsafe cycles, missing termination conditions, and inconsistent permissions before deployment. Dependencies: the current structural checks are limited compared with formal verification. Developing precise graph schemas, temporal constraints, type systems, and semantics-preserving compilation is necessary for dependable production use.
  • Benchmarking and evaluation infrastructure for agent reliability — academia and industry. Procedural graphs can provide a common representation for testing action order, recovery behavior, tool efficiency, instruction retention, and long-horizon resilience. Researchers could compare agents not only by final task score but also by graph violations, redundant calls, failed transitions, and recovery from rejected actions. Dependencies: benchmarks must include distribution shift, rare failures, adversarial instructions, stochastic environments, and cost-sensitive metrics. The paper’s limited episode counts and benchmark-specific graphs indicate that broader replication is still needed.
  • Personalized household and accessibility agents — daily life. Long-term systems could learn individual routines for medication reminders, meal preparation, mobility assistance, appointment coordination, or home-device management while preserving user-specific preferences and safety checks. Dependencies: personalization raises substantial privacy and consent issues; healthcare-adjacent tasks require professional oversight, and the system must gracefully handle ambiguous instructions, changing routines, and emergency situations.
View Paper Prompt  View All Prompts 

Glossary

  • Admissible transition: A transition that is permitted to occur from one procedural state to another. “an edge e=(u,r,v)∈Ee = (u, r, v) \in \mathcal{E} states that node vv is admissible after node uu under relation $r”</li> <li><strong>Attributed graph</strong>: A graph whose nodes or edges carry additional descriptive properties. “Formally, a Procedural Graph is a directed, attributed graph”</li> <li><strong>Ablation</strong>: An experiment that removes or changes a component to measure its contribution to system performance. “Section~\ref{subsec{ablation}} evaluates the resulting performance and efficiency”</li> <li><strong>Binary outcome</strong>: An evaluation result with only two possible categories, typically success or failure. “for tasks with binary outcomes, this reduces to successes versus failures”</li> <li><strong>Cached validation score</strong>: A previously stored performance value used as a reference during later model or graph evaluation. “leaving the retained graph and its cached validation score unchanged”</li> <li><strong>Conditional guidance</strong>: Advice whose applicability depends on the current state or circumstances. “Existing approaches provide procedural structure through textual memory, conditional guidelines, and explicit workflows.”</li> <li><strong>Confidence interval</strong>: A statistical range expressing uncertainty around an estimated quantity. “Brackets give $95\%confidenceintervals;thebestvalueishighlighted.”</li><li><strong>Cyclerepair</strong>:Aprocedurethatmodifiesagraphtoaddressunwantedcyclicstructures.“where confidence intervals; the best value is highlighted.”</li> <li><strong>Cycle repair</strong>: A procedure that modifies a graph to address unwanted cyclic structures. “where \oplusapplieseditstoacopyandperformsanyconfiguredcyclerepair”</li><li><strong>Diagnostictrace</strong>:Arecordedsequenceofactions,observations,andevaluationinformationusedtoanalyzeanagent’sbehavior.“anLLMrefineranalyzesthediagnostictracesandmodifiesthegraphtopologyandattributes”</li><li><strong>Directedgraph</strong>:Agraphwhoseedgeshaveaspecifieddirectionfromonenodetoanother.“TheProceduralGraph(PG),anexplicitandeditabledirectedgraphofproceduralknowledge”</li><li><strong>Directededgeneighborhood</strong>:Thesetofnodesandoutgoingtransitionsreachablefromanodewithinaspecifiednumberofsteps.“Thedirectededgeneighborhood applies edits to a copy and performs any configured cycle repair”</li> <li><strong>Diagnostic trace</strong>: A recorded sequence of actions, observations, and evaluation information used to analyze an agent’s behavior. “an LLM refiner analyzes the diagnostic traces and modifies the graph topology and attributes”</li> <li><strong>Directed graph</strong>: A graph whose edges have a specified direction from one node to another. “The Procedural Graph (PG), an explicit and editable directed graph of procedural knowledge”</li> <li><strong>Directed edge neighborhood</strong>: The set of nodes and outgoing transitions reachable from a node within a specified number of steps. “The directed edge neighborhood \mathcal{N}_h(u_t)contains contains u_tandtheoutgoingtransitionsreachedbyexpandingforupto and the outgoing transitions reached by expanding for up to h$ steps.”</li> <li><strong>Ensemble trajectory</strong>: A combined representation of trajectories produced by multiple model runs or agents. “Figure~\ref{fig:cfo_ensemble_trajectories} plots the Kaplan-Meier survival curves and the ensemble cash trajectories for all four models”</li> <li><strong>Expert prior</strong>: Pre-existing knowledge or structure supplied by a human expert before learning or refinement. “The graph can be initialized from an expert prior or from scratch”</li> <li><strong>Fisher’s exact test</strong>: A statistical test for evaluating the association between categorical variables, especially with small samples. “Fisher&#39;s exact $p = 2.6\times10^{-8}$”
  • Full-horizon survival: Continued task or system operation throughout the entire evaluation period. “PG achieves the highest or joint-highest full-horizon survival and the longest average lifespan across all four LLMs.”
  • Generative guidance: Guidance produced dynamically by a LLM from graph information and the agent’s current context. “Generative Procedural Graph Guidance addresses this by combining three operations: locate, extract, and generate.”
  • Held-out validation set: Data reserved for evaluating candidate models or structures without using it for their direct construction. “A structurally valid candidate graph is adopted if it matches or improves performance on a held-out validation set”
  • In-context exemplar: A previous example included in a model’s prompt to influence its behavior without parameter updates. “RAP~\citep{kagaya2024rap}, which retrieves past trajectories as in-context exemplars”
  • Kaplan–Meier survival curve: A statistical curve estimating the probability that an entity remains operational over time while accounting for censored observations. “Figure~\ref{fig:cfo_ensemble_trajectories} plots the Kaplan-Meier survival curves and the ensemble cash trajectories for all four models”
  • Long-horizon task: A task requiring coordinated decisions over an extended sequence or time period. “To evaluate agent resilience on long-horizon tasks”
  • Macro­economic shock: A large-scale economic event that affects financial conditions or resource availability. “EnterpriseArena~\citep{han2026can} for long-horizon financial decision-making under delayed feedback and macroeconomic shocks.”
  • Negative constraint: Information specifying an action or modification that should be avoided. “rejected candidates are retained as negative constraints”
  • One-sided exact binomial sign test: A statistical test assessing whether one method wins more often than another under a directional hypothesis. “one-sided exact binomial sign test excluding ties, p=4.3×10−4p = 4.3\times10^{-4}”
  • Procedural knowledge: Knowledge about the steps, ordering, and conditions required to accomplish a task. “a PG organizes procedural information into (procedure, relation, procedure) triplets to answer what-to-do questions”
  • Rejection memory: A record of unsuccessful candidate modifications used to prevent repeating them. “The rejection history $\mathcal{H}_{\text{rejected}$ helps the refiner avoid previously unsuccessful edits.”
  • Retrieval-augmented planning: Planning that uses externally retrieved information or prior trajectories to guide decision-making. “RAP~\citep{kagaya2024rap}, which retrieves past trajectories as in-context exemplars”
  • Self-evolution: Iterative automated improvement of a system based on execution feedback and evaluation. “We develop a self-evolution loop that refines graph topology and attributes using execution feedback.”
  • Situational guidance: Context-specific advice generated for an agent’s current state and immediate decision. “the guidance model reads the surrounding subgraph in its topological context and translates the relevant edge attributes into situational guidance for the next step”
  • Structural mutation: A modification to the organization or connectivity of a graph. “To assess whether structural mutations improve performance beyond the training batch”
  • Structural validity: Compliance of a candidate graph with required graph-structure constraints. “a candidate that passes edit application and structural checks is evaluated on an independent validation set”
  • Topological context: The connectivity and relative organization of elements within a graph. “Ψ\Psi translates the static attributes Φ(e)\Phi(e) of the surrounding edges into situational guidance gtg_t”
  • Topology: The structure of connections among nodes in a graph. “an LLM refiner contrasts failed trajectories with successful ones and proposes edits to the graph's topology and attributes”
  • Trajectory window: A bounded portion of an agent’s recent sequence of actions and observations. “The window Tt−w:t\mathcal{T}_{t-w:t} contains the last ww trajectory steps”
  • Validation gate: A criterion that determines whether a candidate modification is accepted based on validation performance. “The validation gate filters out candidates that reduce the measured score”
  • Validation split: The subset of data used to evaluate candidate systems during development. “On the validation split, the unguided baseline has a full-horizon survival rate of 0.0%0.0\%”
  • Workflow graph: A graph representation of procedural steps and their permissible transitions. “Automated workflow search reduces manual design effort by optimizing workflow structure offline~\citep{zhang2025aflow}”
View Paper Prompt  View All Prompts 

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Generate Now

Tweets

Sign up for free to view the 4 tweets with 993 likes about this paper.

Sign Up for Free