Ability Graphs: Capabilities and Applications

• Ability graphs are structured representations that define capabilities through shared procedures in agent benchmarking or quality dependencies in driving systems.
• They are constructed by linking tasks with common operational triggers, supporting transfer evaluation and diagnostic analysis of encoding, routing, and uptake.
• Alternative paradigms like prompt graphs and tool routing illustrate evolving graph-based reasoning, integrating LLM capabilities with modular skill architectures.

Searching arXiv for recent and foundational papers on ability graphs and related graph-based capability representations. Ability graphs are graph-structured descriptions of capabilities, but the term is used in more than one technically distinct sense. In agent benchmarking, an ability graph links tasks through shared procedural operations extracted from execution traces; in driving systems engineering, it denotes a directed, acyclic graph of abilities and their quality dependencies; and in adjacent LLM-on-graph work, the phrase is often used interpretively for prompt graphs, tool-routing structures, or capability landscapes rather than as a single formalism (Gao et al., 6 Jul 2026).

1. Definitions and semantic scope

In EvoAgentBench, an Ability is explicitly procedural: “not a dataset label, topic, or repository name,” but “a reusable operation such as a search strategy, debugging procedure, or validation workflow.” A raw Ability card is a tuple

$$a = (\gamma_a, \pi_a, \mathcal{E}_a, \partial_a, \rho_a),$$

where $\gamma_a$ is the trigger condition, $\pi_a$ the procedure, $\mathcal{E}_a$ the evidence, $\partial_a$ the applicability boundary, and $\rho_a$ the role, taking values Method, Guard, or Workflow (Gao et al., 6 Jul 2026). Under this definition, abilities are trace-grounded operational units that specify not only what procedure is reused, but when it should be applied and where its transfer should stop.

In the driving-systems literature, the semantic center of gravity is different. Pfab et al. adopt the definition that “an ability is the entirety of conditions which are necessary to provide a certain part of the driving task,” and describe an ability graph as a directed, acyclic graph whose nodes are abilities and whose edges represent quality dependencies between them (Pfab et al., 2024). This makes the object solution-neutral: nodes describe what must hold for safe driving, not which software module, sensor, or human action realizes it.

These two lines of work share a family resemblance but not an identical ontology. EvoAgentBench treats abilities as reusable procedures distilled from trajectories; the driving framework treats abilities as conditions necessary to realize parts of a task. A plausible implication is that “ability graph” is best understood as a meta-category for graph-structured capability representations, with the precise semantics determined by the application domain.

A recurring misconception is to equate ability graphs with task graphs, curricula, or knowledge graphs. EvoAgentBench explicitly distinguishes its graphs from traditional task graphs and curricula, where links are based on labels, difficulty, or prerequisite knowledge, and from knowledge graphs, where nodes and edges encode entities and semantic relations. Its edges are instead grounded in shared procedural operations extracted from traces (Gao et al., 6 Jul 2026).

2. Procedure-level ability graphs in EvoAgentBench

EvoAgentBench builds its benchmark around domain-specific Ability Graphs in order to evaluate procedure-level transfer in long-horizon agents. For each domain $d$, it constructs an undirected graph

$G_d = (V_d, E_d),$

where $V_d$ is the set of tasks in the domain and $E_d$ contains an edge between two tasks iff they share at least one edge-eligible canonical Ability (Gao et al., 6 Jul 2026).

Given canonical Ability units $\gamma_a$0, the abilities associated with a task $\gamma_a$1 are

$\gamma_a$2

and the edge-eligible subset $\gamma_a$3 is obtained by filtering to units supported by at least two distinct tasks and still operationally specific after merging. The edge rule is

$\gamma_a$4

Each edge stores the shared Ability units and their roles, and isolated tasks are kept only for training, never as test tasks (Gao et al., 6 Jul 2026).

The benchmark spans four agentic domains: web research, algorithmic reasoning, software engineering, and knowledge work. Tasks come from BrowseComp-Plus, LiveCodeBench, SWE-Bench Verified, and GDPVal. In this construction, raw trajectories from multiple backbones are not merely archived as memory; they are transformed into a substrate for transfer by identifying reusable operations with verified evidence and explicit applicability boundaries (Gao et al., 6 Jul 2026).

The per-domain graphs have markedly different structural character. BrowseComp-Plus is dense, with 572 nodes, 66,046 edges, and density $\gamma_a$5, reflecting broad reuse of search and verification procedures. SWE has 113 nodes, 1,828 edges, and 6 isolated nodes, consistent with the paper’s observation that repository-specific repair procedures generalize less readily. Across the retained graph, EvoAgentBench reports 1,108 tasks and 170 canonical Ability units, with per-domain unit counts of 38 for web research, 58 for algorithmic reasoning, 38 for SWE, and 36 for knowledge work, and an average of approximately 2.3 Abilities per task (Gao et al., 6 Jul 2026).

