[BUG] Teammate system prompt contradicts itself on result delivery ("the parent agent reads your text output" vs "plain text is not visible") — reports silently lost

Summary

An in-process teammate (spawned via Agent with a name, with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) receives two mutually exclusive statements in the same system prompt:

• one presents the final assistant message as the delivery mechanism for findings,
• the other states that plain text output is not visible to anyone on the team and SendMessage is mandatory.

Nothing reconciles them, and nothing instructs the teammate to send its report at end of task. Each teammate therefore resolves the contradiction on its own. Those that resolve it toward "the parent reads my text" finish with the report unread by anyone; those that resolve it toward "I must call SendMessage" deliver. The result is silent, intermittent loss of completed work — which is easy to misread as a flaky transport or as a badly scoped task.

Evidence — verbatim, quoted by the teammate itself

I spawned a named teammate and asked it only to report what its own instructions say. It quoted both places verbatim.

(a) Subagent framing — the parent reads the final message. From the Notes: section appended to its task:

"Do NOT Write report/summary/findings/analysis .md files. Return findings directly as your final assistant message — the parent agent reads your text output, not files you create. (Files written as input to another tool are fine; this note is about report files.)"

(b) Teammate framing — plain text is invisible. From the section # Agent Teammate Communication of the same system prompt:

"IMPORTANT: You are running as an agent in a team. To communicate with anyone on your team, use the SendMessage tool with to: "<name>" to send messages to specific teammates. Just writing a response in text is not visible to others on your team - you MUST use the SendMessage tool. The user interacts primarily with the team lead. Your work is coordinated through the task system and teammate messaging."

The same claim is repeated in the SendMessage tool description:

"Your plain text output is NOT visible to other agents — to communicate, you MUST call this tool."

The teammate's own assessment, before it was told what the bug report was about:

"My instructions are contradictory: one part says 'the parent agent reads the final answer', another says 'text in the response is not visible to the team, SendMessage is needed'. Most likely my final text returns to whoever called me, but I cannot derive a guarantee from my instructions."

Two aggravating details

No end-of-task reporting requirement. The instructions require SendMessage for communicating with teammates in general, but nowhere state that finishing a task means sending the report to the lead, nor name the lead as the destination for a final report. The only end-of-task guidance is the "final assistant message" wording in (a), which points at the parent, not at a SendMessage call.

Address mismatch. The only address documented in the SendMessage description is "main" ("The main conversation (background subagents only)"). The identity the teammate actually sees on incoming dispatches is team-lead, which appears elsewhere only in a legacy-protocol example. A teammate that does decide to report has to guess the destination too.

Observed effect

In one session, five named teammates ran trivial, well-specified tasks. Two delivered their final text to the lead; three went idle with a payload-less idle_notification and their finished reports readable only on disk at ~/.claude/projects/<project>/<session-id>/subagents/agent-<name>-<hash>.jsonl.

Environmental explanations do not split the groups: lead busy vs idle at completion time, network vs local work, and finishing alone vs in a batch all fail. Per-agent resolution of the contradiction does explain it.

The split is externally observable, which makes it easy to confirm: an idle_notification carries a summary field only when the teammate actually called SendMessage — the summary describes the sent message, not the work. The two teammates that delivered had it; the three that did not, did not. The same teammate reproduced both shapes in one session: its first idle notification, after answering only in its final assistant message, was payload-less; its second, after being asked explicitly to reply via SendMessage, carried "summary": "[to main] …". Nothing about the task or the environment changed between the two — only whether the agent resolved the contradiction toward calling the tool.

Environment

macOS 15.5, Claude Code 2.1.226 (2.1.228 installed), in-process teammate mode, Opus, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in ~/.claude/settings.json.

Suggested fix

This is a text fix, not a logic fix:

1. In the teammate system prompt, remove or scope the "the parent agent reads your text output" note when the agent runs as a teammate — it is simply false in that mode.
2. Add one unambiguous end-of-task instruction: when a task is finished, send the report to the lead with SendMessage, naming the exact address to use.
3. Align the address the teammate sees (team-lead) with the address the schema documents (main), or document both.

An agent cannot observe its own runtime mode, so a duty that depends on that mode has to be stated unconditionally by the dispatcher. Today the dispatcher states it twice, in opposite directions.

Related

• #71723 — the name parameter silently switches the call to the teammate protocol, which is how a caller ends up in this mode without intending to
• #84527 — the payload-less idle_notification on the receiving side; this issue is the sending side of the same loss