Mijn AI-agents plaatsten resultaten in onze teamchat. Een mens reageerde, en een tweede agent sprong erin zonder het eerste bericht ooit te hebben gezien. De kettingreactie leidde tot gemiste context, dubbel werk en duidelijke fouten. Na het implementeren van een lichtgewicht Inter-Agent Communication Protocol (IACP) in de bestaande memory server en monitoring stack, verdween de ruis en werd de workflow strakker.

Waarom het probleem ertoe deed

In productie zijn AI-agents niet langer geïsoleerde experimenten; ze fungeren als microservices die data ophalen, code genereren of deployments triggeren. Wanneer elke agent alleen met mensen communiceert, worden overlappende verantwoordelijkheden een verborgen race condition. Een willekeurig Slack-bericht lijkt onschadelijk, maar ontwikkelaars verspillen minuten aan het ontwarren van tegenstrijdige outputs, pipelines lopen vast wanneer twee bots hetzelfde repository bewerken, en het vertrouwen in automatisering erodeert.

De ontbrekende schakel: real-time gedeelde status

De meeste teams behandelen agents als "black boxes" die een prompt ontvangen en een resultaat teruggeven, uitgaande van de veronderstelling dat de prompt alle benodigde context bevat. In werkelijkheid delen agents een werkruimte waar de status voortdurend verandert: een repository kan vergrendeld zijn, een service kan offline zijn, of een eerdere analyse kan net zijn voltooid. Zonder een broadcast-mechanisme werkt elke bot vanuit een verouderde snapshot.

IACP bouwen bovenop bestaande tools

In plaats van een volledig nieuw platform te bouwen, heb ik de memory server die de conversatiegeschiedenis opslaat en de monitoring suite die de gezondheid van de agents bijhoudt, uitgebreid. Het protocol voegt vijf concrete mogelijkheden toe:

  • Gestructureerde identiteit – Elk uitgaand bericht bevat een unieke identifier zoals claude@greenmac:8f3a2c. Het formaat vertelt de ontvanger direct wie het bericht heeft gestuurd en vanuit welke instantie, wat ambigue "bot zegt X"-uitspraken elimineert.

  • Injectie van geschiedenis – Voordat een bot een antwoord genereert, haalt deze het meest recente chatsegment op, inclusief berichten van andere agents, en voegt dit toe aan de prompt. De context gaat nooit verloren en het model kan redeneren over wat zijn peers al hebben bijgedragen.

  • Statusovergangen – Agents sturen niet langer voortdurend heartbeats. In plaats daarvan posten ze een statuswijziging — working, blocked, of idle — telkens wanneer hun interne status verandert. Consumenten reageren onmiddellijk, bijvoorbeeld door een afhankelijke taak pas in de wachtrij te plaatsen wanneer de upstream agent idle rapporteert.

  • Advisory Leases – Wanneer een agent exclusieve toegang nodig heeft tot een resource (een repo, een API-endpoint, een compute node), claimt deze een lease met een TTL (time-to-live). Als de agent crasht, verloopt de lease automatisch, waardoor de resource vrijkomt voor anderen en wordt voorkomen dat twee bots op elkaars tenen staan.

  • Inbox-mechanisme – Een "stop hook" pauzeert de workflow van een agent als de inbox ongelezen berichten bevat. De agent moet deze items verwerken voordat de huidige taak wordt voltooid, zodat lopende coördinatiesignalen niet worden genegeerd.

Deze onderdelen vormen samen een eenvoudige, observeerbare communicatielaag die elke deelnemer op de hoogte houdt.

De risico's voor teams die het negeren

Als een team blijft vertrouwen op ad-hoc prompts en handmatige monitoring, stapelen de verborgen kosten zich op:

  • Dubbel werk – Twee agents kunnen identieke rapporten genereren, wat rekenkracht en cloudkosten verbruikt.
  • Resource contention – Gelijktijdige schrijfacties in een codebase veroorzaken merge conflicts die menselijke tussenkomst vereisen.
  • Operationeel risico – Een agent die handelt op basis van verouderde status kan een deployment proberen terwijl een andere al een rollback uitvoert, wat de service destabiliseert.

Door te formaliseren hoe agents hun identiteit, status en resource-claims aankondigen, vermindert IACP deze risico's zonder een zware orchestratie-engine te vereisen.

Tegenargument: extra overhead

Critici stellen dat het injecteren van geschiedenis en het beheren van leases zorgt voor extra latentie en extra codepaden. In omgevingen waar een enkele agent een smalle taak afhandelt, zouden de voordelen van het protocol marginaal kunnen zijn. Echter, de implementatie maakt gebruik van bestaande memory- en monitoringservices, waardoor de extra belasting beperkt blijft. Voor teams die al te maken hebben met verwarring tussen agents, is de afweging duidelijk gunstig.

Wat je hierna moet volgen

Het protocol is nog een prototype, maar de modulaire aard nodigt uit tot integratie met elk taal-agnostisch agent-framework. Potentiële volgende stappen zijn:

  • Het publiceren van een lichtgewicht SDK, zodat ontwikkelaars de vijf hooks kunnen toevoegen zonder de kernlogica aan te passen.
  • Het toevoegen van metrics aan de monitoring suite die statusovergangen en lease churn visualiseren, wat teams helpt bij het opsporen van knelpunten.
  • Experimenteren met policy-lagen die in scenario's met veel verkeer automatisch de leases van bepaalde agents boven die van anderen prioriteren.

Als deze uitbreidingen tractie krijgen, zou IACP een de-facto standaard kunnen worden voor multi-agent productielijnen, vergelijkbaar met wat HTTP deed voor webservices.

Takeaway: Een bescheiden set conventies — wie er spreekt, hoe het recente gesprek eruitziet, wanneer de status van een agent verandert, wie een resource vasthoudt en of er berichten in de wacht staan — kan voorkomen dat AI-agents langs elkaar heen praten en kan een luidruchtige chatroom veranderen in een betrouwbaar coördinatiekanaal.