3. Extraction, canonicalization, and evaluation

The construction pipeline begins with multi-backbone trace collection. For a task $\gamma_a$6, the trace pool is

$\gamma_a$7

where $\gamma_a$8 is the execution trajectory, $\gamma_a$9 the output, and $\pi_a$0 the verifier scores. An extractor $\pi_a$1, implemented using Claude Sonnet 4.6, consumes the task query, the ground-truth target, and the multi-backbone trace pool to produce task-local raw Ability cards. Cards are retained only if they are grounded in specific trajectory spans, actionable, and bounded narrowly enough to avoid spurious broad transfer (Gao et al., 6 Jul 2026).

Canonicalization then transforms these local cards into shared operational units. The process uses embedding blocking with Gemini Embedding 001, LLM adjudication by Kimi-K2.5, GLM-5.1, and DeepSeek-V3.2, and expert review for non-unanimous cases. Merge decisions induce a compatibility graph; connected components are accepted as canonical units only if all internal pairs are compatible and none has a cannot-link decision. Broad bridge cards may be reassigned to a more specific unit or downgraded to annotation-only status. The accepted unit takes the form

$\pi_a$2

This process yields 170 canonical Ability units over 7,326 raw cards and 2,516 tasks (Gao et al., 6 Jul 2026).

After graph construction, EvoAgentBench applies Louvain community detection to obtain Ability communities. These communities are not evaluation labels; they localize train-side support for test tasks during split construction. The resulting benchmark uses a 528/267 train/test split with zero unsupported test tasks. Every test task must have train-side Ability support, and every Ability family that appears in test must also appear in train. Support@10 averages 10.00 for web research, 7.45 for algorithmic reasoning, 6.82 for SWE, 9.25 for knowledge work, and 8.34 overall (Gao et al., 6 Jul 2026).

This design changes what transfer is being measured. The benchmark’s primary quantity is

$\pi_a$3

where $\pi_a$4 is the baseline score and $\pi_a$5 is the score after applying a self-evolution method. Because every test task is ability-supported yet instance-disjoint, failure can be analyzed as a defect in encoding, routing, or uptake rather than as a consequence of unsupported generalization. The diagnostic “Anchor Skill” condition, which uses curated Ability-grounded skills and curator-side routing via the Ability Graph, yields positive gains in every scaffold–backbone–domain cell, whereas no automatic method sustains positive gain in all settings (Gao et al., 6 Jul 2026).

4. Holistic ability graphs for driving systems

The driving-systems formulation treats ability graphs as an instrument for stakeholder analysis, requirements engineering, and formalized system description. Pfab et al. argue that the graph should cover “the entirety of abilities required for any driving system,” whether autonomous, remote-operated, or human-driven. The graph is directed and acyclic, its nodes are solution-neutral abilities, its edges represent quality dependencies, and its leaves are data sources or data sinks (Pfab et al., 2024).

The paper proposes a four-step construction method. First, existing task descriptions are converted into graphs. Second, these graphs are transformed into weakened ability graphs by renaming nodes as abilities, reformulating or removing implementation-specific nodes, reevaluating edges to retain quality dependency semantics, and inserting appropriate sources and sinks. Third, the resulting graphs are merged into a holistic graph by identifying identical abilities across different source models. Fourth, usability is enhanced through clustering of similar abilities and detailed sub-abilities to reduce complexity while preserving relations and coverage (Pfab et al., 2024).

The source material is deliberately heterogeneous: Bubb’s driving-task hierarchy, SAE J3016 DDT subtasks, Pendleton’s AV software pipeline, Fastenmeier’s requirements for vehicle guidance, Donges’s three-level driving task hierarchy, and Wickens’s information-processing model. Identical nodes such as “perception,” “environmental perception,” “monitoring the driving environment,” and “perceiving the environment” are merged, whereas concepts such as “localization” remain distinct where the semantics differ (Pfab et al., 2024).

The resulting taxonomy includes branches for perception, self-perception, prediction, decision making, guidance, navigation, vehicle operation, communication, and secondary and tertiary tasks. Examples given in the paper include perceiving road geometry, perceiving traffic signs, predicting the behavior of other road users, controlling longitudinal motion, controlling lateral motion, selecting gears, obeying traffic rules, and communicating with the environment (Pfab et al., 2024).

A central methodological point is that the graph is not an implementation architecture. It can be mapped to Autoware-style autonomous-driving modules, to teleoperation systems that distribute responsibilities across onboard automation, remote operators, and communication infrastructure, or to human driving requirements such as those assessed in a German driver’s license exam. The same graph thereby functions as a common semantic reference across autonomous, remote, and human driving, while remaining solution-neutral (Pfab et al., 2024).

5. Prompt graphs, tool routing, and graph reasoning as adjacent ability-graph paradigms

