Claude Managed Agents: self-hosted sandboxes en MCP tunnels uitgelegd.

Wat Anthropic deze week aankondigde

Anthropic heeft Claude Managed Agents uitgebreid met twee fundamentele updates die het verschil maken tussen "leuke demo" en "productie-agent op echte bedrijfsdata". In de aankondiging van mei 2026 introduceert Anthropic self-hosted sandboxes (vanaf nu in public beta) en MCP tunnels (research preview). Beide pakken hetzelfde fundamentele probleem aan: hoe laat je een AI-agent met gevoelige bedrijfsdata en interne tools werken zonder je netwerk open te zetten voor de buitenwereld?

Voor wie nieuw is in deze hoek: Managed Agents is het platform van Anthropic om autonome agents te draaien. De agent loop — beslissen welke tool nodig is, contextbeheer, error recovery, orchestratie — draait op Anthropic's infrastructuur. Tot voor kort betekende dat dat de uitvoering van die tools óók aan de cloudkant zat. Met deze updates verandert dat: tool-uitvoering kan nu in jouw omgeving plaatsvinden, en MCP-servers binnen je private netwerk worden bereikbaar zonder firewall-gaten.

De agent loop draait in de cloud, de uitvoering en de data blijven bij jou. Dat is precies de splitsing die enterprise-gebruik mogelijk maakt.

Een korte historische plaatsbepaling

Om te snappen waarom dit een grote stap is, helpt het om kort terug te kijken. AI-agents hebben de afgelopen drie jaar een aantal duidelijke fasen doorlopen:

• 2023 — Het experiment. AutoGPT en BabyAGI bewezen dat een LLM in een loop met tools kon werken. Onbetrouwbaar, ja, maar conceptueel doorbroken: het idee dat een model meer kon zijn dan een chatbot.
• 2024 — De tool-use kreeg betrouwbaarheid. Claude 3, GPT-4 en Gemini begonnen consistent goede tool-keuzes te maken. Tegelijk werd duidelijk dat het ontbrak aan standaardisatie: elke integratie was custom. Anthropic introduceerde eind 2024 MCP als open protocol.
• 2025 — Het orchestratie-probleem. Modellen werden goed genoeg om in een agent loop een hele werkstap af te ronden, maar de infrastructuur eromheen — error recovery, context-management, retries, timeouts, observability — was alsnog elk team's eigen probleem. Anthropic, OpenAI en concurrenten introduceerden managed agent runtimes; in oktober 2025 verscheen Anthropic's Claude Agent SDK en kort daarna de eerste versie van Managed Agents.
• 2026 — Productie en controle. Dit jaar wordt 'agent in productie' commodity. De vraag verschuift van "werkt het?" naar "hoe houd ik controle over data, kosten en compliance?". Self-hosted sandboxes en MCP tunnels zijn het antwoord van Anthropic op die vraag.

De richting is consistent: elke iteratie haalt een blokkade weg die enterprise-adoptie tegenhield. Wat een jaar geleden nog een proof of concept was, is nu een productie-architectuur met SDK's, providers en best practices.

Self-hosted sandboxes: agent-executie binnen je eigen IT-omgeving

Een sandbox is in deze context de uitvoeringsomgeving voor de tools die de agent aanroept: een script draaien, een bestand schrijven, een build uitvoeren, een afbeelding genereren, een rapport bouwen. Tot deze update gebeurde dat in een door Anthropic beheerde omgeving. Met self-hosted sandboxes verschuift die uitvoering naar een omgeving die jij controleert.

Concreet betekent dat:

• Bestanden, packages en services blijven in jouw infra — een agent die een interne database raadpleegt, een private package gebruikt of een vertrouwelijke template invult, doet dat binnen jouw netwerk. Anthropic ziet alleen de signalen die nodig zijn om de agent loop te orchestreren.
• Jij bepaalt compute resources — CPU, memory en eventueel GPU. Bouwt de agent containers, doet hij videoencoding of laat je hem een Llama-model draaien? Allocate de juiste resources zonder gebonden te zijn aan een one-size-fits-all sandbox in de cloud.
• Bestaande security blijft intact — netwerkregels, toegangsbeheer, audit logging en je beveiligings-tooling zien de tool-executie precies zoals ze elke andere werklast zien. Geen aparte cloud-omgeving erbij die je apart moet bewaken.

Hoe je zo'n sandbox mentaal voorstelt

Beeld een sandbox in als een afgesloten kantoor waarin een tijdelijke kracht zijn werk doet. Anthropic levert de instructies ("haal die gegevens op", "maak dat bestand"), de tijdelijke kracht voert ze uit binnen zijn kantoor, en geeft alleen het eindresultaat terug. Het hele kantoor — bestanden, computers, gegevens — blijft in jouw gebouw. Anthropic ziet alleen het binnenkomende werkbevel en het uitgaande antwoord, niet wat zich daartussen afspeelt.

De winst zit in die afbakening. De agent loop bij Anthropic doet alleen wat hij goed kan: nadenken, plannen, beslissen welke tool nodig is en de uitkomst interpreteren. Het feitelijke werk — gegevens opzoeken, mutaties doorvoeren, bestanden manipuleren — gebeurt binnen jouw IT-omgeving, met jouw beveiliging en jouw logging.

