Graph vs. Loop Engineering bij AI Agents

Bij het ontwerpen van systemen rondom grote taalmodellen staan technische beslissers en engineers voor een fundamentele architectuurkeuze. Hoe geef je een AI Agent de vrijheid om complexe problemen op te lossen, zonder de controle over het proces te verliezen? In de zoektocht naar betrouwbare productiesystemen zijn twee dominante ontwerppatronen komen bovendrijven: loop engineering en graph engineering. Hoewel de termen soms door elkaar worden gebruikt of als tegenpolen worden gepresenteerd, onthult een diepere blik op de onderliggende mechaniek een genuanceerder beeld.

Als Agentic AI Engineer of architect moet je navigeren door een landschap van frameworks, ontwerppatronen en best practices die nog volop in ontwikkeling zijn. Dit artikel ontleedt de concepten graph engineering en loop engineering, traceert waar de begrippen vandaan komen, analyseert de afwegingen en faalmodi, en biedt een kader om de juiste keuze te maken voor jouw specifieke use case.

De fundamenten: Loops en Graphs gedefinieerd

Loop Engineering en de Core Agent Loop

In de basis is een AI Agent een systeem waarbij een taalmodel dynamisch zijn eigen processen en het gebruik van tools aanstuurt, waarbij het model de controle behoudt over hoe een taak wordt volbracht [1]. Dit dynamische proces wordt doorgaans vormgegeven via een 'loop'.

De officiële documentatie van de OpenAI Agents SDK beschrijft deze expliciete agent loop als het kernconcept van hun framework [12]. De mechaniek is relatief eenvoudig maar krachtig: het systeem roept het model aan, inspecteert de output, en neemt op basis daarvan actie. Als het model vraagt om een tool te gebruiken, voert het systeem die tool uit en gaat de loop verder. Als er een 'handoff' plaatsvindt, wisselt het systeem van agent en gaat de loop verder. Pas wanneer het model een eindantwoord genereert zonder verdere tool-aanroepen, stopt de loop en wordt het resultaat teruggegeven [12]. Volgens OpenAI bouwen alle andere functionaliteiten, zoals tools, goedkeuringen en streaming, voort op deze fundamentele loop in plaats van deze te vervangen [12].

Belangrijk terminologieconflict: Het is cruciaal om op te merken dat de term 'loop' niet in de hele industrie hetzelfde betekent. Waar Anthropic, LangChain en OpenAI een loop zien als een model-gestuurd, dynamisch proces, hanteert de Google Agent Development Kit (ADK) een exact tegenovergestelde definitie. In de Google ADK is een "Loop workflow agent" een template waarbij sub-agents in een loop worden uitgevoerd voor een specifiek aantal iteraties of tot een conditie is bereikt, maar waarbij de executie expliciet niet wordt gecontroleerd door een AI-model en volledig deterministisch is [13]. In dit artikel hanteren we de definitie van OpenAI en LangChain, waarbij de loop juist het model-gestuurde hart van de AI Agent vormt, maar wees je als Agentic AI Engineer bewust van deze spraakverwarring in de documentatie van verschillende leveranciers.

Graph Engineering: Controle via State Machines

Tegenover de pure, open-ended loop staat 'graph engineering'. Deze term won sterk aan populariteit nadat LangChain het framework LangGraph introduceerde, dat systemen modelleert als grafen [6, 8]. Bij graph engineering representeer je agentic systemen als een netwerk van knooppunten (nodes) en verbindingen (edges).

De mechaniek hierachter is vergelijkbaar met een state machine. In LangGraph doen de nodes het daadwerkelijke werk. Een node kan deterministische code zijn, een enkele aanroep naar een taalmodel, een tool-executie, of zelfs een volledige AI Agent met zijn eigen interne loop [6]. De edges definiëren vervolgens wat er daarna gebeurt, op basis van de gedeelde datastructuur (de State) [8].

Het doel van graph engineering is om als bouwer jouw vooropgezette ideeën over hoe het systeem moet werken op te leggen via meer begrensde paden. Je vertrouwt niet uitsluitend op het oordeel van het model, maar legt vast waar het model een keuze mag maken en waar het systeem deterministisch gedrag moet afdwingen [6].

De evolutie van het debat: Autonomie versus Voorspelbaarheid

