Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Status: Experimenteel. Toegevoegd in 2026.1.9.
Overzicht
Broadcast Groups laten meerdere agents hetzelfde bericht gelijktijdig verwerken en beantwoorden. Hiermee kun je gespecialiseerde agentteams maken die samenwerken in een enkele WhatsApp-groep of DM — allemaal met één telefoonnummer. Huidige scope: alleen WhatsApp (webkanaal). Broadcast-groepen worden geëvalueerd na kanaal-allowlists en groepsactiveringsregels. In WhatsApp-groepen betekent dit dat broadcasts plaatsvinden wanneer OpenClaw normaal zou antwoorden (bijvoorbeeld: bij vermelding, afhankelijk van je groepsinstellingen).Gebruiksscenario’s
1. Gespecialiseerde agentteams
1. Gespecialiseerde agentteams
Implementeer meerdere agents met atomaire, 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 eenbroadcast-sectie op topniveau 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 broadcast-lijst staat
- Alle vermelde agents verwerken het bericht.
- Elke agent heeft zijn eigen sessiesleutel en geïsoleerde context.
- Agents verwerken parallel (standaard) of sequentieel.
Broadcast-groepen omzeilen geen kanaal-allowlists of groepsactiveringsregels (vermeldingen/opdrachten/enz.). Ze wijzigen alleen welke agents worden uitgevoerd wanneer een bericht in aanmerking komt voor verwerking.
Sessie-isolatie
Elke agent in een broadcast-groep behoudt volledig afzonderlijke:- Sessiesleutels (
agent:alfred:whatsapp:group:120363...versusagent:baerbel:whatsapp:group:120363...) - Gespreksgeschiedenis (agent ziet de berichten van andere agents niet)
- Werkruimte (afzonderlijke sandboxes indien geconfigureerd)
- Tooltoegang (verschillende allow/deny-lijsten)
- Geheugen/context (afzonderlijke 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 geactiveerd
- Verschillende persoonlijkheden
- Verschillende tooltoegang (bijv. alleen-lezen versus lezen-schrijven)
- Verschillende modellen (bijv. opus versus sonnet)
- Verschillende Skills geïnstalleerd
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:
4. Bewaak prestaties
4. Bewaak prestaties
Overweeg bij veel agents:
"strategy": "parallel"(standaard) te gebruiken voor snelheid- Broadcast-groepen te beperken tot 5-10 agents
- Snellere modellen te 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
Broadcast-groepen werken momenteel met:- ✅ WhatsApp (geïmplementeerd)
- 🚧 Telegram (gepland)
- 🚧 Discord (gepland)
- 🚧 Slack (gepland)
Routering
Broadcast-groepen werken naast bestaande routering:GROUP_A: Alleen alfred antwoordt (normale routering).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. - De peer-ID-indeling is correct (bijv.
120363403215116621@g.us). - Agents staan niet in deny-lijsten.
Slechts één agent reageert
Slechts één agent reageert
Oorzaak: Peer-ID staat mogelijk in
bindings, maar niet in broadcast.Oplossing: Voeg toe aan de broadcast-configuratie 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: Code-reviewteam
Voorbeeld 1: Code-reviewteam
- code-formatter: “Inspringing gecorrigeerd en typehints toegevoegd”
- security-scanner: “⚠️ SQL-injectiekwetsbaarheid op 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
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. De waarde is de array met agent-ID’s die berichten moeten verwerken.
Beperkingen
- Max. agents: Geen harde limiet, maar meer dan 10 agents kan traag zijn.
- Gedeelde context: Agents zien elkaars antwoorden niet (zo ontworpen).
- Berichtvolgorde: Parallelle antwoorden kunnen in willekeurige volgorde arriveren.
- Rate limits: Alle agents tellen mee voor WhatsApp-rate limits.
Toekomstige verbeteringen
Geplande functies:- Modus voor gedeelde context (agents zien elkaars antwoorden)
- Agentcoördinatie (agents kunnen elkaar signalen sturen)
- Dynamische agentselectie (agents kiezen op basis van berichtinhoud)
- Agentprioriteiten (sommige agents antwoorden vóór andere)