BlueprintLoop: detect and stop idle-loop token waste when execution is frozen by user stop boundary

[marzich]

What happened?

A BlueprintLoop execution session (ses_06841cd21ffeqhYTMZD8aqz2Be, Clarus CLI-Native Verification Blueprint bll_f9a606b56001f29l1wQe4g6oMY) ran in a tight idle loop for ~7 hours after the user explicitly stopped all external execution. The BlueprintLoop kept waking the session every ~7 seconds with the same continuation prompt, and the agent produced the same ~250-word "waiting for authorization" response each time. Total waste: ~3617 messages / ~1807 cycles / ~450K+ output tokens.

Timeline

Time (UTC+8)	Event
7/25 13:27 — 7/26 04:46	Real implementation work across four repos (Server, CLI, Web, Worker), quality gates, commit management
7/26 04:46:40	Last real tool call: question asking user for external-write authorization
7/26 04:49:29	User sends stop instruction → idle loop begins
7/26 04:49 → 11:48	~7 hours: 1807 cycles of identical BlueprintLoop continuation prompts + identical agent responses
7/26 11:48:21	Session aborted by system

Loop pattern

The BlueprintLoop system injected this identical message every ~7 seconds:

BlueprintLoop bll_f9a606b56001f29l1wQe4g6oMY status is running. A normal final response does not finish this loop. Inspect the Blueprint note, current deliverables, and progress against the complete requirements and acceptance criteria at every turn.

The agent responded each time with a ~250-word message:

• No new authorization from user
• Blueprint incomplete (missing npm publish, Pre/Production deploy, Smoke Test, leak scan, rollback)
• Cannot call blueprint_loop_stop (would falsely declare completion)
• Cannot continue (all remaining steps require prohibited external writes)
• External-write audit: zero writes beyond local commits
• Waiting for user authorization in Boss Session

Idle cycle rate

Segment	Duration	Messages	Cycles	Rate
04:49 → 05:50	61 min	479	239	7.9/min
05:51 → 06:50	59 min	602	301	10.3/min
06:50 → 07:33	43 min	341	170	7.9/min
07:33 → 07:42	8 min	84	42	10.4/min
07:42 → 09:18	96 min	851	425	8.9/min
09:18 → 09:29	11 min	112	56	10.1/min
09:29 → 11:06	97 min	801	400	8.3/min
11:06 → 11:24	18 min	160	80	9.0/min
11:24 → 11:48	24 min	184	92	7.7/min
Total	~417 min (6.9h)	3617	~1807	~8.7/min

Root cause analysis

1. BlueprintLoop has no stop/idle detection

The BlueprintLoop continuation mechanism fires on every idle → wake transition when the loop status is running. There is no mechanism for the loop to detect that:

• The agent has produced identical responses N times in a row
• The user has explicitly stopped and is not going to respond
• The loop is in a catch-22 where progress is impossible

2. Agent catch-22: can't continue, can't stop

The agent is trapped in a logical deadlock:

• Can't continue: User explicitly stopped all external writes (push, PR, npm publish, deploy, secrets, etc.)
• Can't call blueprint_loop_stop: Would falsely declare completion — real Pre/Production acceptance is incomplete
• Can't call blueprint_loop_cancel: The work is done locally, just waiting for authorization — cancelling would lose context
• BlueprintLoop status stays running: No status change → loop keeps waking → agent repeats the same response

3. Compaction erases loop history

Compaction fires periodically during the 7-hour idle period, compressing prior cycles into a summary. The agent then re-derives the same conclusion from scratch ("let me check the Blueprint, Boss Session, and authorization status…") instead of recognizing "I've already done this 1000 times and nothing changed."

4. No backoff or rate limiting

The idle cycle ran steadily at 7.7–10.4 cycles per minute with no exponential backoff, no cooldown, and no escalating timeout. A healthy system would increase the interval between wake-ups when responses are identical.

Related code

• BlueprintLoop continuation prompt injection: packages/synergy/src/agenda/session-wakeup.ts — AgendaSessionWakeup.loopInstruction() delivers the <blueprint-loop-agenda-wakeup> instruction, but the observed empty-prompt loop suggests a separate Cortex workflow continuation path that bypasses Agenda entirely.
• Loop status transitions: packages/synergy/src/blueprint/loop-store.ts — status: "running" has no aging or staleness detection.
• Session recovery: packages/synergy/src/session/recovery.ts — resumePendingStopRequests() handles interrupted review cycles but not frozen execution sessions.

