A multi-agent pipeline has an orchestrator Claude instance that dispatches sub-tasks to three specialized worker agents (data-retrieval, analysis, formatting). The orchestrator passes task context to each worker via tool_result content blocks. During a load test, the formatting agent begins receiving stale data from a prior run because the orchestrator is reusing a conversation thread across multiple pipeline executions. What is the root cause and correct fix?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because the Claude API is stateless — the messages array the client sends is the entire conversation history. If an orchestrator reuses the same messages array and appends to it across multiple pipeline runs, the prior run's tool_result blocks remain in the context window, contaminating the next run's input to workers.
Full explanation below image
Full Explanation
B is correct because the Claude API is stateless — the messages array the client sends is the entire conversation history. If an orchestrator reuses the same messages array and appends to it across multiple pipeline runs, the prior run's tool_result blocks remain in the context window, contaminating the next run's input to workers. The fix is to start a fresh messages array for each pipeline execution. C is wrong because max_tokens controls output length, not conversation state; setting it to zero would not flush context and would also prevent any output. A is wrong because cache_control breakpoints manage prompt caching costs, not data freshness; they do not invalidate or clear tool_result content. B is wrong because system prompts are also sent on every API call and do not represent a different statefulness model; using them for task context does not solve the problem of accumulated messages.