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 and Infographic
A long-haul truck driver who never clears their GPS history starts getting routed by old toll patterns instead of today's road conditions. On the exam: long-lived coordinator agents need explicit context reset at run boundaries, with selective re-injection of relevant history from durable storage — not ever-growing accumulated context.
Full explanation below image
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 fix (option B) is a three-part pattern: archive historical context to a queryable store (preserving it for analysis and selective reuse), reset the working memory at each run boundary (preventing stale context from influencing current decisions), and inject only the relevant subset of historical context on demand (maintaining useful continuity without noise). This is the recommended lifecycle management approach for persistent coordinator agents.
Option A is incorrect because larger context windows do not fix the quality problem — they just allow more stale data to accumulate. The issue is not capacity; it's that old context is irrelevant to current decisions. More window space makes the problem worse, not better.
Option C is partially right in concept (clearing state at run boundaries) but 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.
Option D is incorrect because reducing frequency does not 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 ~30 weeks instead of ~30 days.