Self-Evolving Agents as Dynamic Graph Transformation: A Survey and New Perspective

1. Introduction

Large language model (LLM)-based agents are evolving from short-horizon task solvers into long-running systems that persist across sessions, accumulate experience, and adapt their behavior over time [1,2]. Their capabilities now include persistent memory, tool use, skill acquisition, workflow optimization, and multi-agent coordination [3,4,5,6]. Consequently, agent states are both non-stationary and structurally evolving: stored knowledge, available capabilities, executable workflows, and inter-agent relations can all evolve through interaction, feedback, and environmental drift. Understanding such systems therefore requires a dynamic structural perspective that accounts for how agent states, capabilities, and relations change over time.

Existing surveys address this problem from two complementary but largely separate perspectives. Graph-agent surveys [7,8] are mainly agent-functionality-centered, studying how mostly static graphs support memory, retrieval, tool use, and multi-agent coordination. Self-evolving-agent surveys [9,10] are mainly agent-evolution-mechanism-centered, studying how agent components adapt via reflection, self-training, self-rewarding, and experience distillation.However, neither perspective fully captures a central property of self-evolving agents: persistent updates to memories, tools, skills, workflows, and inter-agent relations are structurally coupled and can propagate through dependencies over time. As a result, existing surveys provide limited support for modeling, analyzing, and governing agent systems whose states evolve as dynamic structures. This gap motivates a new perspective that jointly models agent functionality, state evolution, and dynamic graph topology, as illustrated in Figure 1.

This survey aims to bridge this gap by framing agent evolution as dynamic graph transformation. Thus, a self-evolving agent can be a structured system of coupled entities and relations. As these structures evolve via interaction, a dynamic graph perspective becomes natural: typed nodes and edges encode heterogeneous states, temporal attributes track evolving evidence, and schema-constrained rewrites model activation, propagation, and rollback. This perspective gives rise to three motivations.

Motivation I: Unifying heterogeneous agent evolution. Existing agent-evolution studies [5,11,12,13,14,15,16,17,18,19,20] span dynamic-graph-based agent methods, graph-structured agent modules, and non-graph mechanisms across memory, tool use, workflow optimization, communication topology, coordination efficiency, and safety governance. Yet these works remain fragmented, with different assumptions, objectives, and evaluation criteria. This motivates a dynamic-graph transformation lens under which heterogeneous evolution mechanisms can be studied together with their downstream dependencies, revisions, and rollbacks.

Motivation II: Connecting dynamic graph learning with self-evolving agents. Dynamic graph learning [21,22,23,24,25,26,27,28,29,30] provides mature foundations for modeling evolving structures, including event streams, temporal dependencies, graph generation, and explanation. These foundations are directly relevant to self-evolving agents, whose memories, tools, skills, workflows, and inter-agent relations also change under new evidence, feedback, and drift [20,31,32,33]. However, the two areas remain largely separate: dynamic graph learning rarely targets persistent agent-state evolution, while agent surveys rarely explain how dynamic graph methods can be reused as agent-evolution infrastructure. This motivates a systematic bridge that connects dynamic graph learning to the design, adaptation, diagnosis, and governance of self-evolving agents.

Motivation III: Toward structure-aware evaluation and governance. Current evaluation of self-evolving agents [34,35,36,37] remains largely task- or answer-centered, which can miss failures in the evolving state: correct answers may rely on stale memories, unsafe updates may propagate through tools or workflows, and untraceable changes may persist across interactions. Recent safety works [38,39,40] reinforce this need: tool-use benchmarks expose failures in invocation, stateful interaction, prompt injection, and harmful multi-step actions, while multi-agent studies [20,41] show that errors and anomalies can propagate through communication structures. These findings require structure-aware evaluation and governance, where execution records are modeled as dynamic dependency graphs to support provenance tracing, affected-scope analysis, rollback, and audit [42].

Contribution. These motivations shape the organization of this survey. We first develop a dynamic-graph perspective on agent evolution, using dynamic graph transformation as a shared formal space for dynamic-graph-based, graph-based, and graph-transformable agent methods. This perspective represents evolving agent states through typed nodes, edges, subgraphs, and dependency-aware rewrites. It yields two core contributions: a four-pattern taxonomy of existing dynamic-graph-based agent works; and a systematic mapping from nine dynamic-graph-learning subfields to agent capabilities. We further extend this structural view to graph-aware evaluation and governance that complements end-task evaluation. Overall, dynamic graph transformation provides the organizing lens connecting agent-evolution mechanisms, dynamic graph learning, and governance protocols, as shown in Figure 1.

This survey makes the following contributions.

• Conceptual Framing: We formalize agent evolution as dynamic graph transformation, representing evolving memories, tools, skills, workflows, and inter-agent relations as typed nodes, edges, and subgraphs.
• Systematic Taxonomy: We organize existing self-evolving agent works through four graph-transformation patterns: node/feature evolution, edge/topology evolution, subgraph activation, and cross-component co-evolution.
• Infrastructure Bridge: We connect dynamic graph learning with self-evolving agent infrastructure by mapping nine dynamic-graph-learning families to advance prediction, activation, generation, diagnosis, rollback, and governance capabilities.
• Evaluation and Governance: We discuss five types of graph-aware evaluation and governance protocols for agent evolution: leakage-free temporal evaluation, privacy and deletion checking, safety monitoring, rollback analysis, and audit.
• Future Agenda: We outline six open challenges for building reliable, auditable, and controllable self-evolving agents under the dynamic graph framing.

Survey Scope. This survey studies self-evolving agents from a dynamic-graph perspective, rather than providing a broad review of self-evolving agents [9,10], graph-supported agent systems [7,8], related agent subareas [43,44], or general dynamic graph learning [21,22,23,24,25].

Organization.Section 2 introduces the background. Section 3 presents agent evolution as dynamic graph transformation, covering existing 46 dynamic-graph-based agent works under a four-part taxonomy. Section 4 treats dynamic graph learning as agent-evolution infrastructure, organized by dynamic graph families. Section 5 discusses graph-aware evaluation and governance, and Section 6 concludes.

2. Preliminaries

Dynamic Agent Graph. We model the state representation of a self-evolving agent system at time t as a dynamic graph

$$\mathcal{G}\left(t\right)=\left(\mathcal{V}\left(t\right),\mathcal{E}\left(t\right),{\mathit{X}}_V\left(t\right),{\mathit{X}}_E\left(t\right),\mathit{Y}\left(t\right)\right),$$

(1)

where $\mathcal{V}\left(t\right)$ and $\mathcal{E}\left(t\right)$ are time-indexed nodes and edges, ${\mathit{X}}_V\left(t\right)$ and ${\mathit{X}}_E\left(t\right)$ denote node and edge attributes, and $\mathit{Y}\left(t\right)$ denotes labels for nodes and edges. Equation (1) can cover diverse dynamic graph types [26,28,45,46,47,48,49], including continuous-time dynamic graphs (CTDGs), discrete-time dynamic graphs (DTDGs), dynamic heterogeneous graphs (DHGs), and dynamic text-attributed graphs (DyTAGs). With this dynamic graph view, we next map agent components to graph primitives. The node and edge schemas define the typed objects and relations in agent graphs, while the rewrite operators characterize how these structures evolve in the mechanisms discussed below.

Graph-Conditioned Agent Policy. Given a user query or environmental input $q_t$, action history $h_t$, and activated support subgraph ${\mathcal{G}}_{\mathrm{act}}\left(t\right)$, the agent selects an action by

$$a_t\sim {\mathcal{P}}_{\theta }\left(·\mid q_t,h_t,{\mathcal{G}}_{\mathrm{act}}\left(t\right)\right),$$

(2)

where $a_t$ may be a natural-language response, a tool call, a workflow step, or a message to another agent. This makes the agent graph operational: graph state matters only insofar as it conditions future agent behavior.

Node Schema. A practical base schema for self-evolving agents includes four core node types: memory, tool, skill, and agent. A memory node represents stored knowledge that may be retrieved or revised over time. A tool node describes an external callable resource, such as an API, database, or environment interface, together with its input–output schema, permissions, and execution history. A skill node captures a reusable capability that can be invoked or adapted across tasks. An agent node represents an autonomous or semi-autonomous actor with a role, policy, memory scope, tool access, and communication interface. These nodes carry type-specific attributes, such as textual content, temporal validity, metadata, and prompts [6,13,20,33,50,51].

Edge Schema. Edges are typed relations among agent-state objects and may be directed when the relation is asymmetric or operationally ordered. A compact edge schema can define three core edge families: dependency edges for state, tool, skill, and workflow dependencies; communication edges for inter-agent interaction; and provenance edges for evidence tracing, updates, and rollback. Finer relations, such as reference and workflow control, can be modeled as subtypes. Edges may also carry features such as timestamps, validity intervals, activation status, or policy tags. When direction matters, edge orientation should follow a fixed operational convention.

Rewrite Operators. Evolution is modeled as the application of an ordered sequence of typed rewrites ${\rho }_1,{\rho }_2,\dots$ to the agent graph. A rewrite is a schema-constrained operation, such as node insertion/deletion, edge insertion/deletion, or feature update; dependency propagation is modeled as a cascade of such rewrites [52]. Subgraph activation is treated as a read-only graph operation that selects a relevant subgraph without committing a state change. The agent proposes candidate rewrites, and feedback from users, tools, or other agents determines whether they are accepted, rejected, or rolled back.

