SequentialAgent re-executes all sub-agents after LongRunningFunctionTool resume - expected behavior?

[zsais]

Hi ADK team! 👋

I'm building a multi-phase workflow with human-in-loop (HIL) approval points. I've run into an issue with SequentialAgent and LongRunningFunctionTool that I'd like to understand better.

Architecture

• Root agent: SequentialAgent orchestrating 9 sub-agents (all LlmAgent)
• HIL tools: LongRunningFunctionTool used by sub-agents 1 (clarification) and 5 (approval)
• Session management: App with ResumabilityConfig(is_resumable=True)
• Testing with: adk web

Expected Behavior

1. Execute sub-agents 1-5 sequentially
2. Sub-agent 5 calls LongRunningFunctionTool for approval → workflow pauses ✅
3. User approves → workflow resumes at sub-agent 6 ✅
4. Execute remaining sub-agents 6-9

Actual Behavior

1. Execute sub-agents 1-5 sequentially
2. Sub-agent 5 calls LongRunningFunctionTool for approval → workflow pauses ✅
3. User approves → workflow resumes at sub-agent 1 ❌
4. Sub-agents 1-5 re-execute (duplicate work, wasted tokens)
5. Eventually continues to sub-agents 6-9

Current Workaround
I implemented a custom BaseAgent orchestrator that checks session.state completion keys before calling each sub-agent:

    COMPLETION_KEYS: ClassVar[dict] = {
        "agent_1": "phase_1_complete",
        "agent_2": "phase_2_complete",
        # ...
    }
    async def _run_async_impl(self, ctx):
        for sub_agent in self._sub_agents:
            completion_key = self.COMPLETION_KEYS.get(sub_agent.name)
                        # Skip if already complete
                        if completion_key and completion_key in ctx.session.state:
                          continue                        
                        # Run the sub-agent
                        async for event in sub_agent.run_async(ctx):
                        yield event

This works perfectly—phases don't re-execute after HIL resume. ✅

Questions

1. Is SequentialAgent re-executing all sub-agents after HIL resume expected behavior?
2. Is there a built-in pattern for "checkpoint-based" execution in SequentialAgent?
3. Should I continue using the custom BaseAgent orchestrator, or is there a more idiomatic ADK pattern?

I've reviewed the docs and examples but couldn't find guidance on this specific use case. Any insights would be greatly appreciated!

Environment:

• google-adk version: 1.17.0
• Python: 3.12
• Testing: adk web local UI

Thanks for building such a powerful framework! 🙏

[zsais]

@adk-bot

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: The behavior you're observing is not expected. SequentialAgent is designed to resume execution from where it left off, not restart from the beginning. Your custom agent is a clever workaround, but it shouldn't be necessary.

---

Hi there! Thanks for the detailed question and for using ADK. That's some excellent debugging and a very clean workaround you've implemented.

Here are the answers to your questions based on the intended design of ADK:

1. Is this expected behavior?
   No, it is not. SequentialAgent is designed to handle resumability gracefully. When an agent run is paused (e.g., by a LongRunningFunctionTool) and then resumed, it should continue from the next sub-agent in the sequence, not restart the entire process. [1]

2. Is there a built-in pattern for "checkpoint-based" execution?
   Yes, the built-in pattern is the automatic state management within SequentialAgent itself. Before executing each sub-agent, the SequentialAgent saves the name of that sub-agent into its own state. [2] Upon resuming, it reads this state to determine which sub-agent was last running and continues from the next one. You should not need to build a manual checkpoint system.

3. Should I continue using the custom BaseAgent orchestrator?
   Your custom agent is a great example of leveraging ADK's state management primitives (session.state) to build robust workflows. It correctly solves the problem you're facing. However, the more idiomatic ADK pattern is to rely on the built-in resumability of SequentialAgent.

The fact that it's not working as expected in your case could point to a subtle bug or an edge case in the framework's state handling. Your workaround is perfectly valid, but ideally, the underlying SequentialAgent should manage this for you.

It seems you've uncovered behavior that deviates from the documented design. Thanks for bringing this to our attention!

References

[1] ADK Docs: Resuming Agent Invocations
[2] SequentialAgent Source Code