Van Agent Harness naar Systeem-intelligentie: Wat Graph Engineering Verandert in Productie-AI

Een nieuw onderzoek dat Graph Engineering voorstelt als een opkomend paradigma biedt een nuttige hiërarchie voor ontwikkelaars van agents: prompting en context vormen een model-call; een harness en loop veranderen dat model in een persistente agent; organisatie op graph-niveau coördineert meerdere agents, werkstructuren en runtime states tot één systeem.

1. De paper maakt van de harness een engineering-object, geen lijmcode

Het overzicht plaatst Prompt Engineering, Context Engineering, Harness Engineering, Loop Engineering en Graph Engineering op verschillende lagen in plaats van ze als concurrerende termen te behandelen. Prompt en context werken het dichtst bij de inference. Harness Engineering breidt het model uit met persistente en uitvoerbare mogelijkheden over calls heen. Loop Engineering organiseert de herhaalde interactie met die mogelijkheden. Graph Engineering richt zich op de organisatie op systeemniveau.

Die scheiding is nuttig omdat "agent framework" vaak heel verschillende zaken op één hoop gooit. Een tool-schema, een sessie-store, een sandbox, een goedkeuringscontrolepunt en een retry-loop zijn niet hetzelfde type element, zelfs als één SDK ze via één API beschikbaar maakt.

Het gedeelte over Harness Engineering in de paper groepeert vier gebieden:

Het cruciale punt is de reikwijdte. Harness Engineering is niet simpelweg "geef het LLM tools". Het gaat om de persistente runtime waarin die tools, geheugens, skills, uitvoeringsgrenzen en controles bruikbaar blijven over meerdere calls heen.

2. TrueForge sluit helder aan op de individuele agent-runtime uit de paper

Dit is waar TrueForge een opvallend directe koppeling heeft met het vocabulaire van de paper. De huidige documentatie van TrueForge omschrijft het als een open-source agent harness—de runtimelaag rond een LLM die de execution loop uitvoert en MCP-tools, skills, sandboxing, goedkeuringen, subagents, contextbeheer en persistente sessie-state met elkaar verbindt.

De koppeling is niet louter rhetorisch. De serverdocumentatie van TrueForge vermeldt dat de server een turn plant, het model aanroept, tools uitvoert, stappen streamt, pauzeert voor menselijke goedkeuring bij gevoelige acties, de context slank houdt voor lange taken en sessies behoudt bij herverbindingen en herstarts. De SDK maakt Agent, Session, Turn, Event en Delta tot expliciete runtime-objecten.

TrueForge houdt de productgrens ook zuiver. Het vereist niet de TrueFoundry AI Gateway om te draaien. De openbare productpagina geeft aan dat de harness zelfstandig werkt; het koppelen van de gateway voegt beheerde toegang tot modellen, MCP's en skills toe. Dat is belangrijk voor de draagbaarheid, omdat de open runtime gescheiden kan blijven van het enterprise policy-vlak eromheen.

3. Harness Engineering en Loop Engineering moeten niet worden samengevoegd

De paper maakt een nuttig onderscheid: Harness Engineering bepaalt welke mogelijkheden en bronnen persistent beschikbaar zijn en hoe ze worden georkestreerd; Loop Engineering bepaalt hoe die mogelijkheden herhaaldelijk worden aangeroepen en aangepast naarmate de taak-state verandert.

Dat klinkt subtiel totdat er in productie iets misgaat.

Dit is ook de reden waarom een iteration_limit niet moet worden verward met een verifier. Een runtime kan een ontspoorde uitvoering stoppen; het kan niet voor elke applicatie de juiste domeinspecifieke definitie van "voltooid" afleiden.

Continuïteit met het bestaande werk van TrueFoundry over loops en graphs

Het overzicht ondersteunt niet zomaar de producten van TrueFoundry of eerdere redactionele claims. Wat het wél biedt, is een onderzoekstaxonomie die het gemakkelijker maakt om verschillende grenzen die in deze publicatiereeks zijn verdedigd, precies te formuleren. Vijf korte regels uit die eerdere reeks tonen de continuïteit aan:

