Repository navigation
Decide whether J5 agents keep delegate_task alongside spawn_agent, native Subagents and propose_crew #336
Description
Question
Should J5 agents have delegate_task at all? J5 already gives agents three ways to get help: the provider's native Subagent, spawn_agent (a Peer Agent), and propose_crew (a Crew). Every extra "make an agent" tool makes it more likely an agent picks the wrong one.
History
-
2026-08-24, ST5 (spawn-terminology session): Jackson removed
delegate_task: "a Peer Agent in a Subagent costume". The person can't talk to its child, yet the child outlives the agent that started it. -
2026-09-13, Jackson's review of feat(agents): pick library folders by browsing the environment's filesystem #124: it came back to replace Bryant's J5-only
invoke_agent:I think your
invoke_agentshould probably be folded intodelegate_task… I had originally removed it because it felt like a weird middle ground between provider subagents and peer agents. But, since you now have personas, we need a way to spawn subagents with them. That means that delegate_task has a purpose again. -
2026-09-14/15: Bryant agreed and shipped it in feat(agents): fold invoke_agent into delegate_task with a saved-agent parameter #141, with a J5-written description. That was needed because upstream's text tells the model to delegate for any subagent request, which contradicts J5's native-Subagent steering.
-
2026-09-17: Jackson's feat(agents): Crews, a roster the Captain proposes and the person approves #148 review added a second use: cross-provider work the person doesn't need to talk to directly.
Today delegate_task covers two narrow cases: running a saved persona as a subagent, and cross-provider help. Register entry D1 in docs/j5/product/upstream.md (#329) records it.
What to discuss (Jackson and Bryant)
- Is "run a persona as a subagent" worth a fourth spawn tool? Alternatives:
- a persona is only ever a Peer Agent (
spawn_agentwith a persona), or a Crew seat; - persona instructions reach native Subagents some other way.
- a persona is only ever a Peer Agent (
- Does cross-provider help need it, or is a Peer Agent enough?
- If it goes, what happens to
@personamentions, which route todelegate_tasktoday? See also A saved-agent mention can be silently ignored by the parent model #298.
Activity
docs(j5): D1 points at #336, D2 explains J5's own tools, D3 marked pr…
Jacksondr5 commentedon Sep 28, 2026
Jackson (2026-09-28): this is probably resolved by making the human-contact spectrum (
docs/j5/product/principles.md, Lenses) a real part of the app, and working out what that really means and how it fits into the product. A Foreground agent is one the person talks to; a Background agent reaches the person only through the Inbox or its Captain. If the app knows where an agent sits on that spectrum, 'which spawn tool' may reduce to 'where on the spectrum should this helper live?', rather than four overlapping tools the agent has to choose between.docs(j5): agents know what J5 owns and stop before changing upstream'…
Jacksondr5 commentedon Oct 10, 2026
Evidence for this discussion from the #508 live runs (2026-10-10, Claude Haiku, CLI 2.1.292). Before J5's tools were renamed, agents on Claude used Claude Code's native
SendMessagein place of J5'ssend_message, and ten of those native sends were delivered: they landed in another J5 thread's Claude session on the same machine, outside the ledger, with nothing recorded and nothing shown in the timeline. NativeListAgentslikewise lists other Claude sessions on the host, J5's and others'. After the rename (j5_send_message) there were no native calls in 20 runs, so agents no longer reach for it by mistake, but the channel still exists for an agent that chooses it. Withholding the native tools was rejected in #508 because native subagents needSendMessagefor follow-ups. Whether J5 should see or constrain this channel belongs here.Jacksondr5 commentedon Oct 12, 2026
One more data point for this, from the live-testing work (#546), 2026-10-12, after the
j5_prefix landed.A Claude Haiku agent on an isolated test server was asked in plain language to "list the other agents you can message". It called Claude Code's native
ListAgents, notj5_list_participants, and got back six real Claude sessions on the machine. It sent nothing. When the prompt named the J5 tools, it used them.So the prefix removed the name collision, as the 20 clean runs in #508 showed, but an open-ended prompt can still lead an agent to the native channel. No J5 change is proposed here: the 2026-10-10 direction stands (nothing native is withheld). The testing skill now tells testers to point a test agent at J5's tools and to check which tool it called.
Jacksondr5 commentedon Oct 12, 2026
A second observation from the live-testing cold run (#546), 2026-10-12, one run on one model: a Claude Haiku agent was asked in plain words to "ask me through my J5 inbox ... and mark it as blocking". It tried the harness's own
SendMessage(refused), thenPushNotification, thenTaskCreate, and reported that it had created a blocking task in the inbox. No Inbox row existed. A second thread that namedj5_list_participantsandj5_send_messageworked first time. Details in the artifacttest-reports/j5code-live-test-latest-change.md.Jacksondr5 commentedon Oct 12, 2026
Context from #519 (2026-10-12): Jackson ruled that
delegate_taskstays as it is for now. A check of the code confirmed it still creates a subagent of the calling thread and not a Peer Agent, so its overlap is with the provider's native subagents, which is this issue's question, and not withj5_spawn_agent. The comparison is in this comment on #519.