Formal Semantics. We interpret the rewrite operators as typed graph-transformation rules under the double-pushout (DPO) formulation [53,54]. A DPO rule is specified by a span of typed graph morphisms $L\leftarrow K\to R$, where L is the pattern matched in $\mathcal{G}\left(t\right)$, K is the preserved interface, and R is the replacement structure. This formalism provides type safety for heterogeneous schemas and a basis for reasoning about concurrent rewrites through standard DPO concurrency conditions. In standard DPO graph transformation, the gluing conditions determine whether the pushout complement exists and hence whether a rule is applicable; in our agent setting, a violation is treated as an inadmissible rewrite proposal rejected by the runtime. Accepted rewrites are logged with their matches and affected subgraphs, providing graph-level evidence for audit and rollback. Throughout the survey, concrete update schemas are treated as DPO-style rules instantiated at specific matches. Let ${\mathit{s}}_v\left(t\right)=(y_v\left(t\right),{\mathit{x}}_v\left(t\right))$ and ${\mathit{s}}_e\left(t\right)=(y_e\left(t\right),{\mathit{x}}_e\left(t\right))$ denote node and edge states, where $y_v\left(t\right)$ and $y_e\left(t\right)$ are labels and ${\mathit{x}}_v\left(t\right)$ and ${\mathit{x}}_e\left(t\right)$ are attributes. For attributed graphs, $v\left[{\mathit{s}}_v\left(t\right)\right]$ and $e\left[{\mathit{s}}_e\left(t\right)\right]$ denote nodes and edges equipped with these internal states.

Connection to Graph Databases. The agent graph can be implemented as a temporal property graph using temporal graph-database models [55]. Graph transformation tools such as AGG [53] provide executable DPO rule engines that can support implementation.

3. Agent Evolution as Dynamic Graph Transformation

We organize existing self-evolving-agent methods based on dynamic graph/topology techniques by graph-transformation patterns: node/feature evolution, edge/topology evolution, subgraph activation, and cross-component co-evolution. Figure 2 groups 46 representative methods into four branches, while Table 1 projects them into rewrite patterns.

3.1. Node and Feature Evolution

Node and feature evolution, corresponding to Branch A.1 in Figure 2, captures localized changes to individual agent-state components, represented as typed nodes and their attributes. It covers the insertion, revision, merging, or removal of memories, tools, skills, or agent states, along with the evidence needed to justify, validate, or roll back these updates. This abstraction unifies graph-native systems and persistent non-graph mechanisms by treating component updates as transformations over typed node states. Existing works [13,33,50,56] address such updates across memory, tool, skill, and agent adaptation, but often use component-specific terminology rather than an explicit graph-transformation view. We therefore introduce DPO-style schemas for insertion, deletion, feature update, and merge to characterize representative node-level self-evolving-agent works.

DPO Rule Schemas for A.1. Let ${\mathit{s}}_v\left(t\right)=(y_v\left(t\right),{\mathit{x}}_v\left(t\right))$ denote the internal state of node v at time t, where $y_v\left(t\right)$ is its label and ${\mathit{x}}_v\left(t\right)$ is its attribute vector. At the node level, the main typed DPO schemas are:

$$\begin{array}{cc}\hfill & {\mathrm{INSERT}}_{y,\mathit{x}}:L=K=\varnothing ,R=\left\{v_{\mathrm{new}}\left[(y,\mathit{x})\right]\right\},\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill & {\mathrm{DELETE}}_v:L=\left\{v\left[{\mathit{s}}_v\left(t\right)\right]\right\},K=R=\varnothing ,\hfill \\ \hfill & {\mathrm{FEATUREUPDATE}}_{v,\varphi }:L=\left\{v\left[(y_v\left(t\right),{\mathit{x}}_v\left(t\right))\right]\right\},K=\left\{v\right\},\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill & R=\left\{v\left[(y_v\left(t\right),\varphi \left({\mathit{x}}_v\left(t\right)\right))\right]\right\},\hfill \\ \hfill & {\mathrm{MERGE}}_{v_1,v_2,\psi }:L=\{v_1\left[{\mathit{s}}_{v_1}\left(t\right)\right],v_2\left[{\mathit{s}}_{v_2}\left(t\right)\right]\},K=\{v_1,v_2\},\hfill \\ \hfill & R=\{v_1\left[\mathrm{arch}\left({\mathit{s}}_{v_1}\left(t\right)\right)\right],v_2\left[\mathrm{arch}\left({\mathit{s}}_{v_2}\left(t\right)\right)\right],v^{*}\left[\psi ({\mathit{s}}_{v_1}\left(t\right),{\mathit{s}}_{v_2}\left(t\right))\right]\}\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill & \cup {\{e_{*i}^{\mathrm{prov}}:v^{*}\to v_i\}}_{i=1,2}.\hfill \end{array}$$

(6)

Here, L, K, and R are the matched pattern, preserved interface, and replacement graph. $v_{\mathrm{new}}$ is initialized by $(y,\mathit{x})$, $\varphi$ updates attributes, and $\psi$ consolidates matched states into $v^{*}$. $\mathrm{arch}(·)$ archives the source node by marking it as inactive while preserving its identity and label, and $e_{*i}^{\mathrm{prov}}$ records provenance. Evidence-grounded insertion uses a contextual rule with non-empty $L=K$ or a later Link. By the DPO dangling condition, Delete applies only to nodes with no incident edges unless those edges are also removed. Merge is archival consolidation rather than node identification; dependency redirection is handled by later edge rewrites or cascades. We omit Split, since archived states and provenance already support undoing mistaken merges. We next discuss four node-level cases: agent memory, agent skill, agent tool use, and multi-agent evolution.

Agent Memory. Agent memory is an important setting for node-level self-evolution. Existing graph-based memory works can be broadly categorized into relation-centric and consolidation-centric memory graphs. The former [33,61] links memories to entities, events, tasks, and provenance relations for time-aware recall and update tracking; for example, Zep [33] builds an evolving temporal knowledge graph over memory events, entities, and provenance. The latter [32,62,63,64,65] compresses or organizes low-level observations into higher-level structures for long-term recall and reuse; for example, TiMem [32] organizes interaction histories into time-aware memory levels for temporal-hierarchical consolidation. These graph-based systems make the underlying node-level operations explicit: new observations instantiate Insert, consolidation or abstraction instantiates Merge, and correction, decay, quality revision, or invalidation instantiates FeatureUpdate or Delete. Non-graph memory systems [3,89,90,91] can be mapped similarly by treating persistent memory items as typed nodes with evolving attributes. Recent benchmarks [37,92,93] further show growing attention to long-term memory update behavior.

Agent Skill. Agent skills can be represented as capability nodes whose states encode scope, contract, prerequisites, and validation status. Existing skill-related works can be approximately grouped into graph-structured skill retrieval/maintenance and experience-driven skill acquisition. The first line [56,66] organizes reusable skills and dependencies; the second line [12,94,95,96,97,98] learns or revises skills from interaction experience and can be mapped by treating acquired skills as typed nodes with evolving attributes. Under the node-level schemas in Eqs. (3)-(6), new, revised, and consolidated skills correspond to Insert, FeatureUpdate, and Merge, respectively. This framing records skill provenance and dependencies, enabling targeted revalidation when related memories, tools, or workflows evolve.

Agent Tool Use. Agent tool use is a node-level case of self-evolution, where each tool can be treated as a state object encoding its interface, schema, constraints, and reliability. Existing tool-use works can be classified into graph-native tool organization and API-grounded tool learning. Graph-native methods [50,67,68] organize tools, toolchains, or navigation relations as updatable graph structures. Concretely, SEARL [67] maintains tool graph memory so execution feedback can update tool-use structure for later decisions. Additionally, API-grounded methods [99,100,101] improve tool selection or API use without maintaining an explicit evolving tool graph, but can be mapped by treating tool profiles and usage records as typed nodes. Under our schemas, API or documentation drift instantiates FeatureUpdate, reliability revision updates tool attributes, and obsolete tools are deactivated or removed. Tool-use traces and function-call benchmarks [102,103,104,105] provide evidence for validating such updates. This framing treats tool evolution as a persistent state change that may trigger revalidation of dependent skills and workflows (Section 3.4) .

Multi-Agent Evolution. Agents can be modeled as persistent nodes whose states encode role, expertise, permissions, and participation status. Existing multi-agent works fall into dynamic agent participation and protocol-level collaboration. The former [13,14] change which agents participate, specialize, or remain active, where DyLAN [13] builds a dynamic agent network whose active agents and communication relations adapt during collaboration. Furthermore, protocol-level frameworks [106,107,108,109,110] support collaboration policies such as decentralized coordination, procedural orchestration, or plan–execute–verify–replan control. Under our dynamic-graph view, these mechanisms can be represented as updates to agent-node attributes and to communication, dependency, or provenance edges. This connects node-level agent revision to the topology evolution (Section 3.2).

3.2. Edge and Topology Evolution

Edge and topology evolution, corresponding to Branch A.2 in Figure 2, covers self-evolving agent problems where persistent change lies in the relations among components rather than in individual component states. Such evolution reorganizes memory support, tool–skill dependencies, workflow routing, and inter-agent coordination over time. Compared with node and feature evolution, the focus shifts from local state revision to dependency, communication, and execution topology. Existing work addresses these changes in workflow optimization, multi-agent coordination, and dependency management [5,16,56,57,58,68,111,112]. We therefore introduce DPO-style schemas for edge-level transformations and use them to characterize existing topology-level self-evolving agent works.

