Proposal: Standing Constraint — governance rules that fire above the handoff level

[jwade83]

Category

Authority — new primitive proposal. Sits alongside Action Scope, Delegation Contract, and Escalation Trigger.

Definition

A Standing Constraint is a governance rule that governs agent behavior across an entire collaboration lifecycle, independent of any individual task or handoff. Unlike Action Scope (which bounds what an agent can do for a given task) or Escalation Trigger (which fires at a specific handoff moment), a Standing Constraint fires on a schedule or threshold regardless of what work is currently in progress.

Why it matters

The existing Authority primitives (Action Scope, Delegation Contract, Escalation Trigger) are all task-scoped or moment-scoped. They answer: "What can the agent do in this context?" and "When should the agent stop and ask?"

Standing Constraints answer a different question: "What must always be true about how this collaboration operates, regardless of the current task?"

Examples of the class:

• "Before any infrastructure work, demonstrate external-facing output in the past N sessions" (prevents internal-only drift)
• "Agent cannot commit to external stakeholders without human review, ever" (regardless of trust score)
• "All claimed outcomes must cite evidence at claim-time" (regardless of which task is producing the claim)

These are meta-level governance decisions that sit above individual handoffs. They're closer to organizational policy than task permissions.

What breaks without it

A career management system built with an AI agent experienced a specific failure: the agent consistently prioritized internal infrastructure work (building tools, refining workflows, organizing files) over external-facing activities (writing, community contribution, outreach). This wasn't a trust failure or a scope violation — the infrastructure work was within the agent's authorized scope and was genuinely valuable. The failure was that no mechanism existed to detect the pattern of internal-only work accumulating across sessions.

The fix was a Standing Constraint: "Before any infrastructure or build work in a session, demonstrate one external-facing career action." The constraint fires at session start, not at any specific handoff. It operates above the individual task level.

A drift counter tracked sessions since the last external signal. When the counter exceeded a threshold (2 sessions), the Standing Constraint escalated — flagging the pattern before the session's work was chosen, not after it was completed.

Without this primitive, the agent could fulfill every individual task correctly while the collaboration collectively drifted in an unhealthy direction. The Collaboration Quality Score might eventually surface this, but it's a lagging indicator. The Standing Constraint is a leading governance mechanism.

How it differs from existing primitives

Primitive	Fires when	Scope
Action Scope	Agent attempts an action	Per-task
Escalation Trigger	Agent reaches a decision threshold	Per-handoff
Delegation Contract	Task is assigned	Per-task
Standing Constraint	Session starts OR threshold is reached	Collaboration-wide, persistent

Proposed definition for the taxonomy

Standing Constraint — A governance rule that operates at the collaboration level rather than the task level. Fires on a recurring schedule (each session) or when a cumulative threshold is breached. Not tied to any specific handoff or task. Examples: session-level preconditions, cumulative output requirements, pattern-based escalation.

Possible schema shape:

standing_constraint: {
  id: <unique identifier>,
  rule: <natural language or structured condition>,
  fires_on: "session_start" | "threshold_breach" | "schedule",
  threshold: <optional — cumulative metric and limit>,
  enforcement: "hard_block" | "advisory_flag",
  set_by: "human" | "system" | "collaborative",
  suspended: false,
  evidence: <what the constraint checks against>
}

Key questions for the community:

• Who sets Standing Constraints — the human, the system, or both collaboratively?
• How are Standing Constraints versioned or updated without breaking in-progress work?
• Should violation of a Standing Constraint block the session or flag it? (Hard stop vs. advisory)
• Can Standing Constraints be temporarily suspended, and under what conditions?

Real-world signal

In the system described, the drift counter reached 9 sessions of internal-only work before the Standing Constraint mechanism was implemented. The agent was performing correctly by every task-level metric during those 9 sessions. The pattern failure was only detectable at the collaboration level.

---

From production experience in a single-operator AI orchestration system. Described mechanism works in this environment. Single operator, no multi-user validation.

[kamesh231]

Aligned and open for discussion

[jwade83]

Thanks — a few questions on how this would sit alongside the existing Authority primitives, since the interaction model isn't obvious to me.

The current Authority category has three primitives that are all scoped to a task or a moment:

Primitive	Fires when	Scope
Action Scope	Agent attempts an action	Per-task
Delegation Contract	Task is assigned	Per-task
Escalation Trigger	Agent reaches a decision threshold	Per-handoff

Standing Constraint operates at a different temporal level — across the collaboration lifecycle. That raises some interaction questions I don't have clean answers to:

1. Override precedence. If a Delegation Contract authorizes an action but a Standing Constraint prohibits it at the session level, which wins? In my implementation the Standing Constraint fires first (session start, before any task is selected), so the conflict doesn't arise — but that's one architecture, not a general answer.

2. Inheritance. When a Delegation Contract is created, should it automatically inherit all active Standing Constraints? Or should Standing Constraints be evaluated independently, outside the delegation chain?

3. Escalation relationship. A Standing Constraint violation could be modeled as a special case of Escalation Trigger — a threshold-based escalation that happens to operate at the collaboration level. Is there a reason to keep them separate, or would extending Escalation Trigger with a scope: collaboration parameter cover the same ground?

The third one is a question for the taxonomy — whether this is a new primitive or an extension of an existing one. In practice, the behavior felt different enough to warrant separation (a drift counter accumulating across sessions is structurally different from an agent hitting a confidence threshold mid-task), but I could see the argument for keeping the primitive count lower.