De parallel die het beste werkt voor wie er nog niet eerder mee bezig was: het is alsof je een uitzendkracht aan het werk zet. Het bureau zorgt voor de match en de aansturing, maar de werker zit in jouw kantoor en houdt zich aan jouw huisregels.

De vier managed providers in de public beta

Naast volledig self-host kun je kiezen uit vier provider-profielen. Elk profiel sluit aan op een ander gebruikspatroon:

• Cloudflare — snelle, lichte uitvoeringsomgevingen die wereldwijd dicht bij de gebruiker staan. Geschikt voor kortlopende, snelheidsgevoelige acties.
• Daytona — uitvoeringsomgevingen die meerdere stappen lang blijven bestaan. Past bij agents die in een werkdag bezig zijn met één langer traject en context willen onthouden.
• Modal — gericht op AI- en rekenintensieve werklasten, met snelle opstart en directe toegang tot zwaardere rekenkracht. Geschikt voor agents die meer doen dan tekst en gegevens.
• Vercel Sandbox — uitvoeringsomgevingen die binnen jouw eigen netwerkruimte leven, zodat ze veilig met andere interne diensten kunnen praten.

Voor wie liever volledig zelf host: Anthropic publiceert de spelregels en hulpmiddelen die nodig zijn om een eigen uitvoeringsomgeving te bouwen. Geschikt voor organisaties met strikte data-residency-eisen of een eigen platform waar dit op moet draaien.

Welke provider past bij welk patroon?

De providers verschillen op een handvol assen die er in de praktijk toe doen. De keuze is zelden een "winnaar"; het is een match tussen workload-karakter en provider-sterktes. Hieronder een grof overzicht:

• Veel korte acties, snelheid telt — Cloudflare. De omgeving start razendsnel op en draait dicht bij de gebruiker. Past bij agents die in korte gesprekken meerdere snelle tools willen kunnen aanroepen.
• Lange werkzaamheden die hun staat moeten onthouden — Daytona. De omgeving blijft tussen stappen door bestaan, dus de agent kan terugkomen op eerder werk zonder alles opnieuw op te bouwen.
• Zware rekenklussen (beelden, video, AI-modellen, builds) — Modal. Geschikt voor agents die naast taal-werk ook compute-intensieve handelingen moeten doen.
• Strenge netwerksegmentatie (finance, zorg, overheid) — Vercel Sandbox. De omgeving leeft in dezelfde netwerkruimte als de rest van je stack en kan daar veilig met andere interne diensten praten.
• Strikte EU-residency of eigen platform — zelf hosten. Je bouwt een eigen uitvoeringsomgeving die aan de afspraken van het platform voldoet en host die waar je wilt.

Een nuance die in de praktijk vaak terugkomt: combineren mag. Niets verbiedt je om voor één agent een snelle omgeving te gebruiken voor lichte stappen en een zwaardere omgeving voor de rekenintensieve stap. De agent loop zit aan de cloudkant; welke uitvoeringsomgeving welke tool uitvoert is een keuze die je per workflow maakt.

Wat Anthropic wel en niet ziet

Een terugkerende vraag bij compliance-gesprekken: "wat ziet Anthropic precies?" Het antwoord is gelaagd, maar concreet:

• Wel — de aanvragen die het model formuleert (welke tool, met welke kernparameters) en de samenvattingen die teruggaan naar het model. Dat is wat de loop nodig heeft om verder te kunnen denken.
• Niet — ruwe bestandsinhoud, inloggegevens, het interne netwerkverkeer en alles wat strikt binnen jouw omgeving blijft. Een tool die intern in een database kijkt kan de details binnenhouden en alleen een geredacteerde of geaggregeerde uitkomst meegeven aan het model.

Dat onderscheid is belangrijk bij privacy-design. Met goed tool-ontwerp houd je gevoelige velden binnen je eigen netwerk en deel je alleen het minimum dat de agent nodig heeft om zijn werk te doen. Voor AVG- en NIS2-omgevingen is dat een wezenlijk verschil ten opzichte van "alles gaat naar de cloud".

MCP tunnels: private MCP-servers bereikbaar zonder firewall-gaten

De andere helft van het verhaal gaat over het Model Context Protocol — de open standaard die AI-modellen met externe systemen verbindt. Een MCP-server kan een database, een API, een knowledge base of een ticketsysteem ontsluiten als tool die een agent kan aanroepen.

Het probleem tot nu toe: veel interessante MCP-servers draaien binnen een organisatienetwerk, achter een firewall. Om ze beschikbaar te maken voor een cloud-agent moest je die servers aan het internet hangen — met alle bijbehorende security-implicaties (inbound regels, publieke endpoints, extra IAM, DDOS-bescherming). Voor veel enterprises een onhaalbare kaart.

MCP tunnels lossen dat anders op. Je installeert een lightweight gateway binnen je netwerk. Die gateway opent één outbound verbinding naar Anthropic — geen inbound firewall rules, geen publieke endpoint, geen extra aanvalsoppervlak. Het verkeer is end-to-end versleuteld; alleen de gateway en de agent zien de payload. Je MCP-servers blijven precies waar ze waren: achter je firewall, op je interne netwerk.

Wat dit ontsluit:

