[FEATURE] Populate a stable teammate identity in PreToolUse/SubagentStart hook payloads (Agent Teams)

Problem

Agent Teams lets a coordinator session spawn multiple named teammates (e.g. Agent(name="kiln", ...)) that all run with the same cwd as the coordinator. Hooks (PreToolUse, SubagentStart, etc.) receive a session/cwd-derived field, but no populated, stable field that identifies which named teammate actually made the call. Every hook payload we've inspected carries an empty agent_id for real, live calls originating from a named teammate — confirmed three independent ways:

1. PreToolUse (a custom approval-gate hook) — logs every tool call requiring human sign-off, including a session (cwd basename) and an agent_id field. We wired agent_id through every log/message call site and triggered a real self-edit from a named teammate ("kiln"). The resulting live log entry:

``json
{"timestamp": "2026-08-13T10:40:11", "request_id": "26", "gate_type": "SELF_EDIT", "session": "agenta", "agent_id": "", "target": "/Users/.../hooks/<redacted>.py", "action": "Edit -> ...", "status": "pending"}
`
agent_id is the empty string — not missing, not null, genuinely ""` — even though the call came from a specific named teammate, not the coordinator.

1. SubagentStart payload — same gap: no populated per-teammate identity field.

1. Our own doc-enforcement PreToolUse hook — tracks which agent/session edited which file, keyed by agent_id falling back to raw session_id when agent_id is empty. Every entry from the named teammate that built and tested this hook landed under its own raw session_id, not its team name ("kiln"), because there was no better field to key on.

session/cwd is useless for this because all teammates in an Agent Teams run share the coordinator's working directory — it can tell you which project, never which teammate.

Proposed

Populate a stable, human-readable teammate identity (the name= passed to Agent(), or equivalent) in:

• PreToolUse / PostToolUse hook payloads, as a real (non-empty) value in whatever field is already reserved for this (we observed a field named agent_id that is always present but always empty for teammate calls — either populate that field correctly, or document the actually-correct field to read).
• SubagentStart / SubagentStop payloads, same identity.

This doesn't need to be new plumbing from scratch — the harness clearly already tracks some per-agent identity internally (Agent Teams panes are addressable by name via SendMessage), this is asking for that same identity to be exposed to hooks, which currently only see coordinator-vs-not (via the empty/non-empty check working for subagent-exemption logic) but never which named teammate.

Why it matters

We run approval-gated hooks (human-in-the-loop sign-off via Telegram/dialog for risky actions like self-editing our own hooks, credential access, destructive file ops) shared across a coordinator and several persistent named teammates in the same project directory. Today every approval prompt we see is indistinguishable — "agenta" — regardless of whether the coordinator or one of several named teammates triggered it, which defeats the point of having named teammates for auditability: we cannot tell from the approval log, after the fact, which teammate asked for a given approval. The same gap blocks any hook that wants to track/enforce something per-teammate rather than per-project (our doc-enforcement gate wanted per-teammate pending-work lists and had to fall back to a shared session-level list instead).

Version: Claude Code (Agent Teams / named teammates via Agent() + SendMessage), observed 2026-08-13.