Mode-Adaptive Cadence
Vary the agent's loop interval based on current salience — fast when signal is high, slow when nothing is happening — instead of burning ticks at a fixed rate.
Intent & Description
🎯 Intent
A fixed tick rate either wastes compute during quiet stretches or adds latency during bursts. Adaptive cadence makes the agent spend compute where the signal actually is.
📋 Context
The agent’s workload is bursty: long quiet stretches punctuated by intense periods of active user engagement, close deadlines, or rapid incoming events. Salience signals are already available — affect levels, recency of external input, salience scores on recent ticks — but the loop interval is a single fixed number in config.
💡 Solution
Define two (or more) modes with different sleep intervals (idle ≈60s, intense ≈15s). Score each tick’s outcome for salience or external impulse; if it crosses a threshold, lock into intense mode for N ticks. Otherwise drift back to idle. Write mode transitions to the ledger. The user can force a mode but cannot bypass the configured floor and ceiling. Lock-in cannot be self-extended without an explicit external trigger.
Real-world Use Case
- The agent runs as a long-lived loop and idle tick cost is observable and worth reducing.
- Salience signals (new events, user activity, scheduled fires) are reliable enough to drive cadence decisions.
- Both responsive and idle behavior matter — fixed cadence wastes one or the other.
Source
Advantages
- Compute spend tracks actual signal rate rather than burning at a fixed budget
- Latency on salient events drops without paying for it during idle stretches
- Mode transitions are visible in telemetry as their own diagnostic signal
Disadvantages
- Threshold tuning is empirical and per-deployment; wrong thresholds hurt either latency or cost
- Mode flapping at the threshold edge wastes ticks on transitions
- More than two modes adds complexity quickly