• Interne databases — productiedatabases of data warehouses die nooit naar buiten mochten, kunnen via een MCP-server als tool aan de agent worden aangeboden. Read-only, met permissies en logging.
• Private API's — je eigen interne API, je ERP-koppeling, je boekhoudkoppeling — als ze in je private netwerk draaien, hoeven ze daar niet uit.
• Knowledge bases — interne documentatie, beleidsdocumenten, een Confluence of een eigen RAG-systeem.
• Ticketing en projectmanagement — Jira, Linear, een eigen ticketsysteem of helpdesk-database. De agent kan tickets aanmaken, statussen lezen of blockers herkennen zonder dat het systeem aan het internet hoeft.

MCP tunnels werken zowel in Managed Agents als in de reguliere Messages API. Wie alleen Claude via de API gebruikt, krijgt dezelfde mogelijkheid.

Hoe een tunnel mentaal werkt

Beeld het in als een telefoon-doorschakeling met één vertrouwde tussenpersoon. Binnen je netwerk staat een gateway die zich aan jouw kant gedraagt als een normale interne dienst, en aan de andere kant één langlopende, versleutelde verbinding heeft naar Anthropic. Komt er een aanvraag binnen van een agent, dan loopt die via die verbinding naar de gateway, en de gateway routet hem door naar de juiste interne tool.

Wat dat oplevert: je hoeft niets aan het internet bloot te stellen, je hebt één duidelijk punt om vertrouwen te beheren, en je kunt de hele verbinding in één keer afsluiten als er iets niet pluis is. De gateway is — om in dezelfde beeldspraak te blijven — de portier die je vandaag aanstelt en morgen weer naar huis kunt sturen.

Wat dit betekent voor snelheid

Een terechte vraag bij elke tussenstap: kost dit niet veel tijd? In de praktijk valt het mee, omdat de verbinding tussen gateway en cloud al open staat — er is geen ceremonieel handenschudden bij elke individuele aanvraag. De extra vertraging blijft beperkt tot iets in de orde van tientallen milliseconden, terwijl een typische agent-stap honderden milliseconden tot enkele seconden duurt. Voor agent-werk is dat ruis; voor strakke realtime UI's zou je het ontwerp anders insteken.

De grotere les is conceptueel: ontwerp je tools zo dat ze klein blijven. Een tool die in één keer alle data terugkaatst, is duur in tokens, traag in transport en verwart de agent. Een tool die antwoordt met "deze drie" is bijna altijd beter dan één die antwoordt met "alle tienduizend".

Wat "goed afgebakend" betekent

Welke tools je via zo'n tunnel ontsluit, is een ontwerpvraag, geen technische. De kern: elke tool die je beschikbaar maakt voor een agent doet idealiter één ding. "Klant opzoeken". "Openstaande facturen lezen". "Tickets op status filteren". "Een levering inplannen". Brede, vage tools ("doe iets met een klant") verleiden het model tot interpretatie en maken logging onleesbaar.

De rode draad is dat een tool zich gedraagt als een dienst aan een collega, niet als een database-deur. Hij verwacht expliciete vragen, geeft begrensde antwoorden en weet welke gebruiker hem aanroept. Hoe dat zich technisch vertaalt verschilt per stack; conceptueel is het overal hetzelfde: precisie aan de tool-zijde, vertaling aan de modelkant.

Concrete use cases: bedrijven die hier al op draaien

In dezelfde aankondiging publiceerde Anthropic een aantal launch-partners die op productie met deze stack werken. Een paar voorbeelden om de breedte te laten zien:

Amplitude — Design Agent met Cloudflare

Volgens Amplitude bouwde het bedrijf een agent die on-brand mockups en design-iteraties genereert voor productteams. De keuze voor Cloudflare hangt samen met snelheid: design-feedback moet vlot binnenkomen en de uitvoering staat dicht bij de gebruiker.

Clay — Sculptor GTM engineering met Daytona

Clay zet een GTM engineering-agent in (Sculptor) die langere workflows draait rondom prospect-onderzoek, dataverrijking en outbound. Daytona's stateful sandboxes passen daar omdat een GTM-traject meer stappen telt dan één request-response.

Rogo — Analyst agent voor institutional finance met Vercel

Rogo bouwde een analyst-agent voor de financiële sector. Vercel Sandbox levert strikte isolatie en de mogelijkheid om binnen dezelfde netwerkruimte als de rest van de stack te draaien — wat aansluit op de strenge eisen die institutional finance stelt aan dataverkeer en netwerksegmentatie.

Mason — veilige orchestratie van interne tools met Modal

Mason orkestreert interne tools en data-pipelines via een agent op Modal. Modal's snelle startup en directe toegang tot zwaardere rekenkracht passen bij hun mix van bursty werklast en occasionele AI-inferentie.

Het patroon is duidelijk: er is geen one-size-fits-all. De keuze voor sandbox-provider hangt af van workload-karakter (snelheid, state, GPU, netwerklocatie) en compliance-eisen. Anthropic verzorgt de agent loop, jij kiest waar de uitvoering landt.

Verticale toepassingen die we in eigen werk zien

Buiten de launch-partners zien wij in opdrachten een aantal sectorpatronen die de moeite waard zijn om te benoemen — ze laten zien hoe breed dit toepasbaar is:

