Carry the originating tool_call_id on ActionRequest for HITL tool interrupts

[Rul1an]

Filing this here after a deepagents discussion (langchain-ai/deepagents#2798) where it came up building an external human-in-the-loop consumer. Yokubjon (@yakubka) confirmed the gap there and suggested opening an issue or PR that references the discussion; since ActionRequest is defined in this repo, langgraph seems like the right home for it.

When execution pauses on a tool call for human review, the interrupt surfaces an ActionRequest with action and args, but not the originating tool_call_id. On resume, a consumer reconstructing the ToolMessage needs that id to match the original call in the message history, so today it has to be recovered out of band, either from the raw interrupt value or by reading agent.get_state(config) and pulling AIMessage.tool_calls[*].id. The id already exists at the point the interrupt is created; it just isn't carried onto the artifact the consumer sees.

Proposal: carry the originating tool_call_id as an optional field on ActionRequest (or alongside it on the interrupt payload), populated where the interrupt is constructed from a tool call. As an optional field it stays backward compatible and leaves non-tool-call interrupts unchanged, and it removes the cross-surface correlation for external consumers, so the approval artifact carries the one field that ties it back to the specific call.

Happy to open a PR if this seems reasonable. One open question for you: should the field sit on ActionRequest itself, or on the surrounding interrupt payload?

Reference: langchain-ai/deepagents#2798

[Tuttotorna]

This is the right issue to fix.

The core problem is not only convenience for external HITL consumers. It is transition binding.

When a tool call is interrupted for human review, the approval/rejection artifact must carry the identity of the exact transition it refers to. Otherwise the consumer has to reconstruct that identity out of band, which makes the review artifact incomplete.

Current flow:

tool_call generated → interrupt exposes ActionRequest(action, args) → consumer approves/rejects → consumer must recover tool_call_id elsewhere

Supported flow:

tool_call generated → interrupt exposes ActionRequest(action, args, tool_call_id) → approval/rejection binds directly to the originating tool_call_id → resume can create the correct ToolMessage without cross-surface correlation

I would put the optional field on "ActionRequest" itself.

Reason: the "tool_call_id" is not just transport metadata. It is part of the action request identity when the interrupt originates from a tool call. The artifact shown to the external consumer should carry the field needed to bind the human decision to the exact pending call.

Suggested fix:

• add optional "tool_call_id: str | None" to "ActionRequest"
• populate it when the interrupt is constructed from a tool call
• leave it unset for non-tool-call interrupts
• keep backward compatibility for existing consumers
• add a regression test verifying that a HITL tool interrupt carries the originating call id

If maintainers agree with this direction, could this issue be assigned to me so I can open a PR for the fix?

[yakubka]

the missing tool_call_id on ActionRequest is a real friction point for any consumer that needs to close the loop on a HITL interrupt. when the interrupt fires you have the action and args but not the id, so the consumer has to either enumerate pending tool calls in the state to find the matching one by action name and args, which breaks if the same tool appears more than once in a batch, or store the id out of band before interrupting, which means instrumenting the graph.\n\nincluding tool_call_id directly in ActionRequest would make external HITL consumers straightforward. the ToolMessage on resume always requires it anyway, so surfacing it at interrupt time avoids the reconstruction problem entirely and keeps the contract clean on both sides.

[IgorGanapolsky]

Missing tool_call_id on HITL ActionRequest is a reliability contract hole for any external reviewer/resume path: the human (or external system) cannot reconstruct a valid ToolMessage that OpenAI-compatible APIs will accept, so resume either fails or invents an id and corrupts the transcript.

For production HITL I would treat this as required payload, not optional metadata:

• ActionRequest should carry at least: action, args, tool_call_id, and preferably run_id / step identity.
• On resume, reject payloads that cannot bind to an open tool call (fail closed) instead of accepting a best-effort match.
• Regression: interrupt on tool → external consumer builds ToolMessage with returned id → resume continues without “tool message without tool_calls” errors.

If you have a minimal deepagents/langgraph interrupt dump (redacted ActionRequest JSON as emitted today), I can map the smallest schema addition that unblocks external HITL consumers without breaking existing in-graph resume — no payment needed for that map.