Van Agent tot Loop tot Graph: Een Productiearchitectuur voor Agentische Systemen

Een veelgedeelde X-post van 18 augustus 2026 schrijft een twee uur durende walkthrough toe aan Andrew Ng en presenteert een nuttige escalatie van engineering-scope: een eerste werkende agent om 9:14, loops om 33:11, loops die graphs worden om 1:02:46, agents die hun eigen code aanpassen om 1:30:15, en een orchestratielaag die het systeem samenbindt om 1:49:05. Dit artikel gebruikt die van timestamps voorziene opzet als uitgangspunt voor productiearchitectuur; het is niet afhankelijk van de juistheid van de toeschrijving.

Of die labels nu canonieke woordenschat worden of niet, de progressie is nuttig omdat elke stap een andere systeemvraag toevoegt. Eén enkele agent introduceert vragen over functionaliteit en toolgebruik. Een duurzame loop voegt zorgen over status, herstel, context en goedkeuring toe. Een graph voegt topologie, coördinatie en delegatie toe. Zelfaanpassing roept vragen op over verificatie, inperking en promotie. Orchestratie maakt van het gecombineerde systeem een operationeel probleem.

1. De Eerste Agent Is een Functionaliteit; de Loop Maakt er een Systeem Van

De eerste mijlpaal in de aangeleverde post is het eenvoudigst te herkennen: laat één agent draaien. Geef een model een doel, een tool-interface en voldoende status om een actie te kiezen. Dat is het moment waarop een taalmodel ophoudt alleen een tekstgenerator te zijn en begint deel te nemen aan een systeem.

Maar de operationele complexiteit hoopt zich niet op bij die enkele actie. Complexiteit ontstaat wanneer de agent moet doorgaan: het resultaat observeren, beslissen of de taak is voltooid, een andere tool aanroepen, een mislukte aanroep overleven, context verdichten, om goedkeuring vragen of morgen hervatten.

Dat is de reden waarom TrueFoundry's artikel over loop-engineering van juni de discipline op deze manier definieerde:

De zin is van belang omdat het de aandacht verlegt van één heroïsche prompt. Zodra de loop onbeheerd nuttig werk verricht, worden de ontwerpvragen gewone systeemvragen: waar de status leeft, welke acties opnieuw geprobeerd kunnen worden, hoe vaak een fout zich mag herhalen, wanneer een mens moet ingrijpen, welke code kan worden uitgevoerd, welke authenticatiegegevens bereikbaar zijn en hoe een run later wordt gereconstrueerd.

2. Een Graph Vervangt de Loop Niet; Het Rangschikt Loops en Andere Nodes

De volgende conceptuele stap in de aangeleverde X-post — loops die graphs worden — is waar hype de nuttige engineering kan overschaduwen. Een graph is per definitie niet “meer agents”. Een productie-graph kan agents, deterministische functies, routers, joins, wachtrijen, menselijke controlepunten, evaluatoren, database-schrijfacties en gewone services bevatten.

TrueFoundry's handleiding voor graph-engineering van juli vatte de relatie in zeven woorden samen:

De graph of orchestrator is eigenaar van vragen zoals: Welke node draait als volgende? Kunnen twee vertakkingen parallel worden uitgevoerd? Welk resultaat ontgrendelt een join? Wat gebeurt er als één vertakking mislukt? Welke agent mag delegeren aan welke andere agent? Welk pad vereist een menselijk controlepunt? Een meerstaps loop binnen een agentische node beheert een andere set vragen: welke context de agent ziet, welke tool hij selecteert, hoe hij observaties verwerkt, wanneer hij het opnieuw probeert en wanneer zijn lokale werk is voltooid.

Scheid eerst twee betekenissen van “graph”

De framing op sociale media gebruikt de term “agentic knowledge graphs”. Die formulering kan twee verschillende architectuurniveaus doen samenvallen. Een knowledge graph vertegenwoordigt entiteiten en relaties in informatie. Een agent-uitvoeringsgraph vertegenwoordigt actors, computationele nodes, overgangen, afhankelijkheden en werkstatus. De ene kan de andere voeden, maar ze beantwoorden verschillende vragen.

Als een onderzoeks-agent een knowledge graph raadpleegt en vervolgens de validatie delegeert aan een tweede agent, is de knowledge graph onderdeel van wat het systeem weet; de uitvoeringsgraph beschrijft wat het systeem doet.

3. Edges Zijn Waar Veel Enterprise-Controls Dwingend Kunnen Worden Opgelegd