• Accountancy en boekhouding — een agent die periodieke afsluitwerkzaamheden orchestreert: openstaande post controleren, BTW-aangiftes voorbereiden, afwijkingen signaleren. Verbindt via MCP met Exact Online, Moneybird of Twinfield. Zie ook software voor accountants.
• E-commerce en fulfillment — een agent die orders monitort, voorraadtekorten signaleert, retouren classificeert en klantvragen voor-sorteert. MCP-koppelingen met Bol.com, PostNL en je webshop.
• B2B SaaS-platforms — een "copilot in je app" die klanten helpt om te navigeren, rapporten op te zetten en configuratie uit te leggen. Werkt op het bestaande rollen- en rechtenmodel van het platform.
• Klantenservice en helpdesk — een agent die tickets pre-classificeert, eerstelijns antwoorden voorbereidt en bij escalatie een complete context-briefing voor de menselijke medewerker meelevert.
• Software development — een agent die issues triage't, code reviews voorbereidt, deploys monitort en incidenten correleert. Wij gebruiken dit zelf bij Coding Agency voor onze klantprojecten via Cody.
• HR en interne processen — een agent die onboarding-checks doet, verlofaanvragen valideert, expense reports voor-controleert. Verbindt met je HR-software en interne kennisbank via MCP.
• Marketing en content — agents die campagnes monitoren, performance-data ophalen uit GA4 en ad-platformen, en aanbevelingen formuleren. Compute-intensieve creatives kunnen op Modal landen.
• Logistiek en planning — een agent die ritten herplant op basis van real-time data, vertragingen signaleert en klanten proactief informeert.

De sectoren verschillen sterk in regelgeving, dataschaal en complexiteit, maar het recept is in alle gevallen vergelijkbaar: agent loop in de cloud, tool-uitvoering in jouw IT-omgeving, MCP als interface, sandbox waar nodig.

Veel gemaakte fouten en hoe ze te voorkomen

Wat we de afgelopen maanden bij andere teams en in eigen experimenten hebben zien misgaan — niet om afbrekend te zijn, maar om ze voor jou te besparen:

Te brede tool-permissies

De agent krijgt "voor het gemak" toegang tot alle data en alle mutaties. Het lijkt sneller, totdat een prompt-injection-aanval de agent verleidt om iets te doen wat hij in principe mocht. Beperk per agent en per gebruikersrol. Een agent voor accountancy hoeft geen HR-data te zien.

Tools zonder validatie

De aanname dat "het model schema-conforme input geeft, dus we hoeven niet te valideren" klopt 99% van de tijd. Tot het niet klopt — en dan staat je productie-database open voor een verkeerd geïnterpreteerde parameter. Valideer altijd aan de tool-zijde.

Te grote tool-outputs

Een tool die honderdduizend rijen teruggeeft, kost niet alleen veel tokens; hij maakt het model ook minder accuraat omdat de relevante info in ruis verdwijnt. Paginieren, filteren, samenvatten. Geef het model wat het nodig heeft, niet alles wat je hebt.

Geen idempotentie bij mutaties

Een agent die een actie nogmaals probeert (na een timeout, na een netwerkfout, na een tussentijdse model-correctie) kan dezelfde mutatie twee keer uitvoeren. Een factuur twee keer versturen, een terugbetaling twee keer doen. Zorg dat dezelfde mutatie meerdere keren uitvoeren slechts één effect heeft — zie idempotentie.

Onvoldoende observability

"Het werkt" in dev betekent niets als je niet ziet wat er in productie gebeurt. Log alle tool-calls, koppel ze aan menselijke initiatoren, alert op afwijkingen. Zonder dit ben je blind voor de eerste echte fout.

Te ambitieuze eerste use case

"Een agent die alles doet" faalt voorspelbaar. "Een agent die deze ene workflow afhandelt" lukt vaak. Begin klein, leer, breid uit.

Vergeten dat het model fout zit

Zelfs het beste model hallucineert af en toe of kiest de verkeerde tool. Bouw in dat de gebruiker bevestigt vóór mutaties, of dat een tweede agent (een "reviewer") het resultaat checkt. Human in the loop is geen tekortkoming maar een ontwerpkeuze.

Vendor lock-in negeren

Op het oog koppel je nu aan Anthropic, en wie weet wat er over twee jaar nog bestaat. MCP biedt de uitweg — je tools en MCP-servers werken in principe ook met GPT- of Gemini-agents. Maar de specifieke runtime-features van Managed Agents zijn vendor-specifiek. Houd je business logic in MCP, niet in vendor-specifieke configuratie.

Compliance: AVG, NIS2 en ISO 27001 in agent-context

Voor Nederlandse en Europese organisaties is "werkt het?" maar de halve vraag. De andere helft is: "hoe sluit dit aan op onze compliance-verplichtingen?" Drie kaders waar we in elk traject tegenaan lopen.

AVG en GDPR

De AVG (en de bredere GDPR-verordening) stelt dat persoonsgegevens niet zomaar naar buiten de EU mogen, dat verwerkingen gedocumenteerd moeten zijn en dat betrokkenen rechten hebben om in te zien, te corrigeren en te laten verwijderen. Voor AI-agents betekent dat:

