Add ToolRegistry + AgenticSession proposal#107
Add ToolRegistry + AgenticSession proposal#107lex00 wants to merge 8 commits intotemporalio:masterfrom
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
|
fromMcpTools / from_mcp_tools / FromMCPTools added to Go, Java, Ruby, and .NET. All six SDKs now have MCP tool descriptor support. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…entation notes - Add "Relationship to framework integrations" section with comparison table distinguishing ToolRegistry (all 6 SDKs, local heartbeat state) from Python/TypeScript framework plugins (openai_agents, google_adk_agents, langgraph, ai-sdk) that run each model call as a separate activity - Update Overview to highlight that AgenticSession survives server-side session expiry, not just activity crashes, since state is stored locally - Add conversation compaction and framework plugins to Scope/non-goals - Resolve versioning open question (v0 for initial release) - Add Implementation notes section documenting is_error semantics and the Python error propagation bug that was fixed in the PRs Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…e system param - Add Use cases section: code analysis, long-running research, HITL, MCP, provider migration - Add Known limitations subsection (no compaction, async handler note) - Rename session.issues/s.Issues/session.getIssues() → results across all 6 SDK examples - Remove dead system parameter from Go/Java/.NET/Ruby RunToolLoop examples - Update testing section mock examples to match Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ults) All 6 SDK API-reference code blocks used `issues` as the local collector variable in the simple-loop handler. Rename to `results` for consistency with the SDK READMEs, which were updated in round 2. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…stion 1, fix known limitations async note - Python and TypeScript API-reference simple-loop blocks lacked `results` declarations and return statements, causing NameError/ReferenceError for readers who copy the snippet - Known Limitations async handler bullet incorrectly framed Python/TypeScript async support as a limitation; reworded to put the limitation on Go/Java/ Ruby/.NET (synchronous handlers) and the capability on Python/TypeScript - Open Question 1 (package naming) resolved: each SDK follows its existing convention, no deviation needed Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add explanation of the rejection reason being returned to the LLM (enabling revised proposals), and the deterministic-workflow-ID crash safety property. Reference the Python SDK README for the full working example. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Hi @lex00, thanks for submitting this proposal and concept around a tool registry and Temporal-provided tool loop! We have some planning to do on our side with regards to agentic loop support, and we'd be happy to get back to you in the near future (next week-ish) about this! One question I would have at the moment: out of curiosity, why did go for the activity + heartbeating route, as opposed to running the agentic loop in the workflow (and LLM calls and some tools in small activities)? |
|
The existing Zero workflow code required The primary driver was adoption. A user with an existing workflow calling a Session continuity for long-running use cases The framework plugins rely on provider-side session IDs. For human-in-the-loop scenarios where a tool handler signals a workflow and waits hours for approval, those sessions expire. Storing conversation state in the heartbeat rather than a provider session means the conversation survives both crashes and provider-side expiry. A rejection comes back to the model as a tool result, so it can revise its next proposal rather than restart from scratch. Heartbeat timing The checkpoint is written before each LLM turn, not after. Conversation history is the source of truth; re-issuing a turn on retry is safe because the model produces the same (or equivalent) response given the same history. The tradeoff Individual tool calls are not visible in Temporal's event history. The conversation is a black box from the workflow's perspective. The workflow-native approach gives per-call visibility and per-call retry policies, which are real advantages. For the use cases in scope (direct API usage, fast tools, sessions of moderate length), turn-level checkpointing covers the durability need without that granularity. |
3 participants
Design document for
ToolRegistryandAgenticSession— cross-SDK LLM tool-calling primitives shipping as contrib modules in all six Temporal SDKs.ToolRegistry maps tool names to JSON Schema definitions and dispatches LLM tool calls. AgenticSession wraps a tool loop with crash-safe heartbeating so activity retries resume mid-conversation rather than restart.
PRs are open: