[Question] How should we build a durable agent with a long conversation and many tool calls per turn?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Documentation
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- python
- Domain
- backend, distributed-systems
Research direction
Start with the temporalio.contrib.openai_agents integration and the External Storage setting, especially payload_size_threshold, using the reported history and payload limits as the investigation context. Review the documented limits and workflow patterns, then define what guidance is needed for long conversations, many tool calls, external storage, and one-workflow-per-turn designs.
Written by the indexing model from the issue text.
Description
What we're building
A chat app on temporalio.contrib.openai_agents. One user turn can make up to about 100 tool calls before the agent writes its final answer, and conversations grow to 100k–200k tokens.
We send our requests to LLM providers that don't support OpenAI's conversation chaining, so we can't use previous_response_id or conversation_id. Parallel tool calling also isn't reliable across the models we use.
We couldn't find guidance for this setup, and we'd rather ask than guess, because when it breaks the server kills the whole workflow partway through a turn.
What we saw
Because every model call sends the whole conversation again plus all the tool calls and results so far, and each of those is recorded as an activity input, history grows fast. On temporalio 1.33.0 and openai-agents 0.19.4, model call inputs were 99.8% of the workflow history in every run we did.
History grows roughly like N*B + G*N*(N-1)/2, where N is the number of model calls, B is the size of the conversation, and G is how much each tool call adds.
| conversation | tool output | model calls reached | history | what happened |
|---|---|---|---|---|
| ~209k tok | 5 KB | 53 of 100 | 50.48 MB | TerminatedError: Workflow history size exceeds limit. |
| ~105k tok | 5 KB | 82 of 100 | 50.33 MB | killed |
| ~105k tok | 4 KB | 86 of 100 | 50.15 MB | killed |
| ~105k tok | 1 KB | 101 | 47.49 MB | finished |
| ~209k tok | 5 KB + external storage | 101 | 0.12 MB | finished (108 MB went to the blob store) |
The numbers lined up with what we put in — for a 800 KB conversation we measured 842.2 KB per call, and for 5 KB tool outputs we measured 5.08 KB of growth per call. Our math said the first run would run out of room at call 53, and the server killed it at call 53.
If we push the conversation bigger, what breaks first changes. Above roughly 450k tokens it stops being the 50 MB history limit and becomes the 2 MiB limit on a single payload. Around 522k tokens a single model call's input is too big to send at all, so the turn fails on the first call.
Questions
-
How big can the conversation be, and how many tool calls can one turn make? We worked out our own numbers by measuring, but we don't know if we're measuring the right thing, or if there's a way to avoid sending the conversation again on every call that we've missed. This might be the agent version of what temporalio/ai-cookbook#32 is asking for.
-
Is External Storage the answer here? Turning it on fixed our case completely — history went from 50.48 MB to 0.12 MB. Is it the recommended fix for agents, and is there advice on what to set
payload_size_thresholdto? It's still marked experimental, so we'd like to know if it's considered ready for this. -
Should each user turn be its own workflow? We moved to one workflow per turn, keeping the conversation in our own database and passing it in as workflow input, because we couldn't see how to stop history growing if one workflow handles every turn. Is that the pattern you'd recommend, or have we misread it?
- Dominant language
- Python
- Stars
- 1.2k
- Forks
- 241
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 49
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from temporalio/sdk-python
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
temporalio/sdk-python#1517 · 10 comments ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
temporalio/sdk-python#496 ·
-
[Bug] Local activity resolutions regrouped on replay since 1.32.0, delivering the wrong payload Open
Difficulty 4/5 3-5 days Newbie friendliness 52/100
temporalio/sdk-python#1881 · 1 comment ·
-
bug
temporalio/sdk-python#1817 · 1 comment · 1 assignee ·
-
temporalio/sdk-python#1704 · 1 assignee ·
All issues in temporalio/sdk-python
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
syfoud/Simulated_Scepter#172 ·
-
A cancelled tests run makes the coverage comment workflow fail and reports it as a red check on main Openarea: ci bug perceived difficulty: 3
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Nitjsefnie-Harness-Commons/daedalus#921 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
EleutherAI/lm-evaluation-harness#4207 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ClickHouse/clickhouse-connect#1057 ·