Status: Experimenteel. Toegevoegd in 2026.1.9.
Overzicht
Broadcastgroepen laten meerdere agents hetzelfde bericht tegelijk verwerken en beantwoorden. Zo kun je gespecialiseerde agentteams maken die samenwerken in één WhatsApp-groep of DM — allemaal met één telefoonnummer. Huidige scope: alleen WhatsApp (webkanaal). Broadcastgroepen worden geëvalueerd na kanaal-allowlists en regels voor groepsactivatie. In WhatsApp-groepen betekent dit dat broadcasts plaatsvinden wanneer OpenClaw normaal zou antwoorden (bijvoorbeeld: bij een vermelding, afhankelijk van je groepsinstellingen). De live WhatsApp-QA-lane bevatwhatsapp-broadcast-group-fanout, die verifieert dat één genoemd groepsbericht verschillende zichtbare antwoorden kan opleveren van twee geconfigureerde agents.
Gebruiksscenario’s
1. Gespecialiseerde agentteams
1. Gespecialiseerde agentteams
Implementeer meerdere agents met afgebakende, gerichte verantwoordelijkheden:Elke agent verwerkt hetzelfde bericht en geeft zijn gespecialiseerde perspectief.
2. Meertalige ondersteuning
2. Meertalige ondersteuning
3. Workflows voor kwaliteitsborging
3. Workflows voor kwaliteitsborging
4. Taakautomatisering
4. Taakautomatisering
Configuratie
Basisinstelling
Voeg een top-levelbroadcast-sectie toe (naast bindings). Sleutels zijn WhatsApp-peer-ID’s:
- groepschats: groeps-JID (bijv.
120363403215116621@g.us) - DM’s: E.164-telefoonnummer (bijv.
+15551234567)
Verwerkingsstrategie
Bepaal hoe agents berichten verwerken:- parallel (standaard)
- sequentieel
Alle agents verwerken tegelijk:
Volledig voorbeeld
Hoe het werkt
Berichtstroom
Routering en toelating
OpenClaw past kanaal-allowlists, regels voor groepsactivatie en geconfigureerd ACP-bindings-eigenaarschap toe.
Broadcastcontrole
Als geen geconfigureerde ACP-binding eigenaar is van de route, controleert OpenClaw of de peer-ID in
broadcast staat.Als broadcast van toepassing is
- Alle vermelde agents verwerken het bericht.
- Elke agent heeft zijn eigen sessiesleutel en geïsoleerde context.
- Agents verwerken parallel (standaard) of sequentieel.
Broadcastgroepen omzeilen geen kanaal-allowlists of regels voor groepsactivatie (vermeldingen/commando’s/enz.). Ze wijzigen alleen welke agents worden uitgevoerd wanneer een bericht in aanmerking komt voor verwerking.
Sessie-isolatie
Elke agent in een broadcastgroep houdt volledig gescheiden:- Sessiesleutels (
agent:alfred:whatsapp:group:120363...versusagent:baerbel:whatsapp:group:120363...) - Gespreksgeschiedenis (agent ziet de berichten van andere agents niet)
- Workspace (aparte sandboxes indien geconfigureerd)
- Tooltoegang (verschillende allow/deny-lijsten)
- Geheugen/context (aparte IDENTITY.md, SOUL.md, enz.)
- Groepscontextbuffer (recente groepsberichten die voor context worden gebruikt) wordt per peer gedeeld, zodat alle broadcast-agents dezelfde context zien wanneer ze worden getriggerd
- Verschillende persoonlijkheden
- Verschillende tooltoegang (bijv. alleen-lezen versus lezen-schrijven)
- Verschillende modellen (bijv. opus versus sonnet)
- Verschillende geïnstalleerde Skills
Voorbeeld: geïsoleerde sessies
In groep120363403215116621@g.us met agents ["alfred", "baerbel"]:
- Alfreds context
- Bärbels context
Best practices
1. Houd agents gefocust
1. Houd agents gefocust
Ontwerp elke agent met één duidelijke verantwoordelijkheid:✅ Goed: Elke agent heeft één taak. ❌ Slecht: Eén generieke “dev-helper”-agent.
2. Gebruik beschrijvende namen
2. Gebruik beschrijvende namen
Maak duidelijk wat elke agent doet:
3. Configureer verschillende tooltoegang
3. Configureer verschillende tooltoegang
Geef agents alleen de tools die ze nodig hebben:
reviewer is alleen-lezen. fixer kan lezen en schrijven.4. Bewaak prestaties
4. Bewaak prestaties
Overweeg bij veel agents:
"strategy": "parallel"(standaard) gebruiken voor snelheid- Broadcastgroepen beperken tot 5-10 agents
- Snellere modellen gebruiken voor eenvoudigere agents
5. Handel fouten netjes af
5. Handel fouten netjes af
Agents falen onafhankelijk. De fout van één agent blokkeert de andere niet:
Compatibiliteit
Providers
Broadcastgroepen werken momenteel met:- ✅ WhatsApp (geïmplementeerd)
- 🚧 Telegram (gepland)
- 🚧 Discord (gepland)
- 🚧 Slack (gepland)
Routering
Broadcastgroepen werken naast bestaande routering:GROUP_A: Alleen alfred antwoordt (normale routering).GROUP_B: agent1 EN agent2 antwoorden (broadcast).
Voorrang:
broadcast heeft voorrang op gewone routebindings. Geconfigureerde ACP-bindings (bindings[].type="acp") zijn exclusief: wanneer er één overeenkomt, dispatcht OpenClaw naar de geconfigureerde ACP-sessie in plaats van fan-out-broadcast.Probleemoplossing
Agents antwoorden niet
Agents antwoorden niet
Controleer:
- Agent-ID’s bestaan in
agents.list. - Peer-ID-indeling is correct (bijv.
120363403215116621@g.us). - Agents staan niet in deny-lijsten.
Slechts één agent antwoordt
Slechts één agent antwoordt
Oorzaak: Peer-ID staat mogelijk in gewone routebindings maar niet in
broadcast, of komt mogelijk overeen met een exclusieve geconfigureerde ACP-binding.Oplossing: Voeg gewone route-gebonden peers toe aan de broadcastconfiguratie, of verwijder/wijzig de geconfigureerde ACP-binding als fan-out-broadcast gewenst is.Prestatieproblemen
Prestatieproblemen
Als het traag is met veel agents:
- Verminder het aantal agents per groep.
- Gebruik lichtere modellen (sonnet in plaats van opus).
- Controleer de opstarttijd van de sandbox.
Voorbeelden
Voorbeeld 1: Codereviewteam
Voorbeeld 1: Codereviewteam
- code-formatter: “Inspringing gerepareerd en typehints toegevoegd”
- security-scanner: “⚠️ SQL-injectiekwetsbaarheid in regel 12”
- test-coverage: “Dekking is 45%, tests voor foutgevallen ontbreken”
- docs-checker: “Docstring ontbreekt voor functie
process_data”
Voorbeeld 2: Meertalige ondersteuning
Voorbeeld 2: Meertalige ondersteuning
API-referentie
Config-schema
Velden
Hoe agents worden verwerkt.
parallel voert alle agents gelijktijdig uit; sequential voert ze uit in arrayvolgorde.WhatsApp-groeps-JID, E.164-nummer of andere peer-ID. De waarde is de array met agent-ID’s die berichten moeten verwerken.
Beperkingen
- Max. agents: Geen harde limiet, maar 10+ agents kunnen traag zijn.
- Gedeelde context: Agents zien elkaars reacties niet (volgens ontwerp).
- Berichtvolgorde: Parallelle reacties kunnen in willekeurige volgorde aankomen.
- Snelheidslimieten: Alle agents tellen mee voor de snelheidslimieten van WhatsApp.
Toekomstige verbeteringen
Geplande functies:- Modus voor gedeelde context (agents zien elkaars reacties)
- Agentcoördinatie (agents kunnen elkaar signalen geven)
- Dynamische agentselectie (kies agents op basis van berichtinhoud)
- Agentprioriteiten (sommige agents reageren vóór andere)