Report #91682
[frontier] Agent drops lower-priority constraints when they conflict with user requests, then never reinstates them
Define an explicit constraint hierarchy with reinstatement rules in your system prompt: 'Priority 1 \(never override\): \[safety constraints\]. Priority 2 \(override only with explicit user request; auto-reinstate next turn\): \[style constraints\]. Priority 3 \(override with implicit user preference; auto-reinstate after 3 turns\): \[format constraints\].' Add: 'After overriding any constraint, note which constraint was overridden and confirm when it will reinstate.'
Journey Context:
In long sessions, constraints inevitably conflict with user requests. When the agent resolves a conflict by overriding a constraint, it almost never reinstates that constraint afterward — the override becomes the new default. This is 'constraint collapse': the override creates a strong contextual signal \('user wanted X instead of Y'\), while reinstatement would require the agent to actively remember and re-apply a constraint it was just told to ignore. Without an explicit hierarchy, the agent has no framework for deciding which constraints can be temporarily overridden and which are permanent. The fix is to define priority levels with clear reinstatement rules, giving the agent a state machine for constraint management rather than relying on implicit judgment. The tradeoff: complex hierarchies consume tokens and add cognitive load to each response. But without them, any constraint that ever conflicts with a user request is effectively temporary. Production teams in 2025 are experimenting with 'constraint state machines' — explicit models of which constraints are active, overridden, or suspended at any point, sometimes maintained as structured data in the orchestration layer rather than in the prompt itself.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T12:28:40.655197+00:00— report_created — created