How to process interrupts inside a subagent

[Sai (Chenyl-Sai)]

I have a question about handling interrupts inside a SubAgent and preventing duplicate execution of tools.

A SubAgent is wrapped as a tool, and then grouped together with other tools inside a ToolNode. During a single LLM response, if both a SubAgent call and a normal tool call appear, they will run in parallel.

The problem is:
If the SubAgent encounters an interrupt, when the system resumes the execution it seems to re-run the entire ToolNode, which causes all tools (including the normal ones) to run again. How can this be avoided?

For normal tools, I can work around this by moving the interrupt earlier into the after_model stage, but for SubAgents I don’t have a way to intercept or shift the interrupt timing. This means I can’t prevent re-execution if the SubAgent is interrupted.

Similarly, if the LLM returns multiple SubAgent calls at once, an interrupt in any one of them will cause all SubAgents to be executed again on resume. How can I prevent one SubAgent’s interrupt from causing all other SubAgents to be re-run?

I previously built a deepagents-like framework using LangGraph. Similar to deepagents, I have a main Agent that includes FileOperate, TodoWrite, and Task tools. Inside the Task tool, I also include several tools (except Task itself).

To avoid duplicate executions during interrupt recovery, I had to separate SubAgent tools from normal tools:

• For normal tools, I moved the interrupt handling earlier into after_model to prevent re-execution.
• For SubAgents, I created 20 separate ToolNodes, and whenever a SubAgent runs, I record which ToolNode index handled it.
• On interrupt recovery, I look up the recorded index and resume execution from the corresponding ToolNode.

This workaround does prevent duplicated execution, but the whole solution feels very hacky and unnatural. It doesn’t seem like the intended way to deal with SubAgent interrupts, and managing multiple ToolNodes manually is error-prone and hard to maintain.

Is there a more idiomatic or recommended way to handle SubAgent interrupts without separating tools or manually mapping ToolNodes?

[Javen (Sakura4036)]

good questions!

[BryceGo33 (BryceGo33)]

same issue

[Izma Aziz (IzmaAziz)]

Hi, I'm facing a similar issue on deepagents==0.5.3.

Setup:

create_deep_agent with AsyncPostgresSaver on the main agent
SubAgent wrapped via the task tool (standard SubAgentMiddleware flow)
ToolNode contains both the task tool (which wraps SubAgents) + normal tools
interrupt_on is enabled for a side-effecting tool inside the SubAgent
Behavior:

SubAgent triggers interrupt correctly
After Command(resume), execution resumes
But the entire ToolNode re-runs
All tools inside the ToolNode execute again
This causes duplicate writes for side-effecting tools
This also happens when multiple SubAgents are called in parallel, an interrupt in one causes all SubAgents in the ToolNode to re-run on resume.

Expected:
Only the tool within the Sub Agent should resume, without re-executing other tools.

Root cause (looking at the code):
In deepagents/middleware/subagents.py, the task tool calls the subagent.ainvoke(subagent_state) without propagating config, and the subagent is built via create_agent() with no checkpointer. The SubAgent TypedDict also has no checkpointer/config field. So the subagent has no thread_id/checkpoint_ns and can't checkpoint its own steps resume can only replay the parent's task tool from scratch.

Has this been resolved? If not, what's the current recommended workaround for HITL on side-effecting SubAgent tools?

[sarfaraz-eng]

i am also facing same issue

[Yokubjon (yakubka)]

This is a known rough edge with LangGraph checkpointing and parallel tool execution.

When a ToolNode runs tools in parallel and one of them (the subagent) hits an interrupt, LangGraph saves a checkpoint at the ToolNode boundary, not at the individual tool level. On resume, the entire ToolNode is re-entered, which re-executes all tools including the ones that already completed.

The cleanest solution is to avoid running a subagent tool in parallel with other tools in the same ToolNode. You can do this in two ways:

1. Force sequential tool execution by setting ToolNode(parallel_tool_calls=False). This makes the node run tools one at a time, so if the subagent interrupts, only it is pending on resume.

2. Separate the subagent into its own node. Route the LLM output through a conditional edge: if the tool call is the subagent tool, go to a dedicated SubAgentNode; otherwise go to the normal ToolNode. This isolates the interrupt surface.

Option 1 is the quicker fix. Option 2 gives you more control over resumption logic and is better if you need fine-grained human-in-the-loop behavior alongside the subagent.

[Druhin Bala (theblueskies)]

I think the root cause Izma Aziz (@IzmaAziz) found is the right one, and it goes beyond subagents. LangGraph checkpoints at the ToolNode boundary, not after each individual tool call. So if you fan out N tool calls inside one ToolNode and one of them interrupts, resume has no way to tell which of the other N already finished. It feels less like a subagent bug and more like a missing unit of granularity. There's no record of "this particular call was admitted and we know what happened to it" below the node level.

Disabling parallel_tool_calls or putting subagents in their own nodes both work, but mostly because you're reducing the ToolNode to a single call. You're avoiding the granularity problem by removing the concurrency. That's a reasonable tradeoff if you don't need parallelism, but it doesn't really solve the underlying issue if you do want subagents and side-effecting tools running in parallel. Which is probably why this keeps coming back in different forms.

The approach that seems more robust to me is keeping a small admission record outside the checkpointer. Before dispatching a tool call, whether it's a subagent or something else, write a durable "intent" record keyed by tool_call_id. The call then marks it completed or failed when it returns. On resume, you check that record before replaying the ToolNode. If it's completed, don't invoke it again. If it's still in progress with no outcome, at least you know the call is ambiguous instead of silently running it twice.

That gets around the checkpoint granularity issue because the record isn't tied to where the interrupt happened inside Pregel.

Curious if anyone has tried something along those lines as a stopgap specifically for subagents. They seem like the hardest case since they don't have their own checkpointer, so there's no way to know whether the subagent had already partially advanced before the interrupt.

Also, did the config propagation gap Izma Aziz (@IzmaAziz) found ever get filed as a separate issue, or is it still just part of this thread?