2026-05-26 · Bijgewerkt 2026-07-22

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Langdurig draaiende AI Agent Runtime in 2026: Sessions, Sandboxes, Checkpoints, en harnesses

Deel 5 van de serie ‘Engineering the Agentic Stack’

De vorige vier berichten gingen over het interne ontwerp van de agent: reasoning lussen, geheugen, tool use, en beveiliging. Dit artikel behandelt de runtime die ervoor zorgt dat deze onderdelen blijven functioneren ondanks lange sessions-periodes en procesfouten.

Een agent-run kan uren duren, terwijl de bijbehorende worker-process op elk moment opnieuw kan worden gestart. De model kiest nog steeds de volgende actie, maar de runtime moet de staat behouden, de uitvoering beheren en herstellen van een fout middenin een tool call. In dit artikel wordt de grens van de runtime gedefinieerd. Deel 6 zal de harness daarin onderzoeken: de feedback-, herprobeer-, overdrachts- en acceptatielogica die bepaalt of de agent doorwerkt of stopt.

Wat is een AI agent runtime?

Een AI agent runtime vormt de infrastructuurlaag die ervoor zorgt dat een agent die een hulpmiddel gebruikt, blijft functioneren, geïsoleerd blijft, waarneembaar is en kan worden hervat nadat de model-aanroep is afgerond. Deze laag beheert de session-toestand, de uitvoering van het hulpmiddel, checkpoints, beleidscontroles, geheime informatie, traces, kostenlimieten en de deployment-structuur. De model kiest de volgende actie; de runtime bepaalt waar die actie wordt uitgevoerd, of deze is toegestaan, hoe deze wordt geregistreerd en hoe de uitvoering na een fout kan worden hervat.

Gebruik runtime als ontwerpeenheid voor langlopende agents. Als u niet kunt uitleggen waar elke primitief zich bevindt, blijft de agent een prototype.

Lange uitvoeringscycli ondermijnen de aannames over stateless processen

Een stateless chat‑endpoint kan de status van een verzoek in één proces bewaren en deze na het versturen van het antwoord verwijderen. Een lange agent‑uitvoering omvat herstarten van workers, deployments, herstel van de context en pauzes bij goedkeuring. Het worker‑proces kan dan niet langer als bron van waarheid dienen.

Het OpenAI Codex-team rapporteert de looplengte in zijn beschrijving van harness engineering:

“We zien regelmatig dat enkele uitvoeringen van Codex voor één taak langer dan zes uur doorgaan (vaak terwijl de mensen slapen).”

Het engineeringteam van Anthropic beschrijft het bijbehorende staatprobleem in Doeltreffende hulpmiddelen voor langlopende agents:

“De kernuitdaging van langlopende agents is dat ze moeten functioneren in discrete sessions, en dat elke nieuwe session begint zonder enige herinnering aan wat er eerder is gebeurd.”

Beide observaties duiden op hetzelfde runtime ontwerp: het opslaan van de staat buiten de worker en het maken van workers vervangbaar.

De session moet zich buiten de worker-process bevinden. Een duurzame opslagplaats registreert model-aanroepen, tool results-gebeurtenissen en goedkeuringen, zodat een andere worker kan worden hervat op het laatste veilige punt na een crash. Checkpoints maakt het bovendien mogelijk voor de runtime om een nieuwe model session te starten wanneer de context window vol is, zonder dat de hele geschiedenis opnieuw moet worden afgespeeld. In De formulering van Anthropic, harness instancen worden afvalobjecten die opnieuw gestart kunnen worden; de duurzame toestand bevindt zich op een andere locatie.

De model bepaalt wat er vervolgens moet gebeuren. De runtime beslist of de actie is toegestaan, waar deze wordt uitgevoerd, hoe deze wordt geregistreerd, en hoe de uitvoering wordt hervat na een crash. De rest van dit artikel gaat over die runtime.

De vijf runtime primitieven die elke langlopende AI agent nodig heeft

Anthropic’s Schalen van beheerde Agents De beschrijving biedt een nuttig woordenboek voor vijf runtime verantwoordelijkheden. De harness zet de agent in beweging, terwijl de session vastlegt wat deze heeft gedaan en de sandbox commando’s uitvoert. De checkpoint geeft de volgende werker een startpunt; de trace bewaart bewijsmateriaal voor latere foutopsporing. Een implementatie kan componenten samenvoegen, maar de verantwoordelijkheden en foutgrenzen hebben nog steeds namen nodig.

Session. Een alleen-lezen log van alles wat is gebeurd: model-aanroepen, tool calls, resultaten, fouten en goedkeuringen. Herstel is wake(sessionId) → getSession(id) → resume from last event. In LangGraph wordt dit een thread_id plus een Postgres checkpointer (zie LangGraph-persistentie). De OpenAI Agents SDK levert tien ingebouwde session backends, inclusief SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession, en EncryptedSession (zie de Sessions documentatie).

Harness. De orchestration-lus. Hij roept de model aan, parseert tool calls, voert deze uit, schrijft de resultaten terug naar de session en past herhalingsregels toe. Anthropic zegt het recht voor z’n raap:

“Elk component in een harness geeft een aannames weer over wat de model op zichzelf niet kan doen.”

Het Codex-team van OpenAI noemt deze discipline harness engineering: het schrijven van software vereist nog steeds discipline, maar tegenwoordig gaat er meer inspanning naar de infrastructuur dan naar de code zelf. LangGraph’s CompiledStateGraph, Diepe Agents’ create_deep_agent, Ook Claude Code zelf vallen in deze zin onder de categorie ‘harnesses’.

Sandbox. De geïsoleerde uitvoeromgeving waarin de commando’s daadwerkelijk worden uitgevoerd. De OpenAI Agents SDK sandbox concepten De pagina trekt de grens netjes:

“De buitenste runtime is nog steeds verantwoordelijk voor goedkeuringen, tracing, overdrachten en het bijhouden van de status. De sandbox session beheert commando’s, bestandswijzigingen en isolatie van het omgevingscontext.”

Sandboxes verschillen in hun levensduur en wat ze zich tussen de verschillende uitvoeringen herinneren. De eenvoudigste vorm is vers geëphemeriseerd: start er één op voor één specifieke taak, vernietig hem zodra de taak is voltooid, en betaal de kosten voor een nieuwe start bij elke uitvoering.

Persistent paused sandboxes zorgt ervoor dat het bestandsysteem en een snapshot in geheugen behouden blijven tussen verschillende uitvoeringen. Hierdoor kan de volgende hervatting zonder een volledige opstart plaatsvinden. Snapshot of fork maakt een ‘copy-on-write’-afbeelding aan van een vooraf klaargemaakte ouderkopie, zodat meerdere taken dezelfde geïnstalleerde afhankelijkheden en opgewarmde caches kunnen delen, zonder hun schrijfbare toestand met elkaar te delen.

Per-worktree sandboxes zorgt ervoor dat elke taak zijn eigen werkruimte en observability stack krijgt. Door logs, metrics en traces gescheiden te houden, kun je een specifieke uitvoering debuggen zonder dat de toestand van die uitvoering invloed heeft op andere uitvoeringen. De tabel met providers verderop in dit artikel vergelijkt het gedrag bij een koude start en bij persistente toepassingen.

Checkpoint. Herstartbare staat. Van LangGraph’s PostgresSaver schrijft een StateSnapshot bij elke grens van een super-stap, met per-taakschrijvingen checkpoint_writes Daarom worden de resultaten van succesvolle nodes niet opnieuw berekend wanneer een sibling faalt. De snapshot is een JSON-serialiseerbaar dict.v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) gedocumenteerd in de langgraph-checkpoint-postgres PyPI-pagina en de LangGraph checkpoints-referentie.