DPO Rule Schemas for A.2. Let $e_{ij}\left[{\mathit{s}}_{ij}\left(t\right)\right]$ denote an edge between $v_i$ and $v_j$, where ${\mathit{s}}_{ij}\left(t\right)=(y_{ij}\left(t\right),{\mathit{x}}_{ij}\left(t\right))$ is its edge state, consisting of an edge label and edge attributes. At the edge level, we define four typed schemas:

$$\begin{array}{cc}\hfill & {\mathrm{LINK}}_{y,\mathit{x}}:L=K=\{v_i,v_j\},R=K\cup \left\{e_{ij}\left[(y,\mathit{x})\right]\right\},\hfill \\ \hfill & {\mathrm{UNLINK}}_{e_{ij}}:L=\{v_i,v_j,e_{ij}\left[{\mathit{s}}_{ij}\left(t\right)\right]\},\hfill \end{array}$$

(7)

$$\begin{array}{cc}\hfill & K=\{v_i,v_j\},R=K,\hfill \\ \hfill & {\mathrm{REWIRE}}_{e_{ij}\to e_{ik}^{\prime }}:L=\{v_i,v_j,v_k,e_{ij}\left[{\mathit{s}}_{ij}\left(t\right)\right]\},\hfill \end{array}$$

(8)

$$\begin{array}{cc}\hfill & K=\{v_i,v_j,v_k\},R=K\cup \left\{e_{ik}^{\prime }\left[{\mathit{s}}_{ij}\left(t\right)\right]\right\},\hfill \\ \hfill & {\mathrm{EDGEFEATUREUPDATE}}_{e_{ij},\varphi }:L=\left\{e_{ij}\left[(y_{ij}\left(t\right),{\mathit{x}}_{ij}\left(t\right))\right]\right\},\hfill \end{array}$$

(9)

$$\begin{array}{cc}\hfill & K=\left\{e_{ij}\right\},R=\left\{e_{ij}\left[(y_{ij}\left(t\right),\varphi \left({\mathit{x}}_{ij}\left(t\right)\right))\right]\right\}.\hfill \end{array}$$

(10)

Here, Link adds a typed edge, Unlink removes an edge while preserving its endpoints, Rewire replaces $e_{ij}$ with $e_{ik}^{\prime }$, and EdgeFeatureUpdate revises edge attributes while preserving edge identity. Edge direction follows the semantics of the relation, e.g., sender-to-receiver. The key constraint is not edge removal itself, but downstream consistency: removed or redirected edges must not remain referenced by provenance or dependency records. Otherwise, the edit becomes a cross-component cascade (Section 3.4).

Workflow Optimization. Workflow optimization covers self-evolving-agent methods that revise executable structures rather than only selecting a fixed plan at inference time. Existing works can be roughly grouped into workflow/architecture search and task-graph orchestration. The former [5,70,71,72,113,114] searches over agentic workflows, computational graphs, or modular agent designs, while the latter [57,69] constructs task-dependent execution structures or role/task graphs for multi-agent coordination. For example, DynTaskMAS [57] uses a dynamic task graph to decompose tasks, preserve dependencies, and support asynchronous parallel execution. Under our schema, workflow optimization becomes edge rewriting over an executable task graph: components are selected, ordered, connected, or revised while workflow variants remain comparable and dependency changes traceable.

Multi-agent Communication. Multi-agent communication evolution concerns how agents revise information exchange over time. Existing works span from constructing task-adaptive communication structures to pruning or sparsifying inefficient ones. For construction and routing methods [13,16,17,18,74,75,76,78,79,81,82,83], they generate, route, or adapt communication structures according to task context, agent roles, or robustness objectives. For example, GTD [16] formulates multi-agent topology synthesis as conditional graph generation, producing task-adaptive communication graphs. For pruning and sparsification methods [14,58,73,77,80], they remove redundant, costly, unsafe, or low-utility agents or links. Under our schema, these methods instantiate Link, Unlink, Rewire, or EdgeFeatureUpdate over agent–agent communication edges, distinguishing persistent communication-topology evolution from workflow rewriting and temporary team activation.

Skill–Tool Dependencies. Skill–tool dependencies focus on how self-evolving agents maintain relations among skills, tools, preconditions, and data requirements. This includes (1) skill-side dependency maintenance [56], (2) tool-side dependency maintenance [68], and (3) tool–agent dependency retrieval [111], where skills, tools, and parent agents are linked through prerequisites, compatibility, invocation, or ownership relations. SkillOps [56] represents skills as typed contracts in a hierarchical skill ecosystem graph for library-time maintenance, while NaviAgent [68] maintains a tool navigation structure that updates toolchain selection from execution feedback. Under our schema, newly discovered dependencies instantiate Link, invalid dependencies instantiate Unlink, alternative toolchains instantiate Rewire, and reliability changes instantiate EdgeFeatureUpdate. This framing supports targeted revalidation when a skill is revised, a tool drifts, or a dependency is rerouted.

3.3. Subgraph Activation

Subgraph activation (Branch A.3 in Figure 2) captures task-time adaptation in which an agent system selects a transient support subgraph from a persistent graph for reasoning or execution. Here, the central problem of subgraph activation is relevance-conditioned selection: which subset of available states, relations, and components should be activated for the current task, and how this temporary context should constrain the next decision. Existing systems [13,15,33,82,84] often implement this step through retrieval, planning, routing, or coordination procedures, but rarely formulate it as an explicit graph operation. We therefore formalize subgraph activation as a read-only selection schema and use it to characterize representative task-time activation mechanisms.

Read-only Activation Schema for A.3. Read-only activation describes task-time support-subgraph selection without committing any structural change. For a task q and activation policy $\pi$, the agent selects a support subgraph ${\mathcal{G}}_{\mathrm{act}}\left(t\right)\subseteq \mathcal{G}\left(t\right)$. In DPO-style notation, this can be represented as an identity production over the selected pattern:

$$\mathrm{ACTIVATE}:L_{\pi }=K_{\pi }=R_{\pi },\mathrm{img}\left({\mu }_{q,\pi }\right)={\mathcal{G}}_{\mathrm{act}}\left(t\right),$$

(11)

where ${\mu }_{q,\pi }:L_{\pi }\to \mathcal{G}\left(t\right)$ is the match chosen by policy $\pi$ for task q. Thus, q and $\pi$ determine the match, not a persistent rewrite. Its advantage is auditability: evidence use, tool routing, and team selection can be inspected without being mistaken for persistent learning.

Activation Pattern. Most A.3 methods can be viewed as selecting anchors and then exposing limited context around them. An activation policy $\pi$ first scores candidate memories, tools, skills, or agents for the task q, and then expands the selected anchors with relevant local structure to form ${\mathcal{G}}_{\mathrm{act}}\left(t\right)$. This pattern explains how retrieval, workflow-fragment selection, and communication-neighborhood activation can share the same read-only graph interface [15,84]. The key distinction is that only the activated view changes; the persistent graph remains unchanged. Next, we discuss two cases: memory evidence activation and execution activation.

Memory Evidence Activation. Memory evidence activation selects task-relevant memory states and relations without modifying the persistent memory store. Existing works can be classified into graph-based evidence expansion and memory-store retrieval. The first line [33,84] activate relational support structures from persistent or per-query graphs; for example, ToG-3 [84] iteratively refines a query-specific support graph through multi-agent context retrieval and expansion. We treat such methods as A.3 only when the constructed graph serves as transient evidence for the current agent decision rather than a committed memory update. For memory-store methods [3,89,115], they retrieve persistent memory items without necessarily exposing an explicit graph, but can be mapped by treating retrieved chunks as temporarily activated nodes. Under our activation schema in Equation (11), the selected evidence is recorded as ${\mathcal{G}}_{\mathrm{act}}\left(t\right)$, making missing evidence, stale memories, or overly broad retrieval diagnosable.

Execution Activation: Workflow/Skill/Team. Execution activation chooses task-specific components, e.g., a tool, without committing a persistent state change. Existing works may be divided into graph-native execution activation and component-library activation. For the first line [13,15,86], they activate task-specific agents or communication structures. Here, ARG-Designer [86] constructs a query-conditioned collaboration graph, which we treat as A.3 when the graph is used as a task-time execution view rather than stored as a persistent topology. Second-line works [94,116,117] typically select executable skills, modules, or workflow steps. Taking DyFlow [116] as an example, it provides a workflow-oriented case where selected execution flows can be viewed as activated nodes and edges for the current run. These remain A.3 operations when the selected structure is only used at task time; once written back as a skill, workflow edge, or communication link, the update belongs to A.1, A.2, or A.4.

3.4. Cross-Component Co-Evolution

In self-evolving agents, a local update is often not self-contained: revising a memory may affect skills that rely on it, changing a tool may invalidate workflows that call it, and modifying an agent role may require communication or team structures to be updated. Therefore, the last branch in Figure 2 captures persistent system-level evolution triggered by such cross-component dependencies. The central problem is propagation control: after an initial update, the agent must identify which downstream components (e.g., workflows) should be revised, revalidated, or rolled back to preserve consistency and safety. Existing methods [20,31,41,59,60,87,88,125,126,127] implement related effects through reflection, feedback, optimization, or monitoring, but rarely expose the dependency paths through which these updates propagate as explicit graph transformations. We therefore model cross-component co-evolution as typed cascades of DPO rewrites, providing a graph-level view of system-level self-evolution.

Cascade Rewrite Schema for A.4. A cross-component cascade is a timestamped trace of DPO rewrites triggered by an initial cause c:

