WHOOSH/BACKBEAT-prototype/TEMPO-RECOMMENDATIONS.md

BACKBEAT Tempo Recommendations

Why Slower Beats Make Sense for Distributed Systems

Unlike musical BPM (120+ beats per minute), distributed task coordination works better with much slower tempos. Here's why:

Recommended Tempo Ranges

Development & Testing: 1-2 BPM

• 1 BPM = 60-second beats (1 minute per beat)
• 2 BPM = 30-second beats (30 seconds per beat)
• Perfect for debugging and observing system behavior
• Plenty of time to see what agents are doing within each beat

Production: 5-12 BPM

• 5 BPM = 12-second beats
• 12 BPM = 5-second beats
• Good balance between responsiveness and coordination overhead
• Reasonable for most distributed task processing

High-Frequency (Special Cases): 30-60 BPM

• 30 BPM = 2-second beats
• 60 BPM = 1-second beats
• Only for very short-duration tasks
• High coordination overhead

Window Sizing Examples

With 2 BPM (30-second beats) and 4 beats per window:

• Each window = 2 minutes
• Downbeats every 2 minutes for secret rotation, rollups, reviews
• Agents report status every 30 seconds
• Reasonable time for meaningful work between status updates

With 12 BPM (5-second beats) and 8 beats per window:

• Each window = 40 seconds
• Downbeats every 40 seconds
• Agents report every 5 seconds
• More responsive but higher coordination overhead

Why Not 120+ BPM?

120 BPM = 500ms beats - This is far too fast because:

• Agents would report status twice per second
• No time for meaningful work between beats
• Network latency (50-100ms) becomes significant fraction of beat time
• High coordination overhead drowns out actual work
• Human operators can't observe or debug system behavior

Beat Budget Examples

With 2 BPM (30-second beats):

• withBeatBudget(4, task) = 2-minute timeout
• withBeatBudget(10, task) = 5-minute timeout
• Natural timeout periods that make sense for real tasks

With 120 BPM (0.5-second beats):

• withBeatBudget(10, task) = 5-second timeout
• Most meaningful tasks would need budget of 100+ beats
• Defeats the purpose of beat-based timeouts

BACKBEAT Default Settings

Current Defaults (Updated):

• Pulse service: 2 BPM (30-second beats)
• Window size: 8 beats = 4 minutes per window
• Min BPM: 1 (60-second beats for debugging)
• Max BPM: 60 (1-second beats for high-frequency systems)

Configuration Examples:

# Development - very slow for debugging
./pulse -bpm 1 -bar 4    # 60s beats, 4min windows

# Production - balanced 
./pulse -bpm 5 -bar 6    # 12s beats, 72s windows

# High-frequency - only if needed
./pulse -bpm 30 -bar 10  # 2s beats, 20s windows

Integration with CHORUS Agents

When CHORUS agents become BACKBEAT-aware, they'll report status on each beat:

With 2 BPM (30s beats):

T+0s:   Agent starts task, reports "executing", 10 beats remaining
T+30s:  Beat 1 - reports "executing", 9 beats remaining, 20% progress
T+60s:  Beat 2 - reports "executing", 8 beats remaining, 40% progress
T+90s:  Beat 3 - reports "review", 0 beats remaining, 100% progress
T+120s: Downbeat - window closes, reverb generates BarReport

With 120 BPM (0.5s beats) - NOT RECOMMENDED:

T+0.0s: Agent starts task, reports "executing", 600 beats remaining  
T+0.5s: Beat 1 - barely any progress to report
T+1.0s: Beat 2 - still barely any progress
... (598 more rapid-fire status updates)
T+300s: Finally done, but coordination overhead was massive

Performance Impact

Slower beats (1-12 BPM):

• ✅ Meaningful status updates
• ✅ Human-observable behavior
• ✅ Reasonable coordination overhead
• ✅ Network jitter tolerance
• ✅ Debugging friendly

Faster beats (60+ BPM):

• ❌ Status spam with little information
• ❌ High coordination overhead
• ❌ Network jitter becomes significant
• ❌ Impossible to debug or observe
• ❌ Most real tasks need huge beat budgets

Conclusion

BACKBEAT is designed for distributed task coordination, not musical timing. Slower beats (1-12 BPM) provide the right balance of coordination and efficiency for real distributed work.

The updated defaults (2 BPM, 8 beats/window) give a solid foundation that works well for both development and production use cases.