Welkom bij weer een kennis snippet. Stel je voor dat je een bedrijf runt en een team van briljante specialisten inhuurt, een reisplanner van wereldklasse, een expert in onboarding van werknemers en een IT-supportmedewerker. Maar ze praten niet met elkaar. Telkens wanneer een taak er twee nodig heeft, moet je zelf tussen de bureaus heen en weer lopen en de informatie overdragen. Dat is precies hoe de meeste AI-agents op dit moment werken. Ze opereren in isolatie, zelfs wanneer het probleem duidelijk teamwork vereist. Dus, vandaag praten we over hoe agents kunnen communiceren, werk kunnen overdragen en als echte teams kunnen fungeren. Ik ben Mirko Peters. Dit is geen toekomstmuziek. Multi-agent-orchestratie gebeurt nu al en het wordt aangedreven door een protocol genaamd A2A. We beginnen met het probleem, ontleden dat protocol stap voor stap en kijken hoe Microsoft het gebruikt in Copilot Studio en Azure AI.

Pak je koffie en laten we erin duiken. Dus, wat is het werkelijke probleem? AI-agents zijn vandaag de dag precies als die geïsoleerde specialisten. Ieder heeft zijn eigen kennis, tools en doelen. Een weer-agent kent de voorspelling. Een hotel-agent kent de beschikbaarheid van kamers, maar ze delen niets met elkaar. Stel je nu eens voor dat een gebruiker vraagt om een reis naar Seattle volgende week met een hotel in de buurt van het kantoor. Een enkele agent zou tegelijkertijd een weer-expert, reisexpert en lokale zakelijke expert moeten zijn. Dat betekent enorme, loggen prompts die alle mogelijke capaciteiten in één systeem proppen en die prompts lopen constant vast. De oude oplossing was maatwerkcode. Je schreef een brug tussen de weer-agent en de hotel-agent, dan nog een tussen de hotel-agent en de vlucht-agent en nog een voor de agenda-agent. Dat werkt in het begin, maar elke keer als je een nieuwe agent toevoegt, bouw je weer een nieuwe integratie.

Al snel heb je een spaghetti-nachtmerrie van punt tot punt verbindingen waarbij één wijziging alles kapot maakt. De productiviteitswinst die je AI moest opleveren, wordt volledig opgeslokt door onderhoudswerk. Laten we eens kijken naar de echte zakelijke pijn. Jouw organisatie heeft al processen met overdrachten. Er wordt een ticket aangemaakt, iemand sorteert het, iemand lost het op, iemand registreert het, en elke stap is een overdracht. In de oude wereld automatiseer je elke stap met een aparte agent en besteed je daarna weken aan het aan elkaar knopen ervan. Maar wat als er een protocol was waarmee agents elkaar kunnen ontdekken en samenwerken zonder enige aangepaste bruggen? Dat is precies wat A2A doet. In gewone taal, A2A is een standaardmanier voor agents om met elkaar te praten, werk door te geven en als tien dingen voor elkaar te krijgen. Wat is A2A? De eenvoudige definitie. A2A staat voor agent to agent.

Het is een open protocol waarmee AI agents direct met elkaar kunnen praten, ongeacht wie ze heeft gebouwd. Je kunt het zien als HTTP voor agents. HTTP is de taal die webbrowsers en servers gebruiken om te communiceren, en A2A doet hetzelfde voor agents. Een agent gebouwd door je IT-team op Microsoft Copilot Studio kan praten met een agent van een ander bedrijf op Google Cloud, zolang ze bij de A2A spreken. Dit is bovendien geen klein project. A2A wordt gesponsord door acht grote bedrijven, waaronder Google, Microsoft, Cisco, Salesforce, SAP en andere, en wordt gehost door de Linux Foundation. Versie 1.0 is stabiel en klaar voor echt gebruik, wat betekent dat geen enkele leverancier het protocol controleert. Het is geen Google of Microsoft ding. Het is een industrieding. Het ontwerp is opzettelijk eenvoudig. A2A bouwt voort op bestaande webstandaarden zoals HTTP en JSON-RPC, dingen die elke ontwikkelaar al kent.

