Summary
A consumer that renders tool activity from the SSE stream onto a chat surface has to carry state and special cases to compensate for two gaps in the aura.* tool lifecycle events. Both are small on the producer side and would let consumers render the stream 1:1 — which is also the stated goal of #576.
1. Orchestration has no post-gate "the call is actually running" event.
Single-agent mode emits aura.tool_requested (pre-gate, carries arguments) and then aura.tool_start once the call is past the HITL gate. Orchestration emits only aura.orchestrator.tool_call_started, which fires before the gate. A consumer that posts on that event announces calls that may then be held for approval or denied — and, in a HITL flow, posts "calling pods_delete…" above the approval prompt, which must remain the last message until a decision is made. Today the consumer must hold every orchestration start event until either an aura.approval_completed or the matching tool_call_completed proves the call ran.
Ask: emit a post-gate start event in orchestration mode with the same meaning as single-agent aura.tool_start. Keeping the pre-gate event is fine — it's the only one carrying arguments — but consumers need a signal that means "past the gate".
(Draft PR #595 implements this as aura.orchestrator.tool_call_executing, via an on_execute hook on WrappedTool, and adds tool_name to the completion event per ask 2.)
2. Tool identity is inconsistent across the two event families.
- Single-agent events key on
tool_id; orchestration events key on tool_call_id.
aura.orchestrator.tool_call_completed carries tool_call_id, success, duration_ms, result but not tool_name (nor worker_id), so a consumer must keep a map of open calls from the start event just to label the completion — and must process events in a specific order to keep that map correct.
Ask: one id field name across both families, and tool_name (and worker_id where applicable) on every lifecycle event for a call, including completion. The start→complete correlation should be possible from the completion event alone.
With both in place a consumer can be a stateless table from event → rendered line, and the CLI-style task tree (plan_created / task_started / task_completed) can be rendered by chat consumers with no bespoke handling.
Additional Context
Searched Issues
Code of Conduct
Summary
A consumer that renders tool activity from the SSE stream onto a chat surface has to carry state and special cases to compensate for two gaps in the
aura.*tool lifecycle events. Both are small on the producer side and would let consumers render the stream 1:1 — which is also the stated goal of #576.1. Orchestration has no post-gate "the call is actually running" event.
Single-agent mode emits
aura.tool_requested(pre-gate, carriesarguments) and thenaura.tool_startonce the call is past the HITL gate. Orchestration emits onlyaura.orchestrator.tool_call_started, which fires before the gate. A consumer that posts on that event announces calls that may then be held for approval or denied — and, in a HITL flow, posts "callingpods_delete…" above the approval prompt, which must remain the last message until a decision is made. Today the consumer must hold every orchestration start event until either anaura.approval_completedor the matchingtool_call_completedproves the call ran.Ask: emit a post-gate start event in orchestration mode with the same meaning as single-agent
aura.tool_start. Keeping the pre-gate event is fine — it's the only one carryingarguments— but consumers need a signal that means "past the gate".(Draft PR #595 implements this as
aura.orchestrator.tool_call_executing, via anon_executehook onWrappedTool, and addstool_nameto the completion event per ask 2.)2. Tool identity is inconsistent across the two event families.
tool_id; orchestration events key ontool_call_id.aura.orchestrator.tool_call_completedcarriestool_call_id,success,duration_ms,resultbut nottool_name(norworker_id), so a consumer must keep a map of open calls from the start event just to label the completion — and must process events in a specific order to keep that map correct.Ask: one id field name across both families, and
tool_name(andworker_idwhere applicable) on every lifecycle event for a call, including completion. The start→complete correlation should be possible from the completion event alone.With both in place a consumer can be a stateless table from event → rendered line, and the CLI-style task tree (
plan_created/task_started/task_completed) can be rendered by chat consumers with no bespoke handling.Additional Context
Searched Issues
Code of Conduct