Twee AI-agents kunnen hetzelfde bestand bewerken, beiden ontvangen een "success"-bevestiging, en toch blijft slechts één van hun wijzigingen behouden. In een eenvoudige test met vijf gelijktijdige agents verdwenen vier van de vijf schrijfacties zonder foutmelding of logboekvermelding — een klassieke lost-update-anomalie die de tokens verspilt die zijn betaald voor het verdwenen werk.

Waarom dit probleem ertoe doet

Wanneer een AI-agent een resultaat terugschrijft, brengt de onderliggende service kosten in rekening per gegenereerd token. Als de schrijfactie stilletjes wordt overschreven, brengt de provider nog steeds kosten in rekening voor de berekening die de weggegooide output heeft geproduceerd. In multi-agent-pipelines — agent-swarms, parallelle data-cleaning workers, of elk systeem waarbij meerdere bots een planbestand of een kladblok delen — kunnen deze verborgen verliezen uitmonden in een aanzienlijk kostenlek. De anomalie vormt ook een bedreiging voor de dataintegriteit: vervolgstappen kunnen handelen op basis van onvolledige of verouderde informatie, wat leidt tot een cascade aan fouten.

Hoe de anomalie ontstaat

De hoofdoorzaak is een raceconditie:

  1. Twee (of meer) agents lezen dezelfde versie van een resource, bijvoorbeeld een JSON-planbestand.
  2. Elke agent voert zijn eigen redenering of transformatie uit op basis van die snapshot.
  3. Beide agents voeren een schrijfactie uit naar de gedeelde opslag.
  4. Het opslagsysteem accepteert de tweede schrijfactie en overschrijft de eerste zonder enige conflictdetectie.
  5. Beide agents ontvangen een "ACK" die bevestigt dat de schrijfactie is geslaagd, ook al is de eerste bijdrage verdwenen.

De bevestiging van het opslagsysteem bewijst alleen dat er een schrijfactie heeft plaatsgevonden; het garandeert niet dat de schrijfactie veilig was ten opzichte van andere gelijktijdige updates. Een append-only log, vaak geprezen als een veiligheidsmaatregel, werkt op dezelfde manier: het registreert dat er een schrijfactie heeft plaatsgevonden, maar voorkomt niet dat latere schrijfacties eerdere overschrijven.

Wat een compare-and-set gate doet

Een compare-and-set (CAS) gate voegt een versiecontrole toe voordat de schrijfactie wordt geaccepteerd:

  • Read: De agent haalt het huidige versienummer (of hash) van het bestand op.
  • Compute: De agent voert zijn werk uit en produceert een nieuwe versie van het bestand.
  • Write: De agent stuurt de nieuwe inhoud samen met de versie die hij oorspronkelijk heeft gelezen.
  • Validate: De opslaglaag vergelijkt de meegeleverde versie met de huidige versie. Als ze verschillen, wordt de schrijfactie geweigerd; anders gaat het proces door en wordt de versie verhoogd.

Als de versie is gewijzigd, weet de agent dat zijn weergave verouderd was en moet hij de hele cyclus — lezen, berekenen, schrijven — opnieuw proberen met de nieuwe versie. Dit verandert een onzichtbare overschrijving in een expliciete fout die kan worden gelogd, opnieuw kan worden geprobeerd en kan worden verantwoord.

De prijs van veiligheid

De CAS gate is niet gratis. In dezelfde simulatie met vijf agents:

Scenario Pogingen tot schrijven Succesvolle bijdragen Tokenkosten
Geen CAS gate 5 1 5 eenheden
Met CAS gate 5 5 (na retries) 9 eenheden

De gate voegt extra read-compute-write-cycli toe voor agents die een versieconflict tegenkomen, wat de tokenuitgaven verhoogt. De afweging is duidelijk: zonder de gate verlies je ongemerkt data; met de gate betaal je een bescheiden meerprijs, maar krijg je inzicht in elk conflict.

Hoe vaak komt deze fout voor?

Zelfs met slechts twee agents toonde de test een kans van 75% aan dat een van de schrijfacties verloren zou gaan. Met vijf agents naderde het verliespercentage de 100%. Die cijfers suggereren dat "meestal wel goed" een gevaarlijke aanname is voor elke multi-agent-workflow op productieniveau.

Tegenargument: wanneer je de gate kunt overslaan

Als een systeem één agent per resource draait of strikte serialisatie op een hoger niveau afdwingt, zijn de extra CAS-controles mogelijk overbodig. De risicoberekening moet echter de verborgen kosten van het opnieuw uitvoeren van het mislukte werk en de potentiële impact op de vervolgstappen door ontbrekende gegevens bevatten.

Waar je op moet letten

  • Tooling support: Zoek naar opslag-API's die versienummers of ETags blootstellen en standaard atomaire CAS-bewerkingen bieden.
  • Metrics: Instrumenteer je agents om te registreren hoe vaak een schrijfactie wordt geweigerd vanwege een versieconflict. Een stijgend conflictpercentage geeft aan dat je resources moet opschalen of de workflow moet herontwerpen.
  • Retry strategies: Eenvoudige exponential back-off werkt goed, maar wees je ervan bewust dat herhaalde pogingen het tokenverbruik verhogen. Balanceer de limieten voor retries tegen acceptabel gegevensverlies.
  • Hybrid approaches: Sommige teams combineren een append-only log voor controleerbaarheid met een CAS gate voor consistentie, om zowel een verslag van wat er is gebeurd als bescherming tegen overschrijvingen te garanderen.

Kernpunt

Lost-update-anomalieën veranderen token-gestuurde AI-pipelines in geldverslindende zwarte gaten. Een compare-and-set-versiegat voegt een bescheiden token-overhead toe, maar zet stil gegevensverlies om in een zichtbare, herhaalbare gebeurtenis. Voor elk systeem waarbij meerdere agenten een gedeelde status hebben — databases, planbestanden of scratchpads — is het inbedden van een versiecontrole vóór schrijfacties de goedkoopste verzekering tegen verborgen kosten en beschadigde workflows.