Ga naar inhoud

Automatische vertaling

Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Runtime voor langlopende AI-agents in 2026: sessies, sandboxes, checkpoints en harnesses

Deel 5 van de serie Engineering the Agentic Stack

De vorige vier posts behandelden de binnenkant van de agent: reasoning loops, memory architecture, tool use, security. Deze gaat over de buitenkant: de productieruntime rond langlopende AI-agents.

Production AI-agents waren in 2026 niet langer request handlers maar background workers. Een run kan een paar uur duren. De worker die hem host, misschien niet. Het interessante engineeringswerk verschoof uit de agent naar de runtime eromheen. Het model kiest de volgende stap. De runtime beslist wat er met die stap gebeurt wanneer de worker midden in een call crasht.

TL;DR: Langlopende AI-agents hebben een runtime buiten het model nodig: sessielogs, harness-logica, sandbox-isolatie, checkpoints, traces, policy checks, secrets en kostenlimieten. Queue + worker + checkpoint DB is de default als je de stack zelf beheert; gehoste harnesses passen als de vendorbeperkingen acceptabel zijn. Kies eerst op runlengte, daarna op recovery-semantiek, replay-behoeften, sandbox-isolatie en operationeel eigenaarschap.

Het is een lange post. Dit is wat je krijgt:

De eerste helft loopt door de vijf runtime-primitieven en de failure modes waarvoor elk ervan bedoeld is. De tweede helft vergelijkt elf deployment-vormen — SDK-in-een-app-server, queue + worker, Temporal, Anthropic Managed Agents, Deep Agents Deploy, Cloud Run, Lambda, ECS, Kubernetes Job per sessie, plus nog twee — en eindigt met een beslisgids om er één te kiezen.

Wat verandert er als langlopende agentsessies processen overleven

Een jaar geleden betekende "een agent deployen" dat je een chat-endpoint in een container wikkelde en er een load balancer op richtte. Het werk was niet te onderscheiden van elke andere Python-webservice. Dat was niet langer waar zodra agents urenlang gingen draaien in plaats van seconden.

Het OpenAI Codex-team zette een getal op de nieuwe baseline in hun harness engineering write-up:

"We regularly see single Codex runs work on a single task for upwards of six hours (often while the humans are sleeping)."

Anthropic's engineeringteam formuleerde het structurele probleem net zo helder in Effective harnesses for long-running agents:

"The core challenge of long-running agents is that they must work in discrete sessions, and each new session begins with no memory of what came before."

Neem die zin serieus en de hele runtimestack verandert van vorm. Drie consequenties volgen uit "discrete sessies zonder gedeeld geheugen", en elk daarvan dwingt een specifiek stuk infrastructuur af in het ontwerp.

Als sessies discreet zijn, moet de sessie buiten het proces leven. In-memory state verdwijnt zodra de worker stopt, dus de sessie moet naar een duurzame store worden geschreven die de volgende worker kan lezen. Als een sessie na een crash kan hervatten, moet de duurzame registratie alles bevatten wat tot dan toe is gebeurd, niet alleen het eindantwoord. Daardoor kan de volgende worker op het juiste punt verdergaan in plaats van de run vanaf nul af te spelen. Als het model zijn context window vult voordat het werk klaar is, moet iets de voortgang checkpointen, de huidige sessie afbreken en een verse starten die het checkpoint laadt in plaats van de volledige historie af te spelen. In Anthropic's bewoording wordt de harness "cattle": wegwerpbaar, herstartbaar, identieke instanties. De state leeft ergens anders.

Het model beslist wat het hierna doet. De runtime beslist of die stap is toegestaan, waar die wordt uitgevoerd, hoe die wordt vastgelegd en hoe de run hervat na een crash. De rest van deze post gaat over die runtime.

De vijf runtime-primitieven die elke langlopende AI-agent nodig heeft

Anthropic's Scaling Managed Agents-write-up gaf de industrie een bruikbare woordenschat, en het grootste deel van het veld is daarop geconvergeerd. Vijf componenten doen het meeste runtimewerk. De harness stuurt de agent stap voor stap vooruit; de sessie legt vast wat hij deed; de sandbox is waar commando's draaien; het checkpoint is wat de volgende worker leest bij hervatten; de trace is wat je dagen later leest wanneer je moet begrijpen wat er misging. Elke component is vervangbaar zolang de verantwoordelijkheid intact blijft.

De vijf runtime-primitieven

Sessie. Een append-only log van alles wat is gebeurd: modelcalls, toolcalls, resultaten, fouten, approvals. Recovery is wake(sessionId) → getSession(id) → resume from last event. In LangGraph is dit een thread_id plus een Postgres checkpointer (zie LangGraph persistence). De OpenAI Agents SDK levert tien ingebouwde session backends mee, waaronder SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession en EncryptedSession (zie de Sessions docs).

Harness. De orchestration loop. Die roept het model aan, parseert toolcalls, voert die uit, schrijft resultaten terug in de sessie en past retry-regels toe. Anthropic zegt het zonder omwegen:

"every component in a harness encodes an assumption about what the model can't do on its own."

OpenAI's Codex-team noemt deze discipline harness engineering: software schrijven vereist nog steeds discipline, maar meer daarvan gaat nu naar de scaffolding dan naar de code zelf. LangGraph's CompiledStateGraph, Deep Agents' create_deep_agent, en Claude Code zelf zijn in deze zin allemaal harnesses.

Sandbox. De geïsoleerde uitvoeromgeving waar commando's daadwerkelijk draaien. De pagina over sandbox concepts van de OpenAI Agents SDK trekt de grens scherp:

"The outer runtime still owns approvals, tracing, handoffs, and resume bookkeeping. The sandbox session owns commands, file changes, and environment isolation."

Sandboxes verschillen in hoe lang ze leven en wat ze tussen runs onthouden. De simpelste vorm is fresh ephemeral: er één opstarten voor één taak, vernietigen zodra de taak klaar is, en bij elke run de cold-startkosten betalen. Persistent paused-sandboxes blijven tussen runs in gepauzeerde toestand bestaan; het filesystem en een geheugensnapshot blijven behouden, zodat de volgende resume sub-seconde duurt in plaats van een volledige boot. Snapshot or fork gaat nog een stap verder: elke taak vertakt een copy-on-write image van een parent waarin dependencies al geïnstalleerd zijn en caches al warm zijn, zodat het dure setupwerk één keer gebeurt en N taken het basisimage delen. Per-worktree-sandboxes geven elke taak zijn eigen workspace en zijn eigen observability-stack: gescheiden logs, metrics en traces. Zo kun je één run van een agent debuggen zonder dat die in een andere lekt. Concrete cijfers voor cold start en persistentie per provider staan in de tabel verderop in deze sectie.