Niets exotisch of proprietair aan. Dat maakt het voor bedrijven eenvoudig om te adopteren zonder hun bestaande infrastructuur te slopen. Nu heb je misschien wel gehoord van een ander protocol genaamd MCP, of modelcontextprotocol. Dit is het verschil. MCP is agent naar tool, wat betekent dat het een agent verbindt met externe databronnen en APIs. A2A is agent naar agent en verbindt agents direct met elkaar. Het zijn geen concurrenten, ze zijn complementair. Zie MCP als de verticale verbinding van een agent naar zijn tools en A2A als de horizontale verbinding tussen agents onderling. Nog één ontwerpkeuze, A2A behandelt agents als ondoorzichtig. Dus, wanneer de ene agent met de andere praat, ziet deze niet de interne redenering, tools of privégegevens van de andere agent. Hij ziet alleen de taak die hij stuurde en het resultaat dat hij terugkrijgt. Dat beschermt privacy en intellectueel eigendom.

Een weeragent hoeft niet te weten hoe de hotel agentkamers boekt, hij hoeft alleen de voorspelling door te geven. Laten we nu naar het eerste puzzelstuk kijken, de agentkaart. De agentkaart, het CV. Elke A2A-compatibele agent publiceert iets dat een agentkaart wordt genoemd. Die kaart is een machineleesbaar document dat op een standaard URL op het domein van de agent staat, specifiek op het pad well-known agentkaart JSON. Als je weet waar een agent zich bevindt, kun je de kaart ophalen en alles leren wat je nodig hebt om ermee te werken. Zie de agentkaart als een CV of een visitekaartje. Het vertelt andere agents wie je bent en wat je kunt doen. De kaart bevat de naam van de agent, een platte tekstbeschrijving van zijn mogelijkheden en vaardigheidstekst die helpen bij de vindbaarheid. Het vermeldt ook de endpoint URL waar het verzoeken accepteert, de authenticatieverrijsten en de invoer- en uitvoervormaten die het ondersteunt.

Hier is een concreet voorbeeld. Stel, je hebt een weerspecialist agent. De agentkaart zegt, ik kan het actuele weer en een vijfdaagse voorspelling voor elke stad geven. Het vermeldt zijn API endpoints, aangezien het een stadsnaam accepteert en temperatuur en omstandigheden in JSON-formaat teruggeeft. Dat is alles. Het is gewoon een duidelijke verklaring van wat het kan doen, zonder geheimen of blootgelegde interne logica. Ontdekking werkt als volgt. Een orchestrator-agent heeft een lijst met bekende agent URL's, of je kunt deze zelf configureren. Wanneer er een taak binnenkomt, haalt de orchestrator de agentkaarten op, leest de beschrijvingen en beslist welke agent de beste match is. De weerkaart zegt weer, dus weer taken gaan daarheen. De hotelkaart zegt hotels, dus hotel taken gaan daarheen. Merk op dat er geen centraal register nodig is. Agents hoeven zich niet in te schrijven bij een wereldwijde directory.

Ze publiceren hun kaart gewoon op een bekende locatie en elke andere agent die de URL kent, kan ze vinden. Dat is een bewuste ontwerpkeuze die het systeem gedecentraliseerd en flexibel houdt. Je kunt een nieuwe specialist aan je netwerk toevoegen door de orchestrator de URL te geven en de ontdekking gebeurt automatisch. Dus de orchestrator weet wie er beschikbaar is. Maar hoe dragen ze het werk feitelijk over? Hoe A2A communicatie werkt. De orchestrator weet dus welke agents beschikbaar zijn via de agentkaart. Maar hoe dragen deze agents het werk nu echt aan elkaar over? Het antwoord is simpel. Alle communicatie verloopt via HTTP met JSON-RPC berichten. Hetzelfde protocol dat de meeste webservices vandaag de dag aandrijft. Niets aangepast of ingewikkeld. Gewoon standaard webverkeer dat tussen twee agents vloeit. Dit is het punt. Niet alle taken zijn hetzelfde. A2A ondersteunt drie verschillende interactiepatronen, afhankelijk van wat je nodig hebt.

