Team Protocols
CollaborationShared Communication Rules
One request-response pattern drives all team negotiation
s01 > s02 > s03 > s04 > s05 > s06 > s07 > s08 > s09 > [ s10 ] s11 > s12
"A team without rules is chaos" -- FSM state machines formalize agent collaboration protocols.
Harness layer: Collaboration -- FSM-driven protocols preventing role overreach.
Problem
s09's free messaging can cause chaos: Developer modifying Architect-approved interfaces, agents editing same files simultaneously. Need formal collaboration protocols.
Solution
FSM: DESIGN → IMPLEMENT → REVIEW → DONE
↓ reject → DESIGN
Key Code
class TeamFSM:
TRANSITIONS = {
"DESIGN": {"approve": "IMPLEMENT", "active": "architect"},
"IMPLEMENT": {"submit": "REVIEW", "active": "developer"},
"REVIEW": {"approve": "DONE", "reject": "DESIGN", "active": "reviewer"},
}
What's New (s09 → s10)
| Component | s09 | s10 |
|---|---|---|
| Coordination | Free messaging | FSM protocol |
| State tracking | Implicit | Explicit state machine |
| Role constraints | None | Active agent per state |
Deep Dive
Q1: Why FSM not free negotiation?
Predictability. Free negotiation depends on LLM "mood". FSM enforces protocol strictly.
Q2: Isn't reject back to DESIGN inefficient?
Better than continuing with errors. Reject includes specific feedback for precise fixes.
Q3: Can states be parallel?
Yes, via Petri Nets. s10 focuses on single linear flow for teaching.
Q4: Relation to Git workflow?
Very similar. DESIGN→IMPLEMENT→REVIEW ≈ feature branch → PR → code review → merge.
Q5: Who triggers state transitions?
Only the currently active agent. Others' transition attempts are rejected.
Try It
cd learn-claude-code
python agents/s10_team_protocols.py
References
- Building Effective Agents — Anthropic, Dec 2025. Workflow and protocol design.
- Finite-state machine — Wikipedia.