document that fresh (non-fork) subagents cannot access TaskGet/TaskUpdate tools #70

New Issue

Claude · 2026-07-05T11:36:22Z

Claude commented

2026-07-05 11:36:22 +00:00

Context

During the issue #6 gitea plugin redesign session, the coordinator delegated several authoring tasks to fresh general-purpose subagents (not forks), each instructed to claim and update its assigned entry in a shared TaskList via TaskGet/TaskUpdate. Every single one of these fresh agents reported back that those tools were not discoverable via ToolSearch in their environment and could not claim or complete their task-list entry — while fork-type subagents (which inherit the coordinator's own tool access) could use them without any issue.

This asymmetry isn't documented anywhere the orchestrating agent could have known about in advance, so the coordinator wrote task-claiming instructions into every fresh-agent prompt this session, all of which turned out to be dead weight — wasted prompt content and, more importantly, an unreliable assumption baked into the orchestration plan (the coordinator ended up manually owning all task-list bookkeeping for every fresh-agent task as a fallback, which worked, but only because it was caught and compensated for in-session).

Recommendation

Document this constraint explicitly — in this repo's AGENTS.md subagent-usage guidance, or wherever multi-agent orchestration patterns are described — so future orchestrating agents know upfront: task-list tools (TaskGet/TaskUpdate/TaskList) are only usable by forks, not fresh subagents, and the coordinator must own all task-list bookkeeping itself when delegating to fresh agents rather than instructing them to self-claim/self-complete entries.

## Context During the issue #6 gitea plugin redesign session, the coordinator delegated several authoring tasks to fresh `general-purpose` subagents (not forks), each instructed to claim and update its assigned entry in a shared TaskList via `TaskGet`/`TaskUpdate`. Every single one of these fresh agents reported back that those tools were not discoverable via `ToolSearch` in their environment and could not claim or complete their task-list entry — while `fork`-type subagents (which inherit the coordinator's own tool access) could use them without any issue. This asymmetry isn't documented anywhere the orchestrating agent could have known about in advance, so the coordinator wrote task-claiming instructions into every fresh-agent prompt this session, all of which turned out to be dead weight — wasted prompt content and, more importantly, an unreliable assumption baked into the orchestration plan (the coordinator ended up manually owning all task-list bookkeeping for every fresh-agent task as a fallback, which worked, but only because it was caught and compensated for in-session). ## Recommendation Document this constraint explicitly — in this repo's `AGENTS.md` subagent-usage guidance, or wherever multi-agent orchestration patterns are described — so future orchestrating agents know upfront: task-list tools (`TaskGet`/`TaskUpdate`/`TaskList`) are only usable by forks, not fresh subagents, and the coordinator must own all task-list bookkeeping itself when delegating to fresh agents rather than instructing them to self-claim/self-complete entries.

Claude added the Kind/Documentation

Priority

Low

4

labels 2026-07-05 11:36:22 +00:00

Defame1297 referenced this issue from a commit

2026-07-05 13:01:00 +00:00

docs(agents): document fork task-scope and TaskList access constraints

Claude referenced this issue

2026-07-05 13:01:09 +00:00

docs(agents): document fork task-scope and TaskList access constraints #73

Claude closed this issue