De keuze tussen een open loop en een strakke graph raakt aan een fundamenteel debat in de wereld van Agentic AI: hoeveel autonomie geef je het systeem? Dit debat is de afgelopen jaren sterk geëvolueerd, zichtbaar in de wisselende standpunten van prominente spelers in de markt.

De waarschuwing tegen complexiteit

Anthropic stelt dat de meest succesvolle implementaties geen complexe frameworks of gespecialiseerde libraries gebruiken, maar gebouwd zijn met simpele, samenvoegbare patronen [1]. Zij maken een scherp onderscheid tussen workflows (waarbij modellen en tools worden georkestreerd via vooraf gedefinieerde codepaden) en agents. Volgens Anthropic bieden workflows voorspelbaarheid en consistentie bij goed gedefinieerde taken, terwijl agents beter zijn wanneer flexibiliteit en model-gedreven besluitvorming op schaal nodig zijn [1]. Zij adviseren om altijd de simpelste oplossing te zoeken en complexiteit pas toe te voegen wanneer dat strikt noodzakelijk is. Frameworks creëren vaak extra abstractielagen die de onderliggende prompts en responses verbergen, wat het debuggen aanzienlijk moeilijker maakt [1].

Het multi-agent vraagstuk en Context Engineering

Een gerelateerde discussie is of je taken moet opsplitsen over meerdere agents (wat vaak leidt tot een graph-architectuur) of alles in één krachtige loop moet houden. Walden Yan van Cognition publiceerde aanvankelijk een stuk met de titel "Don't Build Multi-Agents" [4]. Hij betoogde dat de betrouwbaarheid van langlopende agents sterk afhangt van context engineering. Als voorbeeld gaf hij de opdracht om een Flappy Bird-kloon te bouwen, opgesplitst in een subagent voor de achtergrond en een voor de vogel. Zelfs als elke subtaak slaagt, kan het geheel inconsistent zijn. Zijn principes: deel volledige agent-traces (niet alleen losse berichten) en besef dat acties impliciete beslissingen met zich meebrengen; conflicterende beslissingen leiden tot slechte resultaten [4]. Hij bekritiseerde libraries zoals OpenAI Swarm en Microsoft AutoGen omdat ze deze multi-agent architecturen zouden pushen [4].

Tien maanden later herzag Yan dit standpunt echter expliciet in een nieuwe publicatie, waarin hij aangaf dat er veel veranderd was en dat Cognition onder bepaalde voorwaarden multi-agent systemen nu wel omarmt [5]. Harrison Chase van LangChain analyseerde deze verschuivingen en concludeerde dat de bepalende factor voor succes niet een dogmatische regel voor of tegen multi-agent is, maar de kwaliteit van de context-engineering en het delen van context tussen de componenten [3].

De verzoening: Loops zijn simpele Graphs

Uiteindelijk is de tegenstelling tussen loop en graph engineering deels semantisch. LangChain stelt verzoenend dat loops in feite simpele grafen zijn. Loop engineering is geen alternatief voor grafen, maar een eenvoudige versie ervan [6]. Een loop is wiskundig gezien een gerichte, cyclische graaf. Zelfs het standaard LangChain-framework, dat gebaseerd is op een simpele agentic loop, is onder de motorkap bovenop LangGraph gebouwd [6]. Productie-agents zijn vrijwel nooit gerichte acyclische grafen (DAGs); ze hebben cycli nodig voor retries, menselijke input en revisielussen [6].

Wanneer kies je wat? Afwegingen in de praktijk

Als Agentic Consultant moet je de architectuur afstemmen op de taak. De keuze tussen een strakke graph of een flexibele loop hangt af van de aard van het werk.

Wanneer Graph Engineering uitblinkt

Grafen zijn ideaal wanneer een proces een voorspelbare structuur vereist [6]. Enkele voorbeelden:

• Support-agents: Een systeem moet eerst een inkomend probleem classificeren voordat het een antwoord formuleert of escaleert naar een mens.
• Coding-agents: De agent moet verplicht de repository inspecteren en tests draaien voordat hij een codewijziging voorstelt.
• Compliance-workflows: Er is een harde eis dat een specifieke goedkeuringsstap wordt doorlopen voordat een externe actie (zoals een betaling of het verzenden van een e-mail) plaatsvindt.

In deze scenario's wil je niet hopen dat het model de juiste beslissing neemt; je wilt deterministisch gedrag afdwingen via de structuur van de graaf [6].

Wanneer Loops en Agent Harnesses beter zijn