Checkpoint. Hervatbare state. LangGraph's PostgresSaver schrijft een StateSnapshot op elke super-step-boundary, met writes per taak naar checkpoint_writes zodat succesvolle node-outputs niet opnieuw worden berekend als een sibling faalt. De snapshot is een JSON-serializable dict (v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) gedocumenteerd op de langgraph-checkpoint-postgres-pagina op PyPI en in de LangGraph checkpoints reference.

Trace. Het replay- en debug-oppervlak. Elke modelcall, toolcall en sub-agentstap wordt een span met timing, inputs, outputs, tokenaantallen en kosten. Wanneer een run van zes uur faalt, is de trace wat je leest om uit te zoeken wat er misging. De terminaloutput van de run is dan allang weg. OpenTelemetry's GenAI semantic conventions standaardiseren de attribuutnamen (welk model, welke provider, hoeveel tokens, welk gesprek, welke workflow), zodat dezelfde trace netjes rendert in Tempo, Jaeger, Honeycomb of LangSmith zonder opnieuw te instrumenteren.

Policy en secrets zijn aparte runtimegrenzen

Twee grenzen lopen door alle vijf primitieve componenten heen en zijn makkelijker als aparte concerns te zien. Het zijn de runtimeversies van het security-argument uit Deel 4.

Policy engine

Een permissiecheck draait vóór elke toolcall en beslist of die wordt doorgelaten. Twee patronen zijn gebruikelijk in productie. Deep Agents laat elke subagent declareren welke file paths die mag lezen of schrijven, en de middleware blokkeert alles buiten die declaratie. Anthropic Managed Agents routeert elke toolcall via een MCP-proxy, zodat de proxy permissies afdwingt in plaats van de agentcode. Wanneer een gevoelige call menselijke approval nodig heeft, pauzeren LangGraph's interrupt() en de approval hook van Deep Agents de graph tot een persoon ja zegt.

Secret broker

Het model zou geen langlevende secrets mogen zien, en de sandbox meestal ook niet. Het Managed Agents-patroon is degene om te kopiëren:

"For Git, we use each repository's access token to clone the repo during sandbox initialization and wire it into the local git remote. Git push and pull work from inside the sandbox without the agent ever handling the token itself. For custom tools, we support MCP and store OAuth tokens in a secure vault. Claude calls MCP tools via a dedicated proxy; this proxy takes in a token associated with the session. … The harness is never made aware of any credentials."

In de market-analyst-agent-referentiestack leest de MCP-sidecar OAuth-tokens uit een Docker secret (in productie HashiCorp Vault) en stelt alleen het tool-oppervlak bloot aan de LangGraph-worker. De worker ziet de token nooit. git push werkt. cat ~/.ssh/id_rsa werkt niet.

Een praktische sanity check voor je eigen stack: schrijf elke component op die je draait en welke van de vijf primitieve componenten die implementeert. Postgres kan sessie en checkpoint afdekken. De workercontainer is de harness. Een hosted-sandboxdienst zoals Daytona, Modal of E2B is de sandbox. Tempo of LangSmith is de trace. Als je ziet dat twee primitieve componenten in hetzelfde proces leven, haalt één crash ze allebei neer. Als twee componenten één credential delen, haalt één lek ze allebei neer. Beide introduceer je makkelijk per ongeluk als je snel beweegt: een worker die ook traces schrijft, een sidecar-token die ook de checkpoint-DB ontsluit.

Failure modes van AI-agentruntimes in productie

De runtime bestaat voor de dingen die het model niet zelfstandig kan doen: retries beheren, onthouden wat het drie uur geleden deed, het filesystem van de ene run isoleren van dat van een andere, zichzelf stoppen voordat het budget op is. Inmiddels hebben we zeven onderdelen benoemd: harness, session log, sandbox, checkpointer, tracer, policy engine, secret broker. Zodra een enkele agentrun ongeveer 30 minuten wall time overschrijdt, duikt een herkenbare set failures op. De meeste hebben niets met reasoning-kwaliteit te maken; het zijn problemen met state, retries, sandboxes en budgetten.

De failures vallen in vier losse groepen:

  • Outputkwaliteitsfouten: de agent verklaart zichzelf klaar voordat het werk echt af is, vergeet wat hij deed na een context-window-reset, of vertrouwt op zijn eigen zelfevaluatie en levert kapotte output.
  • Kostenbeheersingsfouten: de agent blijft hangen in een retry-loop, of verstookt een token- of toolcallbudget zonder iets bruikbaars op te leveren.
  • State- en crashfouten: workspaces driften omdat de ene run bestanden aanraakt die bij een andere horen, toolcalls vuren meer dan één keer af omdat retries ze opnieuw afspelen, of werk gaat verloren wanneer een worker tussen events door crasht.
  • Context-window-fouten: het model vat samen en stopt te vroeg omdat het denkt dat het ruimte tekortkomt, zelfs als het window nog headroom heeft.

De tabel hieronder koppelt elke failure aan het mitigatiepatroon, de runtime hook waar de mitigatie leeft, en of de mitigatie nog nodig is voor de huidige modelgeneratie. Sommige zijn niet langer nodig. Hoe ouder je harness is, hoe meer verouderde mitigaties die waarschijnlijk bevat.

Failure modes en hun mitigaties