Several graph-and-LLM papers use “ability graph” in an explicitly interpretive rather than formally standardized sense. In PRODIGY, the central object is a prompt graph that unifies data graphs, label nodes, prompt examples, and queries. The model performs message passing first within each data graph and then across the task graph, so that label nodes aggregate information from support examples and transmit it to queries. The paper’s technical description explicitly interprets this prompt graph as a structured ability graph, where label nodes function as ability prototypes and data nodes provide evidence for which abilities should be activated in context (Huang et al., 2023).

Graph-ToolFormer organizes graph-related capabilities as modular tool-invocation patterns. The system teaches a causal LLM to generate graph-loading calls GL(...) and graph-reasoning calls GR(G, domain:func, args) for graph property computation, bibliographic topic classification, molecular graph classification, recommendation, community detection, and knowledge-graph search. The paper does not use the term “ability graph” explicitly, but its own technical explanation describes the framework as a graph of abilities in which capability nodes such as toolx:diameter, graph-bert:topic, seg-bert:molecule-function, bpr:recommendation, kmeans:community, and transe:relation are connected to appropriate datasets and external tools (Zhang, 2023).

GraphLLM addresses a different but related problem: boosting the graph reasoning ability of an LLM by replacing Graph2Text serialization with a graph learning pathway and graph-enhanced prefix tuning. An encoder–decoder extracts node semantics, a graph transformer with RRWP positional encoding learns structural representations, and a fixed-length graph-conditioned prefix is injected into each LLM layer. On four graph reasoning tasks, the method reports an average accuracy enhancement of 54.44% and a context reduction of 96.45% relative to Graph2Text-based baselines, with near-perfect exact-match accuracy on the synthetic tasks studied (Chai et al., 2023).

The broader survey literature places such work in a larger design space. “LLMs on Graphs: A Comprehensive Survey” organizes the area into pure graphs, text-attributed graphs, and text-paired graphs, and describes three model roles—LLM as Predictor, LLM as Encoder, and LLM as Aligner. Within that framing, graphs function as maps of relations, concepts, and reasoning chains that models must learn to encode, traverse, or align with text representations (Jin et al., 2023).

A stricter test of what graph-based reasoning can and cannot support appears in the connectivity literature. “Transformers Can Learn Connectivity in Some Graphs but Not Others” studies reachability in directed graphs and finds that transformers generalize well on low-dimensional grid graphs, where connectivity can be inferred from monotone geometric embeddings, but struggle on disconnected chain graphs with many components. The paper’s technical commentary characterizes this as an induced ability landscape over graph structure, scale, and data regime rather than as a benchmark-defined Ability Graph (Roy et al., 26 Sep 2025).

6. Misconceptions, limitations, and research directions

One persistent misconception is that ability graphs are always explicit formal graph objects with the same semantics across papers. The evidence does not support that view. EvoAgentBench defines a precise undirected graph over tasks with edges induced by shared canonical procedures; the driving literature defines a directed, acyclic graph over solution-neutral abilities with quality-dependency edges; PRODIGY and Graph-ToolFormer use the term interpretively to describe prompt structures or modular skill organization; and the transformer-connectivity work speaks of an induced ability landscape rather than a formal ability-graph data structure (Gao et al., 6 Jul 2026).

Another misconception is that ability graphs are reducible to semantic similarity. EvoAgentBench explicitly rejects this reduction: edges arise from shared, operationally specific procedures under shared triggering conditions, not from topic overlap or metadata similarity. The driving framework makes a parallel distinction by insisting that edges capture quality dependency, not mere information flow (Pfab et al., 2024).

The current literature also exposes sharp limitations. EvoAgentBench remains text-based, spans four domains, uses a single extraction model for raw Ability cards, and depends on non-trivial canonicalization and human adjudication; extending the benchmark to multimodal or embodied agents would require new forms of Abilities, and scaling the construction process to larger task pools is explicitly described as non-trivial (Gao et al., 6 Jul 2026). The driving framework relies heavily on expert reading, discussion, and manual editing, exhibits non-uniform granularity, and requires tool support because the final holistic graph is too large for static inspection (Pfab et al., 2024). In LLM-on-graph systems, tool dependency, hallucination, long-context costs, permutation bias under graph linearization, and poor generalization on non-embeddable graph structures remain recurrent obstacles (Zhang, 2023, Jin et al., 2023, Roy et al., 26 Sep 2025).

Taken together, these works suggest a stable research direction. Ability graphs become most informative when they do not merely enumerate competencies, but specify the structure by which competencies are reused, composed, monitored, or routed. In procedural transfer, that structure supports diagnosis of encoding, routing, and uptake. In safety engineering, it supports completeness checks, responsibility allocation, and degradation analysis. In graph-augmented learning systems, it offers a language for describing how task context, labels, tools, and structural priors are organized. A plausible implication is that future work will increasingly treat ability graphs not as static taxonomies, but as operational interfaces between experience, structure, and decision making.