• Modelhosting binnen de EU — via AWS Bedrock Frankfurt, OpenAI's EU-endpoint of Azure OpenAI EU. Zonder dit is elke verwerking met persoonsgegevens juridisch wankel.
• Tool-uitvoering binnen je eigen IT-omgeving — self-hosted sandboxes lossen dit voor de werklast op. De ruwe persoonsgegevens raken Anthropic's infra niet.
• Verwerkersovereenkomst — Anthropic biedt een standaard DPA. Cloudflare, Modal, Vercel en Daytona idem. Bij eigen platform-hosting documenteer je intern de verwerking.
• Geen training op klantdata — zoals vastgelegd in Anthropic's commercial terms; bij AWS Bedrock is dit contractueel geborgd.
• Audit logging op MCP-niveau — per tool-aanroep wie wat opvroeg. Voor afhandeling van inzage- en verwijderverzoeken is dat het verschil tussen "binnen twee uur antwoord" en "dagen graven".

NIS2

De NIS2-richtlijn (officieel EU 2022/2555) verplicht essentiële en belangrijke entiteiten tot risicobeheer, incident-respons en supply-chain-controles. AI-agents zijn voor NIS2-doeleinden gewoon software-componenten en vallen daarmee onder dezelfde eisen. Concreet:

• Risico-inventarisatie — wat zijn de scenario's waarin de agent ongewenste acties uitvoert, en wat is de schade? Documenteer per agent.
• Toegangscontrole — principle of least privilege per tool. De agent mag alleen wat de gebruiker mag, niet meer.
• Incident-detectie — ongebruikelijk gedrag (te veel tool-calls, foutpatronen, prompt-injection signalen) moet leiden tot alerts. Daarvoor is observability op de tool-laag essentieel.
• Supply-chain — Anthropic, je sandbox-provider en je MCP-dependencies zijn nu onderdeel van je supply chain. Documenteer ze en monitor ze. Zie ook supply chain attacks voor de bredere context.

ISO 27001

Voor organisaties met een ISO 27001-certificering verandert deze opzet relatief weinig — mits je hem goed inricht. De controls op toegang, logging, change-management en data-classificatie gelden onverkort. Het mooie aan self-hosted sandboxes en MCP tunnels is dat ze passen in je bestaande controlframework: ze draaien binnen je eigen netwerkruimte, je security-tooling ziet ze en je toegangsbeheer bepaalt wie wat kan.

Wat wel nieuw is: een "agent" als entiteit in je access-management. Welke agent mag welke tool? Welk audit-record hoort bij welke menselijke initiator? Wij beschouwen agents als "service accounts met een persoonlijkheid" en behandelen ze in IAM en logging zoals andere service accounts — met als extra eis dat de keten van menselijke gebruiker naar agent-actie traceerbaar moet zijn.

Drie lagen waar je mentaal in gaat ontwerpen

Zonder de techniek volledig open te trekken, helpt het om de architectuur in drie lagen te denken. Die indeling is niet Laravel-specifiek; je vindt hem terug in elke moderne agent-stack.

• De applicatie-laag — je bestaande software: de plek waar je business-regels, gegevens en mutaties leven. Hier verandert het minste. Een agent vervangt deze laag niet, hij gebruikt hem.
• De koppellaag (MCP) — een dunne "vertaling" bovenop je applicatie die specifieke acties en queries beschikbaar maakt als "tools" voor de agent. Elke tool wraps één capability uit de onderliggende applicatie en stelt hem beschikbaar met heldere permissies.
• De agent-laag — aan Anthropic's kant: een systeemprompt, de lijst tools die de agent mag gebruiken en configuratie over waar de uitvoering moet landen.

De winst van deze splitsing zit in onafhankelijkheid: je bedrijfslogica blijft op zijn eigen plek, de koppellaag is uitwisselbaar, en de agent-laag is feitelijk niet meer dan een specificatie. Als Anthropic morgen verdwijnt — onwaarschijnlijk, maar denkoefening — neem je de eerste twee lagen mee naar een ander platform. MCP is open en wordt door alle grote partijen ondersteund.

Wat een goede koppellaag in essentie doet

De koppellaag is de plek waar veel teams over struikelen. Niet omdat hij technisch moeilijk is, maar omdat hij conceptueel discipline vraagt. Een paar principes die het verschil maken tussen een werkende koppellaag en een die je drie maanden later weer afbreekt:

• Eén actie per tool — precisie is altijd beter dan flexibiliteit. Het model kiest beter, de logging is leesbaarder en fouten zijn beter af te bakenen.
• Tools weten van permissies — niet het model bepaalt of een actie mag, maar de koppellaag. Het model stelt voor; de koppellaag beslist.
• Mutaties zijn niet vrijblijvend — alles wat data verandert vraagt bevestiging, retry-veiligheid (zie idempotentie) en een logregel.
• Resultaten zijn klein en gestructureerd — geef de agent samenvattingen of compacte lijstjes, geen ruwe data-dumps.
• De koppellaag is los te testen — zonder agent erbij. Als één stap los werkt, weet je dat de agent erbovenop minder verrassingen geeft.

Observability als ontwerpprincipe