$$\mathcal{C}\left(c\right)={\left(({\rho }_i,{\mu }_i,t_i)\right)}_{i=1}^k,{\mu }_i:L_i\to \mathcal{G}\left(t_i\right).$$

(12)

Here ${\rho }_i$ is the i-th rewrite, ${\mu }_i$ is its match, and $\mathcal{G}\left(t_i\right)$ denotes the host graph state immediately before applying ${\rho }_i$. The affected subgraph is $S_i=\mathrm{img}\left({\mu }_i\right)$. Let $\tau \left(S_i\right)$ denote the set of component types appearing in $S_i$, such as memory, tool, skill, workflow, or agent. A trace belongs to A.4 when it spans multiple component types, $\left|{\bigcup }_{i=1}^k\tau \left(S_i\right)\right|\ge 2$, and the sequence is not a set of independent edits: at least one later rewrite depends on, or conflicts with, an earlier rewrite. Such dependency or conflict can be identified from dependency, composition, provenance, invocation, or explicit cause records. This schema ties revalidation and rollback targets to explicit affected subgraphs.

Cross-Component Cascade Rewrites. Cross-component cascade rewrites capture updates whose effects propagate beyond the initially edited component. Existing works generally fall into feedback-to-capability propagation and capability/topology co-adaptation. The first line [31] turns task feedback, failures, or trajectories into reusable skills, rules, or agent expertise, while the second line [59,60,87] uses updated capability, utility, or topology signals to revise roles, communication links, or collaboration structures. For example, TacoMAS [60] couples a fast expertise-update loop with a slower topology-editing loop, making capability changes and communication-structure updates part of the same evolving graph process. Other feedback-driven self-improvement methods [128,129] can be mapped similarly when feedback-derived artifacts are materialized and reused to update dependent memories, skills, workflows, or evaluation components. Under our schema in Equation (12), these methods are unified as cascade traces $\mathcal{C}\left(c\right)$ linking the triggering cause, affected subgraphs, and revalidation or rollback targets.

Safety-Triggered Propagation. Safety-triggered cascades arise when unsafe tool use, API drift, or abnormal interaction invalidates dependent skills, workflows, or policies. Existing dynamic-graph-based methods [20,41,88] model unsafe behavior over temporal interaction or execution graphs. We take GUARDIAN [20] as an example: it models multi-agent collaboration as a temporal attributed graph to detect hallucination and error propagation, providing anomaly signals for later review or mitigation. Additionally, there are non-graph studies [130,131] that address related risks through attack synthesis, policy design, evaluation, or mitigation, but do not explicitly expose graph-state propagation. Under our schema, an anomaly becomes the cause c, and dependency or provenance edges determine which downstream components require revalidation or possible rollback. This graph view identifies the affected subgraph, enabling localized repair instead of global retraining or broad manual inspection.

3.5. Putting the Four Rewrite Branches Together

The four branches above can be read as a progression from local state change to relation updates, read-only activation, and cross-component propagation. As summarized in Table 1, A.1 covers persistent component-state updates: new evidence or trajectory feedback triggers memory or skill Insert, Merge, or FeatureUpdate operations over component graphs. A.2 moves from states to relations: task changes, redundant messages, or round-level context trigger workflow rewrites, communication pruning, or topology routing through Link, Unlink, and Rewire. A.3 differs from both because it is temporary: a query or execution round activates a task-specific support subgraph, such as relevant memories, tools, workflow fragments, or a temporary team, without committing a persistent update. A.4 captures cascades where an initial change propagates across at least two component types, such as expertise changes that affect team or workflow organization, or unsafe traces that trigger revalidation across dependent skills, workflows, or policies. Table 1 therefore highlights four dimensions that distinguish the branches: trigger, rewrite operator, affected scope, and persistence or propagation pattern. A full agent system may involve all four branches: it may activate support for one task, update memories or skills after feedback, rewire workflows or communication links, and trigger a cascade when those changes affect dependent components. Thus, A.1–A.4 are not mutually exclusive system labels; they identify the primary graph-rewrite role of each mechanism, while a full agent system may span several branches.

4. Dynamic Graph Learning as Agent Infrastructure

Section 3 defines a graph-transformation interface for self-evolving agents, exposing control points such as support activation, dependency rewiring, cascade scoping, and rollback. In this section, we build a capability mapping from dynamic graph learning (DGL) to these control points, using DGL as reusable infrastructure for self-evolving agents. Following dynamic-graph surveys and benchmarks [21,25,28,132], we organize this mapping into nine DGL families: general dynamic graph representation, dynamic text-attributed graph representation, dynamic graph generation, temporal graph continual learning, out-of-distribution generalization, temporal knowledge graph reasoning, dynamic graph anomaly detection, dynamic graph unlearning, and temporal GNN explanation 1. As summarized in Table 2, the mapping connects each family to representative methods, supported agent-evolution capabilities, required adaptations, and naive failure modes. Next, we discuss the modeling idea of each DGL family, how it can be adapted to evolving agent graphs, and a concrete agent-facing example.

Figure 3. Dynamic graph learning as agent-evolution infrastructure. It includes nine DGL families and nine agent-evolution tasks over agent-graph streams, showing how dynamic graph methods can be adapted as reusable support for self-evolving agents.

Figure 3. Dynamic graph learning as agent-evolution infrastructure. It includes nine DGL families and nine agent-evolution tasks over agent-graph streams, showing how dynamic graph methods can be adapted as reusable support for self-evolving agents.

4.1. Dynamic Graph Representation Learning

Self-evolving agents need time-aware graph representations because many failures arise from changing state: memories become stale, skills lose reliability in new contexts, and workflow edges become invalid after upstream changes. Thus, dynamic graph representation learning can support concrete agent tasks such as memory-validity scoring, tool/skill reliability prediction, workflow-edge risk estimation, and early cascade alerts. In this subsection, we organize existing methods of this family by temporal granularity [45], including continuous-time dynamic graph (CTDG) and discrete-time dynamic graph (DTDG) methods. CTDG methods [26,29,148,149,150,151,152,153,154,155,156,157,158,159,160] model irregular timestamped events, such as memory writes, tool calls, workflow edits, and agent messages; DTDG methods [21,25,46,132,161,162,163,164,165,166,167,168,169,170,171] operate on graph snapshots, making them suitable for session-level, round-level, or deployment-level agent maintenance. Overall, CTDG encoders are useful for online event prediction, while DTDG encoders are useful for periodic diagnosis.

A representative CTDG method is TGN [26], which combines node memory with temporal structural aggregation for temporal node representation. Given an event $e_i=(u,v,t_i,{\mathit{x}}_{e_i}\left(t_i\right))$, each endpoint $o\in \{u,v\}$ receives a message from the other endpoint $\overline{o}$, updates its memory, and computes its temporal embedding:

$$\begin{array}{cc}\hfill {\varsigma }_o\left(t_i\right)& ={\mathrm{upd}}_{\theta }\left({\varsigma }_o\left(t_i^{-}\right),{\mathbf{m}}_{o,i}\left(t_i\right)\right),\hfill \\ \hfill {\mathbf{h}}_o\left(t_i\right)& ={\mathrm{emb}}_{\theta }\left({\varsigma }_o\left(t_i\right),{\mathrm{AGG}}_{\theta }\left({\mathbf{F}}_o\left(t_i\right)\right)\right).\hfill \end{array}$$

(13)

Here, ${\varsigma }_o\left(t_i^{-}\right)$ is the memory state before $t_i$, and ${\mathbf{m}}_{o,i}\left(t_i\right)$ is the event message computed from the endpoint memories, event feature ${\mathit{x}}_{e_i}\left(t_i\right)$, and time-gap encoding $\varphi (t_i-t_o^{-})$ [27]. ${\mathbf{F}}_o\left(t_i\right)=\{{\mathbf{f}}_{o,r}\left(t_r\right):e_r\in {\mathcal{N}}_o\left(t_i\right)\}$ denotes temporal structural inputs from recent neighbor events of node o; each ${\mathbf{f}}_{o,r}\left(t_r\right)$ contains the event message, event attributes, temporal encoding, and optionally the neighbor memory involved in $e_r$.

For dynamic agent graphs, timestamped events include typed agent-graph events, e.g., memory writes or tool calls. CTDG encoders turn these irregular events into temporal node memories for online predictions such as memory support and tool routing. DTDG encoders summarize session- or deployment-level snapshots for slower maintenance tasks such as drift tracking and workflow comparison. These outputs are bounded activation or maintenance signals; persistent graph changes still require rewrite validation. We provide a toy example below.

Agent-Evolution Example 1.   Consider a GitHub maintenance agent whose tasks, skills, tools, and workflow steps are typed nodes. Its execution history yields typed temporal events, such as task–skill invocations, skill–tool calls, tool outcomes, and workflow-edge revisions. A TGN-style encoder can process these traces after decomposing complex executions into touched-node and touched-edge events while preserving types through schema-aware messages or type embeddings. For a current task q, the encoder scores candidate skill–tool or workflow edges, such as the reliability of calling a pull-request tool in the current repository context, rather than directly committing new dependencies. These scores guide activation or routing; persistent dependency updates still require rewrite validation. For the evaluation, we can use candidate-edge ranking and post-drift recovery.

4.2. Dynamic Text-Attributed Graph Representation

