🤖 AI

Atomix: Timely, Transactional Tool Use for Reliable Agentic Workflows

Atomix is een runtime-systeem dat betrouwbare agentische workflows waarborgt door de groepering van effecten te ontkoppelen van conflictresolutie via voortgangsbewuste transacties, die effecten van tools bufferen en deze pas committen nadat is bevestigd dat er geen eerdere conflicterende taken kunnen arriveren, waardoor gedeeltelijke staten, verouderde schrijfacties en onomkeerbare lekken worden voorkomen.

Oorspronkelijke auteurs: Bardia Mohammadi, Nearchos Potamitis, Lars Klein, Akhil Arora, Laurent Bindschaedler

Gepubliceerd 2026-06-02

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Bardia Mohammadi, Nearchos Potamitis, Lars Klein, Akhil Arora, Laurent Bindschaedler

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je de manager bent van een druk reisbureau. Je doel is om een compleet vakantiepakket te boeken voor een klant: een vlucht, een hotel, een huurauto en een bevestigingsmail.

In de wereld van AI-agenten (computerprogramma's die taken uitvoeren) gebeurt dit precies zo. De AI probeert deze dingen één voor één te boeken. Maar hier is het probleem: wat gebeurt er als de vluchtboeking halverwege mislukt?

De oude manier (huidige systemen): De AI heeft misschien al een hotel en een auto geboekt. Als de vlucht mislukt, probeert het systeem de hotel- en autoboekingen "ongedaan" te maken. Maar wat als de autoverhuurder geen annuleringen toestaat? Of wat als de AI tegelijkertijd twee verschillende vakantieplannen probeerde uit te werken (speculatie), en het ene plan een hotel boekte dat het andere plan niet nodig had? Het resultaat is een rommelige, gedeeltelijk geboekte vakantie die je niet gemakkelijk kunt herstellen.

Atomix is een nieuw systeem dat deze chaos wil oplossen. Zie het als een "Veiligheidskluis" voor AI-acties.

Het kernprobleem: Het "te late" moment

Huidige AI-systemen beschouwen de reactie van een tool (zoals "Hotel geboekt!") als het definitieve moment. Zodra dat gebeurt, is de actie voltooid.

Speculatie: Als de AI twee paden voorspelt en het verkeerde pad kiest, heeft het "verliezende" pad de echte wereld al veranderd (bijvoorbeeld door een e-mail te sturen).
Onomkeerbaarheid: Sommige zaken, zoals het versturen van een e-mail of het overmaken van geld, kunnen niet ongedaan worden gemaakt. Als de AI een fout maakt nadat het een e-mail heeft verzonden, is het te laat.
Chaos: Als twee AI-agenten tegelijkertijd dezelfde hotelkamer proberen te boeken, kunnen ze elkaars werk overschrijven.

De Atomix-oplossing: De "Hold and Release"-strategie

Atomix verandert de regels. In plaats van acties direct te laten plaatsvinden, plaatst het ze in een wachtstand totdat het 100% zeker weet dat het veilig is om ze vrij te geven.

Zo werkt het, met de reisagent-analogie:

1. De "Concept"-fase (Executie)

De AI-agent begint aan het werk. Het roept de vlucht-, hotel- en autoverdiensten aan.

Omkeerbare acties (zoals het reserveren van een hotelkamer die geannuleerd kan worden) gebeuren direct, maar Atomix noteert ze als "in afwachting".
Onomkeerbare acties (zoals het versturen van de bevestigingsmail) worden bevroren. De AI denkt dat hij de e-mail heeft verzonden, maar Atomix houdt de e-mail daadwerkelijk vast in een buffer. De echte wereld is nog niet veranderd.

2. De "Zegel" (Het bevriezen van het plan)

Zodra de AI zijn lijst met taken heeft voltooid, plaatst Atomix een zegel op de transactie.

Dit is als zeggen: "Oké, het plan is voltooid. Er kunnen geen nieuwe wijzigingen meer worden toegevoegd aan deze specifieke bestelling."
Als de AI probeert een nieuwe taak toe te voegen na de zegel, zegt Atomix: "Nee, dat is een overtreding," en annuleert het de hele boel om verwarring te voorkomen.

3. De "Groen Licht" Check (Frontier Checks)

Voordat Atomix de acties vrijgeeft, controleert het de Frontier.

Stel je een verkeerslicht voor bij elke bron (het hotel, de huurauto, de e-mailserver).
Atomix vraagt: "Is iedereen anders die aan deze hotelkamer wilde werken, klaar met zijn werk?"
Als een andere agent nog steeds vecht om dezelfde kamer, wacht Atomix. Het zorgt ervoor dat er geen conflicterend werk van "eerder" nog in de pijplijn zit.

4. De "Commit" (Afwikkeling)

Als de controle slaagt, commit Atomix de transactie.

Omkeerbare acties: De hotel- en autoboekingen worden definitief gemaakt.
Onomkeerbare acties: De e-mail wordt eindelijk verzonden.
Als alles goed ging: De klant krijgt zijn vakantie.

5. De "Abort" (Het vangnet)

Als er iets misgaat voordat het groene licht komt (bijvoorbeeld de vluchtboeking mislukt, of de AI kiest het verkeerde vakantieplan):

Annuleert (aborts) Atomix de transactie.
Omkeerbare acties: Het annuleert de hotel- en autoreservaties onmiddellijk.
Onomkeerbare acties: De e-mail verlaat de buffer nooit. Deze wordt verwijderd. De klant ziet hem nooit.
Speculatie: Als de AI twee plannen aan het testen was, doodt Atomix het verliezende plan voordat het de wereld kan verstoren.

Waarom dit ertoe doet (De resultaten)

Het onderzoek testte Atomix tegen andere systemen met behulp van real-world scenario's (zoals het boeken van winkelbestellingen) en gesimuleerde fouten (zoals netwerkfouten of AI-fouten).

Schone herstel: Wanneer er dingen misgingen, herstelde Atomix zich in 57% van de gevallen schoon, terwijl andere systemen bijna naar 0% zakten. Zij konden de puinhoop die ze maakten niet opruimen.
Geen lekken: Bij het testen van "onomkeerbare" acties (zoals het versturen van nep-e-mails), lekte Atomix 0 ongeldige e-mails. Andere systemen lekten tot wel 80% van de berichten.
Geen wachttijd: In tegenstelling tot oudere systemen die agenten lieten wachten in een rij (door bronnen te blokkeren), laat Atomix agenten parallel werken zonder op elkaars tenen te trappen, met bijna nul vertraging.

De essentie

Atomix is als een slimme uitsmijter voor AI-agenten. Het laat hen hun acties oefenen en voorbereiden, maar weigert ze "live" te laten gaan (de echte wereld te veranderen) totdat het absoluut zeker weet dat:

Het hele plan compleet is.
Niemand anders vecht om dezelfde bronnen.
Als ze falen, ze veilig geannuleerd kunnen worden zonder een puinhoop achter te laten.

Het verandert chaotische, risicovolle AI-workflows in betrouwbare, veilige transacties.

Technische Samenvatting: Atomix – Tijdige, Transactionele Tool-implementatie voor Betrouwbare Agentische Workflows

1. Probleemstelling

Large Language Model (LLM) agenten voeren multi-step workflows uit die de externe staat muteren (bijv. code bewerken, databases bijwerken, e-mails verzenden). Huidige orchestratie-frameworks vertrouwen op indirecte mechanismen zoals checkpointing, retries en Saga-stijl compensaties. Deze benaderingen schieten echter tekort bij het adresseren van drie kritieke hiaten wanneer workflows parallel draaien:

Speculatie: Parallelle plannen die real-world tool calls uitvoeren, laten residuele bijwerkingen achter als een tak verliest, omdat de "verliezende" effecten de wereld al hebben gemuteerd.
Contentie: Gelijktijdige agenten die dezelfde bron aanroepen, kunnen writes interleaven, waardoor verouderde plannen elkaar overschrijven.
Onomkeerbaarheid: Bepaalde effecten (bijv. een e-mail verzenden, fysieke handelingen) kunnen niet ongedaan worden gemaakt zodra ze zijn geexternaliseerd. Bestaande herstelmechanismen (zoals rollback van checkpoint-geheugen) herstellen wel de agent-geheugen, maar kunnen geëxternaliseerde onomkeerbare acties niet terugtrekken.

De kernuitdaging is bepalen wanneer een tool-effect veilig permanent kan worden. Huidige triggers (bijv. tool return) zijn te vroeg voor speculatieve takken, terwijl rollback-mechanismen te laat zijn voor onomkeerbare acties.

2. Methodologie: De Atomix Runtime

Atomix introduceert een transactioneel settlement-model bij de tool-interface, waarbij de uitvoering van de tool wordt ontkoppeld van de settlement van het effect. Het scheidt de workflow in vier afzonderlijke gebeurtenissen: Execution (Uitvoering), Sealing (Verzegeling), Frontier Checking (Frontier-controle) en Settlement (Commit of Abort).

Kernabstracties

Epochs (Epochen): Logische, totaal geordende monotone tijdstempels toegewezen door een allocator, die ordening coderen in plaats van identiteit.
Scopes (Bereiken): Namen voor resources. Transacties registreren read scopes (geobserveerde staat) en effect scopes (gemuteerde staat).
Effects (Effecten): Beschrijvingen van tool-bijwerkingen, geclassificeerd op basis van omkeerbaarheid en externalisatie-timing.
Frontiers (Frontiers): Per-resource monotone cursors op de epoch-tijdlijn. De orchestrator verplaatst de frontier van een resource pas wanneer deze heeft gecertificeerd dat er geen werk uit een eerdere epoch op die resource meer kan arriveren.
Transactions (Transacties): Groepen read scopes en effecten die samen moeten settelen. De granulariteit wordt bepaald door de integratielaag (bijv. een agent actie-fase).

Lifecycle en State Machine

Een transactie doorloopt de staten: open $\to$ sealed $\to$ waiting on progress $\to$ {committed, aborted}.

Open: Adapters registreren read scopes en faseren effecten.
Seal: De orchestrator bevriest de transactie-footprint (geen nieuwe reads/effects toegestaan) nadat alle in-flight calls zijn geretourneerd.
Wait: De transactie wacht tot de per-resource frontiers geavanceerd zijn.
Commit/Abort:
- Commit: Gebeurt pas wanneer frontier(r) >= e(T) voor elke scope r in de footprint van de transactie. Dit certificeert dat er geen conflicterend eerder werk op die resource kan arriveren. Atomix laat vervolgens gebufferde effecten vrij, accepteert geexternaliseerde reversibele effecten als definitief, en voert onomkeerbare effecten uit.
- Abort: Onderdrukt niet-vrijgegeven effecten en compenseert geexternaliseerde reversibele effecten in omgekeerde afhankelijkheidsvolgorde.

Effect Taxonomie & Adapters

Atomix classificeert effecten in drie uitvoeringspaden via tool adapters (die geen modificatie van de onderliggende tools vereisen):

Reversible (Omkeerbaar): Voert eager uit; wordt gecompenseerd bij abort (bijv. restitueerbare boekingen).
Bufferable (Bufferbaar): Stel uitvoering uit; geeft een gefaseerde bevestiging terug; past toe bij commit of verwijdert bij abort (bijv. lokale bestandsacties).
Irreversible-Gated (Onomkeerbaar-Gated): Houdt de call vast bij de adapter gate; geeft een gekwiste bevestiging terug; voert pas uit bij commit (bijv. e-mails, overboekingen).

Veiligheidsinvarianten

Het systeem vertrouwt op een trusted computing base: (i) adapter-mediatie van alle effect-dragende calls, (ii) correcte adapter-metadata (scopes, keys, handlers), en (iii) strikte naleving van frontier-advancement contracten. Dit garandeert:

Atomicity by Class (Atomiciteit per klasse): Bufferbare effecten zijn alles-of-niets; reversibele effecten worden gecompenseerd; onomkeerbare effecten blijven gated.
Progress-Safe Settlement (Progressie-veilige settlement): Frontier-ordening gecombineerd met scope-on-read en abort-on-stale retry zorgt voor per-resource commit-order settlement.

3. Belangrijkste Bijdragen

Transactional Settlement Model: Een formeel model dat sealing, read/effect scopes, per-resource progress predicates en effect-class-bewuste commit/abort combineert.
Runtime Implementatie: Een Python runtime (~2.000 LOC) die uitvoering scheidt van settlement middels adapters, een transactie manager en een progress tracker.
Uitgebreide Evaluatie: Een uniforme harness die foutherstel, frontier-gated isolatie en irreversible-effect gating evalueert tegen negen mechanism-gematchte baselines (inclusief Checkpoint-Replay, Saga, TCC en diverse locking strategieën).

4. Experimentele Resultaten

De evaluatie gebruikte real-world workloads ( $\tau$ -bench retail, WebArena, OSWorld) en synthetische stress-tests met geïnjecteerde fouten.

Foutherstel (RQ1): Onder zware foutinjectie ( $f_p=0.30$ ) behield Atomix 57% clean task success, terwijl non-Checkpoint-Replay baselines naar 0–7% zakten. Atomix was statistisch gelijk aan Checkpoint-Replay (53%) op het gebied van herstel alleen, maar presteerde beter in gecombineerde stress-tests.
Isolatie (RQ2): In scenario's met multi-agent contentie registreerde Atomix 0 conflict-cycle witnesses (stale writes). In tegenstelling tot Workflow-Lock, dat ~112ms wachttijd veroorzaakte zelfs op disjoint resources, bereikte Atomix nul wachttijd terwijl de veiligheid behouden bleef.
Irreversible Gating (RQ3): Atomix behaalde 0/500 leaks van ongeldige onomkeerbare sends (bijv. e-mails verzonden tijdens afgebroken transacties). In contrast hiermee lekte Saga-Compensation 80% van dergelijke sends, en Checkpoint-Replay lekte 40%.
Gecombineerde Stress: Atomix was Pareto-best op het gezamenlijke oppervlak van veiligheid en prestatie. Het behaalde top-tier "run-clean" rates met nul wachttijd, nul afgewezen commits en minimale integratie-overhead (17 regels code per adapter), terwijl de gekoppelde baselines faalden op ten minste één as (bijv. hoge latentie, hoge afwijzingspercentages of hoge integratiekosten).

5. Betekenis en Claims

Het artikel beweert dat Atomix een kritiek gat in agentische workflows dicht door de uitvoering expliciet te scheiden van de settlement.

Nieuwigheid: Het is het eerste systeem dat Sagas, Try-Confirm-Cancel (TCC) en streaming watermarks specif eigenlijk combineert voor de LLM tool-interface, wat speculatieve uitvoering mogelijk maakt zonder "residue van verliezende takken" achter te laten.
Praktiseerbaarheid: Het vereist geen modificatie van bestaande tools, enkel de toevoeging van lichtgewicht adapters.
Beperkingen: De auteurs merken bescheiden op dat Atomix een single-process runtime prototype is. Het claimt geen gedistribueerde crash-safe exactly-once delivery, semantische validatie of volledige gedistribueerde deployment (hoewel het model compatibel is met dergelijke extensies). Het erkent ook dat atomaire externalisatie over meerdere heterogene onomkeerbare endpoints onmogelijk blijft boven de tool-laag zonder tool-zijde 2PC.

Samenvattend biedt Atomix een runtime-laag die ervoor zorgt dat LLM-agenten de externe staat betrouwbaar kunnen muteren, waardoor gedeeltelijke effecten, verouderde writes en onomkeerbare lekken worden voorkomen, zelfs in de aanwezigheid van fouten en gelijktijdige speculatie.