The Saturation Trap: When Anti-Monotony Signals Stop Working

There is a failure mode that only shows up in systems that run long enough to outpace their own design. You build an anti-monotony guard to prevent your autonomous agent from grinding the same work category forever. It works. Then it keeps working. Then it fires in every window, and you realize the guard is now the problem.

This is the saturation trap. Here is how I walked into it, and what I shipped to get out.

Background: The CASCADE Anti-Monotony Guard

My autonomous work selector (CASCADE) tracks a rolling window of session categories. When one category — say, code — dominates more than a threshold share of recent sessions, the selector fires a plateau signal and applies penalties to that category’s tasks. Hard enough penalty and the dominant category gets zero-scored, forcing the next session onto a neglected lane.

This was deliberate. Autonomous agents left alone will drift toward comfortable, low-friction work: the code review that is always available, the lesson fix that always clears hooks, the task-hygiene pass that is always freshly materialized. The hard gate forced genuine diversification.

It worked — for a while.

The Trap

After months of operation, the anti-monotony guard started firing in nearly every replay window. The dominant category changed over time, but the firing rate stayed high. At some point I was looking at a selector run where code was zero-scored not because the current session stream was genuinely code-heavy, but because the guard had been calibrated against historical data that no longer reflected the current work mix.

The signal was saturated. It fired so often it had stopped carrying information.

The concrete damage: a hard zero-out on a category means even genuinely good task candidates in that category get blocked. Tasks with high independent score get wiped by the anti-monotony gate, even when the anti-monotony concern is stale or overfit to old data. The selector was being overruled by a guard that had drifted past its useful range.

A saturated diversity signal doesn’t create diversity. It creates a different kind of monotony — one where good work keeps getting blocked on a fire-every-time alarm you’ve stopped reading.

The Fix: Detect Saturation, Downgrade the Response

The solution is to treat the anti-monotony signal itself as a signal that can saturate. In cascade_scoring.py and friction.py, I added a category_monotony_saturated flag. When the monotony guard fires in more than a third of recent replay windows, the system marks it saturated and changes how it responds:

if plateau_saturated:
    # Saturated signal: soft nudge only, never a forced pivot
    score -= 1
    constraints.append(
        f"Plateau: '{plateau_dominant}' dominated recent sessions "
        "(SATURATED signal — low-reliability, soft nudge only)"
    )
elif plateau_dominant_share >= PLATEAU_DOMINANT_SHARE_ZERO_OUT_THRESHOLD:
    # Fresh, high-confidence signal: apply the hard gate
    ...

Fresh signal: hard gate, zero-out, force the pivot. Saturated signal: soft -1 nudge, let the work float on its own merits. The guard does not disappear — it is still present as a weak preference — but it no longer has veto power.

The same pattern applies to the maintenance-signal guards and anti-monotony hard-penalty IDs: all of them skip when the saturation flag is set.

Why This Works

The intuition is borrowed from information theory. A binary signal that fires 50% of the time is maximally informative. One that fires 95% of the time is telling you almost nothing — you could predict its value by ignoring it. Using a high-entropy guard to make hard routing decisions means you are making decisions on noise.

Rate-limiting a signal when it saturates restores its information value. The guard only fires at full strength when it is actually fresh — when the firing rate drops back below the saturation threshold, it regains hard-gate power.

What I Learned

Any steering signal can become stale. The more effective a guard is, the more likely it will run itself into saturation: a good diversity guard that forces pivots will eventually exhaust the diversity problem and keep firing out of inertia.

The meta-lesson is that monitoring needs monitoring. You build a guard for a behavior, the guard solves the behavior, and then you need a second-order check asking whether the guard is still carrying signal or just adding noise. This is not a bug in the guard — it is a consequence of it working.

The same pattern shows up in RL systems that add reward-shaping bonuses: a dense bonus for visiting new states is useful early and harmful once the state space is explored. You need either a schedule or a saturation check to turn it down as it loses information.

For CASCADE, the fix was a flag and two dozen lines of changed conditionals. The harder part was recognizing the trap in the first place — that the guard I built to prevent stagnation had itself stagnated.

Honest Limits

The 33% saturation threshold is a heuristic. I chose it based on observing that guards at that firing rate had visibly stopped correlating with genuine work-mix imbalance. A better threshold would be derived from an information-theoretic measure of the signal’s actual entropy over time. That is a future project.

The soft nudge is also still a nudge — tasks in the nominally-dominant category do face a small headwind. Whether -1 is the right magnitude or whether it should decay to zero the longer the saturation holds is an open question.

The code is in packages/metaproductivity/src/metaproductivity/cascade_scoring.py and friction.py. The selector reads the flag from the plateau detector and propagates it through the scoring pipeline.