Wat je in productie wilt zien, is meer dan "werkt het?". Je wilt achteraf elke beslissing van de agent kunnen reconstrueren: wie heeft hem aangezet, welke tools heeft hij gebruikt, wat heeft hij gekregen, wat heeft hij teruggegeven. Goede agents zijn niet zwijgzaam — ze laten een trail achter die voor mensen en compliance te volgen is.

Concreet vertaalt dat zich naar drie soorten signalen die je in elke productie-opstelling wilt verzamelen: logregels op het niveau van individuele tool-aanroepen (wat gebeurde er en op welke data), metrics op het niveau van patronen (hoeveel, hoe snel, hoe vaak fout) en alerts op het niveau van afwijking (ongebruikelijke pieken, ongebruikelijke fouten). Voor de fundering ervan zie observability, logging en monitoring.

Migratiepad: van prototype naar productie

Veel teams hebben al een agent-prototype dat lokaal draait of in een vendor-locked omgeving. De stap naar deze stack hoeft niet groot te zijn, maar wel doordacht. Wat wij doorgaans als pad voorstellen:

1. Inventariseer je huidige agent-tools — welke acties roept hij aan, op welke systemen, met welke permissies? Documenteer wat er nu gebeurt voordat je migreert.
2. Identificeer de gevoelige tools — welke tools raken persoonsgegevens, financiële data of interne systemen? Die gaan naar self-hosted sandbox plus MCP tunnel; de rest kan eventueel op de standaard Managed Agents-runtime blijven.
3. Bouw een MCP-server lokaal — herimplementeer de gevoelige tools als MCP-tools binnen een Laravel-app of een dedicated MCP-service. Test ze los van de agent.
4. Zet de gateway op — in dezelfde netwerkruimte als je interne tools, met afgeschermde inloggegevens. Geef hem zo min mogelijk rechten — wat de gateway niet kan, kan ook niet misgaan.
5. Kies een sandbox-provider — op basis van workload-profiel. Begin met één provider; uitbreiden kan altijd.
6. Migreer één use case — niet alles tegelijk. Kies een use case die belangrijk genoeg is om aandacht te krijgen maar klein genoeg om snel te leren.
7. Meet voor en na — latency, foutpercentage, kosten, audit-volledigheid. Pas als de cijfers kloppen ga je naar use case twee.
8. Rol breder uit — met de geleerde patronen wordt elke volgende use case sneller. Wij zien meestal dat de eerste 4–8 weken kosten, en daarna een nieuwe agent in 1–2 weken live kan.

Een veelgemaakte fout: alles in één keer willen migreren. Het lijkt efficiënt, maar je leert dan niet welke keuzes goed of slecht waren. Liever incrementeel met meetpunten, dan in één grote sprong met giswerk achteraf.

Kosten: in welke vakjes zit het geld?

Productie-agents hebben één eigenaardige eigenschap: ze zijn niet gratis en niet duur, maar verrassend. Een agent kan een uur lang "nadenken" voordat hij één stap zet, of door 80 tool-aanroepen heen vliegen in een half uur. Zonder gevoel voor de kostenstructuur is het lastig te sturen.

Conceptueel vallen de kosten in vier categorieën, die je los wilt bewaken:

• De kosten van het denken — iedere aanroep van Claude kost een beetje, afhankelijk van hoeveel tekst er heen en weer gaat. Hoe langer en complexer de redenering, hoe meer het kost. Zwaardere modellen zijn beter in plannen en complex werk; lichtere zijn goedkoper voor eenvoudig bulkwerk.
• De kosten van de orchestratie — Anthropic vraagt een toeslag voor het draaien van de agent loop zelf. Voor korte agents verwaarloosbaar, voor langlopende werk telt het op.
• De kosten van de uitvoering — de sandbox waarin de tools draaien. Bij een managed provider is dat een tarief per CPU- of GPU-tijd; bij self-hosting zijn het je eigen serverkosten. Beeldgeneratie, builds en model-inferentie kunnen hier flink optellen.
• De kosten van je eigen koppelinfrastructuur — gateway, MCP-servers, je applicatielaag. In de praktijk doorgaans de kleinste categorie, mits niet overgedimensioneerd.

De rode draad voor beheersbaarheid: kies per stap het lichtst mogelijke model, geef tools alleen terug wat nodig is, cache wat herhaalbaar is en stel budgetten in voordat de eerste rekening komt. Maar bovenal: meet ROI per use case. Een agent die menselijke tijd vervangt is goedkoop, een agent die alleen indrukwekkend draait niet. Begin altijd met één use case waarvan je weet wat hij vandaag aan handwerk kost.

Waarom dit nu — en wat het betekent voor de toekomst

Drie ontwikkelingen komen hier samen:

• AI-modellen zijn betrouwbaar geworden in tool-gebruik — de huidige generatie Claude-modellen kan autonoom door meerstaps werk lopen, op het juiste moment gereedschap kiezen en zichzelf corrigeren bij fouten. De vooruitgang is meetbaar in benchmarks als SWE-bench en het Berkeley Function-Calling Leaderboard. Zonder die betrouwbaarheid was "agent in productie" geen reëel scenario.
• MCP is de feitelijke standaard geworden — sinds de overdracht aan de Agentic AI Foundation onder de Linux Foundation (zie het persbericht van de Linux Foundation) is MCP geen vendor-eigen protocol meer maar een industrieafspraak die door Anthropic, OpenAI, Google, AWS en Microsoft wordt gedragen. Investeren in een MCP-server is investeren in interoperabiliteit.
• De infrastructuur achter agents wordt commodity — tot voor kort moest elk team dat een agent in productie wilde, zelf nadenken over isolatie, network egress, audit logs en provider-keuzes. Self-hosted sandboxes en MCP tunnels maken die laag standaard.

