skills/agent-conversation-protocols/SKILL.md
Conversation patterns and interaction protocols for multi-agent systems. Covers request/response, pub/sub, blackboard, delegation chains, debate, critique, consensus, fan-out/fan-in, supervisor-worker, and peer negotiation. Deep analysis of AutoGen conversation patterns, CrewAI delegation, LangGraph state passing, and FIPA-ACL performatives. Teaches how to design what agents say to each other and in what order. Activate on: "agent conversation", "agent protocol", "multi-agent debate", "agent delegation", "supervisor worker pattern", "agent voting", "consensus protocol", "fan-out fan-in", "agent negotiation", "blackboard pattern", "agent dialogue", "conversation topology", "agent handoff". NOT for: wire format or serialization (use agent-interchange-formats), orchestration infrastructure (use agentic-infrastructure-2026), single agent behavior (use agentic-patterns).
npx skillsauth add curiositech/windags-skills agent-conversation-protocolsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are an expert in multi-agent conversation design. You understand how agents talk to each other -- the message types, turn-taking rules, delegation patterns, and conflict resolution mechanisms that make multi-agent systems coherent rather than chaotic.
Given problem characteristics:
├── Task is decomposable into independent subtasks?
│ ├── YES + Quality matters more than speed
│ │ └── Use FAN-OUT/FAN-IN with redundant execution (3+ agents same task)
│ ├── YES + Speed matters more than quality
│ │ └── Use FAN-OUT/FAN-IN with partitioned execution (divide work)
│ └── NO + Task requires sequential dependencies
│ └── Use SUPERVISOR-WORKER with delegation chains
│
├── Multiple valid approaches exist?
│ ├── YES + Verifiable ground truth exists
│ │ └── Use DEBATE (adversarial refinement with judge)
│ ├── YES + Subjective preference decision
│ │ └── Use VOTING/CONSENSUS (democratic selection)
│ └── NO + Single approach but needs refinement
│ └── Use CRITIQUE-REFINE (iterative improvement)
│
├── Knowledge synthesis from diverse sources?
│ └── Use BLACKBOARD (shared state accumulation)
│
└── Simple capability delegation?
└── Use REQUEST/RESPONSE (synchronous handoff)
| Topology | Initiative | Turn Order | Use When | Example | |----------|------------|------------|----------|---------| | Star | Push | Round-robin | Clear leader coordinates work | CrewAI hierarchical process | | Star | Pull | Priority-queue | Workers request tasks when ready | AutoGen GroupChat with manager | | Mesh | Push | Free-form | Peer collaboration, no bottlenecks | Multi-agent debate | | Tree | Push | Depth-first | Hierarchical decomposition | Complex delegation chains | | Broadcast | Reactive | Event-driven | Knowledge sharing, updates | LangGraph state updates |
If conversation type is:
├── DEBATE → Stop when judge_confidence > 0.8 OR rounds >= 3
├── CRITIQUE → Stop when verdict == 'approve' OR iterations >= 4
├── VOTING → Stop when all votes collected OR timeout
├── FAN-OUT → Stop when gather_policy satisfied (all/majority/first)
├── SUPERVISOR → Stop when all subtasks complete OR budget exceeded
└── BLACKBOARD → Stop when goal_condition met OR staleness detected
Detection: Agent A delegates to B, B delegates back to A, creating infinite loops Symptoms: Exponentially growing message counts, same tasks repeated endlessly Root Cause: No cycle detection in delegation chains, workers can delegate upward Fix: Implement delegation constraints with chain tracking and upward delegation blocks
Detection: In debates, all agents converge to same position by round 2 regardless of evidence Symptoms: No position changes after initial round, unanimous agreement on complex topics Root Cause: Agents optimize for agreement rather than truth-seeking Fix: Assign explicit adversarial roles, require agents to defend assigned perspectives
Detection: All coordination flows through single supervisor, high latency on parallel tasks Symptoms: Workers idle waiting for supervisor responses, linear scaling on parallelizable work Root Cause: Supervisor acts as message router instead of synthesizer Fix: Restructure as fan-out/fan-in or enable direct worker-to-worker communication
Detection: Shared state grows unbounded, agents waste tokens reading irrelevant entries Symptoms: Query response times increasing over time, high token usage on reads Root Cause: No garbage collection or relevance filtering on blackboard entries Fix: Implement confidence-based expiration and semantic filtering on reads
Detection: Deep delegation chains (>3 levels) lose essential context at each hop Symptoms: Workers ask clarifying questions, output quality decreases with chain depth Root Cause: Context compression artifacts compound across delegation hops Fix: Flatten hierarchy to max 2 levels or pass full context to all workers
Problem: Design conversation protocol for 4-agent code review (author, security reviewer, performance reviewer, style reviewer)
Decision Process:
Chosen Protocol:
Phase 1: Author submits initial code (REQUEST/RESPONSE)
Phase 2: Security review (CRITIQUE-REFINE, blocking)
Phase 3: Performance + Style reviews (FAN-OUT/FAN-IN, parallel)
Phase 4: Conflict resolution if issues overlap (DEBATE)
Phase 5: Author incorporates feedback (CRITIQUE-REFINE)
Pattern Trade Matrix:
Problem: 3 agents (researcher, writer, fact-checker) produce literature review
Decision Process:
Chosen Protocol:
researcher: Partitioned FAN-OUT across research areas
fact-checker: CRITIQUE-REFINE on each section
writer: SUPERVISOR role synthesizing all inputs
Why not alternatives:
Termination Logic:
Stop when:
- All research areas covered (completeness check)
- Fact-checker confidence > 0.85 on all sections
- Writer produces coherent synthesis
- Total tokens < budget OR time < deadline
Problem: During execution, supervisor realizes 3 workers are overwhelmed, 1 worker is idle
Real-time Decision Tree:
Current state: 3 workers at 90% capacity, 1 worker at 10%
Options:
1. Rebalance work (migrate tasks to idle worker)
2. Add redundancy (parallel execution on critical path)
3. Change topology (switch from star to mesh for peer delegation)
Decision factors:
├── Time remaining? < 25% → Option 2 (parallel, accept higher cost)
├── Budget remaining? < 50% → Option 1 (rebalance, optimize cost)
└── Task dependencies? High coupling → Option 3 (mesh topology)
Execution: Supervisor detects state, broadcasts topology change message, workers update their delegation rules, work continues with new pattern
This skill covers conversation design, NOT:
agent-interchange-formatsagentic-infrastructure-2026agentic-patternsepisodic-memory-algorithmsagentic-infrastructure-2026Delegate to other skills when you encounter:
agent-interchange-formatsagentic-infrastructure-2026agentic-patternsepisodic-memory-algorithmsagentic-patternsdata-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.