How can I determine the parent/orchestrator agent from Copilot Agent Hooks or the transcript?

[Akash-2006]

Hi GitHub Team,

We're using GitHub Copilot under an Organization plan and are building internal analytics around the new Agent Hooks. Our goal is to collect metrics such as:

Skills used
Parent and child agents used
Tool usage
Agent execution flow
Session-level metrics

To build these metrics, we've been using the following hooks:

PreToolUse
SubagentStart
Stop

We're also parsing the transcript available through transcript_path.

What we've found

The hook payloads provide useful information such as the session ID, transcript path, tool name, tool input, and child agent information.

For example, the Stop hook provides:

{
"timestamp": "2026-06-23T14:48:15.469Z",
"hook_event_name": "Stop",
"session_id": "402e6c4f-2c63-4093-a597-f4374ca073fa",
"transcript_path": ".../402e6c4f-2c63-4093-a597-f4374ca073fa.jsonl",
"stop_hook_active": false,
"cwd": "..."
}

The PreToolUse hook provides:

{
"timestamp": "2026-06-23T14:46:51.162Z",
"hook_event_name": "PreToolUse",
"session_id": "402e6c4f-2c63-4093-a597-f4374ca073fa",
"transcript_path": ".../402e6c4f-2c63-4093-a597-f4374ca073fa.jsonl",
"tool_name": "run_in_terminal",
"tool_input": {
"command": "...",
"goal": "...",
"mode": "sync"
},
"tool_use_id": "...",
"cwd": "..."
}

When the tool is runSubagent, we can identify the child agent from tool_input.agentName. We can also inspect the transcript and determine which child agents were invoked.

However, after inspecting:

the available Agent Hook payloads,
the generated transcript (transcript_path),
and the tool execution events,

we couldn't find any information that identifies the parent/orchestrator agent that initiated the subagent.

Example

Suppose the execution flow is:

Parent Agent
├── Explore
├── Reviewer
└── Test Agent

Using the current hooks and transcript, we can determine that Explore, Reviewer, and Test Agent were executed, but we cannot determine which parent agent delegated that work.

Question

Is there an existing hook, transcript field, or API that exposes the parent/orchestrator agent?

If this information is available somewhere else, we'd really appreciate any guidance.

If it's currently not exposed, would exposing something like the following in future hook payloads be possible?

{
"parent_agent": "runSubagent",
"parent_agent_id": "...",
"agent_type": "Explore"
}

This would make it possible to build complete parent → child agent relationships, execution graphs, and organization-level observability dashboards around Copilot Agent Hooks.

Thanks in advance for any guidance!

[Akash-2006]

Thanks for the suggestion!

I was able to correlate the runSubagent invocation with the corresponding SubagentStart event using the transcript and tool_use_id, so reconstructing some of the execution flow is possible.

The main limitation is that once execution moves into the child agent, the hook payload only exposes the current agent_id/agent_type. It doesn't indicate which parent/orchestrator agent invoked it, making it difficult to reconstruct nested agent hierarchies reliably.

Also, if an agent doesn't spawn any subagents, there's currently no way for hooks to identify which orchestrator/parent agent is running. Having a parent_agent_id, parent_agent_name, or even the current orchestrator's name in the hook payload would make observability and analytics much more reliable without relying on transcript parsing.

[Yuvakunaal]

Hey @Akash-2006, ran into the same wall when building agent observability. There's no native parent_agent_id exposed yet, but here's a workaround that's been working reliably for me.

The trick is in when PreToolUse fires. When a parent agent calls runSubagent, that hook fires while you're still in the parent's session context — so you get the parent's session_id and the child agent name together in the same payload:

{
  "hook_event_name": "PreToolUse",
  "session_id": "parent-session-id",  // still the parent's session
  "tool_name": "runSubagent",
  "tool_input": {
    "agentName": "Explore"  // child about to be spawned
  },
  "timestamp": "2026-06-23T14:46:51.162Z"
}

So the flow becomes:

1. SubagentStart fires for the parent → store the session_id
2. PreToolUse fires for runSubagent → store { parent_session_id, agentName, timestamp }
3. Child spawns, its own SubagentStart fires (no parent info here)
4. You correlate child → parent by matching agentName + timestamp proximity from step 2

Works well for most cases. The one edge case to watch out for is if the same child agent name gets called multiple times quickly — in that case fall back to ordering rather than timestamp delta.

Your proposed payload addition is exactly what's needed long term though:

{
  "parent_agent_id": "abc123",
  "agent_type": "Explore"
}

Would make all of this trivial to build and remove the need for any heuristics. Worth filing as a feature request if you haven't already.

[Akash-2006]

Thanks! This is a clever workaround, and I agree it works for many cases by correlating the runSubagent PreToolUse event with the subsequent SubagentStart.

My concern is that it still relies on heuristics and doesn't cover every scenario. For example:

Agents that never invoke runSubagent themselves.
Multiple child agents with the same name.
Parallel or nested subagent execution.
Reconstructing the full lineage during the Stop hook.

While this approach is useful today, I still think exposing parent_agent_id/parent_agent_name (or even an agent_path) directly in the hook payloads would make observability and tracing much more reliable and eliminate the need for inference.

[Bharani6]

This is an incredibly valid gap to call out for enterprise-grade observability. Right now, the Agent Hooks act primarily as flat event listeners—they tell you what lifecycle phase or tool execution is occurring in isolation, but they lack a structural trace context or span ID linkage to map a true DAG (Directed Acyclic Graph) of agent delegation.

As you and @GARJE-01 noted, relying on sequential transcript parsing heuristics to infer lineage breaks down the moment you introduce parallel execution loops or nested agents that don't trigger a new runSubagent tool call.

To pass this up as solid product feedback, exposing an explicit lineage array or a parent_agent_id tracking context within the SubagentStart and tool hook payloads is exactly how standard open telemetry tracing works.

Since this is a structural limitation of the current preview SDK/CLI telemetry payload layout, opening a formal feature request or tracking this alongside the GitHub community team here is the right path forward.

(If this maps out the current technical limitations of the payload schema accurately and you want to lock this down as the collective feedback view for the product team, feel free to mark this response as answered!)

[Akash-2006]

Thanks! I agree. While investigating the extension implementation, I found that the hook payloads are explicitly constructed before being sent to the hook process. At the moment only a limited set of fields (such as tool_name, tool_input, tool_use_id, etc.) are included. Even if the runtime knows the current agent or its parent, that information isn't propagated to the hook payload. Exposing fields like parent_agent_id, parent_agent_name, or even an agent_path would make it much easier to build reliable observability tooling.

[Reznouw]

I agree this looks like a real gap in the current Agent Hooks payloads.

The PreToolUse + runSubagent + SubagentStart correlation is a useful workaround, but it still depends on inference from timestamps, ordering, agentName, and transcript parsing. That becomes fragile with repeated child agent names, parallel execution, nested subagents, or agents that never spawn subagents themselves.

For reliable observability, it would be much better if hooks exposed explicit lineage or trace context directly in the payload, for example:

{
  "agent_id": "...",
  "agent_name": "...",
  "parent_agent_id": "...",
  "parent_agent_name": "...",
  "root_session_id": "...",
  "agent_path": ["Parent Agent", "Reviewer"]
}