Knowledge Graphs as Files (DKGI) — agent-written graph tools — What does it mean?
The news. On October 13, 2026, researchers from Texas A&M University and the University of Oregon posted a paper that gives a language-model agent the complete node and edge files of a knowledge graph and lets it write its own graph-access tools. Across three STaRK graphs, the best training-free configuration beat the strongest published baseline on each graph by at least 6.7 Hit@1 points. Read the paper →
Picture the library desk that hands out 20 cards at a time. You ask for every paper by researchers at one university, and the clerk returns 20 names. You can ask again with a different filter, but you never see the other cards, so the paper you need may simply never reach your table. That is how a fixed graph tool behaves: the interface, not the agent, sets how much evidence each call exposes.
Now give the researcher keys to the whole archive instead. DKGI exports the graph into plain files: one JSON line per node with its ID, type and text, one tab-separated edge list per relation type, and a short schema. The agent reads the format description first, then writes Python over those files. The paper groups the code it observed into six kinds of operation: a full node scan, an ID lookup, a one-hop traversal, a multi-hop traversal, set operations such as intersection, and scoring or ranking.
The agent builds its sorting jig per question, and each run teaches it how to rebuild the jig. A query like "papers by co-authors of X on topic Y" becomes a short composition: follow writes from X, follow it backwards to find co-authors, drop X, follow writes forward again, and intersect with the papers that have topic Y. The code then pulls abstracts for the survivors so the model can judge the text. When a run returns an empty set or an error, the agent narrows a filter or repairs the code, and the repaired code changes which nodes the next run touches. The paper calls this co-evolution, and notes it happens within one task, with no training and no tool library carried across tasks.
Because broad traversals can produce more output than the context window can hold, the Pi harness saves every command's full output to a file and shows the model only the head and tail plus the file's size and path. Later code can search that file. This is the same trade-off as any tool whose results are too big to inline: the interface decides what the model sees, so the paper lets the agent control it.
| Variant (710-query test subset, GPT-6-Luna in Pi) | What the agent can do | Overall Hit@1 | Source |
|---|---|---|---|
| Graph tools | Calls four predefined tools (search, get_node, get_schema, neighbors) | 72.8 | Table 3 |
| Graph tools + code | Writes Python that calls those same four tools | 74.2 | Table 3 |
| Shell only | Reads the files with shell commands, no Python | 68.3 | Table 3 |
| One program | Reads the files but gets a single Python run per query | 69.0 | Table 3 |
| Full DKGI | Reads the files and writes Python over several turns | 75.2 | Table 3 |
| No edges | Node files only, with Python | 44.2 | Table 3 |
Worked example, using the paper's own Figure 1. A request asks for papers on data quality enhancement affiliated with the University of the Balearic Islands, and 66 researchers are affiliated with it. A neighbors call returns at most 20, so the agent sees 20 of 66, about 30%, and that call leaves 46 researchers out of view. In the run the paper shows, the agent never meets the correct paper. By contrast, code over the node and edge files can list all 66, filter their papers by topic text in bulk, and return only the selected abstracts to the model (our illustration of the mechanism, not a quoted trace).
The controlled test shows where the gain comes from. Holding the model, harness and budgets fixed, adding Python to the files moves overall Hit@1 from 68.3 to 75.2, a gain of 6.9 points. Adding Python on top of the predefined tools moves it from 72.8 to 74.2, a gain of only 1.4 points. So code helps a little when it must go through the API, and a lot when it can read the data directly. Limiting the agent to one Python run (69.0) wipes out nearly all of that gain, which is why the multi-turn loop matters, and deleting the edge files drops the score to 44.2.
What this does not show. All of these numbers come from one benchmark (STaRK) and the paper's chosen backbones, GPT-6-Luna and GPT-6-Astra, so they say little about other graphs or models. The graphs are exported to files ahead of time, which suits a graph that can be exported to files before the query starts. And letting an agent run arbitrary code over data is a separate security question from the accuracy results above; see Tools as Attack Surface before copying the pattern.
For tool designers the transferable idea is narrow: when a tool's output limit is what hides the answer, a thinner interface will not fix it; give the agent a way to compute over the data. Read it next to the tool schema step and retrieve-then-generate, where retrieval is usually a fixed call, and RAG failure modes, where evidence that never gets retrieved is the classic miss.
Goes deeper in: AI Agents → Tool Use & Function Calling → Tool Design — ACI + Anti-Patterns