De combinatie maakt iets nieuws mogelijk: cloud-AI die binnen je eigen IT-omgeving werkt. Geen of/of meer tussen "laat een cloud-LLM helpen" en "houd alles on-premise". Het kan allebei, in dezelfde workflow.

De volgende lichting AI-agents wordt niet beoordeeld op de modelkwaliteit, maar op hoe goed ze ingebed zijn in echte bedrijfsprocessen en echte data. Daarvoor heb je deze twee bouwstenen nodig.

Wat het oplevert — waarom je dit wilt

Een aantal voordelen die hieruit volgen, in volgorde van wat we zelf bij klanten zien:

• Gevoelige data blijft in je eigen omgeving — agents kunnen werken met klantgegevens, contracten of medische data zonder dat die data Anthropic's infra raakt. Bestaande verwerkersovereenkomsten, AVG-borgingen en NIS2-controles blijven gelden.
• Agents kunnen met bestaande tools werken — je eigen CRM, je ERP, je interne ticketsysteem of dashboard op maat worden tools via MCP. Geen migratie naar een nieuwe stack.
• Schaalbaar van kort naar lang — van een snelle interactieve actie (tens of seconden) tot meerstaps achtergrondtaken die uren duren. De juiste sandbox kiezen kost geen architectuurherziening meer.
• Enterprise-security zonder concessies — isolatie, audit logs, eigen netwerkruimte en data-residency zitten van begin af aan in het ontwerp, in plaats van er achteraf bij geknutseld te worden.
• Vendor-neutrale fundering — MCP is open. Vandaag draai je op Claude, morgen kun je een GPT- of Gemini-agent dezelfde MCP-server laten gebruiken. Je integratie-investering is niet vendor-locked.
• Lagere drempel voor "agent in productie" — minder eigen infra om te beheren, meer managed opties om uit te kiezen.

Waar je rekening mee moet houden

Een paar randvoorwaarden waar deze updates niet aan voorbijgaan:

Het is geen vervanging voor goed agent-ontwerp

Self-hosted sandboxes lossen het deployment-probleem op, niet het ontwerpprobleem. Een slecht ingerichte agent — te brede rechten, geen guardrails, geen bescherming tegen prompt-injection — wordt niet ineens veilig omdat hij in jouw netwerk draait. Goed tool-ontwerp, scherpe permissies en strakke validatie blijven essentieel.

Logging en observability moet je nog steeds zelf doen

Anthropic logt de agent loop, jij logt de tool-executie en de MCP-aanroepen. Voor een compleet audit trail moet je die twee bronnen aan elkaar koppelen. Bij compliance-gevoelige omgevingen koppelen wij dit aan een SIEM.

De MCP tunnel is een research preview

Verwacht nog wijzigingen in de SDK, edge cases en mogelijke performance-tuning. Voor pilots prima geschikt; voor mission-critical productie zou ik wachten tot de GA-release, of een gefaseerde uitrol doen met fallback.

Provider-keuze is een ontwerpkeuze

De keuze tussen Cloudflare, Daytona, Modal en Vercel is niet vrijblijvend. Het bepaalt latency, state-mogelijkheden, GPU-toegang en netwerktopologie. Eenmaal gekozen is wisselen niet triviaal — niet onmogelijk, wel werk. Doe deze keuze bewust, niet bij toeval.

Compute-kosten blijven jouw kosten

Self-hosted betekent dat je voor de compute betaalt — bij een managed provider naar hun tarieven, bij eigen infra naar je eigen platform. Bij compute-intensieve agents (image generation, builds, model-inferentie) kan dat snel oplopen. Reken vooraf.

Multi-agent patronen: meer dan één agent in één workflow

De nieuwe stack maakt iets mogelijk dat eerder erg lastig was: meerdere agents die samenwerken aan een grotere taak, ieder met hun eigen tools, sandbox en context. Een paar patronen die we in opdrachten al toepassen of klaarzetten:

• Planner + Worker — een "planner"-agent die een taak in subtaken hakt, een of meer "worker"-agents die de subtaken uitvoeren. De planner is meestal een zwaarder model voor complexe afweging, de workers zijn lichtere modellen voor uitvoering. Kostenefficiënt en schaalbaar.
• Generator + Reviewer — een agent die iets produceert (een offerte, een rapport, een stuk code), een tweede agent die het checkt op kwaliteit, beleid en consistentie. De reviewer mag de generator niet aansturen, alleen feedback geven. Houdt de feedback-loop scherp.
• Researcher + Drafter — een researcher die data verzamelt via MCP-tools (databases, documenten, web), een drafter die die input verwerkt tot een stuk tekst of beslissing. Splitst tool-using van content-creatie.
• Triagist + Specialist — een eerstelijns agent die binnenkomende vragen classificeert en routet naar een gespecialiseerde agent (sales-context, support-context, finance-context). Voorkomt dat één agent te veel hoeft te weten.

