We're building a system where a stateless HTTP API (following the AG-UI protocol pattern — no workflow ID held in memory between requests) needs to drive a TemporalAgent-backed agent with requires_approval=True tools. The approval decision typically arrives on a separate HTTP request, possibly hitting a different server instance, minutes or hours after the original request that triggered it.
Today, as far as we can tell, making this work correctly requires the application to manually:
Derive and track a deterministic workflow ID (e.g. from a conversation/thread ID),
Use signal-with-start to ensure the same workflow is reused rather than a new execution started per turn,
Build a custom bridge (e.g. via Workflow Streams) to expose the paused/pending-approval state and subsequent events to the stateless HTTP layer,
Translate the approval payload into a signal targeting that specific workflow.
This is a lot of boilerplate for what seems like a common pattern for anyone building a durable, human-approved agent behind a stateless web API (chat UIs, AG-UI-style frontends, webhook-driven approval flows, etc.).
Requested feature
Some combination of the following, at either the Temporal SDK or PydanticAI durable_exec.temporal integration level:
A documented, supported pattern (or helper API) for resuming a TemporalAgent run's pending tool approval from a stateless caller that only has a conversation/thread identifier — without the caller needing to independently implement workflow ID derivation, signal-with-start, and event-stream bridging from scratch.
A built-in "pending approval" query/handle exposed by TemporalAgent itself (e.g. temporal_agent.get_pending_approvals(workflow_id) or similar) so callers don't need to hand-roll a query/signal pair for this specific, common case.
Guidance or a reference implementation showing Workflow Streams used specifically for bridging a TemporalAgent's approval-interrupt events to an external stateless HTTP/SSE layer — since this seems like the natural mechanism, but there's no example combining it with requires_approval specifically.
Optionally, a higher-level "resumable approval token" returned alongside the interrupt event, encoding what's needed to signal the correct workflow — so a frontend/API doesn't need out-of-band knowledge of the workflow ID scheme at all.
Why this matters
Human-in-the-loop tool approval is called out as a first-class use case for both Temporal (signal handling, perfect for human-in-the-loop workflows) and PydanticAI's requires_approval mechanism — but the specific combination of "approval arrives via a stateless HTTP request, possibly on a different node" isn't covered by existing examples (pydantic-ai-temporal-example, AG-UI Dojo), both of which assume either a single long-lived process (Slack bot) or an in-process agent (AG-UI examples without Temporal). Closing that gap would make this pattern usable out of the box rather than requiring each team to independently reinvent the workflow-ID-plus-signal bridge.
We're building a system where a stateless HTTP API (following the AG-UI protocol pattern — no workflow ID held in memory between requests) needs to drive a TemporalAgent-backed agent with requires_approval=True tools. The approval decision typically arrives on a separate HTTP request, possibly hitting a different server instance, minutes or hours after the original request that triggered it.
Today, as far as we can tell, making this work correctly requires the application to manually:
Derive and track a deterministic workflow ID (e.g. from a conversation/thread ID),
Use signal-with-start to ensure the same workflow is reused rather than a new execution started per turn,
Build a custom bridge (e.g. via Workflow Streams) to expose the paused/pending-approval state and subsequent events to the stateless HTTP layer,
Translate the approval payload into a signal targeting that specific workflow.
This is a lot of boilerplate for what seems like a common pattern for anyone building a durable, human-approved agent behind a stateless web API (chat UIs, AG-UI-style frontends, webhook-driven approval flows, etc.).
Requested feature
Some combination of the following, at either the Temporal SDK or PydanticAI durable_exec.temporal integration level:
A documented, supported pattern (or helper API) for resuming a TemporalAgent run's pending tool approval from a stateless caller that only has a conversation/thread identifier — without the caller needing to independently implement workflow ID derivation, signal-with-start, and event-stream bridging from scratch.
A built-in "pending approval" query/handle exposed by TemporalAgent itself (e.g. temporal_agent.get_pending_approvals(workflow_id) or similar) so callers don't need to hand-roll a query/signal pair for this specific, common case.
Guidance or a reference implementation showing Workflow Streams used specifically for bridging a TemporalAgent's approval-interrupt events to an external stateless HTTP/SSE layer — since this seems like the natural mechanism, but there's no example combining it with requires_approval specifically.
Optionally, a higher-level "resumable approval token" returned alongside the interrupt event, encoding what's needed to signal the correct workflow — so a frontend/API doesn't need out-of-band knowledge of the workflow ID scheme at all.
Why this matters
Human-in-the-loop tool approval is called out as a first-class use case for both Temporal (signal handling, perfect for human-in-the-loop workflows) and PydanticAI's requires_approval mechanism — but the specific combination of "approval arrives via a stateless HTTP request, possibly on a different node" isn't covered by existing examples (pydantic-ai-temporal-example, AG-UI Dojo), both of which assume either a single long-lived process (Slack bot) or an in-process agent (AG-UI examples without Temporal). Closing that gap would make this pattern usable out of the box rather than requiring each team to independently reinvent the workflow-ID-plus-signal bridge.