Documentation Index
Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Status: Experimenteel. Toegevoegd in 2026.1.9.
Overzicht
Broadcastgroepen laten meerdere agents hetzelfde bericht gelijktijdig 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 groepsactiveringsregels. In WhatsApp-groepen betekent dit dat broadcasts plaatsvinden wanneer OpenClaw normaal gesproken zou antwoorden (bijvoorbeeld: bij een vermelding, afhankelijk van je groepsinstellingen).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
Basisconfiguratie
Voeg eenbroadcast-sectie op het hoogste niveau 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 gelijktijdig:
Volledig voorbeeld
Hoe het werkt
Berichtstroom
Als deze in de broadcastlijst staat
- Alle vermelde agents verwerken het bericht.
- Elke agent heeft zijn eigen sessiesleutel en geïsoleerde context.
- Agents verwerken parallel (standaard) of sequentieel.
Broadcastgroepen omzeilen kanaal-allowlists of groepsactiveringsregels (vermeldingen/opdrachten/etc.) niet. Ze veranderen alleen welke agents worden uitgevoerd wanneer een bericht in aanmerking komt voor verwerking.
Sessiesisolatie
Elke agent in een broadcastgroep behoudt volledig afzonderlijke:- Sessiesleutels (
agent:alfred:whatsapp:group:120363...versusagent:baerbel:whatsapp:group:120363...) - Gespreksgeschiedenis (agent ziet de berichten van andere agents niet)
- Workspace (afzonderlijke sandboxes indien geconfigureerd)
- Tooltoegang (verschillende toestaan/weigeren-lijsten)
- Geheugen/context (afzonderlijke IDENTITY.md, SOUL.md, enz.)
- Groepscontextbuffer (recente groepsberichten die voor context worden gebruikt) wordt per peer gedeeld, zodat alle broadcastagents dezelfde context zien wanneer ze worden geactiveerd
- 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. Een fout van één agent blokkeert de andere niet:
Compatibiliteit
Providers
Broadcastgroepen werken momenteel met:- ✅ WhatsApp (geïmplementeerd)
- 🚧 Telegram (gepland)
- 🚧 Discord (gepland)
- 🚧 Slack (gepland)
Routing
Broadcastgroepen werken naast bestaande routing:GROUP_A: Alleen alfred antwoordt (normale routing).GROUP_B: agent1 EN agent2 antwoorden (broadcast).
Voorrang:
broadcast heeft prioriteit boven bindings.Probleemoplossing
Agents reageren niet
Agents reageren niet
Controleer:
- Agent-id’s bestaan in
agents.list. - Peer-id-indeling is correct (bijv.
120363403215116621@g.us). - Agents staan niet in weigerlijsten.
Slechts één agent reageert
Slechts één agent reageert
Oorzaak: Peer-id staat mogelijk in
bindings maar niet in broadcast.Oplossing: Voeg toe aan de broadcastconfiguratie of verwijder uit bindings.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: “Fixed indentation and added type hints”
- security-scanner: “⚠️ SQL injection vulnerability in line 12”
- test-coverage: “Coverage is 45%, missing tests for error cases”
- docs-checker: “Missing docstring for function
process_data”
Voorbeeld 2: Meertalige ondersteuning
Voorbeeld 2: Meertalige ondersteuning
API-referentie
Configuratieschema
Velden
Hoe agents moeten worden verwerkt.
parallel voert alle agents gelijktijdig uit; sequential voert ze uit in arrayvolgorde.WhatsApp-groeps-JID, E.164-nummer of andere peer-id. 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 WhatsApp-snelheidslimieten.
Toekomstige verbeteringen
Geplande functies:- Modus voor gedeelde context (agents zien elkaars reacties)
- Agentcoördinatie (agents kunnen elkaar signaleren)
- Dynamische agentselectie (agents kiezen op basis van berichtinhoud)
- Agentprioriteiten (sommige agents reageren vóór andere)