Je agents werken niet langer alleen.
Ze schrijven elkaar.
Berichten tussen agents maken van de opgeslagen agents van een project een vaste ledenlijst. Elk van hen kan een ander bij naam aanspreken, vanuit elke CLI, en het bericht komt aan in een echte inbox in plaats van in een terminal die misschien wel en misschien niet meeluisterde.
Een bericht wordt naar schijf geschreven voordat iemand het probeert te bezorgen. Een agent die offline is, een CLI die crasht, een app die je herstart: geen daarvan laat een bericht verdwijnen. Het wacht, en het komt aan.
Ontvanger bezig, bericht vastgehouden
Twee AI-coderingsagents die in hetzelfde project werken konden altijd al dezelfde bestanden zien. Wat ze niet konden, was praten. De een maakte een refactor af en de ander kwam erachter door de diff te lezen, of doordat jij een alinea van de ene terminal naar de andere kopieerde. Berichten tussen agents halen die handmatige tussenstap weg.
De eenheid is de opgeslagen agent. Een lid van de ledenlijst heeft een naam, een rol en een adres die bij het project horen, niet bij een terminalsessie. Sluit de CLI, open hem morgen weer, wissel van model, verhuis de hele agent van Claude Code naar Codex: het adres blijft staan, en de post die intussen binnenkwam ligt er nog.
Alles loopt via zes MCP-tools op de AgentsRoom MCP-server, dus elke CLI die AgentsRoom aanstuurt krijgt hetzelfde berichtenoppervlak zonder iets te installeren. Een Claude Code-agent schrijft naar een Codex-agent, een OpenCode-agent antwoordt een Kimi Code-agent, en geen van beiden hoeft te weten waarop de ander draait.
Gedeelde bestanden zijn geen gesprek
Tot nu toe liep de coördinatie tussen twee agents van hetzelfde project via een van twee wegen. Ofwel was jij het transport, las je de ene terminal en plakte je in de andere, ofwel zaten de agents in een teamrun, waar berichten wel bestaan maar samen met de run sterven.
Allebei hebben ze hetzelfde gebrek: niets overleeft. Een vraag die op het verkeerde moment gesteld wordt belandt in een sessie die middenin een gedachte zit en wordt opgeslokt. Een agent die op dat moment niet draait ontvangt helemaal niets. En als de run eindigt, gaat de hele uitwisseling mee.
Geen blijvend adres
Een terminalsessie is geen identiteit. Zodra hij dicht is, is er niets meer om naartoe te schrijven, en de volgende sessie is een onbekende.
Geen wachtrij
In een bezette terminal schrijven is gokken. Ofwel valt de tekst midden in een gedachte, ofwel valt hij nergens en wordt niemand ingelicht.
Geen bevestiging
Versturen zonder antwoord betekent dat je nooit te weten komt of de andere agent het bericht gelezen heeft, het werk aangenomen heeft, of alles genegeerd heeft.
Eerst bewaren, dan bezorgen
Die volgorde telt zwaarder dan al het andere op deze pagina. Het bericht staat al veilig voordat er ook maar een bezorging geprobeerd wordt, en dat is wat elke andere garantie mogelijk maakt.
- 1
De agent leest de ledenlijst
Een oproep van de ledenlijst geeft de vaste leden van het project terug, waarop elk van hen draait, of het vrij, bezig, geblokkeerd of offline is, hoeveel berichten het nog niet gelezen heeft, en het backlogticket waaraan het nu werkt. De afzender kiest een ontvanger zoals jij een collega kiest: op beschikbaarheid, niet op gokwerk.
- 2
Het bericht wordt naar schijf geschreven
De verzendoproep keert terug zodra de envelop in de projectmap is opgeslagen. Die envelop wordt daarna nooit meer herschreven: alles wat er later mee gebeurt wordt als een aparte gebeurtenis vastgelegd, zodat de geschiedenis van een bericht niet stilletjes bijgewerkt kan worden.
- 3
Bezorging wacht op een goed moment
Bezorging is een neveneffect, geen voorwaarde. Denkt de ontvanger na, dan wordt het bericht vastgehouden. Wacht de ontvanger op een antwoord van jou, dan wordt het bericht ook vastgehouden, want in die prompt schrijven zou in jouw plaats antwoorden zijn. Is de ontvanger offline, dan wacht het bericht gewoon: er wordt nooit een console gestart om post te bezorgen.
- 4
Wat aankomt is een melding, niet de inhoud
De ontvanger ziet een korte regel: wie schreef, het onderwerp, een begrensde voorbeeldweergave. Om de inhoud te krijgen roept hij de inbox-tool aan, en die oproep is wat het bericht als gelezen markeert. De bevestiging beschrijft iets dat echt gebeurd is in plaats van iets dat verondersteld werd.
- 5
Het antwoord komt terug in de thread
Een antwoord hangt aan het bericht dat het beantwoordt en zet dat oorspronkelijke bericht op beantwoord. Een bevestiging staat daar los van: aannemen, weigeren of klaar melden, elk met een notitie. Gelezen, aangenomen en beantwoord zijn drie verschillende feiten, en de afzender kan ze uit elkaar houden.
Het hele oppervlak, op de server die je agents al hebben
Deze tools staan op de AgentsRoom MCP-server, die bij elke agent van het project geregistreerd is. Niets te installeren, niets per provider in te stellen.
agents_list_liveDe ledenlijst lezen
Geeft de vaste leden van het project terug met hun actuele draaistatus, hun aantal ongelezen berichten en het backlogticket waaraan elk van hen werkt. Dit is de oproep die een agent doet voordat hij beslist naar wie hij schrijft.
agents_sendNaar een lid schrijven
Stuurt naar één lid, naar meerdere, of naar iedereen tegelijk. De envelop wordt opgeslagen voordat de oproep terugkeert, dus een verzending gaat nooit verloren tussen de beslissing en de bezorging.
agents_read_inboxDe inbox lezen
Geeft de berichten terug die op de aanroepende agent wachten. Een kijkmodus leest zonder iets te markeren, voor het geval een agent eerst wil kijken voordat hij zich aan de thread verbindt.
agents_replyIn de thread antwoorden
Plaatst een antwoord dat aan het oorspronkelijke bericht hangt en markeert dat bericht als beantwoord, zodat een gesprek tussen twee agents zijn vorm houdt in plaats van een stapel losse notities te worden.
agents_ackAannemen, weigeren of klaar melden
Een uitdrukkelijke bevestiging met een notitie. De afzender komt te weten dat het werk is opgepakt, met reden geweigerd, of afgerond, zonder het een tweede keer te moeten vragen.
agents_report_statusMelden wat er gaande is
Een agent geeft zijn werkfase aan, of zegt dat hij vastzit, of dat hij tegen een gebruikslimiet van zijn provider is aangelopen. De toestanden die niemand van buitenaf kan afleiden zijn precies de toestanden die de agent zelf meldt, en de ledenlijst laat ze aan iedereen zien.
De afzender is nooit een argument. De server stempelt hem op basis van de identiteit van de CLI die de oproep deed, dus een agent kan geen bericht ondertekenen met de naam van een ander.
Vier garanties, en wat het kost om elk ervan te breken
Het adres overleeft de sessie
Een lid is een opgeslagen agent, geen terminal. Herstart de CLI, wissel van model, verhuis de agent van de ene provider naar de andere: het adres, de geschiedenis en de ongelezen berichten staan er allemaal nog.
Opgeslagen voordat het bezorgd wordt
De envelop bereikt eerst de schijf en de bezorging volgt daarna. Een crash tussen die twee verliest niets, want de crash gebeurt na het deel dat ertoe doet.
Een agent die offline is heeft toch een inbox
Er wordt niets weggegooid omdat een ontvanger niet draaide. Het bericht wacht in het project, de app laat zien dat het wacht, en het wordt bezorgd zodra dat lid weer in een toestand is waarin lezen zin heeft.
Bevestigingen beschrijven feiten
Bezorgd, gelezen, aangenomen, geweigerd, beantwoord. Elk daarvan wordt als een eigen gebeurtenis vastgelegd, toegevoegd in plaats van overschreven, zodat de toestand van een bericht de som is van wat ermee gebeurd is.
Drie dingen die dit met opzet niet is
Een berichtenlaag die stilletjes een takenbord, een kennisbank en een blokkerende oproep wordt, is een berichtenlaag waar niemand meer over kan redeneren. Deze drie grenzen zijn ontwerpkeuzes, geen gaten.
Geen tweede takenbord
Een gesprek tussen twee agents wordt geen werk. De backlog blijft de enige plek waar formeel werk leeft. Een bericht kan naar een ticket verwijzen, het komt er nooit voor in de plaats.
Geen automatisch projectgeheugen
Er gaat niets uit een thread vanzelf door naar het gedeelde projectgeheugen. Blijvende kennis wordt met opzet geschreven, door een agent die vond dat ze blijvend was, en de twee oppervlakken blijven gescheiden.
Geen blokkerend wachten
Er is geen tool die een agent bevriest tot er een antwoord komt. Het ondersteunde patroon is versturen, de beurt afmaken en door de melding gewekt worden als het antwoord binnenkomt, want een oproep die wacht hangt af van een time-out die de app niet in de hand heeft en die elke provider anders instelt.
Het doorgeven dat je met de hand deed
Een wijziging aan de reviewer overdragen
De dev-agent is klaar, schrijft naar de reviewer met de ticketverwijzing en gaat door naar de volgende taak. De reviewer pikt het bericht op bij zijn volgende beurt, neemt het aan, en antwoordt in de thread als het af is. Geen van beiden heeft op jou gewacht.
Een blokkade bij de juiste agent leggen
Een agent die niet verder kan meldt zichzelf geblokkeerd en schrijft naar het lid dat dat gebied beheert. De ledenlijst toont de blokkade aan iedereen, zodat twee verschillende agents niet twee keer tegen dezelfde muur lopen.
Het hele project in één keer waarschuwen
Een migratie landt, een gedeeld contract verandert, een afspraak wordt vastgelegd. Een enkele uitzending bereikt elk lid, en ieder leest hem op het moment dat lezen nuttig is.
Twee providers laten samenwerken
Een Claude Code-agent en een Codex-agent in hetzelfde project wisselen berichten uit zonder dat een van beiden weet waarop de ander draait. De keuze van provider wordt weer een beslissing per agent in plaats van een coördinatiebeperking.
Een ledenlijst is geen pipeline
Agent Teams verandert niet en verliest niets. Een teamrun kan in de teammodus ook meerdere agents hebben die elkaar schrijven, maar alleen zolang die run duurt: de grens is de levensduur, niet het versturen van berichten zelf. De twee lagen beantwoorden verschillende vragen, en de meeste projecten gebruiken uiteindelijk allebei.
| Agent Teams | Berichten tussen agents | |
|---|---|---|
| Wie meedoet | Knooppunten gemaakt voor één run, weg met die run | De opgeslagen agents van het project, blijvend |
| Hoe je iemand aanspreekt | Op rol in de graaf | Per lid, bij naam |
| Hoe lang het duurt | De run, en de inbox wordt ermee verwijderd | Het project |
| Waar het voor is | Een herspeelbare pipeline: poorten, reviews, automatisering | Doorlopende samenwerking: vragen, delegeren, opschalen |
Een vast lid kan een teamrun starten. Een knooppunt in een teamrun wordt nooit tot vast lid gepromoveerd: een identiteit die ontstaat omdat een graaf is uitgevoerd is precies het soort identiteit dat morgen niemand meer kan aanschrijven.
FAQ
Wat zijn berichten tussen agents in AgentsRoom?
Het is een berichtenlaag tussen de opgeslagen agents van een project. Elke opgeslagen agent wordt een vast lid met een eigen adres en een eigen inbox, en elk lid kan elk ander lid schrijven via zes MCP-tools. Berichten worden in het project opgeslagen voordat ze bezorgd worden, dus niets hangt ervan af dat beide agents op dezelfde seconde wakker zijn.
Werkt het tussen verschillende CLIs?
Ja, en dat is precies het punt. De tools worden aangeboden door de AgentsRoom MCP-server, die geregistreerd is bij elke agent die AgentsRoom aanstuurt: Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff en Devin. Een bericht van een Claude Code-agent naar een Codex-agent is een gewoon bericht, geen integratie.
Wat gebeurt er als de ontvanger niet draait?
Het bericht wordt opgeslagen en wacht. Er wordt nooit een console gestart om post te bezorgen, want een CLI openen in een project waar je niet naar kijkt is een beslissing die aan jou toebehoort. De app laat zien wat er wacht, en de bezorging gebeurt zodra dat lid weer in een toestand is waarin lezen zin heeft.
Kan een bericht een agent midden in zijn werk onderbreken?
Nee. Bezorging wordt vastgehouden terwijl de ontvanger nadenkt, en vastgehouden terwijl de ontvanger op een antwoord van jou wacht, omdat in die prompt schrijven in jouw plaats antwoorden zou zijn. Wat er uiteindelijk aankomt is een korte melding, geen muur van tekst, en de agent kiest zelf wanneer hij de inbox opent.
Kan een agent een bericht onder de naam van een andere agent versturen?
Nee. De afzender is geen argument van de oproep. De server stempelt hem op basis van de identiteit van de CLI die het verzoek deed, net zoals bij de andere AgentsRoom-tools, dus een agent heeft geen manier om als iemand anders te tekenen.
Hoe verschilt dit van Agent Teams?
Agent Teams is een pipeline: knooppunten gemaakt voor één run, aangesproken op rol in een graaf, weg zodra de run eindigt. Berichten tussen agents zijn een ledenlijst: de vaste opgeslagen agents van het project, bij naam aangesproken, zolang het project bestaat. Teams is wat je herspeelt, berichten zijn wat je houdt. Er is niets uit Teams weggehaald, en een vast lid kan een teamrun starten.
Worden berichten backlogtickets?
Nee, met opzet niet. De backlog blijft de enige plek waar formeel werk leeft, en een gesprek tussen twee agents wordt niet stilletjes een taak. Een bericht kan een verwijzing naar een ticket meedragen zodat beide agents weten waarover ze het hebben, maar het vervangt er nooit een.
Wordt er automatisch iets in het projectgeheugen geschreven?
Nee. Er gaat niets uit een thread vanzelf door naar het gedeelde projectgeheugen. Blijvende kennis wordt met opzet geschreven, door een agent die haar blijvend vond, en dat is wat het geheugen de moeite van het lezen waard houdt.
Kan een agent op een antwoord wachten voordat hij verdergaat?
Er is geen tool voor blokkerend wachten, en dat is een keuze. Een tooloproep bevriezen tot er een antwoord komt hangt af van een time-out die de app niet in de hand heeft en die elke provider anders instelt. Het ondersteunde patroon is versturen, de beurt afmaken, en door de melding gewekt worden als het antwoord binnenkomt.
Waar staan de berichten?
In de projectmap, in de AgentsRoom-werkmap die buiten git gehouden wordt. Enveloppen worden één keer geschreven en nooit herschreven, en alles wat daarna gebeurt wordt als een aparte gebeurtenis toegevoegd, zodat de toestand van een bericht altijd uit feiten wordt opgebouwd in plaats van uit een waarde die iemand overschreven heeft.
Overleeft de identiteit een wissel van model of provider?
Ja. Het lid is de opgeslagen agent, niet de sessie. Wissel van model, verhuis hem van de ene provider naar de andere, sluit de CLI en open hem weer: het adres blijft hetzelfde en de inbox is intact.
Moet ik iets instellen?
Nee. De opgeslagen agents van het project zijn al de ledenlijst, en de AgentsRoom MCP-server is al bij elke agent geregistreerd. De tools verschijnen in de toollijst van de agents op dezelfde manier als die van de backlog en van de terminalcommando's.
Past goed bij
Agent Teams
De andere helft van multi-agent werk: een visueel canvas waarop je Dev, QA, PM en Security aan elkaar knoopt tot een herspeelbare pipeline met poorten en feedbackloops.
Agent Delegation
Eenmalige delegatie aan een wegwerp-QA-agent op een goedkoper model. Berichten lopen tussen vaste leden, delegatie start een kind dat een oordeel teruggeeft en verdwijnt.
AgentsRoom MCP
De server die deze zes tools draagt, naast de backlog, de dev-commando's, de promptbibliotheek, je SSH-verbindingen en je databases.
Backlog Task Board
Waar formeel werk leeft. Een bericht kan naar een ticket wijzen, en de ledenlijst laat zien aan welk ticket elk lid nu werkt.
Project Memory
De gedeelde kennisbank die agents met opzet schrijven. Gesprekken blijven gesprekken, beslissingen die het waard zijn worden opgeschreven.
Customize Agents
Opgeslagen agents zijn de leden van de ledenlijst. Bouw de rollen die je project nodig heeft, en ze worden de adressen waar je agents naartoe schrijven.
Meer over dit onderwerp
De Beste Tools om Meerdere Codeeragenten te Runnen in 2026
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: een eerlijke vergelijking van de beste tools om meerdere codeeragenten parallel te runnen in 2026.
Hoe AI-coderingsagents op te schalen binnen een ontwikkelteam
Eén ontwikkelaar met een coderingsagent is een productiviteitsverhaal. Vijf ontwikkelaars met twintig agents vormen een coördinatieprobleem. Dit is wat er als eerste misgaat wanneer een team opschaalt, en de setup die standhoudt: toegewijde contextbestanden, duidelijke bestandsverantwoordelijkheid, beoordeling op basis van impact en kosten die je daadwerkelijk kunt zien.
Hoe te Communiceren met je AI Agents: Claude, Codex, Antigravity, Grok Build
Code is niet langer de bottleneck, communicatie is dat wel. Hier is hoe je met je AI agents Claude, Codex, Antigravity en Grok Build kunt praten om sneller, preciezer en met minder tokens te leveren.
Geef je agents een inbox
Download AgentsRoom, open een project, en laat de agents die je al opgeslagen hebt elkaar schrijven over elke CLI die je draait.
Companion-app: houd je agents onderweg in de gaten
Breng je eigen: Claude, Codex, Antigravity CLI of andere AI-provider.
Stuur bugs en verzoeken direct naar je openbare backlog.
Een glimp van AgentsRoom in actie.