De winst van multi-agent: elke agent heeft een scherp domein, een beperkte tool-lijst en een korte context. Dat maakt ze accurater en goedkoper dan één alleskunner. De prijs is meer infrastructuur — observability, routing en handoff worden cruciaal. Self-hosted sandboxes helpen hierbij omdat je per agent een ander uitvoeringsprofiel kunt kiezen.

Hoe dit verschilt van alternatieven

Voor de volledigheid: Anthropic is niet alleen op dit terrein. Een paar alternatieven en hoe ze zich verhouden.

OpenAI Assistants en Responses API

OpenAI biedt een vergelijkbaar managed agent-runtime met tool-calling. Het verschil zit in de openheid van het ecosysteem: MCP wordt door beide ondersteund, maar Anthropic heeft van begin af aan op MCP als kern-interface ingezet, terwijl OpenAI nog steeds een eigen function-calling-formaat als primair pad heeft. Voor wie maximale portabiliteit wil, geeft Anthropic momenteel iets minder weerstand.

Google Vertex AI Agent Builder

Google's aanbod richt zich sterker op visuele bouw en integratie met Google Cloud. Krachtig voor wie volledig in GCP zit; minder ideaal voor wie cloud-agnostisch wil blijven. Ook hier is MCP-ondersteuning aan het komen, maar minder volwassen.

Open-source frameworks (LangChain, AutoGen, CrewAI)

Bouw je hele agent loop zelf, draai hem waar je wilt. Frameworks als LangChain, Microsoft AutoGen en CrewAI bieden maximale controle, maar je betaalt het in compleet eigen onderhoud van orchestratie, error recovery, context-management en monitoring. Voor research en hyper-specifieke use cases prima; voor productie waar het overall proces er meer toe doet dan de loop-implementatie, kost het meer dan het oplevert.

"Doe het allemaal zelf"

De volledig zelfgehoste route: open-source modellen, eigen runtime, eigen sandboxes, eigen MCP-servers. Goed voor onderzoeksinstellingen, organisaties met extreme data-residency-eisen of teams met diepe ML-expertise. Voor de meeste MKB- en enterprise-klanten een onnodige investering die het verschil tussen "af in maanden" en "af in jaren" bepaalt.

De keuze is in de praktijk vaak een mix: managed agent loop bij Anthropic, MCP-tools in eigen Laravel-applicatie, sandbox bij een EU-provider, observability in je eigen stack. Geen religie, wel architectuur-keuze per laag.

Hoe Coding Agency dit inzet

Wij bouwen MCP-integraties en AI-agents voor klanten — meestal bovenop een bestaande Laravel-applicatie. Wat deze updates bij ons werk veranderen:

• MCP-server lokaal achter de firewall — we hoeven de server niet meer aan het internet te hangen om hem voor een Claude-agent bruikbaar te maken. De gateway opent één outbound verbinding, klaar.
• Agent-uitvoering in dezelfde netwerkruimte als je productie-stack — via Vercel Sandbox of een zelf-gehoste omgeving. Bestaande rechten, sleutels en netwerk-policies blijven gewoon gelden.
• EU-gebonden compute — voor klanten die strikt binnen Europa moeten blijven, hosten we de sandbox-laag bij een EU-provider. Anthropic ziet alleen de agent loop-signalen, de echte werklast staat in Frankfurt of Amsterdam.
• Audit-koppeling met je SIEM — elke tool-aanroep, parameter, gebruiker en uitkomst gaat de logging in. Aansluiten op je ISO 27001- of NIS2-compliance-stack is daarmee standaardwerk.
• Permissielaag op tool-niveau — welke gebruiker, welke rol, welke tools, welke data. We sluiten zoveel mogelijk aan op het bestaande rollen- en rechtenmodel van je applicatie. Zie ook security by design.

Concreet: een eerste agent met self-hosted sandbox en private MCP-server op een bestaande Laravel-applicatie bouwen we in 3 tot 6 weken — afhankelijk van het aantal tools, de complexiteit van de data en de compliance-eisen. Daarna is uitbreiden incrementeel: elke nieuwe tool kost een paar uur tot enkele dagen.

Wanneer ga je hier mee aan de slag?

Als je in een eerdere fase tegen één van deze blokkers aangelopen bent — "we kunnen geen cloud-AI gebruiken want onze data mag niet naar buiten" of "we krijgen onze interne tools niet veilig bij een agent" — is dit hét moment om je use cases opnieuw te wegen. De technische obstakels die de afgelopen twee jaar tegen enterprise-adoptie aanzaten, vallen één voor één weg.

Onze aanbeveling: begin klein. Eén afgebakende workflow, één agent, één MCP-server tegen een interne tool. Maak die succesvol, leer van het echte gebruik, breid daarna uit. Het is verleidelijk om groot te beginnen met "AI-agents voor de hele organisatie" — in de praktijk levert dat een mooi plaatje op dat niemand gebruikt.

Wil je sparren over een concrete use case, of nieuwsgierig of self-hosted sandboxes en MCP tunnels passen bij je situatie? Neem contact op voor een vrijblijvend gesprek — we denken graag mee.