A court clerk agent persists sealed-case snippets in memory that later appears in unrelated public-counter sessions. What should be corrected?
Select an answer to reveal the explanation.
Short Explanation
Sealed case notes bleeding into the next resident’s chat is a courtroom confidentiality fail. Isolate agent memory per session so yesterday’s sealed snippet never rides into today’s public counter. Shared sticky memory is not a feature here — it is a leak.
Full Explanation
A court clerk agent that persists sealed-case snippets in memory that later appears in unrelated public-counter sessions demonstrates cross-session leakage of protected judicial information. The correction is enforcing strict session and memory isolation between agent conversations so sealed material cannot bleed into another resident’s interaction. For civic court operations, isolation preserves confidentiality obligations around sealed records and prevents accidental disclosure at the public counter.
Broadcasting sealed snippets to all courtroom digital displays fails by concept: it maximizes disclosure rather than isolating memory. Training the model to invent sealed case facts when memory is empty substitutes hallucination for confidentiality and can still produce false but sensitive-sounding disclosures. Storing sealed material in browser cookies shared across clerk workstations moves sealed content into shared client storage with weak isolation and workstation cross-contamination risk.
Exam caveat: session isolation addresses conversational memory boundaries; sealed data still requires access control, encryption at rest, and retention rules in any backing store the agent uses. Operational check: run two sequential clerk sessions in staging—one with sealed snippets, one as a public-counter matter—and verify no sealed content, embeddings, or summaries appear in the second session’s context, logs, or memory retrieval results.