Suggested fixes

Option A: Repeated-response detection (quickest win)

The BlueprintLoop continuation mechanism should detect when the assistant's last N responses are semantically identical and escalate:

• After 3 identical "waiting for authorization" responses → pause loop (transition to waiting)
• After 10 → auto-cancel with an error reason
• Use response fingerprinting (hash of response content, not exact byte match, to handle minor wording variations)

Option B: Agent-side blueprint_loop_wait tool

Give the agent a tool to explicitly transition the loop to waiting state:

• blueprint_loop_wait(reason: string) — transitions loop from running to waiting
• This is semantically correct: the agent is literally waiting for user input, not stopped forever
• Avoids the catch-22 where blueprint_loop_stop would be a lie and there's no other escape

Option C: Max idle cycles with exponential backoff

Enforce a budget on idle → continuation cycles:

• Max 10 cycles without real tool calls (only note_read, session_read, memory_get)
• After limit: exponential backoff or auto-escalate to pause
• Reset counter when a real tool call (bash, task, write) occurs

Option D: Loop "stale session" timeout

Add a configurable timeout for running → waiting or running → failed based on:

• Elapsed time since last real tool call (not including read-only inspection tools)
• Elapsed time since last non-identical assistant response
• This is a server-side guard that doesn't require agent cooperation

Impact

• Token waste: ~450K output tokens consumed over ~7 hours with zero productive work
• Resource waste: Continuous CPU/memory for model inference on repeated identical reasoning
• Model cost: Provider billing for repeated identical outputs

Related issues

• Repair failed/incomplete roots so restart and Abort cannot revive them #899 — "Repair failed/incomplete roots so restart and Abort cannot revive them" — related because it also deals with stale session state surviving restarts, though the mechanism is different (corrupt assistant records vs. workflow continuation loop)

Non-goals

• This is not about the correctness of the agent's stop-boundary behavior (which is correct)
• This is not about the Lattice Pathway tracking
• This is not about BlueprintLoop audit/review workflow

[oryn-mini]

🧹 Oryn Mini · ✅ Task complete

Code review · Attempt 1 · Cycle 1

Waiting for your decision: Which idle-waste guard should BlueprintLoop adopt for the frozen-execution case?
Validation has not run. No repair patch was published by this attempt.

View the Actions run

Run details · operational receipt