Directe response verwerkt snelle zoekopdrachten waarbij de externe agent onmiddellijk kan antwoorden. Je verstuurt een verzoek, het antwoord direct en je bent klaar. Een weerspecialist om de voorspelling van vandaag vragen werkt precies zo asynchroon antwoord, klaar. Streaming verwerkt de langere taken. Misschien moet de specialist agent meerdere databases doorzoeken of een complexe analyse uitvoeren. In plaats van je te laten wachten op één enkel antwoord, verstuurt de agent status updates terwijl hij werkt via servers en events. Je ontvangt voortgangsrapporten tijdens het proces en het eindresultaat volgt aan het einde. Het volgen van een pakketbezorging werkt op dezelfde manier. Je ziet elke stap terwijl deze plaatsvindt. Asynchrone notificatie verwerkt de langlopende taken waarbij de externe agent minuten, uren of zelfs dagen nodig kan hebben. Het onboarden van werknemers is een goed voorbeeld.

De ene specialist regelt IT-accounts, terwijl de andere de secundaire arbeidsvoorwaarden over meerdere dagen afhandelt. De client-agent dient een verzoek in, ontvangt een taak-idee en gaat door met zijn werk. Later stuurt de externe agent het resultaat via een webhoek. De client kan ook op elk moment de voortgang controleren door dat taak-idee te pollen. Elke interactie volgt dezelfde structuur, alles georganiseerd als een taak. Wanneer de client een verzoek stuurt, maakt de externe agent een taak aan en geeft een taak-idee terug. Dat idee wordt de tracking code voor alles wat volgt. Berichten in die taak hebben een rol die aangeeft wie het verstuurde en onderdelen, zoals platte tekst, binaire data zoals afbeeldingen of documenten, JSON-payloads of URL's naar bestanden elders. Authenticatie volgt de standaard webconventies, OAuth, API-sleutels en bearer-tokens. De gebruikelijke verdachte, niets nieuws om te leren.

De agentkaart vertelt de client welke authenticatie-methode moet worden gebruikt en de client handelt dit af zoals bij elke andere API-aanroep. Zo ziet dit er in de praktijk uit. Stel dat de orchestrator weergegevens nodig heeft voor een reis. Hij stuurt een taak naar de weerspecialist. De weerspecialist bevestigt het verzoek, start de verwerking en streamt voortgangsupdates terug. Gegevens ophalen, resultaten parseren, klaar, dan verstuurt hij de definitieve voorspelling. De orchestrator ziet nooit de interne tools, API-sleutels of het redeneerproces van de weeragent. Hij ziet alleen de output. Dat is het belangrijkste ontwerpprincipe, duidelijke grenzen tussen agents en geen lekkende interne status. Maar A2A alleen is niet genoeg. Je hebt een slimme baas nodig om al deze specialisten te coördineren. Dat brengt ons bij het orchestrator-specialist-patroon. Het orchestrator-specialist-patroon.

Hier komt alles samen. Het orchestrator-specialist-patroon is tegenwoordig de meest gebruikelijke architectuur in multi-agentsystemen. Zie het als een bedrijf met afdelingen, IT, Hour, Finance. Elk handelt zijn eigen gebied af. Je hebt een centrale beslisser die werk doorstuurt naar gespecialiseerde teams. En elk team focust zich op waar het goed in is. De orchestrator houdt het grote geheel in beeld. Hij ontvangt het verzoek van de gebruiker, bepaalt wat er moet gebeuren en beslist welke specialist elk onderdeel kan afhandelen. Als een gebruiker vraagt, plan een reis naar Seattle volgende week. Dan boekt de orchestrator zelf geen vluchten of hotels. Hij weet dat er een vluchtspecialist, een hotelspecialist en een weerspecialist is. Hij verdeelt het verzoek in die stukken en delegeert elk onderdeel. Elke specialist heeft een smalle focus. De ene agent handelt vluchtboekingen af, de andere zoekt hotels en een derde doet de incidenttriage.

Ze hoeven niets van elkaars domeinen te weten. De vluchtspecialist kent vliegmaatschappijen, routes en prijzen. Deze hoeft niets te weten over hotelkamertypes of annuleringsvoorwaarden. Die nauwe focus houdt elk agent simpel, onderhoudsvriendelijk en makkelijk te testen. Dit is het belangrijkste onderdeel. De orchestrator voert de taken niet zelf uit. Deze routeert het werk en voegt resultaten samen. Dat is de enige taak. De rol van de orchestrator is een slimme planner zijn, geen superagent die alles probeert te doen. Wanneer je de orchestrator specialistisch werk laat doen, verlies je het voordeel van dit patroon. Het wordt dan weer een monolithische puinhoop. Pas op voor een veelgemaakte fout. Sommige teams creëren overlappende specialistische domeinen. Twee agenten beweren beide klantenservice of dataopzoeking te kunnen doen, wat zorgt voor routeringsverwarring. De orchestrator weet niet welke hij moet kiezen en gebruikers krijgen inconsistente resultaten.

