You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Interactive escalations for the agent-facing run/debug tools
The supervisor put an LLM on a run's failure path; this puts the calling
agent there. `run_workflow`/`debug_workflow` accept `interactive: true`:
a failing node invocation parks the run and the tool returns the
escalation record, the agent answers with a verdict via the new
`resolve_workflow_escalation` tool, and the final report arrives once the
run settles.
- `packages/websocket/src/debug-sessions.ts`: `InteractiveEscalationHandle`
(a `SupervisorHandle` whose `decide()` waits for an HTTP verdict) plus a
user-owned session registry with a post-run TTL.
- `http-api.ts`: `interactive` on `POST /api/workflows/:id/run|debug`
(responds with the final report or `status: "escalated"`), new
`GET/POST /api/debug/sessions/:id[/verdict|/cancel]` routes. The handle
is wrapped in the same `BoundedHandle` (caps, sticky verdicts, fail-closed
timeout — sized at 10 min for a tool round trip), and the kernel still
enforces `allowedActions`; a disallowed or malformed verdict 400s without
deciding the escalation, so the agent can correct itself.
- Agent tools: `interactive` flag on run/debug, new
`resolve_workflow_escalation`, bridged onto the MCP server.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KNZApg6rgnpV9aqs5BTyX7
Copy file name to clipboardExpand all lines: docs/workflow-supervisor-design.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -239,6 +239,7 @@ Surfaces do not construct `WorkflowRunner` directly anymore — CLI, debug, head
239
239
2.**CLI** — `nodetool run --supervise [--max-decisions N] [--max-retries N] [--supervisor-cost-cap USD] [--supervisor-model id]` and the same flags on `nodetool debug`. Interventions print inline (`⛨` lines) and appear in `--json` reports.
240
240
3.**`Agent({ graph })`** — a fourth branch in `Agent._executeImpl` alongside `executeScriptPlan`/`executeGraphPlan`: hydrate the graph, start a `WorkflowRunner` with itself as supervisor, forward the runner's message stream, return run outputs from `getResults()`. No planning phase — the graph is the plan.
241
241
4.**API/web** — `supervise: true` on the run request; the websocket runner constructs the handle and forwards `supervisor_*` messages to the client for the intervention feed. Trigger rows carry the flag, **off by default** until the plan's PR 8 gate passes; the eventual flip covers newly created triggers only (§6.1 consent).
242
+
5.**Interactive (agent tools)** — `interactive: true` on `POST /api/workflows/:id/run|debug` makes the *calling* agent the supervisor: `InteractiveEscalationHandle` (`packages/websocket/src/debug-sessions.ts`) parks each `decide()` until a verdict arrives on `POST /api/debug/sessions/:id/verdict`, and the escalated HTTP response carries the `Escalation` record itself. The agent-facing `run_workflow`/`debug_workflow` tools expose the flag and `resolve_workflow_escalation` answers; the handle is wrapped in the same `BoundedHandle` (caps, sticky verdicts, a timeout sized for a tool round trip — 10 min — that fails closed), and the kernel still enforces `allowedActions` whatever arrives.
0 commit comments