Sommige taken zijn van nature meer 'agentic' en open-ended. Het forceren van dergelijke taken in deterministische paden is een ontwerpfout [6]. Denk aan open-ended zoekwerk of diepgaande research. LangChain bouwde hun vroege 'deep research'-functionaliteit op vooraf gedefinieerde LangGraph-workflows, maar stapte later over op een meer agentic core loop. Ook het project GPT Researcher ruilde zijn graph-vormige multi-agent pipeline in voor zogenaamde Deep Agents [6]. Voor dit soort open-ended taken, waarbij het pad naar de oplossing vooraf onbekend is, presteert een robuuste orchestrator met subagents (zoals Anthropic's multi-agent research system [2]) vaak beter.

De documentatie van Pydantic AI (die met pydantic-graph een async graph- en state-machinelibrary voor Python biedt) bevat een treffende waarschuwing: grafen zijn een krachtig instrument, maar niet voor elke klus. Ze vergelijken Pydantic AI agents met een hamer, multi-agent workflows met een voorhamer, en grafen met een spijkerpistool. Een spijkerpistool ziet er stoerder uit, maar vereist veel meer setup en maakt je geen betere bouwer, alleen een bouwer met een spijkerpistool [14]. Als je niet zeker weet of een graph-gebaseerde aanpak nodig is, is het waarschijnlijk overbodig [14].

Productie-eisen: State, Duurzaamheid en de Human-in-the-Loop

Het bouwen van een prototype in een notebook is wezenlijk anders dan het draaien van een AI Agent in productie. Twee concepten zijn hierbij onmisbaar: state management en durable execution.

State en Persistentie

Zowel in loops als in grafen moet het systeem onthouden wat er is gebeurd. LangGraph lost dit op met een persistentielaag via 'checkpointers'. Deze slaan de graph state op als checkpoints bij elke stap [9]. Dit geeft agents kortetermijngeheugen (binnen één sessie) en langetermijngeheugen (via stores), wat essentieel is als een agent een gesprek moet voortzetten of na een onderbreking verder moet werken [10].

Deze checkpointers maken ook 'interrupts' mogelijk. Hiermee kun je de executie van de graaf op specifieke punten pauzeren en wachten op externe input, wat het human-in-the-loop patroon faciliteert [11]. Wanneer een interrupt wordt getriggerd, slaat LangGraph de status op en wacht het systeem voor onbepaalde tijd [11]. Ook OpenAI biedt in hun SDK vier strategieën voor state-persistentie, variërend van in-app history tot een server-managed Conversations API [12].

Durable Execution en Verantwoordelijkheid

Als een AI Agent langere tijd draait, nemen de risico's toe. Modellen zijn non-deterministisch, executies moeten soms uren wachten op menselijke input, en het systeem moet servercrashes en software-updates overleven zonder de voortgang van de agent te verliezen [18].

Dit is waar platforms voor 'durable execution', zoals Temporal, in beeld komen. Zoals Cornelia Davis van Temporal stelt: het is opmerkelijk eenvoudig geworden om een AI Agent capaciteiten te geven, maar veel moeilijker om hem verantwoordelijkheid te geven. Verantwoordelijkheid vereist namelijk controle [17]. Door frameworks zoals de OpenAI Agents SDK te integreren met Temporal (een integratie die inmiddels algemeen beschikbaar is [16]), creëer je een infrastructuur waarbij de executie van de agent gegarandeerd doorloopt of correct herstelt na een storing [15, 16]. Dit is een kritieke vereiste voor enterprise-grade Agentic AI.

Vergelijkend overzicht

Onderstaande tabel biedt een kwalitatieve vergelijking tussen de twee benaderingen op basis van de besproken architectuurprincipes.

Afwegingsas	Pure Loop Engineering (Agentic)	Graph Engineering (Deterministisch)
Voorspelbaarheid	Laag. Het model bepaalt dynamisch het pad en de volgorde van tool-gebruik.	Hoog. De flow is vastgelegd in nodes en edges; het model kiest alleen binnen vooraf gedefinieerde kaders.
Observability	Complexer. Vereist het loggen van volledige agent-traces om te begrijpen waarom een model een bepaalde afslag nam.	Inzichtelijk. De state machine maakt exact inzichtelijk in welke node het systeem zich bevindt of is vastgelopen.
Duurzaamheid / Herstel	Vereist externe mechanismen (zoals Temporal of sessie-opslag) om de loop na een crash te hervatten.	Vaak ingebouwd via checkpointers (zoals in LangGraph) die de state per node opslaan voor eenvoudig herstel.
Flexibiliteit	Zeer hoog. Ideaal voor open-ended research en taken waarbij het stappenplan vooraf onbekend is.	Beperkt door de ontworpen graaf. Runtime-flexibiliteit is mogelijk (bijv. fan-out/map-reduce), maar vereist expliciet ontwerp.
Onderhoudslast	Focus ligt op prompt engineering en context sharing. Minder code, maar lastiger te debuggen bij onverwacht gedrag.	Hogere initiële setup (het 'spijkerpistool'). Abstractielagen kunnen onderliggende prompts verbergen, wat debuggen bemoeilijkt.

De status van het bewijs

Belangrijke disclaimer: Bij het evalueren van deze architecturen is het essentieel om te beseffen dat er momenteel geen gecontroleerde, onafhankelijke benchmarks of peer-reviewed studies bestaan die graph-gestructureerde agents objectief vergelijken met pure loops op het gebied van taaksucces, operationele kosten of latency. Al het beschikbare bewijs, inclusief de inzichten in dit artikel, is gebaseerd op praktijkervaringen van ontwikkelaars, blogposts van leveranciers en frameworkdocumentatie. Er kan op dit moment niet wetenschappelijk worden vastgesteld dat de ene aanpak empirisch superieur is aan de andere; de keuze blijft een architecturale afweging gebaseerd op de specifieke use case.

Conclusie

De keuze tussen graph engineering en loop engineering is geen binaire beslissing, maar het zoeken naar de juiste balans op een spectrum. Voor open-ended taken waarbij het model de leiding moet nemen, biedt een robuuste loop de benodigde flexibiliteit. Voor bedrijfskritische processen met harde compliance-eisen biedt een graph de noodzakelijke controle. Zoals vaak in software engineering geldt ook voor Agentic AI: begin met de simpelste oplossing (een basis loop of een eenvoudige workflow) en introduceer de complexiteit van geavanceerde grafen of multi-agent systemen pas wanneer de taak daarom vraagt. Een alternatieve, declaratieve benadering zoals DSPy, waarbij taken worden beschreven als gestructureerde inputs en outputs in zelf-verbeterende pipelines [19, 20], toont aan dat het veld nog volop innoveert in hoe we LLM-aanroepen orkestreren.

Bronnen

1. Anthropic, "Building Effective Agents", 19 december 2024. Link
2. Anthropic, "How we built our multi-agent research system", 13 juni 2025. Link
3. Harrison Chase (LangChain), "How and when to build multi-agent systems", 16 juni 2025. Link
4. Walden Yan (Cognition), "Don't Build Multi-Agents", 12 juni 2025. Link
5. Walden Yan (Cognition), "Multi-Agents: What's Actually Working", 22 april 2026. Link
6. Sydney Runkle & Harrison Chase (LangChain), "3 Years of Graph Engineering with LangGraph", 22 juli 2026. Link
7. Nuno Campos (LangChain), "Building LangGraph: Designing an Agent Runtime from first principles", 4 september 2025. Link
8. LangGraph docs, "Graph API overview". Link
9. LangGraph docs, "Checkpointers". Link
10. LangGraph docs, "Persistence". Link
11. LangGraph docs, "Interrupts". Link
12. OpenAI Agents SDK docs, "Running agents". Link
13. Google Agent Development Kit (ADK), "Loop workflow agent" docs. Link
14. Pydantic AI, "Graphs" documentatie (pydantic-graph). Link
15. Cornelia Davis (Temporal), "Durable Execution meets AI: Why Temporal is ideal for AI agents & Generative AI Apps", 10 juli 2025. Link
16. Cornelia Davis (Temporal), "Production-ready agents with the OpenAI Agents SDK + Temporal", 30 juli 2025 (update 23 maart 2026). Link
17. Cornelia Davis (Temporal), "Temporal Agent Harness: An early look at durable agent infrastructure", 20 augustus 2026. Link
18. Greg Haskins (Manetu via Temporal), "The thread is the Workflow: Durable AI agents without changing Agent code", 3 september 2026. Link
19. DSPy, "Program, don't prompt". Link
20. Khattab et al., "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines", arXiv:2310.03714 (ICLR 2024). Link