Trace. Het interface voor herhaling en debugging. Elke model-aanroep, tool call, en sub-agent stap wordt een span met tijdsgegevens, invoer, uitvoer, token-cijfers en kosten. Wanneer een zes uur durende uitvoering mislukt, is het de trace waar je naar kijkt om te achterhalen wat er mis is gegaan. De terminaluitvoer van die uitvoering is tegen die tijd allang verdwenen. Dat van OpenTelemetry. Semantische conventies van GenAI Standaardiseer de namen van de attributen (welk model, welke provider, hoeveel tokens, welk gesprek, welk workflow), zodat dezelfde trace op een consistente manier wordt weergegeven in Snelheid, Jaeger, Honeycomb, of LangSmith zonder opnieuw te instrumenteren.

Beleid en geheime informatie vallen onder aparte runtime grenzen

Twee grenzen snijden door alle vijf de primitieven heen en zijn gemakkelijker te begrijpen als afzonderlijke zaken. Het gaat hier om de runtime versie van het beveiligingsargument uit Deel 4.

Beleidsmotor

Een toestemmingstoets wordt uitgevoerd vóór elke tool call om te bepalen of deze wordt goedgekeurd. Er zijn twee veelgebruikte patronen in productieomgevingen. Deep Agents stelt elke subagent in staat om aan te geven welke bestandspaden hij kan lezen of schrijven, waarna het middleware alles wat daarbuiten valt blokkeert. Anthropic Managed Agents stuurt iedere tool call via een MCP proxy, zodat de proxy de toestemmingen handhaaft in plaats van de agent-code. Wanneer een gevoelige oproep menselijke goedkeuring vereist, doet LangGraph’s interrupt() En de Deep Agents’-approvatiehook zorgt ervoor dat de grafiek wordt opgeschort totdat een persoon ‘ja’ zegt.

Geheime broker

De model mag geen langlevende geheime informatie ontvangen, en de sandbox zou normaal gesproken evenmin dat mogen doen. Het gemanageerde Agents-patroon is degene die moet worden gekopieerd:

“Voor Git maken we gebruik van de toegangsrechten token van elk repository om dit tijdens de sandbox initialisatie te klonen en het aan te sluiten op het lokale git remote. Git push en pull Werken van binnenuit de sandbox, zodat de agent nooit zelf de token hoeft te verwerken. Voor aangepaste hulpmiddelen ondersteunen we MCP en slaan we de OAuth tokens op in een beveiligde kluis. Claude roept MCP-hulpmiddelen op via een gespecialiseerde proxy; deze proxy ontvangt een token die gekoppeld is aan de session. … De harness wordt nooit op de hoogte gebracht van enige credentials.”

In het market-analyst-agent De reference-stack: de MCP sidecar leest de OAuth tokens-gegevens op uit een Docker-secret (in productieomgevingen). HashiCorp Vault) En het exposeert uitsluitend het gebruikersinterfacegedeelte aan de LangGraph-worker. De worker ziet nooit token. git push Werkt. cat ~/.ssh/id_rsa Nee.

Een praktische controle om zeker te zijn van de juistheid is om elke component op te schrijven en aan te geven bij welk van de vijf primitieven deze zich bevindt. Postgres Het kan session en checkpoint omvatten. De worker-container is de harness. Een dienst zoals Daytona, Modaal, of E2B het biedt de sandbox, terwijl Snelheid of LangSmith Slaat trace op.

Bekijk nu de gekoppelde fouten. Als twee primitieven zich in dezelfde proces bevinden, zorgt één crash ervoor dat beide uitvallen. Als ze een wachtwoord delen, leidt één lek ertoe dat beide grenzen worden overschreden. Veelvoorkomende voorbeelden zijn een worker die ook beschikt over de trace-duurzaamheid, of een sidecar token die ook toegang geeft tot de checkpoint-database.

Foutmodi bij productie AI agent runtime

De runtime beheert herproberingen, herstelt eerdere werkzaamheden, isolateert werkruimtes en handhaaft budgetten. De vijf bovengenoemde primitieven zijn verantwoordelijk voor het levenscyclus van uitvoeringen, terwijl beleidsregels en geheimbeheersing hierover heen werken. Naarmate uitvoeringen zich verspreiden over verschillende workers en context windows, leiden fouten tot problemen met de toestand, dubbele bijwerkingen, sandbox-drift en onvoldoende budgettoepassing.

De fouten vallen onder vier categorieën:

• Fouten met de kwaliteit van het uitvoerresultaat: de agent verklaart al vroeg dat het werk voltooid is, vergeet wat het eerder heeft gedaan bij een herstart van het contextvenster, of vertrouwt op zijn eigen zelfevaluatie en levert een defect resultaat af.
• Fouten bij kostenbeheer: de agent raakt vast in een herprobeerloop, of verbruikt het token-budget of het budget voor toolaanroepen zonder iets bruikbaars te produceren.
• Fouten met betrekking tot toestand en crashes: werkomgevingen gaan uit de koers omdat één uitvoering bestanden aanraakt die door een andere uitvoering worden gebruikt, tool calls wordt meerdere keren uitgevoerd omdat herproberingen deze uitvoeringen opnieuw uitvoeren, of wordt er werk verloren wanneer een worker tussen gebeurtenissen crasht.
• Fouten met het contextvenster: de model vat het resultaat samen en stopt vroeg omdat het denkt dat de opslagruimte op is, zelfs wanneer er nog voldoende ruimte in het venster beschikbaar is.

De tabel koppelt elke fout aan een mitigatiemaatregel, de runtime-hook die deze doorvoert, en de grondslag voor de aanbeveling. Het Model-specifieke gedrag kan veranderen, dus moet men fabrikantengegevens beschouwen als prompts om de aannames opnieuw te testen in plaats van ze als permanente regels te zien.

In elke rij komen twee concepten naar voren. Anthropic, met betrekking tot harness veroudering Harness ontwerp voor de ontwikkeling van langlopende applicaties:

“Elk component in een harness geeft een aannames weer over wat de model op eigen kracht niet kan, en deze aannames verdienen het om getest te worden onder druk, zowel omdat ze onjuist kunnen zijn, als omdat ze snel verouderd raken naarmate models zich ontwikkelt.”

Vercel, met betrekking tot het gerelateerde probleem van te veel tools die te veel aannames coderen, in We hebben 80% van de hulpprogramma’s van onze agent verwijderd.:

“We hebben het grootste deel ervan verwijderd en agent teruggebracht tot één enkel hulpmiddel: het uitvoeren van willekeurige bash-commando’s. Wij noemen dit een agent van het bestandsysteem.”

Vercel rapporteerde voor een representatieve query dat het succespercentage steeg van 80% naar 100%, terwijl de slechtste casus daalde van 724 seconden per 100 stappen en 145.463 tokens (mislukt) naar 141 seconden per 19 stappen en 67.483 tokens (geslaagd). De les hieruit is niet dat je je hulpmiddelen moet verwijderen, maar dat elke primitief in je runtime, inclusief het interfaceoppervlak, een halveringstijd heeft. Test de aannames opnieuw wanneer de model verandert.