Een graph-diagram wordt operationeel wanneer nodes en edges autoriteit dragen. Een edge kan betekenen “roep dit model aan”, “voer deze MCP-tool uit”, “draag dit klantrecord over aan een andere agent”, “schrijf deze patch” of “implementeer dit artefact”. Zodra die overgangen consequenties hebben, worden topologie en governance onafscheidelijk — zelfs hoewel node-evaluatie, graph-status en downstream-autorisatie even belangrijke onderdelen van het beheersingsverhaal blijven.

TrueFoundry's recente post over graph-engineering vat de bedrijfshouding samen in een korte regel:

Dat is een betere framing dan graph-engineering te behandelen als een vervanging voor modelevaluatie. U evalueert nog steeds het gedrag van nodes. Maar evaluatie alleen kan een productiedatabase er niet van weerhouden een schrijfactie te weigeren, een budget af te dwingen of goedkeuring te vereisen vóór een destructieve operatie. Runtime-, gateway- en downstream-autorisatiegrenzen kunnen die beperkingen afdwingen wanneer het relevante verkeer erdoorheen gaat.

De praktische implicatie is dat elke ingrijpende edge vijf vragen zou moeten beantwoorden:

4. Zelfaanpassende Agents Hebben een Toelatingspoort Nodig

De 1:30:15 mijlpaal in de aangeleverde post — agents die hun eigen code refactoren of upgraden — is waar de architectuur niet langer louter compositorisch is, maar reflexief wordt. Het systeem stelt nu wijzigingen voor aan het mechanisme dat het latere gedrag vorm zal geven.

Dat is krachtig, maar de veilige abstractie is niet “de agent verbetert zichzelf”. Het is:

Een code-schrijvende agent kan een patch maken in een sandbox. Een afzonderlijke verifier kan tests, statische controles, beleidscontroles, regressie- of taakspecifieke evaluaties en voorwaarden uitvoeren die passen bij de wijziging. Een mens kan een promotie met een hoge impact goedkeuren. Versiebeheer of een artefactenregister moet de geaccepteerde versie vastleggen en een rollback mogelijk maken. De runtime die de wijziging heeft voorgesteld, zou niet het enige bewijsmateriaal moeten beheren dat wordt gebruikt om die te accepteren.

De graph-structuur helpt hier omdat verificatie een afzonderlijke node kan worden met een eigen autoriteit, in plaats van weer een regel binnen dezelfde prompt. Dat is een van de belangrijkste redenen waarom graphs van belang zijn: ze stellen ons in staat om onafhankelijk oordeel om te zetten in topologie.

5. Waar TrueForge Past: De Open Uitvoeringsloop Binnen de Node

Dit is de duidelijkste plek om TrueForge in te passen. De publieke documentatie definieert het als een open-source agent-harness: de runtimelaag rond een LLM die de uitvoeringsloop van de agent draait en modelaanroepen, MCP-tools, skills, sandboxing, goedkeuringen, subagents, contextbeheer en sessiestatus verbindt die herverbindingen en herstarts overleeft.

Dat betekent niet dat TrueForge eigenaar is van een willekeurige multi-agent graph. De graph kan worden gedefinieerd in applicatiecode, een workflow-systeem of een ander orchestratie-framework. De strakkere koppeling is specifieker: wanneer een graph-node agentisch is, kan TrueForge de runtime zijn die van die node een echte langlopende uitvoeringsloop maakt, in plaats van een functie die slechts eenmaal een model aanroept.

Uit de officiële TrueForge-documentatie: TrueForge wordt omschreven als “an open-source agent harness” en de server ervan “runs the agent loop.” Daarom past het precies binnen agentische graph-nodes in plaats van de graph zelf te vervangen.

Figuur 4. Officieel TrueForge-architectuurdiagram uit de publieke TrueForge-repository en -documentatie. Het plaatst de TrueForge-server en agent-loop tussen de clientvlakken en eigen opslag (bring-your-own persistence), modelproviders, MCP-servers en sandbox-provider.

Bron: TrueForge — official architecture asset; zie ook TrueForge Introduction.

TrueFoundry's recente essay over loops noemt deze laag middleware omdat operationele beslissingen zich daar ophopen. De term is juist nuttig omdat een graph kan veranderen terwijl de runtime-zorgen binnen de nodes hardnekkig hetzelfde blijven: status, context, goedkeuringen, isolatie en bewijsvoering.

6. Waar TrueFoundry-Gateways Passen: Gedeeld Beleid voor Doorgestuurd Verkeer

