Support running ADK agents outside Temporal workflows#1400
Support running ADK agents outside Temporal workflows#1400tconley1428 wants to merge 5 commits intomainfrom
Conversation
Add fallback paths in TemporalModel, activity_tool, and TemporalMcpToolSet that detect when code is running outside a workflow (via in_workflow()) and execute directly instead of scheduling activities. This enables local ADK development without a Temporal worker. Includes tests for all three paths plus the error case when no local MCP toolset is provided. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
| agent = Agent( | ||
| name="test_agent", | ||
| model=TemporalModel("mcp_model"), | ||
| tools=[TemporalMcpToolSet("test_set_local", local_toolset=local_toolset)], |
There was a problem hiding this comment.
If the point is to show code that works in both places,
test_mcp_agent_both_inside_and_outside_workflowwould be a better framing to put pressure on us to show a unified solution. Or if you want them in separate tests, write a comment showing the intent behind the test.- share a function as I mentioned above.
- presumably the lambda should be declared as well in that case?
I'm also curious what prevents you from unifying them a bit further. If it's doable, but there's just an implementation cost, we can make a tradeoff.
There was a problem hiding this comment.
They can't be unified because the provider given to the worker simply doesn't exist if you are running the agent directly without Temporal or the worker existing. So there's no place to acquire the toolset from if it isn't provided here.
There was a problem hiding this comment.
Is the fact that it's a lambda the only real difference between the two?
This looks like a complete dup of the local toolset. Can you wrap it in a function and share b/w two callsites?
My goal is for these tests to show users what they would do in their production code.
There was a problem hiding this comment.
The "local toolset" is teaching the user something they don't need to know and could be confusing. Local to what?
A further evolution of the above idea: could the lambda be referring to a TemporalMcpToolset ? If I'm not mistaken, there would just be one declaration of TemporalMcpToolset that can be shared in two callsites, and you can dispense with the error checking and the "local toolset" framing.
There was a problem hiding this comment.
The parameter still needs to exist and have a name. I don't follow how you are suggesting to remove the error checking.
|
|
||
|
|
||
| @pytest.mark.asyncio | ||
| async def test_agent_outside_workflow(): |
There was a problem hiding this comment.
Can you update the README to have a bullet highlighting that Temporal modes can be run without workflows for testing w/ adk web, and then maybe a section on how to do it if it needs special instructions?
3 participants
Summary
in_workflow()fallback paths inTemporalModel,activity_tool, andTemporalMcpToolSetso ADK agents can run directly outside a Temporal workflow (e.g., local dev withadk run)TemporalMcpToolSetaccepts a newlocal_toolsetparameter for direct MCP tool access outside workflowsMcpModeltest helper to extendTestModelfor reusability across testsTest plan
test_agent_outside_workflow— validates TemporalModel + activity_tool fallbacktest_mcp_agent_outside_workflow— validates TemporalMcpToolSet with local_toolset delegationtest_mcp_toolset_outside_workflow_no_local_toolset— validates ValueError when no local_toolset provided🤖 Generated with Claude Code