Steer the in-flight agent run on work-item updates instead of cancelling it

[waynesun09]

What happened

Every stage job in reusable-dispatch.yml (triage, code, review, fix, retro, prioritize, harness fan-out) runs in a concurrency group keyed on the work item with cancel-in-progress: true. A second push, comment, label, or title edit on the same item cancels the in-flight job and a fresh job repeats all the work on a new VM and sandbox. #1014, #4960, #6573 quantify the token waste on review bursts; #1207 is the same problem from the other side (triage misses the update that arrived while it ran).

Proposed change

Keep the runs; steer the running agent.

• Runtime Steerer capability. Claude Code (-p --input-format stream-json) and pi (--mode rpc, streamingBehavior: steer) take a second user message at the next tool boundary inside the running turn; Codex has no live channel in exec, so interrupt the turn and codex exec … resume <thread_id> - with the message. All three verified on the pinned versions (2.1.258/259, 0.84.4, 0.152.1).
• Follow-up run watcher in the runner. GitHub Actions cannot deliver input to a running job, but every legitimate update already produces a shim run whose Route job applied ADR 0054 and selected a stage. The runner lists shim runs created after its own start (job token, Actions read) and accepts one only on server-side provenance: shim path + event allowlist, referenced_workflows equal to its own run's, Route job success (not the run conclusion: queue: single cancels superseded pending stage jobs), my stage job not skipped, bound to my work item, consumed once by run id. The runner never calls the permission API.
• Dispatch. cancel-in-progress: false on the stage jobs (default queue: single is the burst debounce), a queued-run skip check that reads the in-flight run's "consumed follow-up run N" marker, a run-name: on the per-repo shim carrying the item number, and a /fs-steer route arm (+ fullsend steer <url> "<text>" posting that comment with the gh auth token).
• Fleet backstop (agents repo, separate PR): end-of-run head/comment re-check with FULLSEND_RUN_HEAD_SHA / FULLSEND_RUN_STARTED_AT.

Scope: per-repo installs and this repo (per-org mode is deprecated, ADR 0044). GitLab already queues; only the runner side and the skip check apply there.

Validation criteria

• A push during an in-flight review produces one review on the settled head, with the steer visible in the transcript and the queued run exiting on the skip check.
• A fork author's /fs-steer is ignored (every stage job skipped in its run); an authorized /fs-steer reaches the session.
• No stage regresses when harness.steer is off (default).

Related: #1014, #4960, #1422, #6573, #1207, #1637, #459, #6932, #5445, #2399.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 11:48 AM UTC · Completed 11:54 AM UTC

Commit: 2a10349 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $0.96

[fullsend-ai-triage]

Workflow changes required — manual intervention needed. This feature requires modifying reusable-dispatch.yml (flipping cancel-in-progress to false on all stage jobs, adding a queued-run skip check) and per-repo shim workflows (adding run-name: with the item number). The code agent cannot modify workflow files under current permissions, so these changes will need a human-authored PR or maintainer action.

Related work

This issue supersedes the narrower debouncing proposals:

• Debounce review dispatch on rapid synchronize events #1014 (debounce review dispatch on rapid synchronize) — open
• Debounce review agent runs on rapid force-pushes to reduce token waste #4960 (debounce review on rapid force-pushes) — open
• Deduplicate review runs when PR is rebased multiple times in quick succession #1422 (deduplicate review runs on rapid rebases) — open
• Triage agent missing trigger / doesn't notice changes while it's replying #1207 (triage misses updates while running) — open
• Add /fs-cancel slash command to let humans stop in-flight agent runs #5445 (/fs-cancel slash command) — related but orthogonal
• Remove stale-head re-dispatch: redundant with concurrency group, causes self-triggering #2399 (remove stale-head re-dispatch) — may be resolved by this work

Consider closing #1014, #4960, and #1422 as subsumed if this design is accepted, since steering eliminates the need for debouncing.

Proposed test case

Scenario: Push during in-flight review steers instead of cancelling
  Given a PR with an in-flight review agent run
  When a new commit is pushed to the PR branch
  Then the running review session receives a steer message at the next tool boundary
  And the review completes on the settled head
  And the queued shim run exits on the skip check
  And no second review is produced

Scenario: Unauthorized /fs-steer is rejected
  Given a PR with an in-flight review agent run
  When a fork author comments /fs-steer with a message
  Then every stage job in the steer run is skipped

Scenario: Feature gate off preserves existing behavior
  Given harness.steer is not set (default off)
  Then cancel-in-progress behavior is preserved for all stages

Design note

The fleet backstop (end-of-run head/comment re-check with FULLSEND_RUN_HEAD_SHA / FULLSEND_RUN_STARTED_AT) is correctly scoped as a separate PR in the agents repo. No tracking issue exists for it yet — consider filing one when work begins.

---

Labels: Feature request touching dispatch concurrency and runner lifecycle, with high impact from token waste on review bursts.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

[ifireball]

@waynesun09 see #6909 we seem to be thinking about the same problem, or at least the same problem space

[ifireball]

/re-triage consider the relevance of #6909

[fullsend-ai-scribe]

Meeting update — 2026-09-03

Relevant to this issue: The team discussed shifting from event-based triggering to an entity-based reconciliation model for agents, directly supporting this issue's goal of steering in-flight runs rather than cancelling them.

• A shift from event-based triggering to entity-based reconciliation was proposed, enabling agents to re-process entities (PRs, issues) with more robust state handling
• The reconciliation model aligns with this issue's approach of steering rather than cancelling in-flight runs when work items are updated
• Exploration of entityless agents was initiated for use cases like Scribe that do not operate on a specific forge entity (related: Opt-in scribe install: private-only guard, dispatch-ready workflow, no cron until enabled #6714)
• A separate ADR was agreed upon to formalize the agent steering mechanism

Related PRs: PR #6959 — steer the in-flight agent run on work-item updates; PR #6956 — entity-first harness evaluation ADR

Next steps: Draft a steering mechanism ADR to formalize the entity-based reconciliation approach.

Meeting notes