/insights counts subagent sessions as the user's own, inverting the conclusion

Summary

/insights counts subagent and worktree-agent sessions as the user's own sessions. In my report, 46 of the 50 analysed sessions were agent sessions and only 4 were mine. Because agent sessions almost always come out as not_achieved, the report concluded that I abandon 43 of 50 sessions and built its entire narrative and recommendations on that. My own four sessions were 3 achieved, 1 not.

The conclusion is not slightly off, it is inverted.

What the report said

In 43 of 50 sessions the goal was 'not achieved' — not because Claude got it wrong, but because you interrupted during the exploration phase.

Roughly 28 of your 50 analyzed sessions are pure security_review requests on changed files.

Claude burns through Read and Grep calls (506 and 185 respectively, against only 83 Edits) building context, and somewhere around read #10 or #25 you cut it off.

Key pattern: You run the same security-review ritual on nearly every diff but interrupt Claude mid-exploration in the overwhelming majority of them — using it as a disposable second opinion rather than a process to complete.

What the underlying data says

The report writes one facet file per analysed session to ~/.claude/usage-data/facets/<session-id>.json. Matching each session id back to its transcript directory under ~/.claude/projects/ shows where it came from:

worktree or subagent sessions: 46
my own sessions:                4

Outcome of my own four:

2 mostly_achieved
1 fully_achieved
1 not_achieved

Nearly every not_achieved row is a session in a directory of the form
<project>--claude-worktrees-agent-<id> or <project>/<session-id>/subagents.

Reproduction:

cd ~/.claude/usage-data/facets
for f in *.json; do
  sid=$(basename "$f" .json)
  p=$(find ~/.claude/projects -name "$sid.jsonl" | head -1)
  case "$p" in
    *worktrees*|*subagents*) kind=agent ;;
    *)                       kind=user  ;;
  esac
  echo "$kind $(jq -r .outcome "$f")"
done | sort | uniq -c

Why agent sessions read as failures

A subagent is dispatched with one task, does it, sends its report back to the parent session and stops. There is no human in that session to confirm anything at the end, and the transcript simply ends. That is a completed task, but it scores as a goal that was not achieved.

Three downstream distortions follow from the same cause:

1. The "security reviews" are review agents. I dispatch a code-review agent per change; each one runs in its own session. The report reads them as me firing off review requests. On the day the report covers I typed exactly three slash commands, none of them a review.

1. The Read/Grep-to-Edit ratio (506 / 185 / 83) is by design. Most of those sessions belong to agents that are deliberately read-only (code review, QA). Aggregating them with implementation sessions makes exploration look pathological.

1. "You interrupted" conflates two different things. Agent sessions ending, and a user typing a new instruction mid-turn. In my workflow the second is normal: I steer while work is in progress. Both land in the same bucket.

Suggested fix

Classify sessions before analysing them, and either exclude agent sessions or report them separately:

• A transcript under <project>--claude-worktrees-* or <project>/<session-id>/subagents is not a user session.
• For agent sessions, "goal achieved" needs a different definition than for interactive ones, or should not be scored at all. Whether an agent succeeded is judged by the parent session, not inside its own transcript.
• If agent sessions are kept in scope, state the split in the report. "46 of the 50 sessions analysed were subagents you dispatched" is useful information; silently attributing their outcomes to the user is not.

Same for the tool-call aggregates: separating orchestration from delegated work would make the exploration numbers meaningful instead of alarming.

Impact

The recommendations follow from the wrong premise, so they miss. The report suggested giving each agent its own worktree and never dispatching the same task to two agents. Both are already hard rules in my CLAUDE.md, with the date each was learned. Meanwhile the actual pattern in the data — heavy multi-agent orchestration with read-only reviewers — is described as a problem to fix rather than as the workflow it is.

Environment

• Claude Code 2.1.226, native install, macOS (Darwin 25.5.0)
• 1177 sessions total, 58 analysed, window 2026-08-07 to 2026-08-10
• Heavy use of the Agent tool with isolation: "worktree"