A housing case bot must keep working memory lean across eligibility turns. Which selection practice fits?
Select an answer to reveal the explanation.
Short Explanation
You don't need prior case notes, income PDFs, or waitlist summaries taking up working memory. Keep the active case ID and last eligibility hit, then move on.
Full Explanation
Keeping only the active case ID and last eligibility result in working memory is the correct selection practice for housing case bots because clarification turns need lean, high-signal state. Retaining prior case notes in working memory for extra eligibility context raises token cost, injects outdated notes, and increases the chance Claude fixates on irrelevant past correspondence. Minimal working memory—identity of the open matter plus the latest eligibility outcome—supports coherent follow-ups while leaving detailed archives for on-demand retrieval tools.
Retaining prior case notes in working memory for extra eligibility context fails because volume creates noise, cost, and contradictory older statuses that muddy the current eligibility conversation. Caching current applicant income PDFs inside working memory during eligibility checks fails because bulky document payloads bloat lean state and should be fetched on demand rather than carried turn to turn. Holding the waitlist position summary in working memory while checking eligibility fails because it keeps unrelated case data in active state, adding distraction and privacy exposure without helping the resident at hand.
Exam caveat: “last eligibility result” must be versioned with timestamp and rule-set ID so a later policy change is not misread as the still-current determination. Operational check: walk a multi-turn eligibility clarification in staging with lean memory enabled, confirm the bot retains the correct case ID and latest result, and verify tool retrieval is used when an older note, income PDF, or waitlist summary is explicitly needed rather than caching those items in working memory.