Knowledge Graphs as Files:
An Agent Harness Where Tool Creation and Tool Use Co-Evolve

1Texas A&M University, 2University of Oregon
Figure 1: a predefined neighbors tool versus DKGI on a STaRK-MAG request

Figure 1: An example from the STaRK-MAG dataset: “Papers on data quality enhancement algorithms affiliated with the University of the Balearic Islands”. (a) A neighbors call can only return 20 (out of 66) researchers affiliated with the university. The agent never encounters the gold paper in this run. (b) In our DKGI, tool creation and tool use co-evolve: execution feedback guides how the agent revises and extends its code, and the revised code gathers further evidence, ultimately isolating the gold paper. Bracketed numbers denote call indices.

Abstract

Searching text-rich knowledge graphs requires following relations while examining textual evidence. Predefined graph interfaces constrain what evidence agents can access, even when they write code to combine tool calls or process retrieved subgraphs. We propose direct knowledge graph interaction (DKGI), a harness in which language model agents create graph access tools directly over complete node and edge files. The agent writes Python code to follow relations, combine node sets, and select textual evidence, interleaving execution with shell search and file inspection. This lets agents process large node sets in bulk while returning selected text for the model to assess. Execution feedback guides tool creation and revision, while the evolving tools determine what evidence the agent gathers next. On benchmark datasets spanning three domains, training-free DKGI exceeds the strongest published baseline by at least 6.7 Hit@1 points on every graph, even with a minimal harness. Controlled ablations show the benefits of multi-turn programming over shell-only access and predefined graph tools, while trajectories show agents revising code to extend searches or address errors. These findings highlight the value of allowing tool creation and tool use to co-evolve during graph search.

Three Settings of Graph Access

Existing methods typically access the graph through specialized interfaces: database query languages, retrievers that return reasoning paths or subgraphs, and tools for entity search, node lookup, and neighbor expansion. Some agents write code that combines predefined graph tool calls, while others generate code to traverse graph objects provided by a dedicated subgraph retriever. Across these designs, access to the underlying graph remains governed by a predefined interface. DKGI exposes textual node records and typed graph relations as files, together with the graph schema, and lets the agent implement graph access directly over the complete node and edge files.

PredefinedWritten by the agent
Settinggraph API / retrievercoderevisionsdirect file access
① Direct tool use
ToG, Graph-CoT, ARK, GRASP; Graph tools
✓–––
② Code over a graph interface
semantic parsing, KG-Agent, Code-on-Graph, AvaTaR; Graph tools + code
✓✓(✓)–
③ Direct knowledge graph interaction
Full DKGI
–✓✓✓

Table 1: Graph access and agent-written code across three settings. Direct file access lets agent-written code access all node and edge files without a predefined graph API or subgraph retriever. “(✓)” indicates support in some systems. Italicized entries denote our controlled variants.

On the same request, DKGI writes and revises graph access code (tool creation) and executes it to gather evidence (tool use). Execution feedback guides which access operations to create or refine. The resulting code, in turn, changes how the agent explores the graph and what evidence it obtains. Tool creation and tool use thus co-evolve: the agent develops its tools as it searches, and its evolving tools guide the subsequent search.

Main Results on STaRK

We evaluate DKGI as a training-free method on the three knowledge graphs of the STaRK benchmark (Amazon, MAG and Prime), in the minimal Pi harness and in the more feature-rich Codex CLI. Even in Pi, our best DKGI configuration exceeds the strongest published baseline (GRASP) by at least 6.7 Hit@1 points on every dataset.

AmazonMAGPrime
MethodH@1R@20MRRH@1R@20MRRH@1R@20MRR
Trained or tuned on STaRK
AvaTaR49.960.658.744.450.651.218.439.326.7
PASemiQA45.9–55.743.2–50.229.7–31.0
mFAR (All+2)53.066.364.355.974.164.340.072.652.0
MoR52.259.962.258.275.067.136.463.546.9
GraphRAFT–––69.689.176.263.776.469.0
GRASP71.270.678.782.891.588.367.888.176.8
Training-free
BM2544.953.855.325.945.734.912.831.319.8
ColBERTv246.153.455.531.243.938.411.825.017.4
GritLM-7B42.156.553.537.946.447.315.639.124.1
KAR54.257.261.350.560.357.530.450.839.2
HybGRAG–––65.465.769.828.643.634.5
AF-Retriever†61.235.567.378.661.484.046.251.254.0
ARK56.158.665.773.186.281.050.670.059.6
KG reasoning methods adapted to STaRK by Yang et al. (2025), with GPT-4‡
ToG16.7–21.25.4–6.113.2–15.8
RoG31.2–36.032.9–38.722.7–25.2
GoG21.0–26.341.3–47.818.9–21.1
Ours: direct knowledge graph interaction (training-free)
DKGI (Pi, GPT-6-Luna)57.858.164.788.088.489.863.878.970.4
DKGI (Codex, GPT-6-Luna)59.855.266.288.088.189.666.680.972.4
DKGI (Pi, GPT-6-Astra)79.471.184.091.893.293.274.586.179.1

