Temporary Compensatory Mechanisms¶

Design scaffolding that compensates for current model limitations as removable layers, not load-bearing architecture. Track which mechanisms are compensatory and which are permanently valuable.

The Problem¶

Agent harnesses accumulate mechanisms that compensate for model limitations — unreliable self-verification, instruction fade-out, infinite loops. When this scaffolding becomes load-bearing, removing it requires a rewrite. Design it for removal from the start.

Classifying Harness Mechanisms¶

Every harness mechanism falls into one of three categories:

Category	Design Implication	Examples
Compensatory	Removable middleware; feature-flag; track which model capability obsoletes it	Loop detection, forced verification, instruction reminders, iteration caps
Structurally valuable	Invest in robustness; valuable regardless of model capability	Sandboxing, permission gates, context compaction, tool discovery, feedback loops
Mixed permanence	Design for graceful degradation; shrinks in scope but does not disappear	Context summarization, structured feature tracking, progress files

The classification question: If the model were perfect at this capability, would I still want this mechanism? Yes = structural; No = compensatory; Partially = mixed.

Compensatory Mechanisms in Practice¶

Loop Detection Middleware¶

LangChain's LoopDetectionMiddleware intercepts agent actions and detects repetitive patterns because models lack consistent self-monitoring for circular behavior.

Design for removal: implement as middleware disabled via configuration, not logic woven into the core agent loop.

Forced Verification Passes¶

Pre-completion checklists force agents through verification before declaring completion. Without an explicit gate, agents frequently declare success before running tests or checking linter output — the premature completion failure of treating apparent completion as actual completion.

Design for removal: separate the gate from the criteria. The criteria (tests pass, linter clean) are permanently valuable. The gate forcing the agent to check them is compensatory.

Instruction Fade-Out Reminders¶

The OPENDEV agent re-injects initial instructions during long sessions via event-driven system reminders, counteracting instruction fade-out as context fills.

Design for removal: implement as configurable middleware with a kill switch. If a future model maintains instruction adherence across its full context window, the reminders become noise.

Doom-Loop Iteration Caps¶

Hard iteration limits that terminate execution after N failed attempts — the OPENDEV agent includes this in its execution cycle.

Design for removal: implement as a circuit breaker with configurable thresholds, removable independently of core execution logic.

Structurally Valuable Mechanisms¶

These remain necessary regardless of model capability:

Sandboxing and permission gates — a more capable model is a stronger argument for sandboxing.
Environmental feedback loops — agents must observe effects of their actions (test output, build results, runtime errors).
Tool discovery and lazy loading — deferred tool loading manages finite tool schema budgets; selective loading stays efficient even with larger windows.
Task decomposition — bounded units are sound engineering regardless of model capability.

Decision Framework¶

graph TD
    A[New harness mechanism] --> B{Would a perfect model<br/>still need this?}
    B -->|Yes| C[Structurally valuable]
    B -->|No| D[Compensatory]
    B -->|Partially| E[Mixed permanence]
    C --> F[Invest in robustness]
    D --> G[Implement as removable<br/>middleware layer]
    E --> H[Design for graceful<br/>scope reduction]
    G --> I[Feature-flag it]
    G --> J[Document the model<br/>capability that obsoletes it]

For each compensatory mechanism, record:

What limitation it compensates for — e.g., "models do not self-verify before declaring completion"
What improvement would obsolete it — e.g., "reliable self-verification with 95%+ accuracy"
How to remove it — e.g., "disable PRE_COMPLETION_CHECKLIST_ENABLED flag; remove middleware registration"

Example: Annotating a Harness Config¶

harness:
  middleware:
    - name: loop_detection
      type: compensatory
      compensates_for: "Models repeat failing actions without recognizing the pattern"
      obsoleted_by: "Reliable action-outcome metacognition"
      enabled: true

    - name: instruction_reminder
      type: compensatory
      compensates_for: "Instruction adherence degrades beyond ~60% context utilization"
      obsoleted_by: "Stable instruction following across full context window"
      enabled: true

    - name: sandbox_isolation
      type: structural
      rationale: "Defense-in-depth; value increases with agent capability"
      enabled: true

    - name: context_compaction
      type: mixed
      compensates_for: "Finite context windows require summarization"
      structural_aspect: "Even with larger windows, selective loading is more efficient"
      enabled: true

When This Backfires¶

Classifying scaffolding up front is not free. The steelman for building the mechanism directly:

Short-lived projects — for internal tooling with a 6-month horizon, feature flags and middleware boundaries cost more than the eventual removal would have.
Stable model dependencies — teams pinned to a specific model version do not get capability upgrades, so removability machinery is pure overhead.
No middleware layer — "implement as removable middleware" presumes a middleware layer exists, the kind the scaffold architecture taxonomy catalogs. Retrofitting one to support a single mechanism inverts the cost-benefit.
Slow-improving capabilities — self-verification, instruction adherence, and loop-avoidance remain unreliable years later. Many "temporary" compensations outlive the projects that built them.
Mechanism interaction — compensatory and structural mechanisms often share state (e.g., loop detection feeds iteration caps). Decoupling for independent removability can produce a thinner but more complex architecture.

Treat classification as a tagging exercise on existing scaffolding, not a mandate to build every mechanism behind its own feature flag.

Key Takeaways¶

Classify every mechanism as compensatory, structural, or mixed permanence before building it.
Compensatory mechanisms should be removable middleware — feature-flag them and document what obsoletes them.
Sandboxing, permission gates, and environmental feedback are permanently valuable.
Context management has mixed permanence: compaction shrinks as windows grow but does not disappear.