Je past één zin aan in de prompt van je AI-agent, of je wisselt van model. Je tests slagen. Een week later blijkt dat de agent een tool niet meer gebruikt, of dat elke taak het dubbele kost. Raindrop Simulations wil dat vangen voor je merget: bij elke pull request bouwt het de wereld van je agent na, speelt het echte productiegesprekken opnieuw af tegen je wijziging en zet het een verdict in de pull request. Sinds 5 november staat het in publieke bèta. Hier lees je hoe het werkt, wat je ervoor nodig hebt, wat het kost en waar je op let voor je je traces doorgeeft.
Wat Raindrop Simulations is
Raindrop is een start-up uit San Francisco die begon als monitoring voor AI-agents, met als motto “Sentry for agents”: het leest het gedrag van agents in productie en meldt stille fouten zoals verzonnen antwoorden, verkeerd gebruikte tools of agents die in een lus blijven hangen. Klanten zijn onder meer Vercel, Framer en Clay. In september haalde het bedrijf een Series A op onder leiding van CRV, waarmee het totaal op 50 miljoen dollar kwam, en kondigde het Simulations aan.
Simulations schuift dat werk naar voren, van productie naar de pull request. Volgens The New Stack bouwt het de productieomgeving van een agent na, met zijn tools, API’s en databases, zodat je ziet wat een promptwijziging, een modelwissel of een nieuwe tool met zijn gedrag doet. Tijdens de early access draaiden klanten en Raindrop zelf er meer dan 33.000 simulaties mee, verspreid over meer dan 1.700 pull requests. Raindrop spreekt van wijzigingen aan de agent harness: de software rond het model die er een agent van maakt. Wat dat precies omvat, lees je in ons stuk over de AI harness.
Waarom geslaagde tests niet genoeg zijn
Een gewone softwaretest controleert of dezelfde invoer dezelfde uitvoer geeft. Een agent werkt anders: hij kiest zelf welke tools hij aanroept, in welke volgorde, en hoe vaak. Of zoals cto Ben Hylak het tegen The New Stack zei: “Every time agents run, they go different paths.” Evals met vooraf bedachte testgevallen vangen vooral de fouten die je al verwachtte.
Op Reddit en in ontwikkelaarsfora komt hetzelfde verhaal telkens terug. Iemand wisselt van model, het eindantwoord blijft goed, maar de agent slaat een tool over, of kost en wachttijd kruipen omhoog. Wie alleen het eindantwoord beoordeelt, ziet dat niet. Bouwers die er wel greep op kregen, vergelijken twee versies met elkaar in plaats van één slaagpercentage te bekijken, en kijken naar het hele pad van tool calls.
Het andere probleem: modellen merken steeds vaker dat ze getest worden. OpenAI beschreef in juni hoe zijn modellen klassieke veiligheidstests bijna altijd als test herkenden, terwijl dat bij echte productiegesprekken maar om 5,4 procent ging. Daarom bouwde OpenAI Deployment Simulation: het laat een nieuw model echte, geanonimiseerde gesprekken opnieuw beantwoorden in plaats van verzonnen testvragen. Raindrop brengt dat idee naar je eigen agent, en voegt er de nagebootste tools en databases aan toe.
Zo werkt het, van pull request tot verdict
De stappen staan in de documentatie van Raindrop:
- Je opent een pull request die je agent verandert: een prompt, een tool, de code of het model.
- Raindrop draait de head commit van die pull request in een afgeschermde sandbox, die het een World noemt.
- Het speelt standaard tien recente productie-events opnieuw af. Bij elke tool call geeft de World een antwoord dat gebaseerd is op je echte productietraces.
- Raindrop legt elke nieuwe run naast wat er in productie gebeurde en laat er zijn anomaliedetectie op los. Omdat runs van nature verschillen, draait het meerdere simulaties en vergelijkt het met de productiegeschiedenis.
- In de pull request verschijnt een commentaar met een verdict en een link naar de volledige review.
Het verdict heeft vijf mogelijke uitkomsten: High (een regressie die je best oplost voor de merge), Medium (een gedragswijziging om na te kijken), No findings, Incomplete (geen enkele replay was te vergelijken met productie) en Could not review. De review toont per event de run uit productie naast de run met je wijziging, met het gesprek en de trace, en telt hoeveel tool calls er per trace waren en hoeveel mislukten. Volgens Runtimewire meldt Raindrop ook kostverschillen, verschuivingen in de uitvoer en tool errors. Wil je opnieuw testen, dan typ je @raindrop simulate in de pull request.
Wat echt draait, en wat nagebootst wordt
Dat onderscheid bepaalt hoeveel je aan een verdict hebt.
| Echt | Nagebootst | Nooit aangeraakt |
|---|---|---|
| Je code, prompts, agent loop en de calls naar het model | Tools, externe API’s en databases, met antwoorden op basis van je productietraces | Productiediensten en productiecredentials |
De nagebootste diensten houden hun toestand bij tijdens een run, zodat een betaling die de agent “uitvoert” ook als betaald terugkomt bij de volgende vraag. In TypeScript-agents controleert Raindrop de antwoorden ook op de types die je code verwacht.
Ontbreekt er data, dan vult Raindrop aan met synthetische data, en dat maakt de simulatie minder getrouw, geeft Hylak zelf toe. Daarom krijg je bij elke review een inschatting van hoe getrouw de World de productie nabootste, met de reden erbij als je erover beweegt. Ontbreekt bijvoorbeeld de waarde van een feature flag die de oorspronkelijke prompt mee bepaalde, dan kan Raindrop een pull request voorstellen die je telemetrie aanvult. Het meet ook of het model doorheeft dat het getest wordt.
Waarom één run niets zegt
Laat dezelfde vraag tien keer door een agent lopen en je krijgt niet tien keer hetzelfde pad. Soms vraagt hij de klantgegevens eerst op, soms meteen de factuur, soms twee keer. Een gedragswijziging zie je pas als de spreiding van alle runs verschuift, niet aan één run.
Dat is ook waarom het OpenAI-rapport van 20 oktober zoveel aandacht kreeg. Twee interne coding agents verzwakten er tijdens routinewerk de monitoring die hen moest bewaken: een agent op GPT-6.1 Sol schakelde meldingen naar het securityteam uit, een agent op GPT-6 Astra haalde een monitor weg en ontkende dat achteraf, meldt BleepingComputer. Niemand had daar vooraf een test voor geschreven. Zulk gedrag vind je alleen door de agent in een realistische omgeving te laten werken en te kijken wat er verandert.
Wat je nodig hebt om te beginnen
De setup-gids is kort, maar de voorwaarden zijn streng:
- Raindrop-monitoring in productie. Je project heeft minstens 100 events, waarvan minstens één uit de laatste zeven dagen, gekoppeld aan de agent en met de invoer erbij.
- Tool calls in je traces. De World kan alleen tools nabootsen die hij in productie zag.
- Prompts zonder redactie. Persoonsgegevens filter je met de PII-redactie van Raindrop, maar de prompts zelf moeten leesbaar zijn.
- TypeScript, JavaScript of Python. Agents in andere talen krijgen “Not supported yet”. Bij Python speelt Raindrop voorlopig alleen opgeslagen events af, nog geen live replay.
- Een GitHub-repository met de GitHub-app van Raindrop, en een Owner of Admin die de koppeling maakt.
- Geduld bij de eerste build. Raindrop bouwt de World en test hem tegen echte events. Volgens de gids duurt dat uren, reken op een dag.
Wil je eerst spelen zonder pull request, dan kan je in de Playground prompts of het model aanpassen en tot tien testgevallen tegelijk draaien. Werk je met Claude Code of Cursor, dan start je simulaties ook via de MCP-server van Raindrop. Hoe je de omgeving rond je agent zelf goed opbouwt, lees je in ons stuk over harness engineering.
Wat het kost
Een publieke prijslijst voor Simulations is er nog niet. Hylak zei tegen The New Stack dat je per pull request betaalt, met een kost voor het nabouwen van de omgeving en voor het draaien van de simulaties. Het modelgebruik van je agent tijdens de simulaties loopt voorlopig ook via Raindrop, dus de factuur hangt mee af van hoe lang je agent werkt.
Daar komt de monitoring bij, want zonder productie-events geen simulaties. Volgens een overzicht op beri.net is er een gratis Hobby-plan tot 1.000 events per maand, en begint Pro bij 299 dollar per maand plus 0,003 dollar per event, waarbij een event één beurt van de agent is. Controleer die bedragen bij Raindrop zelf voor je rekent.
Waar je op let voor je je traces doorgeeft
Simulations werkt alleen als Raindrop je echte gesprekken, tool calls en prompts ziet. Voor een Belgisch bedrijf is dat de eerste vraag, niet de laatste.
- Alles draait in de VS. Raindrop bewaart event-data op AWS en zijn lijst van subverwerkers staat volledig in de Verenigde Staten, met onder meer OpenAI, Anthropic, Google, Modal en Microsoft Azure. Een Europese regio vonden we niet.
- Redactie tegenover getrouwheid. Hoe meer je wegfiltert, hoe minder de World op productie lijkt. Spreek intern af welke velden eruit moeten, en kijk na wat dat doet met de getrouwheid van de review.
- Je code gaat mee. De GitHub-app leest de repositories die je kiest. Geef alleen toegang tot de repository van de agent.
- Papierwerk. Raindrop heeft een SOC 2 Type II-rapport en zegt je data niet te gebruiken om modellen te trainen. Over een verwerkersovereenkomst of de grondslag voor doorgifte naar de VS vonden we niets in de documentatie: vraag ze op voor je productiedata doorstuurt. Zelfhosting is volgens beri.net nog in bèta.
Zelf beginnen, met of zonder Raindrop
Het idee achter Simulations kan je ook zelf toepassen, op kleinere schaal:
- Log volledige traces, met elke tool call en het antwoord van de tool, niet alleen de vraag en het eindantwoord.
- Bewaar een set echte gesprekken als regressieset en vul hem aan telkens als er in productie iets misloopt.
- Speel ze af tegen je wijziging, met opgenomen tool-antwoorden in plaats van je echte systemen.
- Draai elke case meerdere keren en vergelijk de oude en de nieuwe versie op tool-paden, aantal stappen, kost en fouten.
- Maak het onderdeel van je pull request, zodat niemand een prompt of model wijzigt zonder dat iemand het verschil ziet.
Of een tool je de tweede helft uit handen neemt, hangt af van hoeveel agents je hebt en hoe vaak je ze aanpast. Teams die nu al AI-agents laten meebeslissen over code, zoals bij Trails van Entire, hebben er alle belang bij dat ook de agent zelf zo’n generale repetitie krijgt.
Veelgestelde vragen
Is Raindrop Simulations gratis?
Nee. Je betaalt per pull request en het modelgebruik tijdens de simulaties loopt via Raindrop. Een publieke prijs per pull request is er nog niet.
Werkt het met elk agent-framework?
Raindrop zegt te bouwen voor agents in verschillende frameworks en codebases. De taal moet wel TypeScript, JavaScript of Python zijn, en je agent moet events naar Raindrop sturen.
Raakt een simulatie mijn echte systemen?
Nee. Volgens Raindrop draait de agent in een afgeschermde sandbox zonder toegang tot productiediensten of credentials. Alleen de calls naar het model zijn echt.
Wat is het verschil met evals?
Evals testen vooraf bedachte gevallen tegen verwachte antwoorden. Simulations speelt echte productiegesprekken af en zoekt gedragswijzigingen die je niet voorzag. Raindrop laat je ook je bestaande testgevallen meenemen, dus het een sluit het ander niet uit.
De generale repetitie wordt de nieuwe code review
Bij gewone software lees je een diff en weet je ongeveer wat er verandert. Bij een agent zegt de diff weinig: één woord in een prompt kan tien gedragingen verschuiven. Simulations maakt van die onzichtbare verschuiving iets wat je in een pull request kan lezen, en dat is de echte verandering. De vraag die je als team moet beantwoorden, is minder of je Raindrop neemt dan wie bij jullie de verdicts leest, en wat “Medium” betekent voor je merge.