Textual attributes are part of the evolving agent state, not merely side information. In self-evolving agents, memory nodes may store observations, policies, and summaries, while tool, skill, and agent nodes may store API descriptions, code snippets, contracts, or role specifications. When these texts change, the validity of retrieval, activation, and update decisions may also change. This motivates Dynamic Text-Attributed Graphs (DyTAGs), where textual attributes co-evolve with temporal events and graph structure.

DyTAGs were introduced in DTGB [48] to support tasks such as future link prediction, destination node retrieval, edge classification, and textual relation generation. Subsequent studies [30,133,172,173,174] can be divided into (1) representation-oriented methods that align text, temporal history, and graph structure for prediction tasks and (2) LLM-driven methods that use large language models for semantic reasoning and prediction over dynamic text-attributed graphs. For agent graphs, this suggests a direct use case: long memories, API documents, skill descriptions, and role specifications can be encoded as evolving textual attributes, while dynamic graph models ground them in temporal validity and structural dependencies.

MoMent [30] is representative, where it first shows textual, temporal, and structural modalities of DyTAGs and then models and aligns three modalities for node representations. Let ${\mathit{x}}_v\left(t\right)$ denote the textual component of the node attribute vector, ${\mathcal{O}}_{v,[0,t)}$ denote access events and accepted rewrites that touch v or its incident edges before t, and ${\mathcal{N}}_v\left(t\right)$ denote the k-hop neighborhood of v before t. We describe the MoMent encoder for an agent-graph node v at time t as

$${\mathbf{h}}_v\left(t\right)=\mathrm{Fus}\left(E_{\mathrm{text}}\left({\mathit{x}}_v\left(t\right)\right),E_{\mathrm{time}}\left({\mathcal{O}}_{v,[0,t)}\right),E_{\mathrm{str}}\left({\mathcal{N}}_v\left(t\right)\right)\right),$$

(14)

where $E_{\mathrm{text}}$, $E_{\mathrm{time}}$, and $E_{\mathrm{str}}$ denote the text encoder, temporal encoder, and structural encoder, respectively, and $\mathrm{Fus}$ is a learnable fusion function. In addition, the alignment mechanism is included in the learning objective; please refer to [30].

When considering dynamic agent graphs, these three modalities describe node text, temporal update history, and structural connections to agent evolution. Thus, a DyTAG encoder can combine semantic content with access history, rewrite history, and workflow context, so outdated but text-similar nodes or edges are less likely to be activated. The main system adaptation is selective re-encoding: when a rewrite changes semantic content, temporal validity, or downstream dependencies, the runtime refreshes the affected node text representations and incident edge features, while leaving unrelated text embeddings untouched. Overall, DyTAG modules provide bounded retrieval, activation, and edge-validity signals. We provide a case below.

Agent-Evolution Example 2.   Consider a GitHub maintenance agent opening a pull request after a repository changes its default branch frommastertomain. Each run forms a DyTAG with repository, branch-memory, workflow, and tool nodes, plus temporal events such as metadata queries, memory writes, and workflow-edge updates. At time t, the graph contains a stale memory ${\mathbf{m}}_{\mathrm{old}}$ formasterand a newer memory ${\mathbf{m}}_{\mathrm{new}}$ formain. Before callingopen_pr, the agent must retrieve the valid branch-memory node. A DyTAG encoder [30] ranks candidate memories by combining text, pre-decision metadata events, and graph connections to the active repository and PR workflow. The ranking determines ${\mathcal{G}}_{\mathrm{act}}\left(t\right)$ for the current run; persistent memory correction still requires a validated rewrite. We can use additional stale-memory activation rate, and wrong-base PR calls for evaluation. Note that labels use only metadata or PR outcomes observed before t.

4.3. Dynamic Graph Generation

Self-evolving agents sometimes need to synthesize candidate graph changes before acting, such as a repaired workflow, a new tool-routing path, or a revised team communication topology. Dynamic graph generation supports workflow and topology synthesis, counterfactual repair planning, and simulation of future evolution traces, but generated structures must remain executable under agent schemas. Existing works fall into (1) temporal structure generation [134,135,175,176,177] and (2) dynamic text-attributed graph generation [178], where generated nodes and edges may also need valid textual attributes. For self-evolving agents, these two groups can be used as proposal modules: they suggest candidate subgraphs or rewrite traces, and the runtime validates them before any persistent graph state changes.

TIGGER [135] is a classical method, which can learn temporal interaction patterns and generate realistic dynamic graph sequences. We can adapt this idea as constrained rewrite-trace generation for agent evolution. Concretely, the generator proposes candidate traces $\mathcal{C}={\left(r_i\right)}_{i=1}^k,r_i=({\rho }_i,{\mu }_i,t_i)$, using the notation of Section 3.4. A trace is eligible only if it satisfies agent-graph validity constraints, e.g., tool signatures and provenance requirements. Among eligible traces, the agent prefers candidates that are likely under the generator, improve predicted or observed task execution after tentative application, and avoid unnecessary rewrite length. The selected trace remains a proposal: it may be activated, repaired, or committed only after explicit rewrite validation. Thus, dynamic graph generation can provide bounded workflow or topology proposals without directly mutating persistent agent state.

Agent-Evolution Example 3.   Consider a GitHub maintenance agent that fixes bugs and opens pull requests. Its old workflow callsGitHub.createPullRequest, but the PR API now requires validowner,head, andbasearguments, together with atitleor an existingissue. For $q=$ “fix this bug and open a pull request,” a TIGGER-style adaptation generates candidate workflow-rewrite traces by sampling temporal structures from past workflow and tool-call patterns. For example, one generated trace addsresolve_repo_metadatabefore the PR call and passes the resolved branch information toGitHub.createPullRequest. The execution layer then checks whether each trace provides required arguments, satisfies branch constraints, and records provenance from the metadata query to the PR call. The agent keeps only candidates that pass these checks, and the selected trace still needs rewrite validation before commitment. Thus, B.3 generation provides workflow-rewrite proposals for A.2, while downstream dependency checks may involve A.4 cascades. Under the leakage-free protocol, labels use only observations before the decision time. For the evaluation, we can report valid-proposal rate, PR completion, and invalid-tool-call reduction.

4.4. Temporal Graph Continual Learning

Self-evolving agents must adapt to newly added memories, tools, skills, and workflows without forgetting how to activate rare but important capabilities. Temporal graph continual learning addresses this stability–plasticity problem for dynamic event streams, making it relevant to persistent agent-graph encoders. Existing continual learning methods on temporal graphs include (1) replay-based approaches [136,179] that retain historical samples or temporal subgraphs for rehearsal, and (2) parameter-based approaches [137] that preserve old knowledge through isolation, freezing, or expansion. For dynamic agent graphs, the retained units should be dependency subgraphs whose forgetting would break downstream behavior, such as rare skills, user-specific memories, prerequisite tools, and validation traces.

We take LTF [136] as an example: it studies selective retention for temporal graph continual learning. Concretely, the model learns from new temporal events ${\mathcal{D}}_k$ at epoch k, while preserving knowledge stored in a historical replay buffer ${\mathcal{B}}_{k-1}$. We write the continual adaptation objective as

$${\theta }_k^{★}=arg\underset{\theta }{min}\left[{\mathcal{L}}_{\mathrm{new}}\left(\theta \mid {\mathcal{D}}_k\right)+{ϵ}_{\mathrm{old}}\left(\theta \mid {\mathcal{B}}_{k-1}\right)\right],$$

(15)

where ${\mathcal{B}}_{k-1}$ stores selected historical agent subgraphs from previous epochs, such as skill-tool dependencies, supporting memories, and user-specific traces. ${\theta }_k^{★}$ denotes the adapted model parameters at epoch k, ${\mathcal{L}}_{\mathrm{new}}$ is the loss on newly observed temporal events, and ${ϵ}_{\mathrm{old}}$ is a retention penalty over replayed historical subgraphs. In our setting, ${ϵ}_{\mathrm{old}}$ should be dependency-aware, giving higher weight to replayed subgraphs that contain rare skills, prerequisite tools, user-specific memories, or safety-critical provenance. The output is a more stable encoder or replay policy for activation and retrieval, rather than a direct rewrite of agent state. Below is an example.

Agent-Evolution Example 4.   We consider a GitHub maintenance agent with a rare skillopen_release_branch_pr, which depends on release-branch memories, CI requirements, and hotfix traces. The skill node and its dependencies remain in the persistent agent graph unless explicitly rewritten or deleted. At epoch k, however, most new events in ${\mathcal{D}}_k$ are routine PRs tomain; naive continual training may therefore make the encoder worse at activating or ranking this rare skill for release-branch hotfixes. A replay-based method stores historical interaction events and dependency subgraphs involving this skill in ${\mathcal{B}}_{k-1}$, and assigns them a high retention weight through ${ϵ}_{\mathrm{old}}(\theta \mid {\mathcal{B}}_{k-1})$. Thus, the adapted encoder should still retrieveopen_release_branch_prfor hotfix tasks while learning new tools and repository patterns. For the evaluation, it can test activation quality (rare-skill Recall@k), task utility (release-branch PR recovery), and routine-task performance across epochs.

4.5. Out-of-Distribution Generalization on Dynamic Graphs

Self-evolving agents encounter distribution shifts as tool versions, user cohorts, policies, and task distributions change over time. Dynamic graph out-of-distribution (OOD) generalization is therefore tied to robust activation and updating: the agent should still select valid memories, tools, skills, and execution subgraphs when node attributes, edges, and temporal interaction patterns shift together. Existing OOD methods can be classified into (1) spatio-temporal invariance approaches [138,139] that seek stable predictive patterns under structural and temporal shifts, and (2) environment-aware approaches [180,181] that treat deployment epochs, tool versions, organizations, user cohorts, or task families as environments.

