While running orchestrate, one of my work-package agents hit a real fork in the road: it needed to reuse code that lived in another WP's owned file, and every option was blocked by the rules I'd given it (couldn't edit the other lane's file, couldn't duplicate it, couldn't proceed cleanly). The sensible move would've been to ask — either me, or the planner/AI that set the jobs up — "which way do you want this?"
It actually tried: it reached for an interactive "ask the user" tool, but that isn't available when it's running headless under claude -p. So it did the only thing left — printed a careful "here are the options, I'll wait for your direction" message and exited cleanly, having changed nothing. From the orchestrator's side that just looks like a no-op (and today that dead-stalls the whole run — see #19). The question I needed to answer never reached me.
The gap: there's no channel for a worker to escalate a genuine decision back up — not to the human, and not to the orchestrating AI that created the work. A worker can only succeed, fail, or quietly give up. So any task that turns out to need a judgment call just stops, invisibly.
The encouraging part is that the substrate already exists on the spec-kitty side: the native spec-kitty next runtime has a first-class "decision required" result plus a decision request/answer mechanism. It's just not wired into the orchestrate → agent path.
What I'd like: a way for a worker to raise a structured "I need a decision: + " signal that the orchestrator recognizes (instead of reading it as a failed/empty run) and routes — either let the orchestrating AI answer and re-dispatch the worker, or pause and surface it to me — then resume the worker with the answer. Reusing the native runtime's decision mechanism feels like the natural foundation.
(Related: #19 — the dead-stall, and the ask to surface the agent's final message. That observability piece is a useful stopgap: I'd at least see the question, even before there's a way to answer it in-loop.)
While running
orchestrate, one of my work-package agents hit a real fork in the road: it needed to reuse code that lived in another WP's owned file, and every option was blocked by the rules I'd given it (couldn't edit the other lane's file, couldn't duplicate it, couldn't proceed cleanly). The sensible move would've been to ask — either me, or the planner/AI that set the jobs up — "which way do you want this?"It actually tried: it reached for an interactive "ask the user" tool, but that isn't available when it's running headless under
claude -p. So it did the only thing left — printed a careful "here are the options, I'll wait for your direction" message and exited cleanly, having changed nothing. From the orchestrator's side that just looks like a no-op (and today that dead-stalls the whole run — see #19). The question I needed to answer never reached me.The gap: there's no channel for a worker to escalate a genuine decision back up — not to the human, and not to the orchestrating AI that created the work. A worker can only succeed, fail, or quietly give up. So any task that turns out to need a judgment call just stops, invisibly.
The encouraging part is that the substrate already exists on the spec-kitty side: the native
spec-kitty nextruntime has a first-class "decision required" result plus a decision request/answer mechanism. It's just not wired into theorchestrate→ agent path.What I'd like: a way for a worker to raise a structured "I need a decision: + " signal that the orchestrator recognizes (instead of reading it as a failed/empty run) and routes — either let the orchestrating AI answer and re-dispatch the worker, or pause and surface it to me — then resume the worker with the answer. Reusing the native runtime's decision mechanism feels like the natural foundation.
(Related: #19 — the dead-stall, and the ask to surface the agent's final message. That observability piece is a useful stopgap: I'd at least see the question, even before there's a way to answer it in-loop.)