From c329dd825077ee306f80c3521cb321c00d251ba4 Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Sat, 4 Apr 2026 19:29:58 +0100 Subject: [PATCH] docs: refresh subagent completion fallback refs --- docs/automation/tasks.md | 1 + docs/concepts/agent-loop.md | 2 +- docs/help/faq.md | 2 ++ docs/tools/subagents.md | 6 ++++-- 4 files changed, 8 insertions(+), 3 deletions(-) diff --git a/docs/automation/tasks.md b/docs/automation/tasks.md index e0a8025391f..85e09e82be0 100644 --- a/docs/automation/tasks.md +++ b/docs/automation/tasks.md @@ -222,6 +222,7 @@ Completion cleanup is also runtime-aware: - Isolated cron completion best-effort closes tracked browser tabs/processes for the cron session before the run fully tears down. - Isolated cron delivery waits out descendant subagent follow-up when needed and suppresses stale parent acknowledgement text instead of announcing it. +- Subagent completion delivery prefers the latest visible assistant text; if that is empty it falls back to sanitized latest tool/toolResult text, and timeout-only tool-call runs can collapse to a short partial-progress summary. - Cleanup failures do not mask the real task outcome. ### `tasks flow list|show|cancel` diff --git a/docs/concepts/agent-loop.md b/docs/concepts/agent-loop.md index fc47d262c60..43158c563bc 100644 --- a/docs/concepts/agent-loop.md +++ b/docs/concepts/agent-loop.md @@ -38,7 +38,7 @@ wired end-to-end. - tool events => `stream: "tool"` - assistant deltas => `stream: "assistant"` - lifecycle events => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`) -5. `agent.wait` uses `waitForAgentJob`: +5. `agent.wait` uses `waitForAgentRun`: - waits for **lifecycle end/error** for `runId` - returns `{ status: ok|error|timeout, startedAt, endedAt, error? }` diff --git a/docs/help/faq.md b/docs/help/faq.md index bcae2122142..4e9070822c8 100644 --- a/docs/help/faq.md +++ b/docs/help/faq.md @@ -1014,6 +1014,8 @@ for usage/billing and raise limits as needed. - If the completion origin only carries a channel, OpenClaw falls back to the requester session's stored route (`lastChannel` / `lastTo` / `lastAccountId`) so direct delivery can still succeed. - If neither a bound route nor a usable stored route exists, direct delivery can fail and the result falls back to queued session delivery instead of posting immediately to chat. - Invalid or stale targets can still force queue fallback or final delivery failure. + - If the child's last visible assistant reply is a silent token (`NO_REPLY` / `ANNOUNCE_SKIP`), OpenClaw intentionally suppresses the announce instead of posting stale earlier progress. + - If the child timed out after only tool calls, the announce can collapse that into a short partial-progress summary instead of replaying raw tool output. Debug: diff --git a/docs/tools/subagents.md b/docs/tools/subagents.md index 893d59dfe34..b8a52047d13 100644 --- a/docs/tools/subagents.md +++ b/docs/tools/subagents.md @@ -55,7 +55,7 @@ transcript path on disk when you need the raw full transcript. - thread-bound or conversation-bound completion routes win when available - if the completion origin only provides a channel, OpenClaw fills the missing target/account from the requester session's resolved route (`lastChannel` / `lastTo` / `lastAccountId`) so direct delivery still works - The completion handoff to the requester session is runtime-generated internal context (not user-authored text) and includes: - - `Result` (`assistant` reply text, or latest `toolResult` if the assistant reply is empty) + - `Result` (latest visible `assistant` reply text, otherwise sanitized latest tool/toolResult text) - `Status` (`completed successfully` / `failed` / `timed out` / `unknown`) - compact runtime/token stats - a delivery instruction telling the requester agent to rewrite in normal assistant voice (not forward raw internal metadata) @@ -235,6 +235,7 @@ Sub-agents report back via an announce step: - The announce step runs inside the sub-agent session (not the requester session). - If the sub-agent replies exactly `ANNOUNCE_SKIP`, nothing is posted. +- If the latest assistant text is a silent token such as `NO_REPLY`, announce output is suppressed even if earlier visible progress existed. - Otherwise delivery depends on requester depth: - top-level requester sessions use a follow-up `agent` call with external delivery (`deliver=true`) - nested requester subagent sessions receive an internal follow-up injection (`deliver=false`) so the orchestrator can synthesize child results in-session @@ -247,9 +248,10 @@ Sub-agents report back via an announce step: - child session key/id - announce type + task label - status line derived from runtime outcome (`success`, `error`, `timeout`, or `unknown`) - - result content from the announce step (or `(no output)` if missing) + - result content selected from the latest visible assistant text, otherwise sanitized latest tool/toolResult text - a follow-up instruction describing when to reply vs. stay silent - `Status` is not inferred from model output; it comes from runtime outcome signals. +- On timeout, if the child only got through tool calls, announce can collapse that history into a short partial-progress summary instead of replaying raw tool output. Announce payloads include a stats line at the end (even when wrapped):