Samen gelezen is de volgorde bewust gekozen: de loop maakt één agent operationeel; de harness maakt de mogelijkheden duurzaam; de graph organiseert het werk boven de individuele loop; en gateways kunnen geselecteerde gedeelde grenzen beheren zonder te beweren dat ze de graph zelf bezitten.

4. De grens van de individuele agent wordt uiteindelijk de bottleneck

Het argument uit de paper voor Graph Engineering begint bij een structurele beperking, niet bij de claim dat "multi-agent altijd beter is". Sommige taken vereisen heterogene expertise, onderling afhankelijke subtaken, parallel werk, onafhankelijke verificatie en persistente state die geen enkele individuele agent-loop overzichtelijk kan organiseren.

Meer tools in één harness stoppen of meer tokens in één context laden lost dat organisatieprobleem niet noodzakelijk op. Het maakt het centrale uitvoeringspunt hooguit groter.

Dat onderscheid is waardevol voor architectuurbeoordelingen. Vraag jezelf af, voordat je meer agents toevoegt, of het probleem daadwerkelijk een systeem-organisatieprobleem is:

5. Graph Engineering roept drie verschillende vragen op systeemniveau op

Het onderzoek verdeelt Graph Engineering in drie onderling verbonden perspectieven. Deze taxonomie is nuttiger dan generieke "multi-agent orchestratie", omdat elk perspectief andere foutmodi en andere infrastructuurvereisten kent.

De derde categorie—Runtime State Management—is in productie bijzonder belangrijk. Een ontworpen workflow vertelt je wat er *zou moeten* gebeuren. Gedeelde runtime state moet je vertellen wat er *werkelijk is* gebeurd, wat geldig blijft, wat is mislukt en waar de uitvoering veilig kan worden hervat.

De paper maakt expliciet onderscheid tussen state-registratie, foutlokalisatie en herstel bij storingen. Dat is een sterkere insteek dan observabiliteit zien als een verzameling traces achteraf. De runtime-historie maakt deel uit van het vermogen van het systeem om veilig door te gaan.

6. Waar TrueForge stopt—en waar de graph begint

Deze grens moet expliciet zijn. TrueForge is een agent harness. Het kan de runtime zijn binnen een agentic graph-node; het moet niet worden omschreven als een oplossing die automatisch een willekeurige graph van taken, services, mensen, databases en andere agents beheert.

Een productie-graph kan worden gedefinieerd in applicatiecode, een orchestratie-framework, een workflow-engine of een ander systeem. Sommige nodes kunnen TrueForge-agents zijn. Andere kunnen deterministische services, queues, menselijke beoordelingsstappen, evaluators, batch-jobs, databases of externe agents zijn.

Dat geeft ons een heldere architectuur:

7. Gedeelde controle-vlakken worden belangrijker naarmate graphs groeien

De overstap van één agent naar een graph vermenigvuldigt het aantal operationele raakvlakken. Verschillende nodes kunnen verschillende modellen kiezen, andere tools aanroepen, onafhankelijk budgetten verbruiken, andere rechten vereisen en afzonderlijke traces genereren. Als elke node de provider-authenticatie, autorisatielogica, tool-policy en kostenbeheersing lokaal inbouwt, leidt de organisatie op systeemniveau al snel opnieuw tot versnippering van de infrastructuur.

Dit is waar de TrueFoundry Gateways de harness aanvullen.

AI Gateway: een gedeelde modelgrens

TrueFoundry positioneert de AI Gateway momenteel als het gemeenschappelijke model-vlak voor uniforme provider-toegang, routing en fallbacks, access control op modelniveau, budgetten, rate limits, guardrails en observabiliteit. In een graph betekent dit dat het modelbeleid gecentraliseerd blijft, zelfs als de uitvoering over meerdere nodes is verdeeld.