Zodra de graph meerdere nodes heeft die modellen of tools gebruiken, kunnen ze verschillende modellen kiezen, onafhankelijk herhaalde pogingen doen, met verschillende frequenties aanroepen, verschillende budgetten verbruiken of verschillende MCP-servers bereiken. Als elke node providers en tools rechtstreeks integreert, kan de graph veranderen in een verzameling van afzonderlijke beheervlakken.

De TrueFoundry AI Gateway is hier nuttig als gedeelde infrastructuur voor modelverkeer: één modelgericht interface met toegangsbeheer, virtuele modelrouting en fallbacks, rate limits, budgetlimieten, guardrails, en request traces en metrics voor aanroepen die erdoorheen gaan. Voor MCP-verkeer dat via de MCP Gateway wordt doorgestuurd, kan TrueFoundry afzonderlijk inkomende authenticatie, server/tool-toegangsbeheer, uitgaande authenticatie, goedkeuringen en auditeerbaarheid op gateway-niveau centraliseren.

De belangrijke zinsnede is voor verzoeken die erdoorheen gaan. Een gateway kan geen verkeer beheren dat eromheen gaat, en het leidt uw graph-topologie niet af. De orchestrator kan identificatielabels zoals graph_id, run_id en node_id doorgeven in door de applicatie beheerde request-metadata — bijvoorbeeld de gedocumenteerde X-TFY-METADATA-header — zodat gateway-logs en -metrics kunnen worden gefilterd of gegroepeerd op basis van identificaties op graph-niveau waar die correlatie nuttig is.

Uit de officiële TrueFoundry-documentatie: de AI Gateway is een proxy-laag tussen applicaties en modelproviders, met toegangsbeheer, routing, rate- en budgetbeheer, guardrails en traceerbaarheid rond dat pad. De MCP Gateway documenteert inkomende authenticatie, server/tool-toegangsbeheer, uitgaande authenticatie en tool-goedkeuringen voor MCP-verkeer. In een graph zijn dat gedeelde beleidsvlakken voor doorgestuurd verkeer — niet de graph-orchestrator.

Figuur 5. Officieel TrueFoundry AI Gateway-architectuurdiagram. De referentiearchitectuur laat zien hoe verschillende AI-clientvlakken samenkomen op een centrale gateway die governance toepast voordat verzoeken modelproviders bereiken.

Bron: TrueFoundry — Govern All AI Traffic Through the AI Gateway. De HTML gebruikt de officiële documentatie-asset rechtstreeks, met een door TrueFoundry gehoste fallback in plaats van een aangepaste tekening.

Laag Eigenaar van TrueForge / TrueFoundry koppeling Graph-orchestrator Topologie, routing, joins, delegatie, herhaalde pogingen, graph-status Eigendom van applicatie/framework Agent-harness Lokale uitvoeringsloop, context, tools, sandbox, goedkeuringen, sessiestatus TrueForge Modelbeleidsvlak Modeltoegang, provider-abstractie, routing, uitgaven/rate-beleid, guardrails, traces TrueFoundry AI Gateway Toolbeleidsvlak Inkomende authenticatie van aanroeper, server/tool-toegang, downstream-authenticatie, goedkeuringen TrueFoundry MCP Gateway voor MCP-verkeer dat erdoorheen wordt doorgestuurd Systems of record Auteur-gevalideerde neveneffecten en bedrijfsstatus Koppeling met enterprise-systemen

Dit is een sterker productverhaal dan beweren dat één platform “graph-engineering doet”. De graph behoort tot de architectuur. TrueForge kan de uitvoeringsloop leveren binnen agentische nodes. De AI Gateway kan een gedeeld model-beheervlak bieden voor aanroepen die erdoorheen worden doorgestuurd. De MCP Gateway kan authenticatie, tool/server-rechten, afhandeling van downstream-authenticatiegegevens, goedkeuringen en andere beheerelementen centraliseren voor MCP-verkeer dat erdoorheen wordt doorgestuurd. De orchestrator en downstream-systemen blijven onderdeel van het beheersingsverhaal.

7. De Test voor de Beheerder: Kunt U de Uitgevoerde Graph Uitleggen?

Een ontworpen graph is wat verschijnt in architectuurdiagrammen. De uitgevoerde graph is wat er daadwerkelijk is gebeurd tijdens een specifieke run. Dat zijn niet automatisch dezelfde objecten.

Een fallback-model kan worden geactiveerd. Een gedelegeerde taak kan zich vertakken. Een tool kan worden geweigerd. Een verifier kan werk terugsturen. Een goedkeuring kan één vertakking urenlang vasthouden terwijl een andere vertakking wordt voltooid. Een zelfaanpassende node kan een patch genereren die nooit wordt gepromoveerd.

