“Are we still talking loops or did we shift to graphs yet?”. Deze woorden van Peter Steinberger op 18 juli 2026 zette een lawine in gang op X. Binnen 48 uur had de term graph engineering drie concurrerende betekenissen en  duizenden likes. Graph engineering is het ontwerpen van de structuren waar AI-agenten mee werken: welke nodes er bestaan, welke overgangen toegestaan zijn en hoe werk door het systeem stroomt. Prompt engineers stuurden de woorden van het model. Loop engineers stuurden de iteraties. Graph engineers sturen de topologie.

Van prompt engineering naar graph engineering

Graph engineering is de nieuwe hypeterm. In 2023 draaide alles om prompt engineering, het formuleren van de woorden die je naar het model stuurt. Medio 2025 volgde context engineering, het samenstellen van alles wat het model te zien krijgt. Juni 2026 bracht loop engineering, het ontwerpen van de cyclus van observeren, redeneren, handelen en verifiëren. In Juli 2026 kwam graph engineering op de proppen: het ontwerpen van wat er tussen en over loops heen gebeurt.

Deze lagen vullen elkaar aan. Een graph vol onbeheerde loops is een organigram van onbetrouwbare medewerkers. Sterke loops met een random topologie geven coördinatiefouten zodra je ze opschaalt. Graph engineering benoemt de laag boven loop engineering.

Drie betekenissen en twee componenten

De virale term kreeg binnen twee dagen drie betekenissen. De eerste is het orchestreren van multi-agent-systemen als expliciete graph, het territorium van frameworks zoals LangGraph. De tweede is een netwerk van zelfverbeterende loops die elkaar bewaken. De derde is kennis en geheugen in graphvorm.

Task graphs beschrijven hoe agenten werken. Nodes zijn taken, edges zijn uitvoeringsmodaliteiten. Knowledge graphs beschrijven wat agenten onthouden. Nodes zijn entiteiten en feiten, edges zijn relaties met een tijdstip en een herkomst.

Taskgraphs als blauwdruk voor agentwork

LangGraph, het bekendste graphframework, wordt maandelijks meer dan 65 miljoen keer gedownload. Het model is eenvoudig. Nodes doen het werk: deterministische code, een LLM bevragen, een tool aanspreken of een complete agent aan het werk zetten. Edges bepalen wat er daarna gebeurt. Sommige edges zijn vast, andere zijn conditioneel en hangen af van de uitkomst van een node of van een extern signaal. Je leest de graph als een state machine met een workflow, een toestand die evolueert en overgangen daartussen.

Drie jaar bouwen aan zulke systemen leverde een aantal lessen op:

  • Loops horen erbij. Productieagenten proberen mislukte tool-calls opnieuw, vragen gebruikers om ontbrekende informatie en herzien antwoorden na validatie. Puur lineaire DAG’s komen in productie zelden voor. Loops vormen de kern van agents.
  • Dynamische nodes zijn essentieel. Je weet vooraf niet hoeveel workers je nodig hebt. Een node moet  werk kunnen uitsplitsen. Je weet niet vooraf hoeveel vervolgnodes er nodig zijn.
  • De diamant als voorstelling. Splits een taak, laat parallelle workers aan de slag, gebruik aparte verifiers met eigen context en laat één eigenaar de resultaten samenvoegen.
  • De soort werk bepaalt of je best agents gebruikt. Onderzoek van Google DeepMind en MIT toonde aan dat agentteams in ongeveer 80 procent betere resultaten opleveren voor opdrachten die opsplitsbaar zijn. Terwijl agentteams slechtere resultaten opleveren sequentieel werk. De aard van het werk beslist of je agents gebruikt of niet.
  • De human in de loop moet op de juiste plek controleren. Bepaal dat menselijke goedkeuring nodig is op plaatsen in het proces waar een fout ongedaan maken veel kost.
  • Verwijder nepedges. Soms brengt een edge niets bij aan het resultaat en heeft deze geen zin.

Knowledge graphs, het geheugen van agents

De tweede helft van graph engineering gaat over geheugen. Vector search vindt dingen die op je vraag lijken, graphs vinden dingen die met je antwoord verbonden zijn.

Neem de vraag “waarom hebben we Redis vervangen voor de job queue?” Vector search haalt tien fragmenten over Redis op. Het antwoord zit in de structuur: een besluitdocument dat een ouder besluit vervangt, dat op zijn beurt veroorzaakt werd door een incident. Drie documenten, één causale keten. Alleen een graph kan die keten stap voor stap volgen. De meeste interessante vragen over een echte kennisbasis zijn zulke multi-stap-vragen.