Here, we illustrate an environment-aware dynamic graph learner [180] that reduces worst-case risk across deployment environments rather than optimizing only average in-distribution performance. Let $m\in {\mathcal{M}}_{\mathrm{tr}}$ index a training environment and let $\xi =(\mathcal{G}\left(t\right),{\mathcal{O}}_{[0,t)},q,z)$. We write an environment-aware robust learning objective as

$${\theta }_{\mathrm{ood}}^{★}=arg\underset{\theta }{min}\underset{m\in {\mathcal{M}}_{\mathrm{tr}}}{max}{\mathbb{E}}_{\xi \sim P_m}\left[\ell \left(h_{\theta }(\mathcal{G}\left(t\right),{\mathcal{O}}_{[0,t)},q),z\right)\right].$$

(16)

Here ${\theta }_{\mathrm{ood}}^{★}$ denotes the OOD-adapted model parameters, ${\mathcal{M}}_{\mathrm{tr}}$ is the set of training environments, and $P_m$ is the environment-conditioned distribution over the current agent graph, its pre-t event history, task query, and prediction target. $\ell (·,·)$ is the task loss measuring the discrepancy between the model output and target z. In agent tasks, z may denote a agent-evolution targets, like a tool-routing label or a rewrite decision. The learned model produces robustness-aware scores for activation, routing, or update proposals under deployment shift, such as selecting tools that remain valid after tool versions change. These scores guide subgraph activation and rewrite inspection, while persistent graph changes still require validation. We provide an example below.

Agent-Evolution Example 5.   For a GitHub maintenance agent trained on organizations, bug-fix PRs usually follow the shortcut: tests pass, then callopen_pr. At deployment, it faces a held-out organization with a new policy regime requiring a linked issue, a passingci/buildcheck, and code-owner approval. This raises an OOD challenge, which is to rely on stable signals such as tool signatures, permission metadata, dependency edges, and recent schema- or permission-error events. Thus, the learner should rank routes that addcheck_branch_policy,run_required_ci, andrequest_code_owner_reviewbeforeopen_prwhen the old route becomes invalid. For the evaluation, we can report policy-compliant routing, rejected-PR reduction, and PR completion under held-out shifts. Note that training and testing should be split by organization or policy regime.

4.6. Temporal Knowledge Graph Reasoning

Many agent decisions require time-valid evidence rather than the most similar text: an old memory may be corrected later, or a tool failure may change a workflow. Temporal knowledge graph (TKG) reasoning is useful because it queries time-stamped facts and relations along valid evidence paths, helping agents connect the current task to relevant agent-state evidence, e.g., tool states or policies. Existing TKG reasoning methods can be broadly divided into (1) path-based temporal reasoning [140], which provides interpretable evidence chains; (2) neural temporal reasoning [141,182,183,184,185,186,187], which learns temporal embeddings, event dynamics, or generative histories; and (3) LLM-assisted temporal reasoning [188,189,190], which extracts, verbalizes, or adapts temporal patterns from language. For self-evolving agents, these methods connect current decisions to timestamped memories, corrections, tool outcomes, and workflow revisions.

xERTE [140] is a useful method, which emphasizes explainable temporal reasoning paths. When applied to agent graphs, this corresponding adaptation is to activate time-valid evidence chains from $\mathcal{G}\left(t\right)$ and ${\mathcal{O}}_{[0,t)}$, rather than retrieving isolated top-ranked memory items. Such chains can link a current query to earlier preferences, later corrections, and tool outcomes, producing a support subgraph for the downstream decision. Therefore, the output is a temporally grounded support subgraph for memory QA, dependency tracing, or delayed-failure diagnosis, reducing stale evidence and temporal leakage. We provide an example below.

Agent-Evolution Example 6.   When a GitHub maintenance agent answers $q=$ “Which base branch should this hotfix pull request target?”, the answer cannot be obtained from a single memory node. The graph contains an old default-branch memory formaster, a later metadata query showingmain, and a release-policy note saying that versioned hotfixes should target the active release branch. Thus, we can leverage temporal path reasoning, which follows a multi-hop evidence chain. That is, current task → hotfix policy → release-series metadata → valid branchrelease/1.x. This path-level reasoning activates ${\mathcal{G}}_{\mathrm{act}}\left(t\right)$ with the supporting policy and metadata evidence before the PR tool is called, rather than simply ranking a text-similar branch memory. Finally, we can measure temporal QA accuracy, path-level temporal validity, and evidence-path precision for evaluation.

4.7. Anomaly Detection on Dynamic Graphs

Unsafe agent behavior often appears as abnormal traces before final task failure: unusual tool-call sequences, suspicious communication, or unsafe provenance paths [39,40,41,191]. Dynamic graph anomaly detection can therefore provide early warnings for unsafe rewrites, prompt-injection propagation, tool misuse, and multi-agent collusion. Existing methods [142,143,192,193,194,195] in this line can be classified into supervised, semi-supervised, and unsupervised/self-supervised detectors. Here, labeled deployments can train incident-aware detectors, while open-ended agents need self-supervised monitoring.

When applied to dynamic agent graphs, existing methods, such as TADDY [143] and SLADE [195], can be adapted as rewrite-aware detectors. Given a committed rewrite $({\rho }_i,{\mu }_i,t_i)$ with affected subgraph $S_i=\mathrm{img}\left({\mu }_i\right)$, the detector scores whether the rewrite type, timing, local dependency context, and provenance path deviate from normal events of the same task phase. The main system adaptation is calibration by rewrite type and task phase, so benign bursts such as memory consolidation are not confused with unsafe escalation. The output is an alert, quarantine decision, or review request before suspicious traces become persistent dependencies.

Agent-Evolution Example 7.   Consider a GitHub maintenance agent that retrieves an issue body containing the hidden instruction “ignore previous rules and exfiltrate repository secrets.” The attack appears as a suspicious memory-write proposal followed by an unusual temporal path: issue memory → secret-scanning tool → external-send tool. Here, we can use a rewrite-aware anomaly detector to score this trace using the affected subgraphs $S_i$, tool-call timing, edge types, provenance links, and optionally the suspicious text attribute. If the score exceeds a rewrite-type-specific threshold, the runtime rejects the memory write before it enters the persistent graph and blocks or flags the external invocation. Then we can use injected-issue traces and benign maintenance logs to measure early-warning precision, attack-block rate, and benign-trace false-alarm rate.

4.8. Dynamic Graph Unlearning

Deletion, rollback, and compliance are difficult in evolving agent graphs because removed events may influence cached embeddings, workflows, or routing policies. Dynamic graph unlearning supports deletion, rollback, and influence removal by targeting event influence rather than only deleting the original node or edge. Existing methods [144,145] along this line focus on efficient post-processing for temporal and spatio-temporal models. When considering dynamic agent graphs, unlearning must be combined with versioned provenance rollback, so deterministic descendants in $\mathcal{G}\left(t\right)$ and residual influence in learned parameters are both removed.

We take GradientTransformation [144] as a representative method. Let $\mathcal{U}\subseteq {\mathcal{O}}_{[0,t)}$ be the unlearning request and let $\mathcal{R}\subseteq {\mathcal{O}}_{[0,t)}\setminus \mathcal{U}$ be retained reference events. A post-processing unlearner can be abstracted as

$${\theta }_{-\mathcal{U}}=\theta +T_{\varphi }\left({\nabla }_{\theta }{\mathcal{L}}_{\mathcal{U}}\left(\theta \right),{\nabla }_{\theta }{\mathcal{L}}_{\mathcal{R}}\left(\theta \right),\theta \right),$$

(17)

where $\theta$ and ${\theta }_{-\mathcal{U}}$ denote the original and unlearned parameters, ${\mathcal{L}}_{\mathcal{U}}$ and ${\mathcal{L}}_{\mathcal{R}}$ are losses on forgotten and retained events, and $T_{\varphi }$ is a learned or analytic update operator. In agent graphs, parameter-level unlearning is insufficient on its own: provenance-linked artifacts such as summaries and execution subgraphs may still carry the deleted influence and must be regenerated, invalidated, or reverted. The output is therefore an unlearning scope together with the required model or representation updates; validation is needed to ensure that removing deleted influence does not damage shared skills or retained memories.

Agent-Evolution Example 8.   Consider a GitHub maintenance agent that accidentally stores a private repository token in a memory item $v_{\mathrm{priv}}$. The token may affect a repository summary, cached embeddings, and a PR-opening skill. When deletion is requested, $\mathcal{U}$ contains the insertion event and provenance-linked propagation events. Graph rollback removes $v_{\mathrm{priv}}$, regenerates affected summaries, and recomputes dependent embeddings or skill states from the post-deletion graph. Equation (17) targets residual influence in learned parameters, while retained events $\mathcal{R}$ preserve normal bug-fixing behavior. After deletion, the agent should fix public bugs, but privacy probes should not elicit derived summaries.

4.9. Explanation for Temporal GNNs