De oplossing is eenvoudig. Elke specialist beheert een duidelijk begrensd domein zonder overlap. Als twee agenten hetzelfde kunnen, voegt ze dan samen of splits het domein duidelijker. Microsoft's Copilot Studio gebruikt dit patroon standaard. Je hoofdcopilot fungeert als orchestrator, terwijl onderliggende en verbonden agenten als specialisten werken. Wanneer een gebruiker iets vraagt dat meerdere domeinen beslaat, delegeert de hoofdcopilot dit via A2A naar de juiste specialisten. Het is ingebouwd in het platform, dus je hoeft de orchestratielogica niet vanaf nul te programmeren. Het grote voordeel hier is modulariteit. Moet je je hotelbookingsprovider vervangen? Vervang de hotelspecialist zonder de orchestrator of andere agenten aan te raken. Een nieuwe functionaliteit toevoegen? Bouw een nieuwe specialist, registreer deze bij de orchestrator en je bent klaar. Elke agent blijft klein, beheersbaar en onafhankelijk inzetbaar.

Dat is precies het doel van de overstap van monolithische agenten naar een multi-agentsysteem. We hebben dus het protocol, de agentkaarten en het patroon. Laten we dit in actie zien met echte scenario's. Echte voorbeelden van A2A in actie. Hoe ziet A2A er nu eigenlijk uit in de echte wereld? Laten we beginnen met een simpel voorbeeld. Je vertelt je AI-assistent, plan volgende week een reis naar Seattle. Op de oude manier zou die ene assistent alles moeten weten, weer vluchten, hotels, restaurants, alles tegelijk. Dat is veel gevraagd van één prompt. Met A2A breekt de orchestrator het op. Deze stuurt een taak naar een weerspecialist met de vraag naar de voorspelling voor die specifieke dagen. Tegelijkertijd vraagt het een vluchtspecialist om vluchten te zoeken die dinsdagochtend aankomen en donderdagavond terugkeren. En een hotelspecialist om te zoeken naar accommodaties nabij het centrum van Seattle voor drie nachten.

Elke specialist werkt onafhankelijk en ze hoeven niet met de andere agents te communiceren, omdat ze elk hun eigen databronnen, tools en expertise hebben. De orchestrator verzamelt alle resultaten en voegt ze samen tot één antwoord. De gebruiker ziet één enkel antwoord. Dit is de weersverwachting. Dit zijn uw vluchtopties en hier zijn drie hotels in de buurt van het kantoor. Achter de schermen werkt de drie afzonderlijke agents samen zonder enige aangepaste integratiecode. Nu een bedrijfscenario. Stel, er komt een ticket binnen. Mijn laptop maakt geen verbinding met de VPN. De orchestrator begrijpt dat dit een netwerkprobleem is. Het geeft het ticket door aan een runboek specialist die de standaardstappen kent. Controleer de status van de VPN-client, verifieer netwerkreferenties, start de service opnieuw. Die specialist geeft de stappen terug. Vervolgens geeft de orchestrator het resultaat door aan een ticketschrijverspecialist die de oplossing in het systeem logt.

Dit alles gebeurt in seconden zonder menselijke tussenkomst, en het IT-team komt alleen in actie als de geautomatiseerde stappen het probleem niet oplossen. Anboarding van werknemers is een ander voorbeeld, maar dit duurt dagen in plaats van seconden. Een nieuwe werknemer komt bij het bedrijf. De orchestrator activeert een IT-specialist om accounts aan te maken en hardware toe te wijzen, wat een paar uur kan duren. Tegelijkertijd activeert het een hour-benefit-specialist voor inschrijformulieren, en later een facilitair-specialist voor bureau- en toegangspasjes. Elke specialist voert onafhankelijk zijn eigen langlopende taak uit, en de orchestrator volgt de voortgang met behulp van die taakidees waar we het eerder over hadden. Dus als de IT-specialist klaar is, weet de orchestrator dat, en als de facilitair-specialist vertraging heeft, kan het actie ondernemen. De gebruiker ziet één soepel onboarding-proces, maar achter de schermen is het een gecoördineerd team dat over meerdere dagen werkt.

