Part of #275
Question
Surfaced while resolving #276: all four adapters (Claude Code, Codex, Claude Agent SDK, OpenAI Agents SDK), as currently wired, need the same general temporal/agent_id-matching inference rule for subagent parent-linking -- none has a real field on the API surface each adapter actually uses today. But one asymmetric upgrade path exists: the Claude Agent SDK's message-stream API (query()/ClaudeSDKClient.receive_response(), yielding UserMessage/AssistantMessage) carries a genuine parent_tool_use_id field exactly matching the spawning tool call's id -- verified empirically, not just in docs. claude.py (this repo's adapter) doesn't consume that stream today; it only wires up the hooks={...} API, which does not carry this field. OpenAI Agents SDK has no equivalent path anywhere in its public surface (including its tracing spans, which don't carry tool_call_id).
Resolve: should agent-context-graph's Claude Agent SDK adapter be extended to also consume the message stream (giving Claude-Agent-SDK users a real, non-inferred parent link), accepting that this creates a real asymmetry (three of four adapters stay inference-only, one gets a strictly better mechanism) -- or should the general inference rule (from #277) be used uniformly across all four adapters for consistency, leaving this upgrade path as explicit future work? Resolve with the driving user via /grilling + /domain-modeling.
Part of #275
Question
Surfaced while resolving #276: all four adapters (Claude Code, Codex, Claude Agent SDK, OpenAI Agents SDK), as currently wired, need the same general temporal/agent_id-matching inference rule for subagent parent-linking -- none has a real field on the API surface each adapter actually uses today. But one asymmetric upgrade path exists: the Claude Agent SDK's message-stream API (
query()/ClaudeSDKClient.receive_response(), yieldingUserMessage/AssistantMessage) carries a genuineparent_tool_use_idfield exactly matching the spawning tool call's id -- verified empirically, not just in docs.claude.py(this repo's adapter) doesn't consume that stream today; it only wires up thehooks={...}API, which does not carry this field. OpenAI Agents SDK has no equivalent path anywhere in its public surface (including its tracing spans, which don't carrytool_call_id).Resolve: should
agent-context-graph's Claude Agent SDK adapter be extended to also consume the message stream (giving Claude-Agent-SDK users a real, non-inferred parent link), accepting that this creates a real asymmetry (three of four adapters stay inference-only, one gets a strictly better mechanism) -- or should the general inference rule (from #277) be used uniformly across all four adapters for consistency, leaving this upgrade path as explicit future work? Resolve with the driving user via /grilling + /domain-modeling.