Operators need event-level evidence for why an agent activated a memory, selected a tool, revised a skill, or rewired a workflow. Dynamic graph explanation supports audit and attribution by turning unclear temporal predictions into compact evidence subgraphs for rollback and accountability. Existing works fall into temporal history explanation [146,196] and causality-inspired spatiotemporal explanation [147]. Here, we discuss TGNNExplainer [146], as it explains predictions through temporally ordered events rather than static neighborhoods alone. For dynamic agent graphs, this idea can serve as an audit module: after an activation, rewrite, or reassignment, the explainer returns a minimal event history and local subgraph context that preserves the same decision. The explanation may include affected subgraphs $S_i=img\left({\mu }_i\right)$, provenance edges, retrieved memories, tool observations, or review traces. Thus, it can justify the current ${\mathcal{G}}_{\mathrm{act}}\left(t\right)$, be stored as an audit artifact, or indicate which previous rewrites should be checked during rollback. Below is an example.

5. Graph-Aware Evaluation and Governance

Self-evolving agents are usually evaluated by end-task success, but many failures arise from the evolving agent state they read and update. A final answer may be correct even when the agent uses an invalid state, such as stale or future evidence. This creates an evaluation and governance gap: existing benchmarks (e.g., long-term memory and tool-use) expose parts of the problem [37,92,93,103,104], but rarely test whether evolving agent state is temporally valid, localized, reversible, and auditable. This section turns that gap into concrete protocols: graph-aware support and locality metrics, leakage-free temporal splits, deletion and privacy checks, safety/rollback/audit criteria, and open challenges for agent evolution.

5.1. Graph-Aware Evaluation

We first evaluate whether the agent succeeds for the right graph reasons. A task may pass while using stale or future evidence, or while a rewrite damages unrelated memories, tools, skills, or workflows. We therefore use two graph-level checks when the benchmark exposes the needed instrumentation: (1) support-subgraph accuracy, which tests whether the activated evidence was valid at decision time, and (2) rewrite locality, which tests whether an update changed only the intended graph region. Otherwise, graph-level counts should be treated as diagnostics. Let $\mathcal{Q}$ be a set of evaluation decisions, where each decision has a task context q and decision time $t_q$. For any subgraph H, let $\mathcal{V}\left(H\right)$ denote its node set. We define them below.

M1: Support-Subgraph Accuracy. For time-aware memory retrieval, planning, skill activation, or tool selection, the agent should activate evidence that is both relevant and temporally valid. As many decisions admit multiple compact valid evidence chains, M1 is based on the best Dice overlap [197] with an acceptable gold support subgraph. Then we define it as

$$\mathrm{M}1={\displaystyle \frac{1}{\left|\mathcal{Q}\right|}}\sum _{(q,t_q)\in \mathcal{Q}}\underset{H^{★}\in {\mathbb{G}}_q^{★}}{max}{\displaystyle \frac{2|\mathcal{V}\left({\mathcal{G}}_{\mathrm{act}}(q,t_q)\right)\cap \mathcal{V}\left(H^{★}\right)|}{|\mathcal{V}\left({\mathcal{G}}_{\mathrm{act}}(q,t_q)\right)|+|\mathcal{V}\left(H^{★}\right)|}}.$$

(18)

Here ${\mathbb{G}}_q^{★}$ contains acceptable compact support subgraphs for decision q, and ${\mathcal{G}}_{\mathrm{act}}(q,t_q)\subseteq \mathcal{G}\left(t_q^{-}\right)$ is the support subgraph activated by the agent. The Dice form rewards covering one valid support chain while penalizing overly broad activation. Thus, M1 intentionally favors compact evidence use: if an agent activates several acceptable chains at once, it may receive a lower precision-oriented score even though the evidence is valid. This is useful because answer-only metrics cannot distinguish valid reasoning from reliance on invalid evidence (e.g., leaked context). When relational support is labeled, the same idea can be extended by replacing node overlap with edge- or path-level overlap. For example, in GitHub maintenance, M1 can check whether the activated graph contains current branch-policy and PR-tool evidence rather than a stale master memory. In practice, ${\mathbb{G}}_q^{★}$ requires benchmark annotations or logs of acceptable support nodes, paths, or subgraphs.

M2: Counterfactual Rewrite Locality. For state updates of evolving agent graphs, a successful rewrite should fix the target behavior while preserving unrelated behavior. This mirrors model editing, where methods are evaluated by both edit success and locality on unrelated probes [198,199,200,201]. Let $\widehat{\mathcal{C}}={\left(({\widehat{\rho }}_i,{\widehat{\mu }}_i,{\widehat{t}}_i)\right)}_{i=1}^k$ be a predicted rewrite trace, following the cascade notation of Section 3.4, and let ${\mathcal{G}}_{\widehat{\mathcal{C}}}\left(t\right)$ be the tentative graph obtained by applying it to $\mathcal{G}\left(t\right)$. Let ${\mathcal{D}}_{\mathrm{l}}\left(\widehat{\mathcal{C}}\right)$ denote locality probes whose outputs should remain unchanged, and let ${\mathrm{out}}_{\theta }(q;H)$ denote the agent output for task context q under graph state H. We define this metric as

$$\mathrm{M}2={\displaystyle \frac{1}{|{\mathcal{D}}_{\mathrm{l}}\left(\widehat{\mathcal{C}}\right)|}}\sum _{q\in {\mathcal{D}}_{\mathrm{l}}\left(\widehat{\mathcal{C}}\right)}\mathbf{1}\left[{\mathrm{Eq}}_{\mathrm{loc}}\left({\mathrm{out}}_{\theta }\left(q;{\mathcal{G}}_{\widehat{\mathcal{C}}}\left(t\right)\right),{\mathrm{out}}_{\theta }\left(q;\mathcal{G}\left(t\right)\right)\right)\right].$$

(19)

Here ${\mathrm{Eq}}_{\mathrm{loc}}$ is a task-defined equivalence predicate over agent behaviors (e.g., tool choices), evaluated under deterministic decoding and controlled tool execution. M2 complements target-task success: high locality alone does not show a successful repair, while low locality signals harmful side effects. For example, an open_pr fix should not break release-branch PRs, CI routing, or unrelated testing workflows. In practice, ${\mathcal{D}}_{\mathrm{l}}$ can be supplied by benchmark annotations or sampled from graph regions outside the affected dependency/provenance frontier. When locality probes are unavailable, edit size or touched-element counts are only diagnostics; affected-set F1 is optional if gold affected elements $A^{★}$ are annotated.

Existing benchmarks can be upgraded to support these two metrics by logging activated support subgraphs, rewrite traces, and locality probes. Tool benchmarks such as ToolSandbox and BFCL [102,103,104,105] can expose tool-call events and stateful tool interactions. Interactive and software-agent benchmarks [34,36,120,121,202,203,204,205,206,207,208] can provide interactive action traces, but deriving graph-level rewrite records, tool-edge changes, or before/after locality probes from them requires additional instrumentation. The advantage is that two agents with the same final success can be compared by whether they used valid evidence and avoided unrelated graph side effects. Note that M1 requires additional labels.

5.2. Leakage-Free Temporal Protocols

Temporal leakage can overestimate the effectiveness of self-evolution: agent-state artifacts (e.g., memory summaries and tool scores) may accidentally include events recorded after the evaluated decision. To separate genuine adaptation from future-state leakage, we adopt a chronological split following temporal graph evaluation [28,209]: fix transaction-time cutoffs $T_{\mathrm{train}}<T_{\mathrm{val}}<T_{\mathrm{test}}$, train only on $\mathcal{G}\left(T_{\mathrm{train}}\right)$ and ${\mathcal{O}}_{[0,T_{\mathrm{train}}]}$, and evaluate each validation or test decision at time t using only $\mathcal{G}\left(t^{-}\right)$ and ${\mathcal{O}}_{[0,t)}$. This protocol is useful because agent state has both transaction time and valid time: a fact may describe the past, but it should affect decisions only after it has been recorded. In practice, this means rebuilding retrieval indexes and summaries per split, sampling negative tool edges from the pre-t graph, and calibrating tool reliability without future calls. Under this protocol, performance gains reflect information that the agent could actually have used at decision time.

5.3. Privacy and Deletion in Evolving Agent Graphs

Deletion is a governance problem because private or revoked evidence can remain in derived artifacts, such as skill scores, workflows, or routing policies, even after the source graph item is removed. Thus, privacy evaluation should test influence removal, not only raw node or edge deletion. This extends graph unlearning on node, edge, and feature removal [210,211,212,213] and dynamic graph unlearning in Section 4.8 to end-to-end agent behavior. Next, we define the deletion success.

Deletion Success. Let $\mathcal{U}\subseteq {\mathcal{O}}_{[0,t_d)}$ be a deletion request at $t_d$, and let ${\mathcal{Q}}_{\mathcal{U}}$ be post-deletion decisions that may depend on $\mathcal{U}$, identified by provenance or replay. For query q at time $t_q>t_d$, let ${\mathcal{G}}_{\mathrm{del}}\left(t_q\right)$ be the post-deletion graph and ${\mathcal{G}}_{\mathrm{cf}\setminus \mathcal{U}}\left(t_q\right)$ the counterfactual graph replayed without $\mathcal{U}$ and its deterministic descendants. The deletion success can be defined as

$$\begin{array}{cc}\hfill \mathrm{DELSUCC}\left(\mathcal{U}\right)=& {\displaystyle \frac{1}{|{\mathcal{Q}}_{\mathcal{U}}|}}\sum _{(q,t_q)\in {\mathcal{Q}}_{\mathcal{U}}}\mathbf{1}\left[{\mathrm{Eq}}_{\mathrm{task}}\right(f_{\mathrm{del}}(q;{\mathcal{G}}_{\mathrm{del}}\left(t_q\right)),\hfill \\ \hfill & f_{\mathrm{cf}\setminus \mathcal{U}}(q;{\mathcal{G}}_{\mathrm{cf}\setminus \mathcal{U}}\left(t_q\right))\left)\right],\hfill \end{array}$$

