ToolCallStatus gives pending | in_progress | completed | failed, and long-running work reports via successive tool_call_update notifications. That covers a tool call running within a turn. Two adjacent cases appear to have no expression, and I'd like to know whether they're considered in scope.
1. Backgrounded vs foreground-blocking
in_progress covers both "the agent is blocked inside this tool" and "the agent moved on and this is running in the background".
Harnesses do distinguish these. Claude Code exposes is_backgrounded on tool results, and a background_tasks[] summary whose documented purpose is to "distinguish 'session is done' from 'session is paused waiting for background work to wake it'". It also auto-backgrounds a command that exceeds its timeout, so a tool call can become backgrounded without the agent ever requesting it.
A client rendering an ACP session currently can't tell whether the agent is stuck or waiting, and an orchestrator can't tell whether silence means progress or a wedge.
2. A tool call settling after its turn ends
When backgrounded work completes after prompt() returns, its tool_call_update arrives outside the turn that created it. I can't find a statement about whether that's permitted.
This interacts with #554, which proposes a turn_complete signal meaning all session/update notifications for a turn have been delivered. If backgrounded tool calls may still emit updates after the turn, that signal needs qualifying, or backgrounded calls need to be explicitly excluded from it. Both can't be unconditionally true.
Asking rather than proposing
Not proposing a shape. The questions are:
- Are these in scope for the protocol, or intentionally left to implementations?
- Is the intended modelling that a backgrounded tool call simply remains
in_progress indefinitely, including across turn boundaries?
Happy to write this up as an RFD if the answer to the first is yes.
ToolCallStatusgivespending | in_progress | completed | failed, and long-running work reports via successivetool_call_updatenotifications. That covers a tool call running within a turn. Two adjacent cases appear to have no expression, and I'd like to know whether they're considered in scope.1. Backgrounded vs foreground-blocking
in_progresscovers both "the agent is blocked inside this tool" and "the agent moved on and this is running in the background".Harnesses do distinguish these. Claude Code exposes
is_backgroundedon tool results, and abackground_tasks[]summary whose documented purpose is to "distinguish 'session is done' from 'session is paused waiting for background work to wake it'". It also auto-backgrounds a command that exceeds its timeout, so a tool call can become backgrounded without the agent ever requesting it.A client rendering an ACP session currently can't tell whether the agent is stuck or waiting, and an orchestrator can't tell whether silence means progress or a wedge.
2. A tool call settling after its turn ends
When backgrounded work completes after
prompt()returns, itstool_call_updatearrives outside the turn that created it. I can't find a statement about whether that's permitted.This interacts with #554, which proposes a
turn_completesignal meaning allsession/updatenotifications for a turn have been delivered. If backgrounded tool calls may still emit updates after the turn, that signal needs qualifying, or backgrounded calls need to be explicitly excluded from it. Both can't be unconditionally true.Asking rather than proposing
Not proposing a shape. The questions are:
in_progressindefinitely, including across turn boundaries?Happy to write this up as an RFD if the answer to the first is yes.