coily dispatch: add a consult-posture axis and a third soft-stop mode #130

New issue

Closed

opened 2026-05-28 04:14:30 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-05-28 04:14:30 +00:00

Owner

Feature - add a consult-posture axis to coily dispatch, and a third soft-stop mode.

The reframing

The dispatch modes look like they are about execution surface (detached log file vs live Warp tab), but the thing that actually distinguishes them is consult posture - how readily the dispatched agent stops to involve the operator. Today only two points on that axis exist, and each conflates surface with posture.

The axis, from least to most operator involvement:

headless - never consults. Goes off into the sunset. Effectively --dangerously-skip-permissions. AFK queue work, no expectation of being watched.
interactive (current) - auto mode, renders a live report in a tab, assumes the operator may be watching but does not expect to talk to them. It proceeds.
new mode - auto mode, live in a tab, but carries an encoded expectation that it is allowed and encouraged to pause and consult when it hits a real decision. A suggested stop, not a hard stop. The agent still moves by default. It just knows the operator is reachable and that surfacing a judgment call is welcome rather than a failure.

Explicitly not plan mode. Plan mode is a hard read-only-until-approve stop. If the operator wanted that, they would launch Claude in plan mode by hand. This new mode is less cautious than plan mode - it is normal auto mode with the ask-propensity dialed up.

Naming - the current name is backwards

The current interactive does not actually interact. It lets you watch. The new mode is the one that genuinely interacts with the operator. Proposal:

Rename current interactive to watch (or report / observed).
Give the interactive-feeling name to the new mode - interactive, or if the collaboration framing should be front and center, pair / collab / consult.

Naming is a decision to settle in this issue.

Mechanism - it is a prompt posture, not a permission mode

This is the key implementation reality. Claude Code's permission knobs are hard: plan mode is read-only-until-approve, default / acceptEdits just proceed. There is no built-in soft-consult dial. So "encouraged but not required to wait" cannot be a permission mode. It lives in the prompt - a per-mode posture preamble that dispatch injects ahead of the work instruction.

Today dispatch hardcodes the prompt as Work on issue <ref> with no augmentation. The work here is:

Give dispatch a per-mode posture preamble, prepended to the existing Work on issue <ref> prompt.
Wire the three postures:
- headless - no preamble, or an explicit "do not stop to consult, complete the work end to end."
- watch - minimal or none.
- consult/new - something like: "You are in auto mode. The operator has this tab open and is reachable. When you hit a judgment call worth their input - a naming choice, an irreversible schema decision, two viable designs - you are encouraged to surface it and wait for their answer rather than guess. This is a soft expectation, not a hard stop: keep moving on everything that does not need them."

That preamble language mirrors the auto-mode posture Claude already runs under, just with the interruption budget raised.

Why this matters

Right now the only way to force a dispatched agent to pause on a decision is to bury a decision-gate in the issue body itself (this was done for agentic-os-kai#433 - a DECISION GATE - PAUSE FOR KAI callout). That is a per-issue contortion. A posture mode moves the expectation into the dispatch, reusable across every issue, with no issue-body hacking.

Open decisions

Final names (rename of interactive, name of the new mode).
Is the posture a distinct mode subverb, or a flag (e.g. --consult) layered on the existing surfaces? A flag would decouple surface from posture cleanly, which is the whole insight of this issue.
Default posture for a bare interactive-style dispatch.

**Feature - add a consult-posture axis to `coily dispatch`, and a third soft-stop mode.** ## The reframing The dispatch modes look like they are about execution surface (detached log file vs live Warp tab), but the thing that actually distinguishes them is **consult posture** - how readily the dispatched agent stops to involve the operator. Today only two points on that axis exist, and each conflates surface with posture. The axis, from least to most operator involvement: - `headless` - never consults. Goes off into the sunset. Effectively `--dangerously-skip-permissions`. AFK queue work, no expectation of being watched. - `interactive` (current) - auto mode, renders a live report in a tab, assumes the operator may be watching but does not expect to talk to them. It proceeds. - **new mode** - auto mode, live in a tab, but carries an encoded expectation that it is **allowed and encouraged to pause and consult** when it hits a real decision. A suggested stop, not a hard stop. The agent still moves by default. It just knows the operator is reachable and that surfacing a judgment call is welcome rather than a failure. Explicitly **not** plan mode. Plan mode is a hard read-only-until-approve stop. If the operator wanted that, they would launch Claude in plan mode by hand. This new mode is less cautious than plan mode - it is normal auto mode with the ask-propensity dialed up. ## Naming - the current name is backwards The current `interactive` does not actually interact. It lets you watch. The new mode is the one that genuinely interacts with the operator. Proposal: - Rename current `interactive` to `watch` (or `report` / `observed`). - Give the interactive-feeling name to the new mode - `interactive`, or if the collaboration framing should be front and center, `pair` / `collab` / `consult`. Naming is a decision to settle in this issue. ## Mechanism - it is a prompt posture, not a permission mode This is the key implementation reality. Claude Code's permission knobs are hard: plan mode is read-only-until-approve, default / acceptEdits just proceed. There is no built-in soft-consult dial. So "encouraged but not required to wait" cannot be a permission mode. It lives in the **prompt** - a per-mode posture preamble that dispatch injects ahead of the work instruction. Today `dispatch` hardcodes the prompt as `Work on issue <ref>` with no augmentation. The work here is: 1. Give dispatch a per-mode posture preamble, prepended to the existing `Work on issue <ref>` prompt. 2. Wire the three postures: - headless - no preamble, or an explicit "do not stop to consult, complete the work end to end." - watch - minimal or none. - consult/new - something like: "You are in auto mode. The operator has this tab open and is reachable. When you hit a judgment call worth their input - a naming choice, an irreversible schema decision, two viable designs - you are encouraged to surface it and wait for their answer rather than guess. This is a soft expectation, not a hard stop: keep moving on everything that does not need them." That preamble language mirrors the auto-mode posture Claude already runs under, just with the interruption budget raised. ## Why this matters Right now the only way to force a dispatched agent to pause on a decision is to bury a decision-gate in the issue body itself (this was done for agentic-os-kai#433 - a `DECISION GATE - PAUSE FOR KAI` callout). That is a per-issue contortion. A posture mode moves the expectation into the dispatch, reusable across every issue, with no issue-body hacking. ## Open decisions - Final names (rename of `interactive`, name of the new mode). - Is the posture a distinct mode subverb, or a flag (e.g. `--consult`) layered on the existing surfaces? A flag would decouple surface from posture cleanly, which is the whole insight of this issue. - Default posture for a bare interactive-style dispatch.

coilysiren referenced this issue from coilyco-flight-deck/cli-guard

2026-05-28 04:27:51 +00:00

dispatch: add a consult-posture axis decoupled from execution surface #27

coilysiren referenced this issue from a commit

2026-05-28 04:28:26 +00:00

feat(dispatch): add consult-posture axis orthogonal to surface

coilysiren referenced this issue from a commit

2026-05-28 04:30:44 +00:00

feat(dispatch): expose consult-posture axis via cli-guard bump

coilysiren closed this issue

2026-05-28 04:30:44 +00:00

coilysiren referenced this issue from coilyco-flight-deck/cli-guard