Failure mode Mitigatie Nog nodig? Runtime hook
Premature completion: agent verklaart te vroeg succes Generator/evaluator-splitsing: een evaluator met verse context leest files (niet de chat) en stemt "done" of "not done." Default-FAIL op elke acceptatiecheck. Ja; Anthropic's eigen cwc-long-running-agents quick-start levert nog steeds een evaluator-subagent mee. Sub-agent zonder Write/Edit-tools en met eigen context window
Feature-amnesie over context windows heen Initializer agent schrijft claude-progress.txt, feature-list.json, init.sh. Coding agent leest die bij elke cold boot. Ja; compaction alleen dicht het gat niet. Boot hook vóór de eerste modelcall van elke sessie
Gedupliceerd werk na sessiereset Append-only event log plus een gestructureerd handoff-bestand. Elke nieuwe sessie start met pwd → read PROGRESS.md → review tests. Ja LangGraph PostgresSaver checkpoint plus progress.md artifact
Context anxiety: model vat samen en stopt te vroeg (a) Schakel de 1M-token-beta in maar cap effectief gebruik op 200k (Cognition's Sonnet 4.5 fix). (b) Breek de sessie af en bouw opnieuw op vanuit een handoff. Nee op Opus 4.5; Anthropic meldt dat "the behavior was gone" en dat de resets "had become dead weight." Ja op Sonnet 4.5 en GPT-5/Codex. Outer driver cap't sessielengte, start de volgende en hervat vanaf checkpoint
Zelfevaluatie-optimisme: model markeert werk als goed Aparte evaluator plus Playwright/MCP-grounding in de echte DOM, niet in screenshots. Anthropic's harness design-frontendrubric straft "AI-style" defaults af. Ja Evaluator draait in een aparte sandboxsessie zonder write-tools
Vastgelopen loops en retrystormen Iteratiecap per beurt, exponentiële backoff, circuit breaker op tool error rate. Hard budget op toolcalls. Ja Decorator op de tool-execution-node; RetryPolicy op Temporal Activities (zie Temporal OpenAI Agents SDK contrib)
Workspace drift: agent bewerkt ongerelateerde files Git commits als checkpoints, file-permission-middleware, workspace-mount per sessie. Deep Agents-middleware laat je path read/write declareren. Ja LangGraph file-permission-middleware of Daytona/Runloop per-task fork
Ontspoorde token- of toolkosten Per-run tokenbudget, per-tool budget, kill switch gekoppeld aan een Prometheus-counter. Ja; een Opus-sessie van 24 uur met slechte budgettering kan in een middag een week API-budget verbranden (Addy Osmani over long-running agents). Cost-attribution span attributes plus Alertmanager-regel
Niet-idempotente toolcalls Idempotency key per toolcall. In durable workflows kunnen retries dezelfde toolcall meer dan één keer afvuren, dus een deduplicatiesleutel blokkeert het duplicaat. Ja Temporal Activity met start_to_close_timeout en idempotency key
Verloren werk na proces- of sandboxcrash Durable session log buiten het proces; checkpoint na elke super-step. wake(sessionId) → getSession(id) → resume. Ja PostgresSaver op elke super-step, of verpak als een Temporal Workflow

Twee ideeën keren in elke rij terug. Anthropic over veroudering van harnesses in Harness design for long-running application development:

"Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing, both because they may be incorrect, and because they can quickly go stale as models improve."

Vercel over het verwante probleem van te veel tools die te veel aannames coderen, in We removed 80% of our agent's tools:

"We deleted most of it and stripped the agent down to a single tool: execute arbitrary bash commands. We call this a file system agent."

Het gerapporteerde resultaat van Vercel op een representatieve query: het success rate ging van 80% naar 100%, en het worst-case scenario daalde van 724 s / 100 stappen / 145,463 tokens (gefaald) naar 141 s / 19 stappen / 67,483 tokens (geslaagd). De les is niet "verwijder je tools." Het is dat elke primitieve component in je runtime, inclusief het tool-oppervlak, een halfwaardetijd heeft. Test de aanname opnieuw wanneer het model verandert.

Cognition zag hetzelfde bewegende doel bij sessielengte met Sonnet 4.5. In Rebuilding Devin for Claude Sonnet 4.5 beschrijven ze een model dat proactief SUMMARY.md / CHANGELOG.md schrijft zodra het contextuitputting voelt aankomen, maar onderschat hoeveel tokens het nog over heeft. Hun fix is de 1M-token-beta inschakelen en het gebruik op 200k cappen, zodat het model blijft geloven dat het headroom heeft. Ook die mitigatie wordt uiteindelijk dood gewicht.

Het harness-team van OpenAI heeft de discipline in één zin samengevat: "Humans steer. Agents execute." Als iets faalt, is de vraag niet "probeer harder." Het is "welke capability ontbreekt, en hoe maken we die zowel leesbaar als afdwingbaar voor de agent?"

De lifecycle van een gezonde run

Een goed gedragende run is saai. Het is een keten van kleine herstelbare stappen, waarbij elke stap zijn resultaat naar duurzame opslag schrijft vóór de volgende begint, in plaats van één gigantisch request dat end-to-end moet slagen. Een run op die manier opsplitsen in stappen laat hem crashes overleven: als iets faalt, gaat alleen de stap verloren die op dat moment in flight was, en de volgende worker hervat vanaf de laatste voltooide stap in plaats van opnieuw te beginnen.

De lifecycle van een gedeployde agentrun

  1. Boot vanuit een verse sessie of een hervatte sessie. Bij resume mount je de workspace in de laatst bekende staat, lees je eventuele voortgangsbestanden die de vorige poging heeft achtergelaten (PROGRESS.md, feature-list.json), en laad je het laatste checkpoint uit de database. Hier geeft de harness de agent alles wat de vorige worker in geheugen had voordat die stierf.
  2. Plan vóórdat toolcalls afgaan. Schrijf op hoe "done" eruitziet, hoeveel de run mag uitgeven, welke tools de agent mag aanroepen, en wat de run vroegtijdig moet stoppen. Deze planwaarden worden runtimechecks; zonder die checks heeft de uitvoering niets om tegenwicht aan te geven.
  3. Voer één toolcall tegelijk uit. De policylaag beslist of de call is toegestaan. De harness voert hem uit, legt het resultaat vast en schrijft één event in het session log. Eén stap, één event. Een crash tussen events in is herstelbaar omdat het log, niet het geheugen van de worker, de source of truth is.
  4. Checkpoint op super-step-boundaries, of na elk event in een simpelere harness. Persisteer de graph state, de workspace diff en referenties naar eventuele artifacts die zijn geproduceerd. Dit checkpoint is wat stap 1 leest bij de volgende resume. Als het checkpoint ontbreekt of stale is, degradeert recovery naar het volledig replayen van het session log vanaf nul, en dat is veel trager.
  5. Evalueer tegen de artifacts wanneer de agent denkt dat hij klaar is: tests, een reviewer met verse context, schema-validatie, browserchecks. Als de check slaagt, eindigt de run succesvol. Als die faalt, hervat de run vanaf het laatste schone checkpoint met de foutmelding aan de context toegevoegd en probeert opnieuw.

Er zit geen stap in die lijst die vereist dat de agent iets onthoudt tussen runs. De state leeft in de sessie en het checkpoint, en de agent leest die bij elke resume opnieuw in.

Tools met side effects hebben idempotency nodig. Elke tool met side effects heeft een idempotency key nodig die is afgeleid van de session ID en tool-call ID, opgeslagen vóór de side effect afgaat. 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). At-least-once execution is de default in queues en workflow engines. Als het herhalen van een toolcall echte schade kan veroorzaken, is de tool niet klaar voor agents.

Evaluatie moet buiten de producerende context draaien. Dezelfde context die het antwoord produceerde kan niet betrouwbaar beoordelen of het antwoord correct is. Een verse evaluator leest files en artifacts, draait tests, lints, browserchecks of schema-validatie, en retourneert pass, fail of needs_human. Voor codeagents is dit nog een modelsessie met read-only tools. Voor data- en reportagents is het een deterministische validator plus een reviewermodel.