Cognition observeerde hetzelfde bewegende doel op session lengte met Sonnet 4.5. In Devin opnieuw bouwen voor Claude Sonnet 4.5 ze beschrijven een model die proactief schrijft SUMMARY.md / CHANGELOG.md Aangezien het systeem een tekort aan context detecteert, schat het echter verkeerd in hoeveel tokens er nog beschikbaar is. Hun oplossing is om de beta-versie met 1M-token te activeren en het gebruik te beperken tot 200k, zodat de model nog steeds denkt dat er voldoende ruimte is. Deze mitigatiemaatregel zal uiteindelijk ook een dode weight worden.

Het team van OpenAI’s harness hanteert voor deze discipline een eenvoudige formule: “Mensen sturen het proces. Agents voert de acties uit.” Wanneer er iets misgaat, luidt de vraag niet “probeer harder”, maar “welke capaciteit ontbreekt en hoe kunnen we die zowel begrijpelijk maken als doorvoeren voor de agent?”

Het levenscyclus van een gezonde run

Een goed functionerende uitvoering is saai. Het bestaat uit een reeks kleine, herstelbare stappen, waarbij elke stap zijn resultaat op een duurzame opslagplaats schrijft voordat de volgende stap wordt gestart.

Die grens omvat schade veroorzaakt door een crash. Bij een fout wordt alleen de huidige stap in de uitvoering verloren; de volgende worker vervangt deze direct door de vorige, voltooide stap, in plaats van de hele aanvraag opnieuw te starten.

1. Start op van een nieuwe session of van een hervatte versie. Bij hervatting wordt de werkruimte gemounted uit zijn laatst bekende staat, en worden eventuele voortgangsbestanden die bij de vorige poging zijn achtergebleven gelezen.PROGRESS.md, feature-list.json), en laad dan de laatste checkpoint uit de database. Hier geeft de harness de agent alles wat de vorige worker in zijn geheugen had voordat deze stopte.
2. Plan eerst voor elke tool calls uitvoering. Noteer hoe “afgerond” eruitziet, hoeveel tijd de uitvoering mag gebruiken, welke hulpmiddelen de agent kan aanroepen, en wat de uitvoering moet stoppen als deze te vroeg moet eindigen. Deze geplande waarden worden runtime controles; zonder ze heeft de uitvoering niets om zich tegen te verzetten.
3. Voer één tool call per keer uit. De beleidslaag beslist of de oproep is toegestaan. De harness voert hem uit, slaat het resultaat op en schrijft één event in het session logboek. Eén stap, één event. Een crash tussen events is herstelbaar, omdat het logboek – en niet de geheugeninformatie van de worker – de bron van waarheid is.
4. Checkpoint bij grenzen van super-stappen, of na elk event in een eenvoudiger harness. Zorg ervoor dat de toestand van de graaf, de verschillen in het werkgebied en referenties naar alle gegenereerde artefacten worden opgeslagen. Dit checkpoint is wat stap 1 leest wanneer de uitvoering wordt hervat. Als de checkpoint ontbreekt of verouderd is, verloopt het herstel trager, omdat dan het hele session logboek vanaf nul moet worden afgespeeld.
5. Evalueer het resultaat tegen de artefacten zodra de agent aangeeft dat dit voltooid is: door middel van tests, een beoordeling door iemand met een schone context, schemavalidatie en browsercontroles. Als deze controles slagen, eindigt de uitvoering succesvol. Mocht dit niet het geval zijn, wordt de uitvoering hervat vanaf de laatste schone checkpoint, waarbij de foutmelding aan de context wordt toegevoegd, om opnieuw te proberen.

Er is geen enkele stap in die lijst waarbij de agent iets hoeft te onthouden tussen afzonderlijke uitvoeringen. De toestandsinformatie wordt opgeslagen in de session en de checkpoint, en de agent leest deze weer in bij elke herstart.

Hulpmiddelen die bijwerkingen hebben, vereisen idempotentie. Elk hulpmiddel met bijwerkingen moet een idempotentie-sleutel hebben die is afgeleid van de session ID en de tool-call ID, en deze sleutel moet worden opgeslagen voordat de bijwerking optreedt. send_email(session_id, tool_call_id, message_hash). create_pr(session_id, tool_call_id, branch_name). charge_customer(session_id, tool_call_id, invoice_id). Een minstens één keer uitvoeren is de standaard in queues en workflow-machines. Als het herhalen van een tool call echte schade kan veroorzaken, is het hulpmiddel nog niet klaar voor agents.

De evaluatie moet bewijsmateriaal omvatten dat afkomstig is uit een andere context dan waarin het werd gegenereerd. Een schone evaluator vermindert de bias veroorzaakt door gedeelde context, terwijl tests, linters, browsercontroles en schemavalidaties deterministisch bewijs leveren. De controle kan een resultaat teruggeven pass, fail, of needs_human. Voor de code agents kan de reviewer een andere model session zijn die over alleen-lezen gereedschappen beschikt. Voor gegevens en rapporten agents moet men deterministische validatie combineren met een reviewer model, waarbij nog steeds oordeelsvermogen vereist is.

Elf AI agent deployment patronen en wat de keuze daartussen bepaalt

Zodra de vijf primitieven zijn genoemd, rijst de vraag welke deployment-structuur ze uitvoert. Met ‘structuur’ bedoel ik een arrangement van deze primitieven: waar de harness zich bevindt, waar de toestand wordt opgeslagen, en wat voor soort sandbox de werkzaamheden uitvoert. Het gaat hierbij niet om een keuze die louter door één leverancier wordt gemaakt. De onderstaande grafiek geeft aan waar elke structuur zich op de run-length-as bevindt. De tekst ernaast legt uit wat de verschillen tussen hen bepaalt.

Als je maar één van de elf varianten gaat lezen, kies dan voor shape 2: queue + worker + checkpoint DB. Dit is de standaard die ik aanbeveel voor de meeste teams, de vorm die wordt gebruikt in het referentierepo, en het basismodel waarop de meeste andere varianten zijn gebaseerd: queue → worker → durable state, waarbij de sandbox bron, de harness eigenaar of de state engine worden vervangen. Door eerst shape 2 te bestuderen, kun je de overige varianten sneller doorlopen.

De grafiek vergelijkt de vormen op basis van hun looplengte. De matrix hieronder vergelijkt ze op basis van eigendom: namelijk waar elk van de vijf primitieven fysiek zich bevindt. Groene cellen geven aan dat de vorm zelf de primitief levert; grijs duidt erop dat u deze zelf moet koppelen.

1. SDK binnen een app-server (synchronisch, request-gebonden)

De oorspronkelijke vorm. De agent SDK wordt uitgevoerd binnen een request handler. Dit is geschikt voor taken die minder dan 30 seconden duren, demos en interne hulpprogramma’s. Het is echter niet bruikbaar voor situaties waarin een HTTP-client zich kan afkoppelen. De HTTP-tijdschrijving van Cloud Run De uitvoering duurt maximaal 60 minuten, en eventuele paniek op het weblaag niveau zorgt ervoor dat de uitvoering wordt afgebroken. De SDK is de harness; het webproces fungeert tevens als sandbox. De toestandsinformatie bevindt zich meestal in het geheugen van het proces, tenzij deze expliciet ergens anders wordt opgeslagen. Gebruik dit niet voor werkzaamheden die meerdere uren duren.

2. Queue + worker + checkpoint DB

De standaard die ik aanbeveel voor de meeste teams, en de productievorm die wordt gebruikt in market-analyst-agent: een Python-worker met een PostgreSQL-checkpointer, Redis Streams (of) RabbitMQ) Voor de inbound-queue en een MCP sidecar voor tools. Dit is geschikt voor uitvoeringscycli van 10 minuten tot meerdere uren met idempotente stappen. De lokale runner kan de queue omzeilen voor synchrone ontwikkeling, maar zodra async-inzending en backpressure nodig zijn, maakt de queue deel uit van de productieomgeving.

