Much of the conversation about graphs in AI assumes the graph already exists: we discuss graph neural networks, GraphRAG, graph agents, and graph foundation models. Far less attention goes to the critical step that determines what those systems can do — converting raw data into the right graph.
Consider a company that stores customer records in tables, support conversations in documents, product telemetry in event streams, and incident histories in tickets. Before any of that becomes a usable graph, someone must decide what counts as an entity, what constitutes a relationship, how to represent time, and which source to trust when records conflict. Those decisions shape every downstream prediction, retrieval result, and agent action.
I call this perspective graph‑native AI: treating graph modeling as a first‑class stage between raw data and the systems that consume it. The graph becomes a shared representation supporting queries, prediction, retrieval, agents and, potentially, foundation models.
What a graph actually is — and why that matters
At its simplest, a graph has nodes and edges, possibly with features. Real systems also require types, timestamps, provenance, confidence, permissions and other context. Describing the finished graph tells us little about how to build it.
Take support data as an example. Should a company be one node or a set of legal entities that change over time? Is an email an edge between two people, a document node linked to its authors, or evidence for claims extracted from text? Is a purchase a persistent relationship or a timestamped event? If two records refer to the same customer, should we merge them, link them as possible matches, or keep them separate?
There is no single correct answer. An entity graph is useful for identity and relationships, an event graph for process and temporal analysis, and an evidence graph for retrieval and provenance. The right choice depends on the system’s goals.
Graph modeling precedes graph learning
Graph representation learning normally begins with an existing adjacency structure: embeddings learn vectors for nodes, graph neural networks propagate information across neighborhoods, autoencoders reconstruct structure or attributes, and graph transformers combine local graph structure with longer‑range attention. Those methods ask: given this graph, how should we learn from it?
Graph modeling asks a different question earlier: what should the nodes and edges be?
Relational deep learning makes this concrete by mapping rows in relational tables to nodes and primary‑foreign‑key links to edges, producing a temporal heterogeneous graph for a GNN. This reduces manual joins and feature engineering but also assumes that a database schema designed for storage is useful as a graph for machine learning.
Recent work tested that assumption across 26 relational tasks. Graphs derived directly from database schemas sometimes suffered from information overload and semantic fragmentation. The authors improved performance by adapting the structure — removing distracting connections and adding dependencies the original schema missed. This shows the graph itself is part of the learning problem: more edges are not always better; the structure must support the reasoning the task requires.
Therefore graph construction needs its own evaluation loop: generate several plausible graph views, test them on downstream tasks, inspect failures, and revise the structure. Keep provenance and uncertainty so we know where an edge came from and how confident we are in it. The first extractable graph is rarely the only useful one.
What modeled graphs can support
After modeling and validation, multiple design paths are possible. It’s not necessary to build one enormous universal graph. A practical approach is to create several governed views from the same modeled data while keeping identity, evidence, time and access rules consistent underneath. Five common uses:
-
Query and analytics: a graph database and ordinary graph algorithms (traversals, path queries, neighborhood aggregation, centrality, community detection) can reveal relationships that flattening into tables obscures. This is also a baseline: if a deterministic query answers the question, there is no need to start with an LLM.
-
Prediction and graph representation learning: embeddings, GNNs, graph autoencoders and graph transformers can predict at node, edge, subgraph or whole‑graph level (examples: fraud detection, recommendation, molecular property prediction, link prediction). The graph gives the model an explicit view of which entities relate and how information should flow.
-
Retrieval and GraphRAG: the graph may serve as an index rather than training data. Microsoft’s GraphRAG work constructs an entity graph and community summaries to answer broad questions over a corpus that chunk retrieval handles poorly. Other approaches retrieve a task‑specific subgraph and pass it to an LLM. These can help, but the added graph pipeline must improve the final result; benchmarks have found cases where GraphRAG underperformed vanilla RAG and argue that graph construction, retrieval and generation should be evaluated together.
-
Graph‑augmented agents: agents have memory, plans, tools, state transitions and sometimes relationships to other agents. Some state is naturally relational. A graph can make that state persistent, inspectable and easier to update across turns. Emerging literature groups these uses around planning, memory, tool use and multi‑agent coordination. The design question is which parts of an agent’s state benefit from graph representation.
-
Graph foundation models: the aim is to pretrain models that transfer across graph tasks, datasets and domains. Current work mixes graph backbones, self‑supervised objectives, adaptation mechanisms and sometimes language models. The hard part is that graph semantics vary widely: nodes and edges mean different things across molecular, transaction and knowledge graphs. Transfer requires methods to bridge structural and semantic differences, with suitable training data.
What better graph modeling would do
I am not suggesting a single universal converter that outputs one correct graph. A more useful goal is a system that can propose, test and maintain multiple graph views of the same raw data.
Such a system should:
- Identify candidate entities and relations from tables, text, events, images and existing schemas.
- Retain type, time, provenance, confidence and permission metadata.
- Suggest alternatives rather than committing silently to one structure.
- Compare alternatives by downstream quality, cost, stability and human constraints.
- Keep graphs current as source data and organizational understanding evolve.
Downstream feedback is essential: prediction errors can indicate missing relations, retrieval failures may reveal poor granularity or disconnected evidence, agent failures can show absent state transitions, and weak transfer across datasets can expose schema misalignments. In this view, a graph is judged by what it enables the system to do.
Today teams often build a graph for a single application (fraud, recommendation, or a chatbot knowledge graph). There is broader opportunity: carefully done graph modeling could allow the same raw data to support multiple graph views and applications without rebuilding identity, provenance and governance each time.
We already have strong methods for learning from graphs; the harder and less settled problem is deciding which graph to build. Making that step systematic and measurable would elevate graph modeling into a field of its own and a shared foundation for analytics, prediction, retrieval, agents and foundation models.
References (as cited)
- Arijit Khan, Longxu Sun, Xin Huang, “LLMs+Graphs: Toward Graph-Native, Synergistic AI Systems,” arXiv, June 2026.
- William L. Hamilton, Graph Representation Learning (Morgan & Claypool, 2020).
- Matthias Fey et al., “Relational Deep Learning: Graph Representation Learning on Relational Databases,” arXiv, submitted Dec 2023.
- Yao Cheng and Siqiang Luo, “What Makes a Desired Graph for Relational Deep Learning?” arXiv, submitted June 2026.
- Darren Edge et al., “From Local to Global: A Graph RAG Approach to Query-Focused Summarization,” arXiv, revised Feb. 19, 2025.
- Zhishang Xiang et al., “When to Use Graphs in RAG,” arXiv, revised Feb 2026.
- Yixin Liu et al., “Graph-Augmented Large Language Model Agents,” arXiv, revised Aug 2025.
- Zehong Wang et al., “Graph Foundation Models: A Comprehensive Survey,” arXiv, May 2025.
