dispatching-parallel-agents: a dispatched agent can re-delegate and return a status promise, silently losing the lane

Open Beginner friendly
#2,202 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
88/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Domain
ai, documentation

Research direction

Start in skills/dispatching-parallel-agents/SKILL.md, reading the "Agent Prompt Structure" and "Review and Integrate" sections. Add the terminal-agent constraint and the receipt check described in the issue, then verify that both the prompt and review guidance require a deliverable rather than a status promise.

Written by the indexing model from the issue text.

Description

enhancement skills subagents

What happened

Dispatched five agents in one response for an independent-domain fan-out (research briefs, not test fixes — see the scope note below). Four returned full reports. The fifth silently re-delegated its brief to three of its own background sub-agents and returned this instead of a deliverable:

"All three research agents are running in the background... I'll report back once all three land"

It had spent ~76k tokens getting there. There is no "later" for a dispatched agent — its turn is its only output channel — so that lane was a total loss. The orchestrator had to notice the stub and re-dispatch to recover.

Why the skill doesn't currently prevent it

Two gaps, both in skills/dispatching-parallel-agents/SKILL.md:

  1. The dispatch prompt structure never states the agent's role. "Agent Prompt Structure" asks for focused / self-contained / specific-about-output, and the worked example ends with "Return: Summary of what you found and what you fixed." Nothing tells the agent it must not itself delegate, or that this turn is its only chance to deliver. An agent that reads its brief as "coordinate this work" is not violating any stated rule.

  2. The Verification section checks the work, not the receipt. It says "Review each summary — Understand what changed", which presumes a summary arrived. A lane that returns a confident status update passes a skim; a lane that returns nothing is obvious, but this one isn't.

Checked against main today: the strings terminal agent, do not spawn, sub-agent, report back and status update do not appear in that file.

Suggested fix

Add a mandatory clause to the dispatch prompt for any agent that isn't itself an orchestrator:

You are a terminal agent. Do not spawn sub-agents. Your text output in THIS turn is the entire deliverable — there is no later turn in which to report back.

And add a receipt check to "Review and Integrate", before "Read each summary":

Check each return is a deliverable, not a promise. Scan for promise-shaped language — "running in the background", "will report", "once complete", "kicked off" — and re-dispatch any lane that returned a status update instead of the artifact.

Generalised: any dispatch prompt should state whether the agent is terminal or an orchestrator, and the dispatcher should validate that returned payloads contain deliverables before treating a lane as complete.

Scope note

My fan-out was research lanes, not the failing-test scenario the skill's examples are built around. I'm reporting it anyway because the description — "Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies" — invites the broader use, and the role-ambiguity is domain-independent: a test-fixing agent can re-delegate too. If you'd rather narrow the skill's scope than add the clause, that would resolve it as well.

Dominant language
Shell
Stars
289k
Forks
25.8k
Avg merge
2d 11h
Merged PRs (30d)
19

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from obra/superpowers

All issues in obra/superpowers

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.