De applicatie accepteert een verzoek, maakt een session-rij aan, stuurt een taak door en geeft een run-ID terug. De worker haalt de taak op, voert de harness uit, schrijft checkpoints op, streamt de status en slaat artefacten op terwijl dit proces verloopt. Postgres blijft functioneren, workers fungeren als eenvoudige uitvoerders, en de diepte van de queue zorgt voor backpressure. Spot/Preemptible computing werkt zolang de checkpointer klaar is met het opslaan van gegevens op disk voordat hij succes meldt.

In deze configuratie fungeert de worker als de harness. Zijn container en het werkgebied per thread vormen een uitvoeringsgrens, maar onbetrouwbare code heeft nog steeds behoefte aan een versterkte sandbox of VM. Postgres beheert de staat van session en checkpoint. Traces gaan via OpenTelemetry naar de gewenste observability stack die je gebruikt.

3. Duurzame workflow-engine (Temporal-stijl)

Agent orchestration De code wordt uitgevoerd binnen een Temporal Workflow; model aanroepen en tool calls worden uitgevoerd als Activiteiten. Workflow de staat wordt opgeslagen in een event-history log die wordt ondersteund door Cassandra, MySQL of Postgres, zodat de staat correct kan worden herhaald bij elke deploy. De public-preview Integratie van Temporal met OpenAI Agents SDK stuurt naar buiten OpenAIAgentsPlugin en een activity_as_tool helper, en de beschrijving van agentic sandboxes Het beschrijft het kopiëren van een lopende agent naar een andere sandbox-provider middenin een gesprek. Inactieve workflows-processen verbruiken geen rekenkracht. Er zijn echter wel beperkingen: streaming en spraak agents worden in de huidige integratie niet ondersteund. LocalShellTool en ComputerTool Ze zijn uitgeschakeld omdat ze niet passen binnen een gedistribueerd model-systeem.

Gebruik deze vorm wanneer de uitvoering daadwerkelijke wachtpunten kent: menselijke goedkeuringen, externe callback‑aanroepen, lange slaapperioden, herproberingen onder invloed van bedrijfsregels, en deploy‑tijfen. Een menselijke goedkeuring resulteert in een duurzame slaaptoestand die geen rekenkracht verbruikt, in tegenstelling tot een polling‑lus die dat wel doet.

De Workflow-code is de harness. De sandbox bevindt zich meestal buiten Temporal en wordt aangeroepen vanuit Activiteiten. Session en checkpoint worden opgenomen in het gebeurtenislogboek van Temporal, terwijl de zichtbaarheid van trace voortkomt uit de Temporal UI in combinatie met OpenTelemetry spans in elke Activiteit.

4. Sandbox-provider volgens session

Een nieuwere vorm. Elke uitvoering van agent krijgt een eigen microVM of container van een sandbox-as-a-service-aanbieder. De harness bevindt zich op een betrouwbare opslaglocatie; de sandbox vormt daarentegen de tijdelijke uitvoeromgeving.

De tabel combineert de Vergelijking E2B versus Daytona, Daytona’s sandboxes documentatie en fork/snapshot changelog, Modal’s sandboxes en cold start gidsen, de Runloop-lijsting op AWS Marketplace, en Vercel Sandbox-prijzen.

Daytona registreert een ouder-kind-relatie voor elk afzonderlijk fork, waardoor de afstamming van de afgeleide sandboxes behouden blijft. OpenAI’s Codex harness maakt gebruik van de variant per worktree: “Codex werkt met een volledig geïsoleerde versie van die applicatie, inclusief de bijbehorende logs en metrics, die worden verwijderd zodra de taak is voltooid.”

Grijp naar deze vorm wanneer agent onbetrouwbare code uitvoert, browsers automatiseert, tests uitvoert of pakketten installeert. Het nadeel hiervan zijn de hogere kosten en de sterkere koppeling aan de provider, vergeleken met het gebruik van gedeelde workers.

De provider is eigenaar van sandbox en niets anders. Harness, session, checkpoint en trace blijven op uw kant, meestal geconfigureerd in de vorm van een queue plus workers zoals beschreven in #2.

5. Anthropic Managed Agents (gehosteerd op harness)

Anthropic heeft Managed Agents in een publieke beta-versie gelanceerd op 8 april 2026, achter de managed-agents-2026-04-01 Beta-header. De dienst biedt een gehostte session, harness, sandbox en door een vault ondersteunde MCP proxy. wake(sessionId) Het is mogelijk om de harness in een nieuwe worker in te stellen zonder dat de permanente session-toestand verloren gaat.

Claude factureert Managed Agents tegen de standaard token tarieven, plus $0,08 per session-uur. De facturatie vindt plaats op millisecondenniveau en is alleen van toepassing zolang de session-status “running” is; tijd dat de dienst niet actief is, valt niet onder de kosten. Een ongeremde herprobeerloop leidt daarom tot extra kosten van session-uur bovenop de reeds verschuldigde token kosten.

Lees de voorwaarden zorgvuldig. De korting voor batchverwerking API is niet van toepassing (“Sessions zijn stateful en interactief; er is geen batchmodus”). Gemanaged Agents is niet beschikbaar via AWS Bedrock of Google Vertex AI. Multi-agent Coördinatie en zelfevaluatie bevinden zich nog in de onderzoeksfase. Het risico op lock-in is groot: men geeft op voorhand harness vrijheid op in ruil voor het niet zelf hoeven uitvoeren van de iteratieve processen.

Anthropic biedt alle vijf de primitieven aan: session, harness, sandbox, checkpoint en trace. U stuurt de runtime naar hen toe en ontvangt daarna de uitvoer.

6. LangChain Deep Agents Implementatie (beheerde open harness)

deepagents deploy packages een deepagents.toml in een LangSmith Deployment met betrouwbare uitvoering, geheugenbeheer, multi-tenancy, human-in-the-loop, observability, gesandboxde codeuitvoering en geplande uitvoeringen. Er wordt ondersteund voor cloud-, hybride- en zelfgehoste deployment modi. Sandbox aanbieders (LangSmith Sandboxes, Daytona, Modal, Runloop of maatwerk) kunnen worden gewisseld via één enkele configuratiewaarde. De toestand wordt opgeslagen in een virtueel bestandsysteem met plugbare backends; het geheugen is toegewezen aan de gebruiker, de assistent of beide. Het risico op lock-in is lager dan bij Managed Agents: de harness is onder licentie MIT uitgegeven en de instructies maken gebruik van open-source technologieën. AGENTS.md De standaard en agents worden via het MCP-, A2A- en Agent-protocol blootgesteld. Zie LangChain’s runtime – achter de productieomgeving, diep geïntegreerd agents verslag.

De vijf primitieven zijn standaard gehosted, maar elk van hen kan worden vervangen door een andere configuratie. De sandbox bevindt zich achter één specifieke configuratiewaarde. Session en checkpoint staan op een virtueel bestandsysteem waarbij pluggable backends-modules kunnen worden gebruikt. Trace wordt verwerkt door LangSmith.

7. Google Cloud Run-service of -job