Het verschil zit in getypeerde edges. Een ongetypeerde edge zegt alleen dat twee dingen gerelateerd zijn, één bit aan informatie. Een getypeerde edge zegt hoe ze verbonden zijn: supersedes, depends_on, decided_by, caused. Dankzij die types kan een agent over de graph redeneren in plaats van elke link opnieuw te moeten interpreteren.

Knowledge graphs kunnen ook iets dat vector stores niet kunnen, rekening houden met tijd. Graphiti, de open-source-engine achter Zep, houdt per edge twee tijdslijnen bij, namelijk wanneer een feit waar was en wanneer het systeem het leerde. Nieuwere informatie sluit de geldigheid van de oude edge af in plaats van die te overschrijven. Zo beantwoordt dezelfde graph zowel “waar werkt ze?” als “waar werkte ze in 2024?” Beslissingen vervangen beslissingen en claims verouderen.

Wat onafhankelijke benchmarks zeggen

Graphs winnen op drie terreinen. Bij multi-stap-redeneren scoort GraphRAG 53,4 procent tegen 42,9 procent voor vector-RAG, en HippoRAG 2 verslaat een sterk embeddingmodel met 9,5 F1-punten. Bij temporeel redeneren scoort de graphvariant van Mem0 58,1 waar het geheugen van OpenAI op 21,7 blijft steken. Voor synthese zijn de scores respectievelijk 64,4 en 51,3 procent.

Graphs verliezen op twee terreinen. Bij het opzoeken van eenvoudige feiten wint vector search nipt, met 60,9 tegen 60,1 procent. De kosten lopen bovendien op. De globale zoekfunctie van Microsoft GraphRAG verbruikte in de benchmark 331.375 tokens per vraag, tegen 880 voor vector-RAG. HippoRAG 2 laat met 1.008 tokens zien dat efficiëntie wel degelijk kan.

Routeer op vraagtype. Vector search voor lookups, graphs voor ketens.

Waar graph engineering-projecten mislopen

Als graph benchmarks winnen, waarom worden ze dan niet meer gebruikt? Omdat entity resolution roet in het eten gooit. Entity resolution is beslissen dat dr. Jan Smit, J. Smit en Jan één node vormen, en dat Mercurius de planeet en Mercurius het scheikundig element (kwik) en Mercurius de Romeinse god juist drie nodes zijn. Extractiepipelines maken hier constant fouten, en die fouten worden groter over meerdere stappen (hops). Bij 95 procent nauwkeurigheid per hop is een keten van vijf hops nog 77 procent betrouwbaar. Bij 85 procent zakt dat naar 44 procent. Je indrukwekkend multi-hop-proces krijgt evenveel waarde als een muntopgooi. Wat graph engineering duur maakt is het beslissen wat hetzelfde ding is, veel meer dan het ontwikkelen van graphalgoritmes.

Wanneer je graph engineering gebruikt en wanneer je het vermijdt

Graphs blinken uit waar een workflow een voorspelbare structuur heeft. Een supportagent classificeert een probleem voordat hij antwoordt of escaleert. Een coding-agent inspecteert de repository voordat hij een wijziging voorstelt.  Met een graph leg je jouw kennis over hoe het systeem hoort te werken vast in code, net zoals je domeinkennis in prompts stopt.

Bij taken die van nature agentisch zijn, schiet een vaste graph tekort. Generieke deep research vereist plannen, delegeren, zoeken en samenvatten op manieren die je vooraf moeilijk vastlegt. GPT Researcher verving zijn graphvormige multi-agent-pipeline door een agentische kernloop. Hier wordt de planning en de delegatie van de deeltaken pas bepaalt tijdens de opdracht.

De sterkste systemen combineren beide. Determinisme waar het kan, agentic waar het waarde toevoegt. Die mix maakt het systeem meer voorspelbaar, sneller en goedkoper.

Wat overblijft als de hype voorbij is

Het label graph engineering zal net als zijn voorgangers blijven evolueren. Maar de kern blijft. Wie de structuur van een AI-systeem bewust ontwerpt, hoeft minder te hopen dat het model telkens de juiste keuze maakt. De investering zit in het opruimen van entiteiten, het typeren van edges en het kiezen van de juiste route per vraag.