Separate rooms for client work

A useful assistant remembers. That is also the failure mode. The note you pasted for one client is still in the thread when you ask about the next one, and the model has no idea those were different obligations.

Most teams respond by being careful. They open a new chat, they delete the file, they tell the assistant to forget. Carefulness is not a boundary. It slips on a Friday, and it slips when a teammate who was not in the original conversation picks up the same login.

Acumane starts from the other end. The thing you are selling — the questions, the tone, the checklist — is an agent. It belongs to your organization, and you publish it when you mean to. The thing you are entrusted with — files, memory, the people from that client — is a space. A space has an organization and nothing else gets to query it.

That split changes the improvement loop. If the method and the files are the same object, improving the method means touching client data, or cloning the whole object and letting the clones drift. If they are separate, you edit a draft, you publish a version, and every linked space receives the version. Their files stay put. A space that must not move during a live engagement can pin a version; that pin is part of the data model even though the button is not in this release.

Roles follow the same cut. Editors and admins on your side maintain the agent. A client joins a space as a viewer. They can use what you published. They cannot rewrite it, and they cannot see the space next door.

None of this requires pretending the model is wise. It requires the application to refuse a query that names the wrong organization. The tenant helper in this codebase does that for the tables that carry an organization id. Database row policies are a later belt. The application check is the one that exists today.

If you are still pasting last month's board pack into a chat you also use for someone else, the fix is not a longer system prompt. It is a second room.