I used to think of tenant isolation as a database concern, something you enforce at the query layer and then stop worrying about. A lot of it turns out to live in the agent's own working memory, where a summarised history or a cached plan can carry one tenant's context straight into the next. Calling it contamination rather than a query bug feels like the right instinct. Glad someone is writing this down.
Thanks, Adam. I agree; the database filter is the easy part. The harder part is anything that lives between requests, like a summary or a cached plan made for one user and then reused for the next. In MemorySync, every call has to name the end user, and a search only looks at that user's memories. That helps, but it can't protect a summary your agent keeps in its own working memory. Have you seen this happen in a real system, or mostly in testing?
Adam Lewis
Product Engineer/Architect navigating the AI revolution
I used to think of tenant isolation as a database concern, something you enforce at the query layer and then stop worrying about. A lot of it turns out to live in the agent's own working memory, where a summarised history or a cached plan can carry one tenant's context straight into the next. Calling it contamination rather than a query bug feels like the right instinct. Glad someone is writing this down.