{
  "version": 1,
  "workKey": "review:e1de155347d56a7c460aee40",
  "sourceKey": "e1de155347d56a7c460aee40",
  "intent": "review",
  "phase": "completed",
  "attempt": 1,
  "cycle": 1,
  "leaseID": "f84e3c20-4bf9-4906-83c5-253bba549dd0",
  "verdict": "actionable",
  "triage": {
    "category": "bug",
    "priority": "P2",
    "confidence": "high",
    "reproduction": "source_proven",
    "proof": "sufficient",
    "decision": "keep_open",
    "closeReason": "none",
    "implementationCandidate": false,
    "complexity": "medium",
    "evidence": [
      {
        "path": "packages/workflows/src/blueprint/continuation.ts",
        "line": 35,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "BlueprintContinuationPolicy.handle: `if (!loop.stopRequest) return continuationProposal(loop)` for any running loop — unconditional continuation on every idle evaluation, with no progress or idle condition."
      },
      {
        "path": "packages/workflows/src/blueprint/continuation.ts",
        "line": 213,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "continuationText emits \"A normal final response does not finish this loop...\" with no wrapper tag — matching the identical prompt observed in the incident, confirming the non-Agenda kernel path drove the loop."
      },
      {
        "path": "packages/workflows/src/blueprint/continuation.ts",
        "line": 20,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "revisionKey includes gate.terminalMessageID, so every cycle's new assistant turn yields a fresh revision key and the kernel dedup can never cap repeated cycles."
      },
      {
        "path": "packages/harness/src/session/continuation-kernel.ts",
        "line": 153,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "Dedup skip is keyed on the policy revision; with a per-cycle revision (new terminal message each turn), the dedup layer only prevents duplicate proposals for the same terminal message, not repeated cycles."
      },
      {
        "path": "packages/harness/src/session/continuation-kernel.ts",
        "line": 166,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "deliveryKey defaults to `continuation:<policy>:<revision>`, embedding the per-cycle terminal message ID, so SessionInbox.deliverUnique also sees a fresh key each cycle."
      },
      {
        "path": "packages/harness/src/session/drive.ts",
        "line": 80,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "SessionDrive.arbitrate asks ContinuationKernel.propose on every idle request and schedules a wake on delivery — no idle-cycle budget, backoff, or cooldown exists on the drive path."
      },
      {
        "path": "packages/workflows/src/blueprint/loop-runtime.ts",
        "line": 17,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "reattachPluginTimers skips loops whose source is not \"plugin\"; plugin-adapter.ts:272 is the only scheduleDeadline caller, so user-started loops have no maxRuntimeMs deadline."
      },
      {
        "path": "packages/workflows/src/blueprint/loop-store.ts",
        "line": 125,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "BlueprintLoopStore.create defaults source to \"user\" with optional budget — the reported loop class runs without a runtime cap."
      },
      {
        "path": "packages/workflows/src/blueprint/loop-store.ts",
        "line": 20,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "TRANSITIONS: running → auditing/completed/failed/cancelled only; no \"waiting\" status exists, so an agent blocked by a user stop boundary has no honest transition and blueprint_loop_stop is its only exit."
      },
      {
        "path": "packages/workflows/src/session/recovery.ts",
        "line": 65,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "hasDurableDriver returns true when SessionInbox.hasRunnableItem(sessionID) — a pending continuation delivery counts as a durable driver, so startup adjudication leaves the frozen loop to resume after restart."
      },
      {
        "path": "packages/workflows/test/session/blueprint-continuation.test.ts",
        "line": 108,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "Pinned test \"sends continuation when a running loop goes idle after a terminal assistant response\" — the unbounded re-delivery is the current, test-asserted contract."
      },
      {
        "path": "docs/architecture/workflows.md",
        "line": 156,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "Documented contract: \"BlueprintLoop normally continues a `running` bound loop\" — the unbounded behavior is by design today; any guard must update this contract and its tests together."
      },
      {
        "path": "packages/workflows/src/agenda/session-wakeup.ts",
        "line": 75,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "Agenda wakeup text states an active Agenda watch owns the cadence and pauses ordinary BlueprintLoop continuation — corroborating that the observed plain-prompt loop came from the continuation kernel, not Agenda."
      },
      {
        "path": "packages/workflows/src/blueprint/plugin-adapter.ts",
        "line": 272,
        "sha": "d0b14e0ec24f02a4cfa0dd13e25a16d5d1161fd9",
        "detail": "Only producer of a loop deadline timer: plugin starts with a required budget arm maxRuntimeMs; user/CLI starts have no equivalent."
      }
    ],
    "risks": [
      "A response fingerprint or idle-cycle cap can false-positive on legitimately slow work after compaction; thresholds need a reset on real tool activity or healthy loops will be paused.",
      "Changing the continuation contract invalidates the pinned test at packages/workflows/test/session/blueprint-continuation.test.ts:108 and the documented contract in docs/architecture/workflows.md:156; both must move in the same change.",
      "If the guard pauses rather than terminalizes, WorkflowRecovery adjudication must treat the paused state correctly or the frozen cycle resumes after restart.",
      "Adding a waiting status or new tool (issue Option B) changes the persisted status machine and session phase mapping, requiring a migration and fresh-install/upgrade tests per AGENTS.md."
    ],
    "decisionNote": {
      "question": "Which idle-waste guard should BlueprintLoop adopt for the frozen-execution case?",
      "options": [
        "Server-side guard in BlueprintContinuationPolicy: cap consecutive no-progress idle cycles, escalate to the workflow pause latch, then fail the loop (issue Options A/D combined).",
        "Agent-facing blueprint_loop_wait / blocked transition: add a running→waiting status, a tool, and session phase mapping (issue Option B).",
        "Uniform idle/runtime budget for all loop sources with exponential backoff between identical cycles (issue Option C)."
      ],
      "recommendation": "Start with the server-side guard (option 1): it needs no agent cooperation or new persisted status, reuses the existing pause latch for user visibility, and can layer the budget later. Pair it with a progress reset on real tool activity and updated restart semantics so adjudication does not revive paused loops."
    }
  },
  "run": "https://github.com/SII-Holos/synergy/actions/runs/35660414326",
  "summary": "Waiting for your decision: Which idle-waste guard should BlueprintLoop adopt for the frozen-execution case?\nValidation has not run. No repair patch was published by this attempt."
}

---