En dit is niet alleen theorie. Coca-Cola Beverages Africa gebruikt al co-pilot studio agents met Dynamics 365 om plannings Cicli te automatiseren. Hun planners besteden voorheen tot wel anderhalf uur per dag aan repetitieve taken. Met multi-agent-orchestratie draaien die Cicli vanzelf. De orchestrator delegeert aan specialisten die verschillende onderdelen van het supply chain-planningsproces afhandelen. Het resultaat is meer dan een uur besparing per persoon per dag door agents met elkaar te laten communiceren in plaats van mensen informatie tussen systemen te laten overbrengen. Het patroon is dus hetzelfde in al deze voorbeelden. Elke agent is een zelfstandige expert die zijn eigen domein kent, over eigen tools beschikt en niets hoeft te weten over de andere agents. A2A biedt een eenvoudige communicatielaag zodat ze kunnen samenwerken zonder aangepaste code. Je krijgt een standaard protocol en een slimme orchestrator zonder bruggen, punt tot punt integraties of onderhoudzorgen.

Microsoft zet hier volledig op in. Laten we kijken waar Copilot Studio en Azure AI in het plaatje passen. Het ecosysteem van Microsoft, Copilot Studio en Azure AI. Dus, waar staat Microsoft in dit geheel? Precies in het centrum. Copilot Studio ondersteunt A2A nu standaard en is algemeen beschikbaar sinds april 2026. Dit is geen preview of beta. Het is klaar voor productie en elke in aanmerking komende klant kan het vandaag gebruiken. Dit is het punt. Je kunt externe agents verbinden met je Copilot Studio orchestrator. Als ik zeg extern, bedoel ik ook echt extern. Agents gebouwd op Google Cloud, AWS of elk ander platform dat het A2A protocol ondersteunt. De orchestrator geeft niet om waar de agent zich bevindt of met welk framework deze is gebouwd. Zolang het A2A spreekt, kan het zich bij het team voegen. De installatie is eenvoudig. In Copilot Studio maak je iets aan dat een connected agent wordt genoemd.

Je plakt het point URL van de agent erin. Copilot Studio haalt automatisch de agentkaart op van de URL, het bekende agentkaart JSON bestand waar we het over hadden. Het leest de mogelijkheden, authenticatieverrijsten en de input- en outputformaten van de agent. Vervolgens bouwt het op de achtergrond een aangepaste connector en kan je orchestrator direct taken delegeren. Je hebt geen handmatig integratiewerk of aangepaste code nodig. Plak simpelweg de URL en je bent klaar. Aan de kant van Azure ondersteunt de Azure AI Foundry Agent Service ook A2A. Het heeft een toegewezen A2A API het point waarmee open source orchestrators zoals Autogen, Longchain en cementen kernel Foundry agents kunnen aanroepen. Dus als je agents hebt gebouwd met die frameworks kun je ze aansluiten op het Microsoft ecosysteem zonder iets te herschrijven. Het werkt in twee richtingen. Microsoft volgt hetzelfde orchestrator-specialist patroon dat we hebben beschreven.

De hoofdagent in Copilot Studio fungeert als de orchestrator, terwijl onderliggende agents en verbonden agents de specialisten zijn. Ieder beheert zijn eigen domein en de orchestrator routeert en voegt samen. Het is dezelfde architectuur, maar dan draaiend op het platform van Microsoft. Maar dit is het punt, er zijn enkele beperkingen waar je vanaf moet weten. Ten eerste voegt elke extra orchestratie stap latentie toe. Als je hoofdagent een verbonden agent aanroept en die agent roept weer een specialist aan, voegt elke stap netwerktijd toe. Bij real-time gesprekken kunnen te veel stappen de ervaring traag laten aanvoelen. Ten tweede zorgt overmatige delegatie voor routeringschaos. Als je te veel specialisten hebt met overlappende domeinen, gaat de orchestrator slechte routeringsbeslissingen nemen. Hou dus het aantal specialisten beheersbaar en hou je domeinen duidelijk gescheiden. Ten derde is er een specifieke beperking bij Fabric Data Agents.

