What happened
delegate_task was working correctly in cron jobs from 7/1 through 7/8 (v0.18.1). After upgrading to 0.18.2 on 7/9, all delegate_task calls from cron agents became fire-and-forget — returning only a 300-char dispatch confirmation instead of waiting for the actual subagent results (1000-23000 chars of analysis).
Evidence (from agent.log)
Before 0.18.2 (7/1-7/8):
delegate_task completed (35.42s, 3,419 chars) ✓ sync, real results
delegate_task completed (402.71s, 15,075 chars) ✓ sync, real results
After 0.18.2 (7/9+):
Dispatched async delegation batch deleg_xxx
delegate_task completed (0.05s, 322 chars) ✗ async, dispatch confirm only
Root cause
run_agent._dispatch_delegate_task (line 5685) forces background=True for all top-level agents:
_is_subagent = getattr(self, "_delegate_depth", 0) > 0
return _delegate_task(
...
background=(not _is_subagent), # top-level → always async
)In interactive sessions this is fine — async results re-enter the conversation. But cron sessions produce ONE final response and exit. The subagent results never arrive because the session is already closed.
Impact
Any cron job that uses delegate_task silently produces incomplete output. The agent dispatches subagents, gets back "dispatched" confirmations, then outputs its final response — which contains only placeholder text like "waiting for results" instead of actual analysis.
This affects the evening portfolio report cron (6-role investment committee) and any other scheduled job that relies on parallel subagent analysis.
Suggested fix
Detect cron/stateless session context and fall back to synchronous execution (inline the subagent results), similar to how the stateless HTTP API path already falls back at lines 2778-2796:
if not _async_ok:
# ... run synchronously insteadA cron session is effectively stateless — it should get the same treatment.
Workaround
Currently working around by removing delegate_task from cron prompts entirely and having the main agent simulate multiple analyst roles in its own context. This loses the benefit of isolated subagent contexts and adds significant prompt complexity.
What happened
delegate_task was working correctly in cron jobs from 7/1 through 7/8 (v0.18.1). After upgrading to 0.18.2 on 7/9, all delegate_task calls from cron agents became fire-and-forget — returning only a 300-char dispatch confirmation instead of waiting for the actual subagent results (1000-23000 chars of analysis).
Evidence (from agent.log)
Before 0.18.2 (7/1-7/8):
After 0.18.2 (7/9+):
Root cause
run_agent._dispatch_delegate_task(line 5685) forcesbackground=Truefor all top-level agents:In interactive sessions this is fine — async results re-enter the conversation. But cron sessions produce ONE final response and exit. The subagent results never arrive because the session is already closed.
Impact
Any cron job that uses delegate_task silently produces incomplete output. The agent dispatches subagents, gets back "dispatched" confirmations, then outputs its final response — which contains only placeholder text like "waiting for results" instead of actual analysis.
This affects the evening portfolio report cron (6-role investment committee) and any other scheduled job that relies on parallel subagent analysis.
Suggested fix
Detect cron/stateless session context and fall back to synchronous execution (inline the subagent results), similar to how the stateless HTTP API path already falls back at lines 2778-2796:
A cron session is effectively stateless — it should get the same treatment.
Workaround
Currently working around by removing delegate_task from cron prompts entirely and having the main agent simulate multiple analyst roles in its own context. This loses the benefit of isolated subagent contexts and adds significant prompt complexity.