Cloud Run beschikt over twee verschillende runtime-modi, en welke modus geschikt is, hangt af van de manier waarop de agent wordt aangeroepen. Services zijn gebonden aan HTTP en schalen terug naar nul tussen aanvragen; de harness werkt als een aanvraagverwerker die stopt zodra de uitvoering is voltooid. Jobs worden tot het einde uitgevoerd zonder HTTP-entrypoint; de harness fungeert als eenmalige worker die ophoudt te werken zodra de taak is afgerond. Beide kunnen de harness bevatten, maar geen van beide bewaart staat tussen verschillende uitvoeringen. Sessions en checkpoints moeten worden opgeslagen in Postgres, Spanner of een soortgelijke externe opslag.

De harde limieten verschillen sterk tussen de twee. Timeout bij het aanvragen van een Cloud Run-service: De standaardtijd is 300 seconden, met een maximale tijd van 3.600 seconden (60 minuten). WebSockets Krijg dezelfde tijdslimiet. Cloud Run-taken: De standaardduur is 10 minuten per taak, met een maximale duur van 168 uur (7 dagen); voor taken die GPUs gebruiken, is de maximale duur 1 uur. De diensten schalen terug naar nul tenzij u altijd‑aanstaande CPU inschakelt; taken hebben geen HTTP‑interface en schalen niet automatisch.

Gebruik een service voor synchrone uitvoeringen van maximaal 60 minuten. Gebruik een job voor langdurige, éénmalige of asynchrone taken. Cloud Run Jobs kunnen een taak dagenlang in leven houden, maar ze bieden geen duurzame herhalingss mogelijkheid na het uitvoeren van nieuwe versies of bij het vervangen van workers. Voor meer dan 7 dagen moet u Cloud Run niet gebruiken.

Cloud Run host de harness. De Session en checkpoint-toestanden worden opgeslagen in Postgres, Spanner of een andere externe opslag, terwijl traces kan worden doorgestuurd via Cloud Logging en OpenTelemetry. Het servicecontainer vormt het uitvoeromgeving; voeg een aparte sandbox toe wanneer de agent onbetrouwbare code uitvoert.

8. AWS Lambda (waarom het de verkeerde tool is)

De maximale tijdslimiet voor het uitvoeren van een Lambda-functie De tijdslimiet is 900 seconden (15 minuten), wat behoorlijk kort is. Als de API Gateway de functie voorafbehandelt, hangt de integratielimiet af van het type API. HTTP APIs staat 30 seconden toe; REST-integraties hebben standaard een timeout van 29 seconden, terwijl Regionale en privé REST APIs-omgevingen kunnen een langere timeout instellen.. Geen enkele van deze aanpakken zorgt er ervoor dat Lambda wordt omgevormd tot een worker die urenlang actief is. Een langlopende harness heeft nog steeds externe staat en opnieuw uitvoeren nodig, waardoor de queue- en workerstructuur opnieuw wordt gecreëerd. Gebruik Lambda voor beperkte tool calls-taken, zoals het ophalen van bestanden of het uploaden naar S3, die worden uitgevoerd door een langlopende orchestrator. Plaats de orchestrator niet in Lambda zelf.

In het beste geval kan Lambda één tool call bevatten binnen zijn limiet van 15 minuten. De harness, session, checkpoint, sandbox en trace moeten allemaal op een andere locatie worden opgeslagen.

9. AWS ECS / Fargate-taak per uitvoering

Volgens de Fargate-documentatie is er geen strikte limiet voor taken runtime, in tegenstelling tot Lambda. Fargate-throttelingquotums Stel een startopbrengst in van 100 en vul deze opnieuw aan met 20 per seconde, waarbij er aparte budgetten zijn voor op verzoek en voor spotprijzen. ECS-servicequotums Beperk de capaciteit van services door gebruik te maken van AWS Cloud Map voor ontdekking tot 1.000 taken per service, en van EC2-gebaseerde clusters tot 5.000 containerinstanzen.

Fargate vereist awsvpc In deze modus krijgt elke taak een eigen netwerkinterface en privé‑IP-adres. Deze opzet is geschikt voor intern dataverkeer binnen een VPC. Fargate Spot brengt echter een risico op onderbrekingen met zich mee, en de duurzaamheid van de diensten blijft uw verantwoordelijkheid, aangezien de platform geen Temporal‑achtig herhalingsmechanisme biedt.

Fargate host de harness en geeft elke uitvoering zijn eigen taak. Hierdoor worden de werkruimtes en de credentials van de taken gescheiden, maar dit vormt op zichzelf geen volledige sandbox tegen vijandig code. Session, checkpoint en trace maken gebruik van externe diensten zoals RDS of DynamoDB, evenals CloudWatch/X-Ray.

10. Kubernetes Job of namespace per session

Handig wanneer je er al mee werkt. Kubernetes en men wil sandbox-per-session in combinatie met clusterwijde controles. Dit is problematisch wanneer een starttijd van subseconden vereist is, omdat het ophalen van de containerimage en het initialiseren van de pod te lang duurt op een cold start. Het patroon is één Job per agent uitvoering, waarbij activeDeadlineSeconds, een PersistentVolumeClaim voor het werkgebied, en een sidecar voor de MCP-server. De herstelmechanismen bij crashes moet u zelf ontwikkelen. Het gebruik van Kubernetes louter om agents te hosten, brengt hoge kosten met zich mee door de grote configuratievereisten en het operationele gewicht. Het is alleen zinvol als u K8s al om andere redenen gebruikt.

Kubernetes beherigt zowel de harness als de uitvoeromgeving per uitvoering, meestal als één Job en soms binnen een gespecialiseerde namespace. Sterke isolatie is nog steeds afhankelijk van de runtime-klasse, netwerkbeleid, pod-beveiliging en de grenzen van de onderliggende container of VM. De Session- en checkpoint-toestanden worden opgeslagen in een externe database of via een PersistentVolumeClaim.

11. Lokale Docker Compose (alleen voor ontwikkeling)

De referentie voor het volgende gedeelte. Het doel van deze configuratie is om de productietopologie één-op-één weer te geven (zelfde primitieven, dezelfde netwerkstructuur), maar dan op één enkele server. Lees de lijst met “niet producties veilig” aan het einde van het volgende gedeelte voordat u iets dat er zo uitziet naar buiten stuurt.

Componeer de mirrors shape #2 op één enkele host. Postgres bevat de session en checkpoint-toestanden, terwijl de worker-container fungeert als harness. Het monteren van een gedeelde werkruimte is handig voor ontwikkeling, maar zorgt niet voor isolatie van onbetrouwbare uitvoeringen. De optionele OpenTelemetry-stack slaat de traces-gegevens op.

Referentiestack: Docker Compose

De referentietopologie, die wordt gebruikt in slavadubrov/market-analyst-agent, is een LangGraph worker, een Postgres checkpointer, Qdrant voor retrieval, een MCP sidecar, een Redis-queue voor asynchrone uitvoeringen in productieomgevingen, en een optioneel Prometheus / Grafana / Loki / Tempo / OTel observability stack. In lokale compose is Redis alleen optioneel omdat de synchrone uitvoerder de worker rechtstreeks kan aanroepen. docker compose up zet de hele topologie lokaal online.

Het enige onderdeel dat direct weergegeven moet worden, is de canonieke configuratie van LangGraph. Dit vormt het kleinste concrete voorbeeld van de checkpoint primitief:

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

Observability die na de uitvoering overblijft

Korte verzoekverwerkers zijn gemakkelijk te debuggen: wanneer er iets misgaat, leest men de respons en het live-logbestand. Langlopende agents hebben die luxe niet. Tegen de tijd dat een zes uur durende uitvoering faalt, heeft het interessante evenement zich al vijf uur eerder voorgedaan, is de output van de live-terminal verdwenen en is de worker die deze heeft gegenereerd al vervangen. Niemand zal de uitvoering op basis van geheugeninformatie reconstrueren. Daarom wordt er gedebogueerd aan de hand van duurzame artefacten die zijn gemaakt terwijl de uitvoering nog actief was.