Ze werken niet wanneer de hoofdagent wordt ingezet in Microsoft 365 Copilot. Als je implementatie op M365 is gericht, plan hier dan naar. Deze beperkingen zijn reëel, maar ze zijn beheersbaar. Het platform is volwassen genoeg voor productiegebruik en Microsoft werkt actief aan het dichten van deze gaten. Laten we nu de punten verbinden en het grote geheel bekijken. Verbindingssectie, hoe alles in elkaar past. Laten we een stap terug doen en zien hoe deze onderdelen verbinding maken. A2A is het telefoonsysteem dat agents gebruiken om elkaar te bellen. De agentkaarten, dat is je telefoonboek. Ze laten zien wie je moet bellen en wat elk agent afhandelt. De orchestrator is de receptionist die elk gesprek doorverbindt naar de juiste afdeling. Geen van deze onderdelen werkt alleen. Je hebt ze alle drie nodig. Zonder telefoonboek weet je niet wie je moet bellen. Zonder receptionist is er niemand die het verkeer regelt.

En zonder telefoonsysteem kan een receptionist niemand doorverbinden. Ze werken alleen als een team. Dat is waar modulariteit om de hoek komt kijken. Wanneer je specialisten modulair zijn, kun je nieuwe mogelijkheden toevoegen zonder te breken wat al werkt. Stel dat je een autoverhuurspecialist wilt toevoegen aan je reisassistent. Je bouwt hem, publiceert de agentkaart en geeft de orchestrator de URL. Klaar, de vluchtspecialist en hotelspecialist blijven exact hetzelfde. De orchestrator verandert ook niet. Je plugt gewoon een nieuw onderdeel in en het systeem past zich aan. Omdat het protocol open is, zit je nooit vast aan één leverancier. Je orchestrator kan draaien op Copilot Studio. Je weeragent kan op Google Cloud staan. Je hotelagent op AWS en je interne systemen kunnen op Azure blijven. Ze spreken allemaal dezelfde taal. Dat is het mooie van een open standaard. Het voorkomt vendor lock-in en laat je de beste tool voor elke taak kiezen.

A2A gaat niet over het bouwen van één super slimme agent die alles weet. Het gaat over het bouwen van een flexibel personeelsbestand van specialisten die je kunt herschikken naarmate je behoefte veranderen. Je vervangt je agents niet. Je herschikt ze. Je voegt nieuwe toe. Je ruilt oude in. Het systeem groeit met je mee in plaats van een knelpunt te worden. Dus, wat kun je vandaag met deze kennis doen? Praktische inzichten. Begin klein. Kies één repetitief proces in je organisatie waarbij meerdere systemen betrokken zijn. Bijvoorbeeld ticketoplossing, onboarding van medewerkers of onkostendeclaraties. Iets met duidelijke overdrachten tussen stappen. Bouw vervolgens een prototype met één orchestrator en twee specialisten. Je hebt geen grootse architectuur nodig. Je hebt alleen een werkend voorbeeld nodig waarvan je kunt leren. Gebruik de tools die dit al ondersteunen. Copilot Studio heeft ingebouwde A2A-ondersteuning.

Azure AI Foundry heeft het ook. Je hoeft het protocol niet vanaf nul op te bouwen of aangepaste integratiecode te schrijven. Plak een URL, configureer je agents en begin met delegeren. Pas op voor veel voorkomende valkuilen. Zorg dat de domeinen van je specialisten elkaar niet overlappen. Als twee agents hetzelfde kunnen, voeg ze dan samen of splits het domein beter op. Laat de orchestrator de routing afhandelen, niet de uitvoering. En let op latentie door orchestration hops. Als je respons tijd begint op te lopen, heb je misschien te veel delegatielagen. De beste eerste stap is simpel. Breng de overdrachtsmomenten in je bestaande workflow in kaart. Waar wordt informatie doorgegeven tussen mensen of systemen? Dat zijn de plekken waar agents het kunnen overnemen. Elke overdracht is een kans. Dat is dus het A2A-systeem in een notendop. Drie eenvoudige onderdelen die samenwerken. Agents zijn niet langer geïsoleerd en gaan als een echt team werken.

Kies één workflow met duidelijke overdrachten en bouw daarop voort. Abonneer je voor meer begrijpelijke uitleg en laat een reactie achter als het duidelijk was.