De productietest is daarom niet “hebben we een graph?”. Het is de vraag of een team een ingrijpende run over verschillende lagen heen kan reconstrueren.

De graph-audit. Kies één productie-actie en traceer deze terug. Welke graph-node heeft deze geïnitieerd? Welke lokale loop heeft tot de beslissing geleid? Welk model heeft elke aanroep verwerkt? Welke context en tool-interfaces waren beschikbaar? Welke budgetten, rate rules of guardrails waren van toepassing? Was er een sandbox of goedkeuringsgrens? Welke edge droeg de actie? En welk downstream-record bewijst wat er werkelijk is veranderd? Als het antwoord eindigt bij “de agent heeft beslist”, mist de graph nog steeds een operationeel model.

8. Wat Deze Architectuur Wel — en Niet — Beweert

De aangeleverde X-post is een nuttige overzichtskaart, maar de framing op sociale media moet niet zonder primaire bron worden omgezet in een historische claim of toeschrijving. We hebben geverifieerd dat de post en gesyndiceerde kopieën de bovenstaande volgorde van timestamps gebruiken; we hebben het exacte onderliggende twee uur durende artefact niet geverifieerd als een publicatie van Andrew Ng. De officiële catalogus van DeepLearning.AI wijst momenteel naar andere cursussen en instructeurs, dus de timestamps hier moeten strikt worden gelezen als de beschrijving van de video in de post.

“Graph-engineering” is ook nog steeds een opkomende term. Geen van de kernmechanismen is op zichzelf nieuw: DAG's, actor-systemen, workflow-engines, gedistribueerde coördinatie, beleidshandhaving en menselijke controlepunten hebben allemaal een lange geschiedenis. Wat nieuw genoeg is om aandacht te verdienen, is de manier waarop agentische systemen die mechanismen concentreren rond modelgedreven nodes die kunnen handelen, delegeren, artefacten kunnen wijzigen en gedurende lange periodes kunnen draaien.

Ten slotte moeten noch TrueForge, noch de TrueFoundry-gateways worden beschreven als eigenaar van de gehele graph. TrueForge beheert en legt de agent-loop vast die het uitvoert. De AI en MCP Gateways beheren alleen het verkeer dat via hun respectievelijke grenzen wordt doorgestuurd. De orchestrator is eigenaar van de topologie en de graph-status. Downstream-systemen blijven bepalend voor hun eigen autorisatie en neveneffecten. Serieuze graph-engineering begint door die grenzen expliciet te houden.

Referenties

• Aangeleverde X-post — bron op sociale media voor de opzet van timestamps. Het exacte onderliggende twee uur durende artefact is niet onafhankelijk geverifieerd als een publicatie van Andrew Ng.
• DeepLearning.AI — Agentic AI — huidige cursusvermelding van Andrew Ng (7u45m); opgenomen om de officiële catalogus te onderscheiden van de virale toeschrijving van twee uur.
• DeepLearning.AI — Agentic Knowledge Graph Construction — huidige cursusvermelding gegeven door Andreas Kollegger (3u8m); opgenomen ter verduidelijking van de herkomst.
• Boyu Wang — Graph Engineering for Multi-Agent Systems: Architecture, Governance, and Observability. TrueFoundry (2026).
• Boyu Wang — Graph Engineering for AI Agents: Govern the Connections. TrueFoundry (2026).
• Boyu Wang — Loop Engineering at Enterprise Grade: From Laptop Loops to Governed Runtimes. TrueFoundry (2026).
• Boyu Wang — The Loop Is the New Middleware: Loop Engineering as an Enterprise Strategy. TrueFoundry (2026).
• TrueForge — Introduction en Harness Capabilities.
• TrueFoundry AI Gateway — Introduction; Custom Metadata and Headers; Metrics Dashboard.
• TrueFoundry MCP Gateway — Authentication and Security.

Disclaimers: TrueFoundry publiceert dit artikel, verkoopt de TrueFoundry AI Gateway en MCP Gateway, en onderhoudt TrueForge. Productclaims zijn beperkt tot gedrag dat is gedocumenteerd in huidig openbaar TrueFoundry- en TrueForge-materiaal. De voortgang met tijdstempels is afkomstig uit de opgegeven X-post; de vertaling van die voortgang naar de bovenstaande productie-architectuur is een redactionele analyse van TrueFoundry en wordt niet toegeschreven aan, ondersteund door of gepresenteerd als een verklaring van Andrew Ng. Auteursvermeldingen in de referentielijst identificeren de individuele auteursregel op de geciteerde TrueFoundry-artikelen; die artikelen blijven door TrueFoundry gepubliceerde eigendommen.

‍