Elf AI-agentdeploymentpatronen en wat de keuze ertussen bepaalt

Zodra de vijf primitieve componenten een naam hebben, is de vraag welke deployment-vorm ze draait. Met "vorm" bedoel ik een rangschikking van die primitieve componenten: waar de harness leeft, waar state persisteert en welk soort sandbox het werk draait. Het is niet alleen een keuze voor één vendor. De grafiek hieronder laat zien waar elke vorm zich comfortabel voelt op de as van runlengte. De tekst erna loopt door wat de keuze bepaalt.

Als je maar één van de elf leest, lees dan vorm 2: queue + worker + checkpoint DB. Dat is de default die ik voor de meeste teams aanraad, de vorm die de referentierepo gebruikt, en het skelet waarop de meeste andere vormen variëren: queue → worker → durable state, waarbij de sandboxbron, harness-eigenaar of state engine is omgewisseld. Eerst vorm 2 lezen maakt de rest sneller te scannen.

Deployment-vormen en hun sweet spots voor runlengte

De grafiek vergelijkt vormen op runlengte. De matrix hieronder vergelijkt ze op eigenaarschap: waar elk van de vijf primitieve componenten fysiek leeft. Groene cellen zijn waar de vorm de primitieve component levert; grijs is waar je hem zelf inbedt.

Waar elke primitieve component leeft in elke deployment-vorm

1. SDK binnen een app-server (synchroon, request-scoped)

De oorspronkelijke vorm. De agent-SDK draait binnen een request handler. Goed voor taken onder de 30 seconden, demo's en interne tools. Slecht voor alles waarvan een HTTP-client zou kunnen disconnecten. Cloud Run's HTTP-timeout gaat maximaal tot 60 minuten, en elke web-tier panic beëindigt de run. De SDK is de harness, het webproces fungeert ook als sandbox, en state leeft meestal in procesgeheugen tenzij je die expliciet elders heen schrijft. Gebruik dit niet voor werk van meerdere uren.

2. Queue + worker + checkpoint DB

De default die ik voor de meeste teams aanraad, en de productievorm gebruikt in market-analyst-agent: een Python-worker met een PostgreSQL-checkpointer, Redis Streams (of RabbitMQ) voor de inkomende queue, en een MCP-sidecar voor tools. Goed voor runs van 10 minuten tot meerdere uren met idempotente stappen. De lokale runner kan de queue omzeilen voor synchrone development, maar de queue is onderdeel van de productievorm zodra je async indiening en backpressure nodig hebt.

De app accepteert een request, maakt een session row aan, pusht een job en retourneert een run ID. De worker trekt de job, draait de harness, schrijft checkpoints, streamt status en slaat artifacts op terwijl hij draait. Postgres overleeft, workers zijn cattle, en queuediepte geeft je backpressure. Spot/Preemptible compute werkt zolang de checkpointer klaar is met schrijven naar disk vóórdat die success meldt.

In deze vorm is de worker de harness. De workercontainer plus een workspace-mount per thread is de sandbox. Postgres beheert session- en checkpoint-state. Traces gaan via OpenTelemetry naar welke observability-stack je ook draait.

3. Durable workflow engine (Temporal-stijl)

Agent-orchestrationcode draait binnen een Temporal Workflow; modelcalls en toolcalls draaien als Activities. Workflow-state leeft in een event-history-log ondersteund door Cassandra, MySQL of Postgres, zodat state netjes replayt over deploys heen. De public-preview Temporal × OpenAI Agents SDK integration levert een OpenAIAgentsPlugin en een helper activity_as_tool mee, en de agentic sandboxes write-up beschrijft hoe je een draaiende agent halverwege een gesprek naar een andere sandboxprovider fork't. Idle workflows verbruiken nul compute. De kanttekeningen zijn reëel: streaming- en voice-agents worden niet ondersteund in de huidige integratie, en LocalShellTool en ComputerTool zijn uitgeschakeld omdat ze niet passen in een distributed model.

Gebruik deze vorm wanneer de run echte wachtpunten heeft: menselijke approvals, externe callbacks, lange sleeps, retries met business rules, deploy-windows. Een menselijke approval wordt een durable sleep die geen compute verbruikt, geen polling loop die dat wel doet.

De Workflow-code is de harness. De sandbox leeft meestal buiten Temporal en wordt vanuit Activities aangeroepen. Session- en checkpoint-state vallen samen in Temporal's event-history-log, terwijl trace-zichtbaarheid uit Temporal UI plus OpenTelemetry-spans op elke Activity komt.

4. Sandboxprovider per sessie

Een nieuwere vorm. Elke agentrun krijgt zijn eigen microVM of container van een sandbox-as-a-service-provider. De harness leeft ergens duurzaams; de sandbox is de wegwerpbare uitvoeromgeving.

Provider Isolatie Max sessie Concurrency Persistentie Cold start
E2B Firecracker microVM 1 h Hobby / 24 h Pro 20 / 100 (tot 1.100 add-on) Pause/resume, ~4 s/GiB pause, ~1 s resume (public beta) ~150 ms p50
Vercel Sandbox Firecracker microVM 45 min Hobby / 5 h Pro/Ent 10 / 2.000 Wegwerpbaar n/a
Daytona Docker (optioneel Kata) configureerbare auto-stop/archive tier-based Stop → Archive → Delete; fork ondersteund ~90 ms (sommige configs 27 ms)
Modal Sandboxes gVisor typische lifecycle van 1–15 min hoog Volumes voor persistentie; geheugensnapshot in preview "about one second" volgens Modal docs
Runloop Devboxes microVM (custom hypervisor) suspend/resume; snapshot+branch "more than 30,000 concurrent instances" volgens de AWS Marketplace-listing Snapshot + branch vanaf disk state sub-1 s

Bronnen: de E2B vs Daytona comparison, Daytona's eigen sandboxes documentation en fork/snapshot changelog, Modal's sandboxes guide en cold-start guide, de Runloop AWS Marketplace listing, en Vercel Sandbox pricing. Daytona's docs voegen een nuttige noot toe over fork-semantiek: "the new sandbox is fully independent … Daytona tracks the parent-child relationship in a fork tree." Elke geforkte sandbox houdt een vastgelegde link terug naar de basis waarvan hij is afgetakt, zodat je de lineage van elke afgeleide sandbox kunt opvragen. OpenAI's Codex-harness gebruikt de per-worktree-variant: "Codex works on a fully isolated version of that app, including its logs and metrics, which get torn down once that task is complete."