Productiestacks omvatten doorgaans vier soorten artefacten, verdeeld in twee groepen. Twee daarvan worden gelezen na de uitvoering, voor postmortems en herhaling: een querybaar eventlog van elke stap, en OpenTelemetry traces die aangeeft waar de tijd en tokens naartoe zijn gegaan. De andere twee worden gelezen tijdens de uitvoering, om het proces in real time te volgen: een live weergave van wat de agent in het werkgebied genereert, en een per-worktree observability stack waarnaar de agent zelf kan kijken terwijl deze nog draait.

Gestructureerd evenementenlogboek (lees na de uitvoering)

Elke model oproep, tool call, resultaat, fout en goedkeuring worden opgeslagen in duurzame opslag, gecodeerd met behulp van een session ID en tijdstempel. Zodra de uitvoering is afgerond, kun je deze opzoeken zoals bij een gewone database-tabel. Addy Osmani stelt hier duidelijke eisen aan. Een langlopend Agents: “Als je niet in staat bent om uit duurzame opslag weer te geven wat agent de afgelopen 24 uur heeft gedaan, dan heb je te maken met een langlopend shellscript dat toevallig een LLM aanroept, en niet met een langlopend agent.”

OpenTelemetry GenAI traces (lees na de uitvoering)

Hetzelfde soort stapsgewijze gegevens, maar uitgezonden als spans met behulp van de standaardattributen uit de gen_ai.* semantische conventies: model naam, provider, invoer en uitvoer token aantallen, gespreks-ID, workflow naam (Ontwikkelingsstatus per v1.36.0). Veldkenmerken die specifiek zijn voor een provider bevinden zich in subnamenruimtes.anthropic.*, openai.*) uitgeschakeld gen_ai.provider.name. De reden om deze standaard te gebruiken, is de portabiliteit: dezelfde trace wordt op een consistente manier weergegeven in Tempo, Jaeger, Honeycomb of LangSmith, zonder dat u de code opnieuw moet instrumenteren bij elke wisseling van backends.

Tijdslijn van toolaanroepen plus verschillen in het werkgebied (lees tijdens de uitvoering)

De snelste manier om te weten wat een agent op dit moment doet, is door het output dat het in de werkruimte genereert in de gaten te houden, in plaats van door te zoeken in een session-log. Anthropic’s Harness Primitieven voor langlopende Claude Agents Quick-Start levert twee hooks voor dit doel: watch -n 5 'git log --oneline -8' toont de meest recente commits die agent heeft gemaakt, en watch -n 5 'find screenshots -name "*.png" | tail -5' Het toont de meest recente screenshotten die zijn genomen. Twee terminalvensters die om de vijf seconden worden bijgewerkt, zijn voldoende om vast te stellen of een uitvoering daadwerkelijk vooruitgang boekt of alleen maar loopt.

Tijdelijke stack per worktree (gelezen door de agent zelf, tijdens de uitvoering)

Per De post van OpenAI over harness: “Logbestanden, metrics en traces worden via een lokale observability-stack die voor elke specifieke worktree tijdelijk is, aan Codex blootgesteld.” Elke agent worktree beschikt over zijn eigen kortstondige Loki + Prometheus + Tempo-installatie, die uitsluitend voor die ene uitvoering wordt gebruikt. De agent voert onderzoek uit terwijl deze systemen actief zijn. Dit maakt het mogelijk dat een prompt-claim als “geen span in deze vier gebruikersprocessen langer dan twee seconden duurt” direct door de agent kan worden geverifieerd, in plaats van dat dit moet worden geraden.

(The fresh-context evaluator uit de failure-modes-tabel leest deze artefacten om te bepalen of het proces “afgerond” is. Het valt onder evaluatie, en niet onder observability; zie § Gezonde levenscyclus van een run.

Een minimale zelf gehoste observability-stack

Voor zoiets als market-analyst-agent:

1. OpenTelemetry Collector met de GenAI-processor en een attribuutfilter gen_ai.*.
2. Tempo (of Jaeger) voor traces, gecodeerd op basis van gen_ai.conversation.id / thread_id.
3. Loki voor gestructureerde eventlog-entrées.
4. Prometheus voor gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (zie de Conventies voor metrics van generatieve AI).
5. Grafana-dashboards die zijn gebaseerd op gen_ai.agent.name en gen_ai.request.model.

Gehoste alternatieven (kies er één, niet drie):

• LangSmith: Geïntegreerde ondersteuning voor LangGraph; eveneens het deployment-doel voor Deep Agents Deploy. Braintrust: De beste optie is wanneer eval-de eerste regressietests prioriteit hebben.
• Arize Phoenix: OSS, OTLP-native, kan worden gecombineerd met OpenInference Instrumentatie.
• Het dashboard van OpenAI’s tracing: automatisch wanneer je de OpenAI Agents SDK gebruikt of diens Temporal-integratie.
• Anthropic’s Claude tracing: voor sessions die wordt uitgevoerd binnen Managed Agents.

Het LangGraph-node instrumenteren

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "claude-sonnet-4-5")
span.set_attribute("gen_ai.response.model", "claude-sonnet-4-5")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Naamvanattributenwordtlettervoorletterovergenomenuitde OpenTelemetry Register voor semantische conventies van generatieve AI.

Vragen over drie veelvoorkomende fouten

