Split out from #16328 (@versun docx triage). The docx flagged a real failure mode:

User used the sharethis-chat skill via delegation. Subagent reported success; page was empty except "test". User asked "are you sure?", Hermes rechecked, found only "test" had been uploaded.

PR #16325 shipped the cheap mitigation — a new bullet in the delegate_task tool description warning the calling model that subagent summaries are self-reports, and asking it to verify external-side-effect claims (HTTP uploads, remote writes, file creation at shared paths) by requiring a verifiable handle (URL, ID, path) from the subagent and fetching/stat'ing it before claiming success to the user.

That's a prompt-level nudge. It relies on the model reading and following the guidance. This issue tracks the structural fix.

The underlying problem

tools/delegate_tool.py returns a summary string to the parent. By design, the parent has zero visibility into intermediate tool results in the subagent's context — that's the whole point of context-isolated delegation. But it means:

1. A subagent can claim "uploaded" when the last HTTP response was a 400.
2. A subagent can claim "wrote file X" when it actually wrote to /tmp/… and the shared path still has the old content.
3. A subagent can claim "the deploy succeeded" when the deploy script exited 0 on a no-op.

Each individual tool (terminal, write_file, send_message, etc.) has its own success/failure semantics the subagent sees. None of that bubbles up in the summary. The parent only gets the subagent's narrative reconstruction of what happened.

What a structural fix would look like

Not obvious, and that's why we deferred it. Some possible shapes:

• Side-effect manifest. Subagent records a typed list of side-effects it claims to have performed ({"kind": "http_post", "url": "…", "status": 200}, {"kind": "file_write", "path": "…", "bytes": 14823}). Parent gets the manifest alongside the summary and can verify each entry with a corresponding tool call. Needs: a recording mechanism, a taxonomy of side-effect kinds, a verification library per kind, and opt-in per-call (not every delegation has external effects worth verifying).

• Capability-scoped subagent grants. Parent declares what external-effect capabilities the subagent is granted (network.post, fs.write_outside_cwd) and the manifest records what was used. Lets the parent decide whether to verify.

• Tool-level result propagation. Specific tools (HTTP clients, upload helpers) return a "verifiable handle" as part of their normal result; delegate_task surfaces those handles in a structured field on the summary object.

• Stay with the warning. Accept the structural limitation and lean harder on the tool-description warning + skill-level verification (sharethis-chat skill does a GET <url> and checks content length before returning).

Non-goals

• Preventing a malicious subagent from lying. This is about honest mistakes, not adversarial cases. Parent-side verification raises the bar but doesn't eliminate the class.
• Verifying every subagent call. Most delegations (research, code review, debugging) have no external side-effects worth verifying. The mechanism should be opt-in.
• Breaking the context-isolation invariant. The reason delegate_task exists is to keep intermediate noise out of the parent's context. Any mechanism here needs to avoid leaking that.

Related

• Tracking: #16328 (the original docx triage — this is the one deferred item)
• Mitigation shipped: #16325 (delegate_task description warning)
• Code: tools/delegate_tool.py — DELEGATE_TASK_SCHEMA description and the per-task subagent result synthesis.

Priority: P3 (the mitigation covers the common case; structural fix is a design question, not a bug).