Grijp naar deze vorm wanneer de agent niet-vertrouwde code, browserautomatisering, tests of package installs draait. De trade-off is kosten en provider coupling, beide hoger dan bij gedeelde workers.

De provider beheert de sandbox en verder niets. Harness, sessie, checkpoint en trace blijven aan jouw kant, meestal bekabeld als de queue + worker-vorm uit #2.

5. Anthropic Managed Agents (hosted harness)

Gelanceerd in public beta op 8 april 2026, achter de managed-agents-2026-04-01 beta-header. Claude factureert Managed Agents tegen standaard tokenrates plus $0.08 per session-hour. Billing is op milliseconden nauwkeurig en geldt alleen zolang de sessiestatus "running" is. Idle time is gratis; session runtime "replaces the Code Execution container-hour billing model when using Claude Managed Agents." Je krijgt een hosted session, harness, sandbox en vault-backed MCP-proxy. De brain/hands-splitsing is waar wake(sessionId) voor betaalt: de harness kan op een nieuwe worker opnieuw geïnitialiseerd worden zonder state te verliezen. Let goed op de kostenvorm; een runaway retry-loop op session-hour billing tikt sneller aan dan billing per token.

Lees de caveats. De Batch API-korting geldt niet ("Sessions are stateful and interactive. There is no batch mode."). Managed Agents is niet beschikbaar via AWS Bedrock of Google Vertex AI. Multi-agentcoördinatie en zelfevaluatie zitten nog in research preview. Lock-in is hoog: je ruilt harness-vrijheid in voor het niet zelf draaien van de loop.

Anthropic host alle vijf primitieve componenten: sessie, harness, sandbox, checkpoint en trace. Je geeft de runtime uit handen en krijgt de outputs terug.

6. LangChain Deep Agents Deploy (managed open harness)

deepagents deploy verpakt een deepagents.toml in een LangSmith Deployment met durable execution, memory, multi-tenancy, human-in-the-loop, observability, sandboxed code execution en scheduled runs. Cloud-, hybrid- en self-hosted-deploymentmodi worden ondersteund. Sandboxproviders (LangSmith Sandboxes, Daytona, Modal, Runloop of custom) zijn wisselbaar via één configwaarde. State leeft in een virtueel filesystem met pluggable backends; memory is scoped naar user, assistant of beide. Lock-in is lager dan bij Managed Agents: de harness heeft een MIT-licentie, instructies gebruiken de open standaard AGENTS.md en agents worden blootgesteld via MCP, A2A en Agent Protocol. Zie LangChain's runtime-behind-production-deep-agents-write-up.

Alle vijf primitieve componenten zijn standaard hosted, maar elk is config-wisselbaar. De sandbox zit achter één configwaarde. Session en checkpoint leven op een virtueel filesystem met pluggable backends. Trace gaat naar LangSmith.

7. Google Cloud Run service of job

Cloud Run heeft twee verschillende runtimemodi, en welke past hangt af van hoe de agent wordt aangeroepen. Services zijn aan HTTP gebonden en schalen tussen requests terug naar nul; de harness draait als request handler die terugkeert wanneer de run klaar is. Jobs draaien tot completion zonder HTTP-entrypoint; de harness draait als one-shot worker die stopt wanneer de taak klaar is. Beide kunnen de harness hosten, maar geen van beide houdt state over runs heen vast. Sessies en checkpoints moeten in Postgres, Spanner of een vergelijkbare externe store leven.

De harde limieten verschillen sterk tussen de twee. Cloud Run service request timeout: default 300 s, max 3.600 s (60 min). WebSockets hebben dezelfde timeout. Cloud Run jobs: default 10 min per taak, max 168 h (7 dagen); voor taken die GPU's gebruiken max 1 uur. Services schalen naar nul tenzij je always-on CPU inschakelt; jobs hebben geen HTTP en autoscalen niet.

Gebruik een service voor synchrone runs tot 60 minuten. Gebruik een job voor langer one-shot of async werk. Cloud Run Jobs kunnen een taak dagen in leven houden, maar ze geven je geen durable replay over deploys, versiewijzigingen of workervervanging heen. Boven 7 dagen: gebruik geen Cloud Run.

Cloud Run host de harness. Session, checkpoint, sandbox en trace zijn externe diensten die je inbedt, typisch Postgres of Spanner voor session/checkpoint, de container zelf als sandbox, en Cloud Logging plus OpenTelemetry voor trace.

8. AWS Lambda (waarom het het verkeerde gereedschap is)

Lambda's maximale function timeout is 900 s (15 minuten), hard. API Gateway voegt daar nog een aparte cap van 29 s bovenop toe. Een agent-harness waarvan de minimale nuttige run "minuten tot uren" is, kan niet op Lambda overleven zonder een externe state store en een re-invocation-strategie die in feite de queue + worker-vorm vanaf nul herbouwt. Gebruik Lambda voor individuele toolcalls, zoals file fetches of S3-uploads, aangeroepen door een langer draaiende orchestrator. Zet de orchestrator daar niet neer.

Hoogstens houdt Lambda één toolcall binnen zijn limiet van 15 minuten. Harness, sessie, checkpoint, sandbox en trace moeten allemaal ergens anders leven.

9. AWS ECS / Fargate task per run

Geen gedocumenteerde harde cap op task-runtime (anders dan Lambda). Volgens Fargate throttling quotas zijn launches rate-limited: een burst van 100, aangevuld met 20 per seconde, waarbij on-demand en spot op aparte budgetten van 20/sec worden bijgehouden. ECS service quotas: services met AWS Cloud Map service discovery hebben een limiet van 1.000 tasks per service; het theoretische plafond is 5.000 EC2-instances per cluster. Fargate vereist mode awsvpc, zodat elke task zijn eigen netwerkinterface en private IP krijgt, wat de juiste vorm is wanneer je VPC-interne toegang tot gevoelige databronnen nodig hebt. Fargate Spot is beschikbaar; budgetteer voor interrupties. Duurzaamheid is jouw verantwoordelijkheid: er zit geen Temporal-achtige replay ingebouwd.

Fargate host de harness en geeft elke run zijn eigen sandbox: één task per run. Session, checkpoint en trace gaan naar externe diensten. RDS of DynamoDB plus CloudWatch/X-Ray zijn de gebruikelijke keuzes.

10. Kubernetes Job of namespace per sessie

Goed als je al Kubernetes draait en sandbox-per-sessie wilt met clusterbrede controls. Slecht als je sub-seconde startup nodig hebt, omdat het pullen van het containerimage en het initialiseren van de pod op cold start te lang duurt. Het patroon is één Job per agentrun, met activeDeadlineSeconds, een PersistentVolumeClaim voor de workspace en een sidecar voor de MCP-server. Crash recovery moet je zelf bouwen. Kubernetes adopteren alleen om agents te hosten is duur in configuratie-overhead en operationele last. Alleen de moeite waard als je om andere redenen al K8s draait.