# Loki: token usage per agent over 1h
sum by (gen_ai_agent_name) (
    rate({service_name="market-analyst-agent"} | json | unwrap gen_ai_usage_output_tokens [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

Het debug-bundlepatroon

Wanneer een uitvoering mislukt, moet de worker deze afbreken. /workspaces/${THREAD_ID}/_debug/ met de artefacten die u zou opvragen bij een postmortem:

• session.jsonl: volledige dump van het eventlog uit de PostgresSaver (checkpointer.list({"thread_id": ...})).
• last_state.json: StateSnapshot.values van de laatste succesvolle super-stap. trace.json: OTLP-geëxporteerde spans voor de uitvoering.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: de werkmapdirectory plus git diff tegenover de initialisatierecommit. screenshots/*.png: Wat de agent heeft waargenomen.
• PROGRESS.md, feature-list.jsonen alle andere door agent gemaakte voortgangsbestanden. env.txt: afbeeldingstags, model-versie, harness commit SHA.

Deze bundel levert een mens of reviewer agent voldoende bewijsmateriaal om de fout te reconstrueren. De uitspraak “De agent zat vast” is vaag. Een illustratief rapport daarentegen is concreet: session s_123 Het bestand bracht 71 procent van zijn tokens door met het herhalen van drie commando’s. npm install Fout.

Het juiste formaat kiezen: een beslissingsgids

Het grootste deel van de bovenstaande vergelijking komt neer op een handvol beslissingen.

Begin met de looplengte

Gebruik de looplengte als eerste filter:

• Minder dan 30 seconden, idempotent: request-lifecycle SDK op een app-server.
• 30 seconden tot 60 minuten, geen herstel van crashes nodig: queue + worker + checkpoint DB.
• 60 minuten tot 24 uur: dezelfde queue + worker, of een Cloud Run Job voor éénmalige taken. Gebruik een duurzame workflow engine als je ook versienummering en herhaling nodig hebt.
• Langer dan 24 uur, moet bestand blijven na deployments: duurzame workflow engine (in hetTemporal-stijl). Cloud Run Jobs kunnen lange taken opslaan tot aan hun taalimiet, maar ze bieden geen mogelijkheid tot herhaling.
• Meerdere dagen durende RL-trainingsschleifen: K8s Job + volume + Temporal.

Na deze grove filtering moeten de bijwerkingen, herstelmogelijkheden, replay-functie, isolatie, opslaglocatie van de gegevens en het team dat het systeem zal bedienen worden gecontroleerd.

Passendheid van de platform voor specifieke toepassingscasussen

De matrix is dik omdat één enkele groene cel niet bepaalt hoe de architectuur eruitziet. Een brede dekking van werklasten is zeker nuttig, maar het geeft geen inzicht in de locatie van de gegevens, de semantiek van herhaling, de afhankelijkheid van de leverancier, de operationele volwassenheid, noch de kosten die gepaard gaan met het verplaatsen van de staat op een later moment.

Deep Agents Deploy omvat elk type werklast dat in de matrix is opgenomen, waardoor het een geschikte optie is wanneer één platform zowel korte uitvoeringen, meerdere uren durende taken, code agents, onderzoek agents als geplande jobs moet verwerken. Deze breedte van functionaliteit komt echter met een korter productieverleden vergeleken met een stack die bestaat uit een queue, workers en Postgres. Beschouw de groene cellen als specificaties die geverifieerd moeten worden, en vergelijk ze vervolgens met de operationele beperkingen die niet in de matrix zijn weergegeven.

Anthropic Managed Agents Het past ofwel volledig bij uw werkbelasting, of helemaal niet. Het product kent drie strikte beperkingen: het kan alleen worden gehost, alleen met Claude, en de verwerking duurt minder dan 24 uur per keer. session. Als uw werklast aan alle drie voldoet, bijvoorbeeld een interne codering agent dat in bursts van 2 tot 6 uur draait en dat je liever niet wilt laten werken harness zichzelf, Beheerd Agents is een uitstekende keuze en verwijdert een groot deel chunk van het platformwerk van uw team. Als één beperking niet kan worden nageleefd omdat u een niet-Claude agent nodig heeft modelzelf gehoste conformiteit, of 48-uurs uitvoeringen, Beheerd Agents Past niet. Geen enkele configuratiewijziging kan dat veranderen.

Het is raadzaam om de prijsmodellering al vóór het maken van een beslissing uit te voeren, en niet pas daarna. De session-uurprijs bedraagt $0,08/uur bovenop de standaard token-kosten. Als één enkele session continu draait, komt dat neer op ongeveer$58 per maand per session. Bij 100 sessions die continu draaien, is dat ongeveer $5.800 per maand _voordat de tokenkosten worden meegerekend_. Vermenigvuldig$0,08 met het aantal verwachte gelijktijdige session-uren, voeg dit toe aan je token-rekening en vergelijk dit met de kosten van een eigen queue- en workerstack op je infrastructuur. Doe dit alvorens je een beslissing neemt, want het migreren van Managed Agents later is een geheel nieuwe platformimplementatie, en geen eenvoudige configuratiewijziging.

Gehosteerd harness versus eigen harness

Het verschil hier is operationeel, en heeft niets te maken met wie de harness-code heeft geschreven. Gehosteerd betekent dat de leverancier de harness-loop uitvoert op zijn eigen infrastructuur, terwijl u een API gebruikt. In eigendom hebben betekent dat u de loop zelf op uw eigen infrastructuur draait, zelfs wanneer de harness-code afkomstig is van een leverancier.

LangChain komt aan beide kanten van deze regel voor, waardoor veel mensen in de war raken. Ze leveren LangGraph uit, een onder licentie van MIT staande bibliotheek die je zelf host (dus in eigen beheer hebt), en Deep Agents Deploy, een beheerde oplossing die een Deep Agents harness uitvoert op LangSmith Deployment in zijn standaard cloudmodus (gehosteerd). Het is dezelfde onderneming, maar met twee verschillende operationele models. Jij kiest het model, niet de leverancier. (Deep Agents Deploy beschikt ook over een zelfhostmodus voor teams die de harness gebruikersvriendelijkheid willen zonder de cloudcomponent; die modus valt onder de optie in eigen beheer.)

Kies voor een gehost harness wanneer de ondersteuning voor model, de gegevensgrenzen, het herstelgedrag en de uitbreidingspunten al voldoen aan uw behoeften. Kies voor een eigen harness wanneer deze beperkingen juist eisen zijn die u van plan bent te wijzigen. De migratie tussen deze twee opties verandert zowel de observability als de uitvoeringsgrenzen, dus test de afsluitende procedure voordat productiedata daarvan afhankelijk wordt.

Gehosteerd sandbox versus een eigen uitvoeromgeving

Kies voor een gehost sandbox wanneer de isolatie van de provider, de mogelijkheid om te pauzeren of hervatten, of de fork-semantiek overeenkomen met de dreiging model en het beschikbare startbudget. Docker of Fargate zijn geschikt voor betrouwbare interne werklasten die toegang tot een VPC of strikte gegevensresidentie nodig hebben, maar een standaardcontainer vormt geen voldoende beveiligingslaag tegen vijandige code. Voeg gVisor, Kata, een microVM of een andere versterkte runtime toe wanneer de agent onbetrouwbare pakketten installeert of gegenereerde programma’s uitvoert.

Stateopslag: Git, databases en objectopslag naast elkaar

Langlopende agents-processen maken doorgaans gebruik van drie state stores tegelijk, omdat elke store een ander artefact beheert.

Git slaat de staat van het werkgebied op: de code, documenten en voortgangsbestanden die door agent worden gewijzigd. Elke commit biedt de harness een stabiele herstelpunt en zorgt er voor dat de volgende session over een compacte geschiedenis beschikt.

De checkpoint-database slaat de toestand van het graf op: wat is besloten, welke knopen zijn uitgevoerd, welke resultaten zijn teruggegeven en wat vervolgens moet worden uitgevoerd. De artefactopslag bevat grote eindresultaten zoals PDF’s, Parquet-bestanden en screenshotten. Deze artefacten horen niet in Git of de checkpoint-database thuis.

Wanneer git moet worden gebruikt als toestandsopslag

Gebruik Git wanneer de werklast bestaat uit code (meerdere bestandswijzigingen, refactoring, applicatiegeneratie) of voldoende uit documenten is zodat het bestandshistorisch verloop belangrijk is. Het patroon is eenvoudig: maak een ‘run’-branch aan, voer een initiële commit uit en commit vervolgens op logische momenten: na de configuratie, na elk nieuw feature, nadat de tests zijn geslaagd en na de finale opruiming. Bewaar de SHA van de meest recente workspace-commit naast de checkpoint-rij. Bij hervatting haalt de volgende werker de branch op en leest git log --oneline -8, controleert git status en de meest recente diff, waarna het wordt gelezen PROGRESS.md of welk overdrachtsbestand dan ook dat door de vorige session is gemaakt.

Dat maakt van Git een herstelpunt voor het momenteel bewerkte artefact, en niet een vervanging voor de checkpoint DB. Git kan twee vragen beantwoorden: wat is veranderd, en welke versie heeft de tests doorstaan. Het kan de harness echter niet vertellen welk grafieknode als volgende moet worden uitgevoerd, welke tool call op goedkeuring wacht, of welke herhaalpoging al zijn idempotentie‑sleutel heeft gebruikt. Anthropic’s harness maakt gebruik van initialisatie‑commits plus commits per functie als bron van waarheid voor het herstellen van het werkgebied; de model leest deze informatie in. git log --oneline -8 Om de staat te herstellen. Sla Git over wanneer het eindresultaat slechts één gespreksantwoord is; de extra overhead is niet gerechtvaardigd.

Wanneer DB-checkpointing moet worden gebruikt

Gebruik PostgresSaver-stijl checkpointing wanneer de agent een grafische structuur bezit met meerdere knopen, waarbij de tussentijdse staat belangrijk is (planner → onderzoeker → schrijver → verificator). Het referentierepo gebruikt deze aanpak om precies deze reden. Plaats artefacten van terabyte-grootte niet in de checkpoint; die gaan naar objectopslag.

Wanneer je een artifactopslag gebruikt (S3 / GCS)

Gebruik objectopslag wanneer:

• De uitvoer is groter dan de hoeveelheid die de checkpoint database kan bevatten;
• Downstream-consumenten hebben een via een URL bereikbaar artefact nodig, zonder dat dit via de agent moet gaan; of
• Het eindresultaat en de status van de uitvoering hebben verschillende retentieperiodes.

Bijvoorbeeld: je kunt het session-log na 30 dagen verwijderen, maar het eindrapport jarenlang bewaren. Bepaal de opmaak hierop. (thread_id, checkpoint_id, artifact_name) Zodat de productierun nog steeds reconstrueerbaar blijft.

Wanneer menselijke goedkeuring nodig is

Voeg gates toe wanneer tool call destructief en onomkeerbaar is (DB-opslag, geldtransacties, verzending van externe communicatie), wanneer tool call de ‘blast radius’ van agent verlaat (productiedeploy’s, publicaties voor klanten), of wanneer toezichthouders een evaluatie eisen. LangGraph’s interrupt() Zowel Deep Agents’ approval middleware als de andere oplossingen beschikken over ingebouwde ondersteuning voor deze controlepunten. Deel 4 Er is uitgelegd waarom deze gates een probleem vormen met betrekking tot toestemmingen, en niet een probleem met prompt.

Een praktische controlelijst voor productieomgevingen

Voordat een langlopende agent wordt geïmplementeerd, beantwoord deze vragen in termen van de concrete infrastructuur.

1. Welke store beheert de session-evenementen en checkpoints?
2. Wat gebeurt er als de worker halverwege een tool call stopt met werken?
3. Kan één run de werkruimte van een andere run corrumperen?
4. Welke acties vereisen goedkeuring?
5. Kunnen de model of sandbox ruwe credentials lezen?
6. Welke tool calls mogen veilig opnieuw proberen?
7. Waar wordt het maximale kostenplafond per run toegepast?
8. Welke controle op een nieuwe context bepaalt of een run “afgerond” is?
9. Waar worden de eindresultaten opgeslagen nadat de sandbox is verwijderd?
10. Kunnen we een mislukte run morgen uitleggen zonder deze opnieuw uit te voeren?

Als het antwoord op een van deze vragen is dat “de prompt de agent instrueert om voorzichtig te zijn”, dan is het systeem nog niet geïmplementeerd. Het blijft een demo.

De volgende laag is de harness-lus

Deze runtime kan ervoor zorgen dat een uitvoering actief blijft en herstelbaar is, maar duurzaamheid bewijst niet dat het werk correct is. Deel 6, Harness Engineering voor AI Agents, Het behandelt de lus rondom model: hoe een trace wordt omgezet in een testgeval, waar de regels voor herproberen en stoppen zich bevinden, wat bij een overdracht moet worden behouden, en hoe een externe acceptatiecontrole bepaalt wanneer een uitvoering is voltooid.

Referenties

Technische rapporten

• OpenAI, Harness engineering: het benutten van Codex in een agent-gerichte omgeving.
• Anthropic Engineering, Doeltreffende hulpmiddelen voor langlopende agents.
• Anthropic Engineering, Harness ontwerp voor de ontwikkeling van langlopende applicaties.
• Anthropic Engineering, Schalen van gemanaged Agents: Het scheiden van de ‘brain’ van de ‘hands’, 8 april 2026.
• Cognitie AI, Het opnieuw bouwen van Devin voor Claude Sonnet 4.5: lessen en uitdagingen.
• Vercel, We hebben 80% van de tools van onze agent verwijderd..
• Addy Osmani, Een langlopend Agents.

LangGraph en Deep Agents

• LangGraph-documentatie, Persistentie.
• LangGraph-referentie, Checkpoints.
• langgraph-checkpoint-postgres op PyPI.
• LangChain-documentatie, Diepgaande overzicht van Agents.
• LangChain-blog, De runtime achter de productie Deep Agents.

OpenAI Agents SDK

• OpenAI Agents SDK, Sessions.
• OpenAI Agents SDK, Sandbox concepten.

Tijdsgebonden

• Tijdsgebonden blog, We stellen Temporal en agentic sandboxes voor: de OpenAI Agents SDK.
• Tijdsgebonden blog, Productierijp agents met de OpenAI Agents SDK + Temporal.
• Temporal × OpenAI Agents SDK bijdrage README (temporalio/sdk-python).

Anthropic-platform

• Anthropic, Prijzen van de Claude-platform: Gemanageerde tarieven per Agents session uur. anthropics/cwc-long-running-agents: Het schrijven van code met Claude 2026 voor thuisgebruik, waarbij evaluator als subagent wordt gebruikt en er rekening wordt gehouden met specifieke patronen voor progressiefielbestanden.

Sandbox providers

• ZenML, E2B versus Daytona: een vergelijking van sandbox voor platformengineers.
• Daytona-documentatie, Sandboxes.
• Daytona changelog, de Sandbox-, fork- en snapshot-endspunten.
• Modale documentatie, Sandboxes.
• Modale documentatie, Cold start handleiding.
• Runloop op AWS Marketplace.
• Vercel Sandbox prijzen en beperkingen.

Tijdslimieten en quota’s voor cloudplatforms

• Google Cloud, Stel de verzoekstijdschrijving in voor services.
• Google Cloud, Het gebruik van WebSockets.
• Google Cloud, Stel de tijdslimiet voor taken in voor jobs.
• AWS, De tijdslimiet van de Lambda-functie configureren.
• AWS, Lambda-quotas.
• AWS, Fargate-throttellimieten.
• AWS, Quotas voor ECS-diensten en beperkingen voor throttling van API.

Observability

• OpenTelemetry, Semantische conventies voor generatieve AI systemen.
• OpenTelemetry, Registre van AI-attributen.
• OpenTelemetry, Semantische conventies voor GenAI agent en framework spans.
• OpenTelemetry, Semantische conventies voor generatieve AI-metingen.

Serieën

• Deel 1: AI Agent Reasoning Lussen in 2026: ReAct, ReWOO, en Plan-and-Execute. Deel 2: AI Agent Memory Architectuur in 2026: checkpoints, vector stores, en het documentatiegeheugen. Deel 3: AI Agent Tool Use in 2026: MCP, CLI, vaardigheden, uitvoering van code, en ACI.
• Deel 4: AI Agent Beveiliging in 2026: - guardrails, rechten, sandboxes, HITL, en MCP-scopebepaling.
• Deel 5: Langdurige AI Agent Runtime in 2026 (dit artikel) Deel 6: Harness Engineering voor AI Agents: Acceptantiecontroles, traces, herproberingen, overdrachten, en de lus rondom de model.

De code van de Market Analyst Agent (LangGraph worker, Postgres checkpointer, Qdrant geheugen, MCP sidecar en de hierboven beschreven Docker Compose-topologie) is actief. GitHub._