Table 2: H@1, R@20 and MRR on the synthetic test sets of STaRK. Bold marks the best value in each column. Baseline numbers are published values (backbones in the paper's appendix), and a dash marks a value absent from the source paper. †R@20 from the complete-pipeline row of its ablation table. ‡From the H@1 and MRR tables of Yang et al. (2025). The DKGI rows cover the full test sets (7,108 queries) and share the prompt and the time limit.

Ablation Study

We fix the model (GPT-6-Luna), the harness (Pi), the budgets and the prompt apart from its tool section, and vary which actions the agent can take. A 2×2 design crosses graph access (the graph files or predefined graph tools based on ARK) with Python. All variants run on STaRK's test subset (710 queries).

H@1Overall
VariantGraph accessPythonAmazonMAGPrimeOverallΔR@20MRR
Full DKGInode and edge files✓59.191.069.675.2–78.078.9
Shell onlynode and edge files–48.886.162.968.3−6.969.572.0
Graph tools + codepredefined graph tools✓60.490.267.174.2−1.079.478.9
Graph toolspredefined graph tools–59.887.666.472.8−2.479.577.6
One programnode and edge filesonce48.287.263.969.0−6.270.872.5
Retrieval onlysearch, get_node, get_schema–58.548.540.747.7−27.555.153.9
No edgesnode files✓49.445.540.044.2−31.052.650.6
Full DKGI (Codex)node and edge files✓58.587.667.573.0−2.375.576.9

Table 3: Ablation on the test subset (710 queries) with GPT-6-Luna in Pi, unless marked Codex. Python: ✓ over several turns, “once” for a single program per query, and – for no Python access. The first four rows form the 2×2 design, the fifth row limits Python to one program, and the last three rows are controls. Δ: overall H@1 minus that of Full DKGI.

With Python, the agent outperforms predefined graph tools in overall H@1. With the shell but no Python, the agent scores 68.3 overall H@1, below Graph tools (72.8). With Python, Full DKGI reaches 75.2, 2.4 points above Graph tools.
Python improves the agent far more than it improves predefined graph tools. On the graph files, adding Python improves overall H@1 by 6.9 points. With the graph tools, adding Python improves overall H@1 by 1.4 points.
The agent gains most from Python when it writes and executes programs over several turns. One program reaches 69.0 overall H@1 and recovers about a tenth of the 6.9-point gain from Python on the graph files.
The agent relies on the relations in the graph. No edges reaches 44.2 overall H@1, 31.0 points below Full DKGI. The closed-book ID probe, in which the model answers from its own knowledge, shows little recall of benchmark IDs.

How Tool Creation and Tool Use Co-Evolve

Figure 2: behavior of Full DKGI on the full test sets

Figure 2: Behavior of Full DKGI (Pi, GPT-6-Luna) on the full test sets. (a) Python commands, rg searches and other calls (mostly read) by position in the trajectory. (b) Programs by operation type (types overlap). The blue types have counterparts among predefined graph tools. (c) Error types of incorrectly answered queries.

The agent searches first and then writes programs. A trajectory starts with file reads and rg searches, and Python makes up 83.3% of the calls in its last 20%. The agent writes 4.0 programs per query on average.
Programs reuse IDs from earlier outputs and code from earlier programs. Of all programs, 48.4% contain a node ID shown in the output of an earlier turn. After a program fails, the next program revises it in 88.6% of cases, and after a program runs successfully, the next program revises it in 49.7% of cases.
The agent's lead over predefined graph tools is largest on queries where both tool-based agents make many calls. On the 100 test-subset queries for which both Graph tools and Graph tools + code call neighbors at least ten times, Full DKGI leads them by 9.0 and 6.0 H@1 points.
With a stronger LLM, the agent reuses earlier outputs more often and revises more of its failed programs. With GPT-6-Astra, 59.9% of its programs contain an ID from an earlier output, and the next program revises a failed one in 92.2% of cases.

Code and Data

ResourceContentLicense
leopoldwhite/DKGIcode that exports the STaRK graphs to files, runs every configuration and computes the paper's numbers; exact prompt textsMIT
yuyangbai/DKGI-STaRK-Graphsthe exported node and edge files, questions and labels of the three STaRK graphsCC BY 4.0
yuyangbai/DKGI-Trajectoriesfor every test configuration and question: the agent's trajectory, its answer and its scoresCC BY 4.0

BibTeX

@misc{bai2026dkgi,
  title  = {Knowledge Graphs as Files: An Agent Harness Where Tool Creation and Tool Use Co-Evolve},
  author = {Bai, Yuyang and Wang, Yu and Zhang, Yu},
  year   = {2026}
}
Texas A&M University University of Oregon