(20)

where $f_{\mathrm{del}}$ is the post-deletion agent, $f_{\mathrm{cf}\setminus \mathcal{U}}$ is the counterfactual replayed agent, and ${\mathrm{Eq}}_{\mathrm{task}}$ is a task-specific equivalence predicate over answers, tool choices, or activation decisions. DelSucc is an oracle-style metric for benchmarks that support counterfactual replay. It requires controlled randomness, such as fixed decoding seeds, tool stubs, and scheduler choices; otherwise, differences may reflect trajectory noise rather than residual deleted influence. It also depends on complete provenance and replay logs: derived artifacts (e.g., skill scores) can make ${\mathcal{Q}}_{\mathcal{U}}$ incomplete and DelSucc overly optimistic. Thus, DelSucc measures empirical behavioral equivalence to an agent that never observed $\mathcal{U}$, not a certified distributional unlearning guarantee. When replay or provenance is incomplete, deletion should also be evaluated through descendant invalidation logs, cached-embedding removal, privacy probes, and retained-task utility.

5.4. Safety, Rollback, and Audit

Safety failures in long-running agents are often structural: unsafe memories may activate tools, dependency edges may bypass checks, and multi-agent communication paths may amplify harmful instructions. Existing safety benchmarks [38,39,40,214] reveal whether unsafe behavior occurs, but not which committed evidence or rewrite made it persist. Graph-aware safety governance therefore needs three pieces: (1) pre-commit admissibility checks from Section 2, (2) anomaly detection from Section 4.7, and (3) rollback through cascade analysis from Section 3.4. The remaining evaluation question is whether the audit evidence actually explains the activation or rewrite that must be reviewed.

Audit Faithfulness. For an audited decision $(q,t_q)$, let $H\left(q\right)$ be the audit explanation and let $\mathcal{E}\left(H\left(q\right)\right)\subseteq \mathcal{G}\left(t_q^{-}\right)$ be the cited evidence subgraph. Let $\mathcal{G}\left(t_q^{-}\right)\ominus \mathcal{E}\left(H\left(q\right)\right)$ denote replay-time masking of the cited evidence, not a committed deletion. In practice, ⊖ should mask the cited information while preserving executable graph structure, e.g., by replacing evidence content with placeholders rather than deleting required control-flow nodes. We define it as

$$\begin{array}{cc}\hfill \mathrm{AUDITFAITH}=& {\displaystyle \frac{1}{|{\mathcal{Q}}_{\mathrm{aud}}|}}\sum _{(q,t_q)\in {\mathcal{Q}}_{\mathrm{aud}}}\mathbf{1}[f\left(q;\mathcal{G}\left(t_q^{-}\right)\ominus \mathcal{E}\left(H\left(q\right)\right)\right)\hfill \\ \hfill & \not\equiv \mathrm{dec}f\left(q;\mathcal{G}\left(t_q^{-}\right)\right)].\hfill \end{array}$$

(21)

where $f(q;\mathcal{G})$ is the activation or rewrite-decision function, and $\not\equiv \mathrm{dec}$ denotes task-defined decision inequivalence under deterministic decoding. A high AuditFaith score means that masking the cited evidence changes the activation or rewrite decision, making the explanation useful for review and rollback. This is a necessity-side fidelity test from static and temporal GNN explanation [146,147,215], lifted from prediction targets to agent activation and rewrite decisions. Because necessity alone can reward overly broad explanations, AuditFaith should be reported with explanation size, support precision, or a sufficiency-side check that keeps only the cited evidence and tests whether the decision is preserved. The metric should be reported only when the benchmark supports replay or evidence masking and the masked graph remains executable; otherwise, $H\left(q\right)$ and $\mathcal{E}\left(H\right(q\left)\right)$ should be stored as qualitative audit artifacts instead of being converted into a faithfulness score.

5.5. Open Challenges

The following challenges identify graph-level capabilities that self-evolving agents need before persistent rewrites can become reliable. They arise because memories, tools, skills, workflows, and interacting agents evolve as coupled nodes, edges, attributes, and event histories. Together, they define a research agenda for moving self-evolving agents from opportunistic adaptation to controllable graph evolution. We introduce six challenges from the graph perspective.

Challenge I (Benchmark): Observability of evolving graph state. A self-evolving agent can produce a correct output while relying on stale evidence, leaked future information, or an unintended rewrite path. The core challenge is that graph-state correctness is usually hidden: benchmarks observe the answer, but not the activated support graph, valid-time evidence, provenance path, or rewrite history that produced it. The research problem is to make these graph-state signals observable in a way that is independent of any single-agent implementation. Thus, existing agent benchmarks should be complemented with a graph-aware evaluation view: agents are judged not only by what they output, but also by whether the evolving state that supported the output was temporally valid, locally updated, and auditable.

Challenge II (Memory): Lifecycle of memory influence. Memory evolution is not just node insertion or deletion. A memory can be summarized, embedded, retrieved, and reused by skills or workflows, so its influence may persist through derived graph states after the original node changes. The central challenge is to track this influence as a provenance subgraph: which summaries, embeddings, skills, workflow steps, or decisions inherit from a memory, when they become stale, and which should be invalidated. Under limited compute budgets, agents need query-aware routing over memory processing modules [216], deciding which memory subgraphs are worth retrieving, refreshing, or maintaining. Thus, memory lifecycle management becomes influence tracing, staleness detection, and selective maintenance over derived graph states.

Challenge III (Tools): Downstream validation for evolving tool graphs. Tool failures can arise from keeping, deleting, or rewiring a tool edge without checking whether it remains executable, authorized, and workflow-compatible. Existing tool-graph and tool-navigation systems organize tools, traces, or toolchains as graph topologies [50,68], but local tool changes still require downstream validation. A task–tool or skill–tool edge may remain semantically plausible while becoming invalid after deployment shifts, e.g., policy shifts. The central challenge is tool-specific dependency validation: after a tool node or edge changes, the agent must identify which dependent components, such as workflows, should be revalidated, rewired, or rolled back [56,60]. This requires provenance-aware tool graphs that record selection, invocation, dependency, justification, and authorization, so local tool updates do not silently corrupt downstream execution.

Challenge IV (Skills): Structural validity in large-scale skill libraries. As skill libraries scale up, textual similarity becomes an increasingly weak signal for deciding whether a skill is usable. A skill may appear relevant to the current task but still be structurally invalid because dependencies, including required tools, are unavailable. The open challenge is to evaluate and maintain skill usability as a graph-structural property: the agent must know not only which skill matches the task, but whether the dependency subgraph around that skill can actually support execution. Thus, scaling self-evolving agents requires skill activation mechanisms that prevent text-similar but structurally invalid skills from being selected as the library grows.

Challenge V (Workflows): Predicting rewrite cascades in coupled workflow–topology graphs. Workflow graphs and multi-agent topologies are tightly coupled: changing an execution step can also change roles, communication edges, dependency order, and tool or skill invocation. Unlike tool-edge validation, which focuses on whether a selected tool relation remains executable and authorized, workflow evolution concerns broader topology cascades across execution and coordination structures. The open challenge is to predict and bound these cascades before commitment: which downstream roles, edges, and execution dependencies will change, and which graph regions should remain stable. Addressing this would make workflow self-repair more controllable without silently destabilizing collaboration topology.

Challenge VI (Multi-agent): Safety governance over propagation paths. Multi-agent safety failures often do not originate from a single agent, but from harmful information or unreliable assumptions propagating along communication edges. Once such influence spreads along propagation paths, e.g., paths through shared memories, the final failure may be far removed from the original source. The open challenge is to localize and govern these propagation paths: identifying where unsafe influence entered, which edges or nodes carried it, and where the system should block, review, or roll back. We would make multi-agent safety a graph-governance problem, enabling agents to contain harmful propagation before it becomes downstream behavior.

6. Conclusion

In this paper, we study self-evolving agents from a dynamic-graph perspective by framing agent evolution as dynamic graph transformation. This provides a new structural lens for discussing existing graph-native and graph-transformable agent methods under a common language. Concretely, we organize existing self-evolving-agent works based on dynamic graphs/topologies into four graph-transformation patterns, showing that existing agent-evolution mechanisms, e.g., memory editing or workflow optimization, can be analyzed as changes to nodes, edges, activated subgraphs, and cross-component dependencies. Furthermore, we connect this four-pattern taxonomy to nine dynamic graph learning families, positioning dynamic graph methods as reusable infrastructure for controllable agent evolution. We also develop five graph-aware evaluation and governance protocols that complement end-task evaluation, and identify six open challenges for benchmarkable and reliable self-evolving agents. Together, these contributions shift the discussion from ad hoc adaptation to structured and governable agent evolution.

Limitation. The goal of this survey is to provide a dynamic-graph perspective for understanding, improving, and governing self-evolving agents, rather than to exhaustively cover all self-evolving-agent works. This perspective connects existing agent-evolution research with dynamic graph learning, showing how DGL methods can serve as reusable infrastructure for self-evolving agents. As a result, some graph-based agent systems and non-graph self-evolving-agent methods may be omitted or briefly mentioned rather than classified in detail.

In addition, our mapping from dynamic graph learning to self-evolving agents is primarily conceptual. It provides research insights and possible infrastructure designs, but does not provide empirical evaluation. We leave this as future work.