K8s host de harness en de sandbox, meestal als één Job per run en soms met een dedicated namespace voor sterkere isolatie. Session en checkpoint leven in een externe DB of op een PersistentVolumeClaim. Trace stroomt naar welke in-cluster observability-stack je ook al draait.

11. Lokale Docker Compose (alleen dev)

De referentie voor de volgende sectie. Het punt van deze vorm is dat hij de productietopologie één-op-één spiegelt (dezelfde primitieve componenten, dezelfde netwerkvorm) terwijl alles op één machine draait. Lees de lijst "niet production-safe" aan het eind van de volgende sectie voordat je iets shipt dat hierop lijkt.

Compose spiegelt vorm #2 op één host. Postgres houdt session en checkpoint vast. De workercontainer is de harness. De workspace-mount is de gedeelde sandbox. De optionele OpenTelemetry-stack is de trace.

Referentiestack: Docker Compose

De referentietopologie, gebruikt in slavadubrov/market-analyst-agent, is een LangGraph-worker, een Postgres-checkpointer, Qdrant voor retrieval, een MCP-sidecar, een Redis-queue voor async productieachtig draaien, en een optionele observability-stack van Prometheus / Grafana / Loki / Tempo / OTel. In lokale compose is Redis alleen optioneel omdat de synchrone runner de worker direct kan aanroepen. docker compose up brengt de hele topologie lokaal omhoog.

De referentie-Docker-Compose-topologie

Het ene stuk dat het waard is om inline te tonen is de canonieke LangGraph-wiring. Het is het kleinste concrete voorbeeld van de checkpoint-primitieve component:

from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://agent:${POSTGRES_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 de run overleeft

Korte request handlers zijn makkelijk te debuggen: als iets faalt, lees je de response en de live log. Langlopende agents hebben die luxe niet. Tegen de tijd dat een run van zes uur faalt, vond het interessante event vijf uur geleden plaats, is de live terminaloutput weg en is de worker die die produceerde vervangen. Niemand gaat de run uit het geheugen reconstrueren. Dus debug je vanuit duurzame artifacts die zijn weggeschreven terwijl de run nog leefde.

Productiestacks dekken meestal vier soorten artifacts af, in twee groepen. Twee daarvan lees je na afloop van de run, voor postmortems en replay: een bevraagbaar event log van elke stap, en OpenTelemetry-traces van waar tijd en tokens heen gingen. Twee ervan lees je tijdens de run, om hem live te volgen: een live tail van wat de agent in de workspace produceert, en een observability-stack per worktree die de agent zelf kan bevragen terwijl hij nog draait.

Structured event log (lezen na de run)

Elke modelcall, toolcall, resultaat, fout en approval weggeschreven naar duurzame storage, gesleuteld op session ID en timestamp. Zodra de run eindigt, query je die zoals een normale databasetabel. Addy Osmani legt de lat helder in Long-running Agents: "If you can't reconstruct what the agent did in the last 24 hours from durable storage, what you have is a long-running shell script that happens to call an LLM, not a long-running agent."

OpenTelemetry GenAI-traces (lezen na de run)

Hetzelfde soort stap-voor-stapdata, maar uitgezonden als spans met de standaardattributen uit de gen_ai.* semantic conventions: modelnaam, provider, aantallen input- en outputtokens, conversation ID, workflow name (Development status vanaf v1.36.0). Provider-specifieke velden leven in subnamespaces (anthropic.*, openai.*) gesleuteld op gen_ai.provider.name. De reden om de standaard te gebruiken is portability: dezelfde trace rendert netjes in Tempo, Jaeger, Honeycomb of LangSmith zonder de code telkens opnieuw te instrumenteren wanneer je van backend wisselt.

Tool-call-tijdlijn plus workspace-diffs (lezen tijdens de run)

De snelste manier om te weten wat een agent nu doet is volgen wat hij in de workspace produceert, niet door een session log te greppen. Anthropic's Harness Primitives for Long-Running Claude Agents quick-start levert hiervoor twee hooks: watch -n 5 'git log --oneline -8' toont de laatste commits die de agent heeft gemaakt, en watch -n 5 'find screenshots -name "*.png" | tail -5' toont de laatste screenshots die hij heeft genomen. Twee terminalvensters die elke vijf seconden verversen zijn genoeg om te zien of een run echt vooruitgaat of rondjes draait.

Ephemeral stack per worktree (gelezen door de agent zelf, tijdens de run)

Volgens OpenAI's harness post: "Logs, metrics, and traces are exposed to Codex via a local observability stack that's ephemeral for any given worktree." Elke agent-worktree krijgt zijn eigen kortlevende Loki + Prometheus + Tempo, gescope'd op alleen die run. De agent bevraagt die terwijl hij werkt. Dat is wat een prompt als "no span in these four user journeys exceeds two seconds" iets maakt dat de agent direct kan verifiëren, in plaats van iets waar hij naar moet gissen.

(De evaluator met verse context uit de failure-modes-tabel leest deze artifacts om "done" te beslissen. Die hoort bij evaluatie, niet bij observability; zie § healthy run lifecycle. Hij hangt van elk oppervlak hierboven af.)

Een minimale self-hosted observability-stack

Voor iets als market-analyst-agent:

  1. OpenTelemetry Collector met de GenAI-processor en een attribute filter op gen_ai.*.
  2. Tempo (of Jaeger) voor traces, gesleuteld op gen_ai.conversation.id / thread_id.
  3. Loki voor structured event-log entries.
  4. Prometheus voor gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (zie de GenAI metrics conventions).
  5. Grafana-dashboards gesleuteld op gen_ai.agent.name en gen_ai.request.model.

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

  • LangSmith: native LangGraph-integratie; ook het deploymenttarget voor Deep Agents Deploy.
  • Braintrust: sterkste fit als eval-first-regressiesuites de prioriteit zijn.
  • Arize Phoenix: OSS, OTLP-native, combineert met OpenInference-instrumentatie.
  • OpenAI's tracing-dashboard: automatisch wanneer je de OpenAI Agents SDK of de Temporal-integratie daarvan gebruikt.
  • Anthropic's Claude-tracing: voor sessies die binnen Managed Agents draaien.

Instrumenteer de LangGraph-node

# 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)

Attribuutnamen letterlijk overgenomen uit de OpenTelemetry GenAI semantic conventions registry.

Drie queries die je echt nodig hebt

# 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-bundle-patroon