MCP Gateway: een gedeelde functionaliteitsgrens

MCP Gateway centraliseert de ontdekking van en beheerde toegang tot tools en MCP-servers, inclusief authenticatie, access control, downstream-wachtwoorden, goedkeuringen en controleerbaarheid voor al het verkeer dat erdoorheen wordt geleid. Dat sluit naadloos aan bij de aandacht in de paper voor functionaliteitsfundamenten: het systeem heeft in toenemende mate behoefte aan een expliciet overzicht van welke mogelijkheden bestaan, wie ze mag gebruiken en onder welke voorwaarden.

Agent Gateway: een gedeelde agentgrens

De huidige documentatie over de Agent Gateway van TrueFoundry beschrijft een gecentraliseerd agent-register, identiteits-/toegangsbeheer, quota/budgetten en tracing/controle op agentniveau. Dit helpt om een groeiend agent-landschap overzichtelijk te houden. Maar dit moet niet worden verward met taak-graph-orchestratie; het registreren en beheren van agents is niet hetzelfde als het bepalen van de graph-topologie die ze coördineert.

8. Runtime state is de brug tussen harness-observabiliteit en graph-betrouwbaarheid

Een van de sterkste productiegerichte gedeelten van het artikel gaat over Runtime State Management. Er wordt in betoogd dat gedistribueerde systemen meer nodig hebben dan taakdefinities en communicatiepaden. Ze hebben een betrouwbaar overzicht nodig van vastgelegde state-overgangen, herkomst (provenance), huidige verplichtingen, storingen en herstelgrenzen.

Het Agent → Session → Turn → Event-model van TrueForge levert hierin nuttige lokale informatie. Een sessie begrenst één probleem en behoudt de gesprekshistorie; turns volgen elkaar op binnen die sessie; events beschrijven modelberichten, MCP-initialisatie, tool-antwoorden, goedkeuringsvereisten, voltooiing en subagent-threads. Dat maakt de lokale execution loop op een bruikbaar niveau reconstrueerbaar.

Op systeemschaal zijn lokale event-streams echter slechts een deel van de oplossing. Een omvangrijke graph-run moet mogelijk het volgende met elkaar correleren:

• orchestrator-/taak-state,
• TrueForge-sessie en event-historie voor agentic nodes,
• AI/MCP/Agent Gateway-traces voor verkeer dat via die controle-vlakken is gerouteerd,
• menselijke goedkeuringen en escalatie-records, en
• gezaghebbende logboeken van downstream-systemen (systems of record) die bewijzen welke neveneffecten daadwerkelijk zijn doorgevoerd.

Dat is het verschil tussen "we hebben traces" en "we kunnen het uitgevoerde systeem reconstrueren".

9. Het graph-native agent OS uit de paper is een onderzoeksrichting—geen huidige productcategorie

Het overzicht vraagt zich ten slotte af of de huidige versnipperde stack zou kunnen evolueren naar een graph-native agent operating system. Het stelt zich taken, agents, mogelijkheden en runtime states voor als getypeerde en geversioneerde eersteklas objecten, met gedeelde services voor scheduling, capability-discovery, persistente state, provenance-logging, rechtenhandhaving, checkpointing, replay, rollback en observabiliteit op graph-niveau.

Dat is een nuttige stip op de horizon, maar het moet niet worden verward met huidige marketingtaal.

TrueForge en de TrueFoundry Gateways bieden verschillende bouwstenen die zo'n toekomstig fundament nodig zou hebben: een open uitvoerings-runtime, persistente sessies/events, toegang tot functionaliteit via MCP, sandboxing, goedkeuringen, controle-vlakken voor modellen/tools/agents, budgetten, identiteit en traces. Maar de huidige stack biedt niet automatisch het in de paper voorgestelde universele getypeerde graph-fundament, structurele transacties, structuurevolutie over de hele graph of een universele graph-scheduler.

