A coordinator agent orchestrates a nightly batch pipeline and accumulates context across runs. After 30 days, the coordinator begins making decisions based on context from prior runs that is no longer relevant, causing incorrect task routing. What is the correct remediation?
Select an answer to reveal the explanation.
Short Explanation
You need to clear the coordinator's working memory at each run boundary and pull only relevant history from durable storage when needed. That keeps useful continuity without letting stale context drive routing. Think of it as resetting the route before every trip instead of letting old toll patterns steer you.
Full Explanation
Stale context accumulation is a classic long-running agent failure mode. A coordinator that appends context across dozens of runs eventually bases decisions on outdated information that contradicts the current state. The correct remediation is a three-part pattern: archive cross-run context to a queryable long-term store, reset the coordinator's working memory at the start of each run, and inject only relevant prior context on demand. This preserves historical data for analysis and selective reuse, prevents stale context from influencing current decisions, and maintains useful continuity without noise. It's the recommended lifecycle management approach for persistent coordinator agents.
The approach that increases the coordinator's context window size is incorrect because larger context windows do not fix the quality problem; they just allow more stale data to accumulate. The issue isn't capacity; it's that old context is irrelevant to current decisions. More window space makes the problem worse, not better.
The approach that switches to a stateless coordinator is partially right in concept because it clears state at run boundaries, but it goes too far by discarding all historical context. Some historical data is genuinely useful—recurring failure patterns, baseline metrics, learned routing preferences—and losing it completely degrades the coordinator's effectiveness. The answer is selective preservation, not total discard.
The approach that reduces the nightly batch frequency to weekly is incorrect because reducing frequency doesn't fix the underlying architecture problem. Running weekly instead of nightly still accumulates stale context across runs; it just does so more slowly. The same failure will manifest after about 30 weeks instead of about 30 days.