Learn Claude Code
s10

Team Protocols

Collaboration

Shared Communication Rules

466 LOC12 toolsrequest_id correlation for two protocols
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)

Components09s10
CoordinationFree messagingFSM protocol
State trackingImplicitExplicit state machine
Role constraintsNoneActive 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