Deze afbakening maakt het productverhaal juist sterker. We kunnen beschrijven wat er vandaag de dag bestaat zonder te beweren dat we een onderzoeksagenda hebben voltooid die de paper zelf omschrijft als toekomstige infrastructuur.

10. Vijf ontwerpregels voor platformteams

1. Begin niet bij de graph. Begin bij het werk. Gebruik één agent wanneer één duurzame loop de taak op een coherente manier kan afhandelen.
2. Behandel de harness als architectuur. Tools, geheugen, skills, sandbox, goedkeuring, state en bewijslast moeten bewuste keuzes in de runtime zijn—geen losse hulpprogramma's verspreid door de applicatiecode.
3. Stel systeem-state boven gespreksgeheugen. Zodra het werk zich over meerdere nodes uitstrekt, hebben gedeelde afspraken en de herstel-state een expliciete weergave nodig buiten de context van een enkel model.
4. Centraliseer beleid waar verkeer gedeelde grenzen kruist. Toegang tot modellen, tools en agents moet niet in elke node afzonderlijk opnieuw worden geïmplementeerd.
5. Houd topologie gescheiden van governance. De orchestrator bepaalt hoe het werk stroomt. Harnesses voeren agent-loops uit. Gateways beheren het gerouteerde verkeer. Legacy-systemen (systems of record) beslissen over de definitieve zakelijke effecten.

11. Wat deze benadering wel—en niet—beweert

De paper is een overzicht en conceptuele synthese, geen bewijs dat elke complexe taak multi-agent moet worden. De term "System Intelligence" is het door de auteurs voorgestelde kader, geen gestandaardiseerd volwassenheidsmodel voor de industrie.

Evenzo claimt dit artikel niet dat TrueForge of TrueFoundry "Graph Engineering" implementeert zoals gedefinieerd in de paper. De zuivere koppeling is specifieker:

Referenties

• Yuyuan Feng et al., Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence, arXiv:2608.21156 (2026). Hugging Face paper-pagina: 2608.21156.
• Boyu Wang — From Agent to Loop to Graph: A Production Architecture for Agentic Systems. TrueFoundry (2026).
• 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 op Enterprise-niveau: van Laptop Loops naar Beheerde Runtimes. TrueFoundry (2026).
• Boyu Wang — De Loop is de Nieuwe Middleware: Loop Engineering als een Enterprise-strategie. TrueFoundry (2026).
• TrueForge Documentatie — Introductie: agent-harness-definitie, execution loop, goedkeuringen, context-controls, subagents, sandboxing en permanente sessies.
• TrueForge Documentatie — API / SDK-concepten: Agent, Session, Turn, Event, Delta, goedkeuringen en subagent-threads.
• TrueFoundry — TrueForge: positionering van open-source harness en gateway-integratie.
• TrueFoundry AI Gateway — Introductie: modeltoegang, routing, policies, kostenbeheer, guardrails en observabiliteit.
• TrueFoundry MCP Gateway — Overzicht: gecentraliseerde MCP-discovery, authenticatie, toegangsbeheer, credentials, goedkeuringen en auditeerbaarheid.
• TrueFoundry — Agent Gateway: positionering van de huidige agent-registry, identiteit/toegang, quota/budget en tracing.

Onthulling: TrueFoundry publiceert dit artikel, ontwikkelt de TrueFoundry AI/MCP/Agent Gateways en onderhoudt TrueForge. Productclaims zijn beperkt tot het huidige openbare materiaal van TrueFoundry en TrueForge. De koppeling van de onderzoekstaxonomie uit de paper aan deze producten is een redactionele analyse van TrueFoundry; noch de paper, noch de auteurs ervan beoordelen of ondersteunen TrueFoundry. Auteursvermeldingen in de referentielijst identificeren de individuele auteur van de geciteerde TrueFoundry-artikelen; verwijzingen in de tekst verwijzen naar die artikelen als TrueFoundry-publicaties.

‍

‍