Wanneer een run faalt, moet de worker /workspaces/${THREAD_ID}/_debug/ droppen met de artifacts waar je in een postmortem om zou vragen:

  • session.jsonl: volledige event-log-dump uit de PostgresSaver (checkpointer.list({"thread_id": ...})).
  • last_state.json: StateSnapshot.values uit de laatste succesvolle super-step.
  • trace.json: OTLP-geëxporteerde spans voor de run.
  • tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
  • workspace.tar.zst: de workspace-directory plus git diff tegen de initializer-commit.
  • screenshots/*.png: wat de agent zag.
  • PROGRESS.md, feature-list.json, en alle andere door de agent geschreven voortgangsbestanden.
  • env.txt: image tags, modelversie, harness-commit-SHA.

Deze bundle is wat een mens (of een andere agent) nodig heeft om uit te zoeken wat er is gebeurd. Zonder die bundle is elke gefaalde run giswerk. "De agent liep vast" is vaag. Een bruikbaar failurerapport ziet er meer zo uit: session s_123 besteedde 71 procent van de tokens in een retry-loop van drie commando's nadat npm install was gefaald.

De juiste vorm kiezen: een beslisgids

Het grootste deel van de vergelijking hierboven valt terug op een handvol beslissingen.

Begin met runlengte

Gebruik runlengte als eerste filter:

  • Onder 30 seconden, idempotent: request-lifecycle SDK in een app-server.
  • 30 s tot 60 min, geen crash recovery nodig: queue + worker + checkpoint DB.
  • 60 min tot 24 h: dezelfde queue + worker, of een Cloud Run Job voor one-shot werk. Gebruik een durable workflow engine als je ook versioning en replay nodig hebt.
  • Meer dan 24 h, moet deploys overleven: durable workflow engine (Temporal-stijl). Cloud Run Jobs kunnen lang werk vasthouden tot hun taaksgrens, maar bieden geen replay-semantiek.
  • Meerdaagse RL-trainingsloops: K8s Job + volume + Temporal.

Zodra runlengte vaststaat, is de rest een platformkeuze.

Platformfit per use case

Platformfit per use case

De matrix is expres dicht: elf vormen over veel workloadtypes in één beeld. Twee patronen kleuren bijna elke lezing ervan.

Deep Agents Deploy is de enige kolom met groen op elke rij. Dat betekent dat het de enige vorm in de line-up is die past bij elk workloadtype dat de matrix volgt: korte runs, runs van meerdere uren, codeagents, research agents, scheduled jobs. Die breedte is het sterkste argument om ervoor te kiezen. De trade-off is maturiteit. De harness is recent geleverd, en er is minder productietrackrecord omheen dan rond oudere alternatieven zoals een queue + worker + Postgres-stack die teams al jaren draaien. Als "past bij elk workloadtype zonder re-platforming" voor jou de doorslaggevende constraint is, accepteer dan de lagere maturiteit en kies Deep Agents Deploy. Anders: geef de voorkeur aan de vorm die je al runt.

Anthropic Managed Agents past óf volledig bij je workload, óf helemaal niet. Het product heeft drie harde constraints: het is alleen hosted, alleen Claude en per sessie onder 24 uur. Als je workload aan alle drie voldoet, bijvoorbeeld een interne coding agent die in bursts van 2-6 uur draait en je liever niet zelf een harness runt, dan is Managed Agents een sterke fit en haalt het een groot stuk platformwerk weg bij je team. Als één constraint faalt omdat je een niet-Claude-model, self-hosted compliance of runs van 48 uur nodig hebt, dan past Managed Agents niet. Geen enkele configwijziging verandert dat.

Het prijsmodel is de moeite waard om te modelleren vóór je commit, niet erna. De session-hour-regel is $0.08/uur boven op standaard tokenkosten. Als een enkele sessie continu zou draaien, is dat ongeveer $58/maand per sessie. Bij 100 sessies die continu draaien is het ongeveer $5.800/maand vóór tokens. Vermenigvuldig $0.08 met je verwachte gelijktijdige session-hours, tel dat op bij je tokenrekening en vergelijk het met wat een queue + worker-stack op je eigen infra kost. Doe dit vóór je commit, want migreren weg van Managed Agents is later een re-platforming-oefening, geen configwijziging.

Hosted harness versus eigen harness

Het onderscheid hier is operationeel, niet wie de harnesscode heeft geschreven. Hosted betekent dat de vendor de harness-loop in zijn infrastructuur draait en jij een API aanroept. Owned betekent dat jij de loop op je eigen infrastructuur draait, zelfs als de harnesscode zelf van een vendor komt.

LangChain verschijnt aan beide kanten van deze grens, en dat maakt mensen in de war. Ze leveren LangGraph, een MIT-gelicentieerde library die je zelf host (owned), en Deep Agents Deploy, een managed product dat standaard een Deep Agents-harness op LangSmith Deployment draait (hosted). Dezelfde company, twee verschillende operationele modellen. Jij kiest het model, niet de vendor. (Deep Agents Deploy heeft ook een self-hosted-modus voor teams die de harness-ergonomie willen zonder het cloudcomponent; die modus valt in de owned-categorie.)

Kies een hosted harness wanneer je geen platformcapaciteit hebt en de vendorconstraints passen. Managed Agents betekent alleen Claude. Deep Agents Deploy in cloudmodus betekent LangSmith in productie. In ruil daarvoor beheert de vendor caching en compaction.

Een eigen harness (LangGraph, Deep Agents Deploy in self-hosted-modus, of een custom harness boven op een SDK) is de juiste keuze wanneer je platformengineers hebt, wanneer je sneller op harness-vorm moet itereren dan een vendor updates uitbrengt, wanneer compliance dataverblijf onder jouw controle duwt, of wanneer multi-modelrouting over providers heen niet onderhandelbaar is. Je betaalt ervoor in pages en operationeel oppervlak.

De meeste teams zouden hosted moeten beginnen, meten wat ze moeten veranderen, en pas naar owned migreren wanneer de hosted constraints pijn gaan doen.

Hosted sandbox versus Docker / Fargate-sandbox

Kies een hosted sandbox wanneer sandbox-creatietijd telt (sub-200 ms), je session pause/resume met memory state nodig hebt, of fork/branch-semantiek nodig hebt. Kies Docker of Fargate wanneer je al voor die compute betaalt, VPC-interne toegang tot gevoelige databronnen nodig hebt, of harde data-residency-constraints hebt.

State stores: Git, DB en object storage naast elkaar

Langlopende agents draaien meestal drie state stores tegelijk, niet één, en elke houdt een ander soort state vast. Git slaat de workspace-state op: de code, documenten en voortgangsbestanden die de agent wijzigt. Elke commit geeft de harness een stabiel recoverypunt en geeft de volgende sessie een compacte historie om te inspecteren. De checkpoint-DB houdt de graph-state van de harness vast: wat is besloten, welke nodes draaiden, welke resultaten terugkwamen en wat hierna moet draaien. Dat is wat de volgende worker halverwege een run laat hervatten. De artifact store houdt de grote eindoutputs vast, zoals PDF's, parquet-files en screenshots. Die horen niet in git of de checkpoint-DB.

Wanneer git als state gebruiken

Gebruik git wanneer de workload code-vormig is (multi-file-edits, refactors, app generation) of document-vormig genoeg dat file history ertoe doet. Het patroon is simpel: maak een run branch aan, maak een initializer-commit, en commit dan op betekenisvolle grenzen: na setup, na elke feature, nadat tests slagen, na de definitieve cleanup. Sla de nieuwste workspace-commit-SHA op naast de checkpoint-row. Bij resume checkt de volgende worker de branch uit, leest git log --oneline -8, inspecteert git status en de laatste diff, en leest dan PROGRESS.md of welk handoff-bestand de vorige sessie ook schreef.

Dat maakt git tot een recovery-oppervlak voor het artifact dat in bewerking is, niet tot een vervanging voor de checkpoint-DB. Git kan twee vragen beantwoorden: wat is veranderd, en welke versie slaagde voor tests. Het kan de harness niet vertellen welke graph-node hierna moet draaien, welke toolcall op approval wacht, of welke retry zijn idempotency key al gebruikte. Anthropic's harness gebruikt initializer-commits plus commits per feature als source of truth voor workspace-recovery; het model leest git log --oneline -8 om state te herstellen. Sla git over wanneer het werkproduct één enkel conversationeel antwoord is. Dan betaalt de overhead zich niet terug.

Wanneer DB-checkpointing gebruiken

Gebruik checkpointing in PostgresSaver-stijl wanneer de agent een graphstructuur heeft met meerdere nodes waarvan de intermediate state ertoe doet (planner → researcher → writer → verifier). De referentierepo gebruikt dit exact om die reden. Zet geen workspace-artifacts op terabyte-schaal in het checkpoint; die horen in object storage.

Wanneer een artifact store (S3 / GCS) gebruiken

Grijp naar object storage in drie situaties. Ten eerste wanneer de output groter is dan een paar honderd KB. Checkpoint-DB's zijn niet gebouwd om grote blobs vast te houden, en proberen ze daar te bewaren maakt zowel de DB als het checkpointformaat pijnlijk. Ten tweede wanneer downstream consumers zoals BI-tools, klanten of andere services URL-adresseerbare artifacts nodig hebben die ze zelf kunnen ophalen zonder via de agent te gaan. Ten derde wanneer de retentietermijn voor run-state en de retentietermijn voor het deliverable uit elkaar lopen. Je kunt het session log na 30 dagen weggooien maar het eindrapport jaren bewaren. Sleutel de layout op (thread_id, checkpoint_id, artifact_name) zodat je altijd kunt reconstrueren welke run welk artifact produceerde.

Wanneer human approval gates toevoegen

Voeg gates toe wanneer de toolcall destructief en onomkeerbaar is (DB-writes, geldbewegingen, externe communicatie versturen), wanneer de toolcall buiten de blast radius van de agent treedt (productiedeploys, klantgerichte publicaties), of wanneer toezichthouders review vereisen. LangGraph's interrupt() en de approval-middleware van Deep Agents hebben ingebouwde ondersteuning voor deze gates. Deel 4 behandelde waarom deze gates een permissieconcern zijn, geen promptconcern.

Een praktische productiechecklist

Voordat een langlopende agent live gaat, beantwoord je deze vragen in concrete infrastructurele termen.

  1. Welke store bezit session events en checkpoints?
  2. Wat gebeurt er als de worker halverwege een toolcall crasht?
  3. Kan de ene run de workspace van een andere corrumperen?
  4. Welke acties vereisen approval?
  5. Kan het model of de sandbox ruwe credentials lezen?
  6. Welke toolcalls kunnen veilig retried worden?
  7. Waar wordt de kostenlimiet per run afgedwongen?
  8. Welke fresh-context-check beslist "done"?
  9. Waar leven definitieve outputs nadat de sandbox weg is?
  10. Kunnen we morgen een gefaalde run uitleggen zonder hem opnieuw te draaien?

Als het antwoord op één van deze vragen "de prompt zegt tegen de agent dat hij voorzichtig moet zijn" is, dan is het systeem nog niet gedeployd. Dan is het nog steeds een demo.

Belangrijkste takeaways

  1. Langlopende agents hebben een runtime nodig, niet alleen een grotere HTTP-timeout. De runtime houdt de sessie, workspace, toolresultaten, checkpoints, traces, budgetten, approvals en credentials buiten het geheugen van het model.
  2. De kerncomponenten zijn sessie, harness, sandbox, checkpoint en trace. Policy checks en secret brokering lopen door al die componenten heen.
  3. De eerste deploymentvraag is runlengte. Een helper van 20 seconden kan in een app-server leven. Een coding- of researchrun van zes uur heeft een queue, worker, durable state en een sandboxstrategie nodig.
  4. Queue + worker + checkpoint DB is de praktische default als je de runtime zelf wilt bezitten. Hosted harnesses zoals Anthropic Managed Agents of Deep Agents Deploy zijn beter wanneer hun vendorconstraints passen en je de loop niet zelf wilt draaien.
  5. Tools met side effects hebben idempotency keys nodig. In queues en workflow engines zijn retries normaal. Zonder deduplicatie kan een retry dezelfde e-mail versturen, dezelfde PR maken of dezelfde klant twee keer belasten.
  6. Observability moet de worker overleven. Voor een gefaalde run van zes uur zijn de bruikbare artifacts het event log, laatste checkpoint, trace, tool-call-tijdlijn, workspace diff, screenshots en omgevingsmetadata.
  7. Runtime-aannames verouderen als modellen veranderen. Test context resets, evaluatorpatronen, tool-oppervlakken en budgetregels opnieuw wanneer je van model of harness wisselt.
  8. Secrets moeten buiten de harness en buiten de modelcontext blijven. De agent krijgt tool-capabilities, geen ruwe credentials.

Referenties

Engineering write-ups

LangGraph en Deep Agents

OpenAI Agents SDK

Temporal

Anthropic-platform

Sandboxproviders

Cloudplatform-timeouts en quotas

Observability

Serie

De code van de Market Analyst Agent (LangGraph-worker, Postgres-checkpointer, Qdrant-memory, MCP-sidecar en de hierboven beschreven Docker Compose-topologie) staat op GitHub.