What task are you trying to do?
We want PawWork's agent tool to behave like a schedulable subagent lifecycle, not just a synchronous helper call that eventually returns a text block.
This matters when the main agent delegates slow or parallel work to one or more subagents. The main agent should be able to list active subagents, inspect their results, stop the ones it owns, and recover cleanly when a subagent is canceled, empty, failed, or slow.
What happens today?
The current agent tool is mostly a foreground call: the parent session starts a child session and waits for a final text result. That leaves several product gaps:
- If a subagent is manually stopped, the parent may not receive an explicit
canceled_by_user result.
- If a subagent completes without final text, the parent can see an empty result instead of an actionable state.
- If a foreground subagent runs for a long time, the parent can appear stuck.
- If multiple subagents exist, the model has no first-class way to list, inspect, or stop the subagents it launched.
- The main session card does not reliably show the latest subagent activity.
- Session exports do not yet provide a clear subagent lifecycle trail for debugging.
What would a good result look like?
PawWork tracks each agent invocation as a structured SubagentRun attached to the parent session. The model can use agent_list, agent_output, and agent_stop to coordinate its own subagents. The UI stays simple: the existing agent card only shows the latest useful activity line.
Subagent cancellation, empty output, failure, foreground timeout warning, background completion, and result consumption are explicit states. Background completion injects a notification into the parent session so the main agent does not continue blindly.
Which audience does this matter to most?
Both. Non-technical users get a reassuring experience where subagents visibly make progress and cancellation works. Technical users get debuggable session exports and predictable model-facing scheduling tools.
Acceptance criteria
agent supports run_in_background?: boolean, defaulting to foreground.
- A structured
SubagentRun lifecycle is persisted on the parent session's agent tool metadata.
- Foreground and background subagents share the same lifecycle model.
- The model can call
agent_list, agent_output, and agent_stop.
- Background subagent concurrency is limited to 5 per parent session.
- User cancellation returns
canceled_by_user, never an empty result.
- Empty final output returns
completed_empty, never an empty result.
- A foreground subagent running longer than 10 minutes emits a warning and wakes the parent, but is not killed automatically.
- Background terminal states inject a parent-session notification and trigger auto-resume when safe.
- The existing agent card shows the latest useful activity in one line.
- Session export includes subagent lifecycle state and event-level progress.
- The first version does not add a full task system, automatic backgrounding, a new task panel, cross-parent-session management, full transcript pagination, or automatic runtime kill.
What task are you trying to do?
We want PawWork's
agenttool to behave like a schedulable subagent lifecycle, not just a synchronous helper call that eventually returns a text block.This matters when the main agent delegates slow or parallel work to one or more subagents. The main agent should be able to list active subagents, inspect their results, stop the ones it owns, and recover cleanly when a subagent is canceled, empty, failed, or slow.
What happens today?
The current
agenttool is mostly a foreground call: the parent session starts a child session and waits for a final text result. That leaves several product gaps:canceled_by_userresult.What would a good result look like?
PawWork tracks each
agentinvocation as a structuredSubagentRunattached to the parent session. The model can useagent_list,agent_output, andagent_stopto coordinate its own subagents. The UI stays simple: the existing agent card only shows the latest useful activity line.Subagent cancellation, empty output, failure, foreground timeout warning, background completion, and result consumption are explicit states. Background completion injects a notification into the parent session so the main agent does not continue blindly.
Which audience does this matter to most?
Both. Non-technical users get a reassuring experience where subagents visibly make progress and cancellation works. Technical users get debuggable session exports and predictable model-facing scheduling tools.
Acceptance criteria
agentsupportsrun_in_background?: boolean, defaulting to foreground.SubagentRunlifecycle is persisted on the parent session's agent tool metadata.agent_list,agent_output, andagent_stop.canceled_by_user, never an empty result.completed_empty, never an empty result.