Which memory do you delete when a project ends: the chat, the saved routine, or the logged-in browser profile?

Delete the logged-in browser profile first, then the saved routine, then the chat. The profile can still act as you after the project is “over,” because the cookies do not know the project ended. The routine will run the next time a schedule or a phrase fires, and it may still point at tools. The chat is a record. It can hold secrets you should not keep, and it does not click by itself. If you only have ten minutes, spend them on the profile. A transcript you meant to archive is not the thing that will send mail on Thursday.

Ending a project is an access change. Treat it like unplugging, not like filing.

The profile that outlived the client

A short contract used an agent browser signed into the client’s staging site and, because it was convenient, into my mail. The contract ended on a Friday. I renamed the project folder and left the profile, thinking I might need the staging cookies if they asked a follow-up. On Monday a different task, in a different chat, reused “the agent browser” because that was the profile the tool defaulted to. It opened a tab already logged into the old staging admin. Nothing catastrophic left the building. The session was simply still alive for a client I was no longer working for. That is enough. Their admin panel is not a souvenir.

I deleted the profile that afternoon and signed the staging account out of all sessions from their security page, not only from my machine. Deleting a local profile does not revoke a server session if the product keeps one. Do both. The folder on disk is the agent’s habit. The account’s device list is the actual login.

Why the routine is next, not last

A saved routine is a compressed intention: when this happens, do that, with these tools. It does not expire when you stop caring. A weekly “check the project inbox and draft a status” will draft, or send, on a project that has no status. I have found these in cron lists and in agent “skills” folders with the client’s name still in the file. The chat that created them was months stale. The routine was fresh every Monday.

Delete or disable it before you tidy prose. If the routine holds a token or a path to the browser profile, removing the profile first means Monday’s run fails instead of acting. That is the order on purpose. A failing routine you then delete is safer than a working routine you forget because you were reading old chats. After the profile is gone, remove the routine so the failure does not page you, and so a recreated profile with the same path does not revive it.

Read the routine once while you delete it. You are looking for other accounts it names, not for literary quality. If it mentions a key, revoke that key. Deleting the text does not revoke a key that is still in the provider. The file is a map. The map is not the lock.

The chat is real memory and a bad first delete

Chats contain the decisions, the pasted tickets, and sometimes a secret someone dropped into the thread. Delete them when the project ends if they hold customer data or credentials, and do not keep a copy “for the portfolio” if that copy has the data. Exporting the chat to a notes app is how the secret gets a second home. If you need the decisions, rewrite them in a short file with the secrets left out, then delete the thread.

Do this after the profile and the routine. People start with the chat because it is the visible history and because the delete button is in the app they have open. The app is not where the session lives. I have deleted a thread and felt done while the browser profile still had the client’s cookies and a skill file still had the schedule. The feeling is the bug. The chat is the part that looks like memory. The profile is the part that is power.

If the product stores memory separately from the transcript — a “remember this” store, a vector index, a summary the agent reloads — that store is a routine wearing the chat’s name. Clear it with the routine, not with a vague hope that deleting the thread clears it. I ask the product what it will still know about the client after the thread is gone, and if I cannot get a straight answer, I assume it remembers and I avoid reusing that agent identity for the next client.

What I keep on purpose

A branch or a folder of the work product, without secrets, if the contract says I may. A logged-out note of how the deploy worked, written by me. Not the agent’s browser. Not the OAuth app. Not the weekly skill. Not the raw chat if it has their data. The work product is not the memory that can log in. Mixing them is how a zip file of “the project” includes a profile directory and a token. I do not zip the home folder. I copy the files I can show a stranger.

Shared team agents need a named owner to do this. Otherwise everyone assumes someone else will clean up, and the profile sits on the server. The day the project ends, one person deletes the profile, revokes the app, and disables the schedule, and says so in the team channel in one line. That line is not the cleanup. It is the record that the cleanup happened. If nobody can say it, the project has not ended. It has gone quiet.

A reopen is a new grant

If they come back in a month, you do not restore the profile from a backup. You make a new empty one and you sign in only if the new work needs it. A backup of a logged-in profile is the old project still running. I do not keep that backup. The inconvenience of signing in again is the point. It makes the new scope visible. Restoring “so we can move faster” restores every cookie you meant to end.

Same for the routine. Rewrite it from the new request. The old file knows the old inbox and the old definition of done. Speed from reuse is how Monday’s draft talks about a project that closed. I would rather spend twenty minutes writing five lines than explain a message the corpse of a routine sent.

Mail drafts and tokens in the repo

The profile is not the only place a session hides. A project folder often has an env file the agent used, a copied cookie, or a draft that still quotes a private thread. Deleting the browser profile and leaving the env file means the next agent in that folder has the token. I revoke the token in the provider and then delete the file. Order matters: if you delete the file first and the token stays valid, you have only lost your copy of a secret that still works. Revoke, then delete, then search the folder for the key’s name. I do not use the agent to do that search. I use a plain search on disk, because the agent is what I am retiring.

Drafts of emails from the project are not the chat, and they are not harmless if they contain the other person’s private words. Delete them with the chat once you have sent what you meant to send, or once you have decided not to. A folder called outbox-drafts that survives the project will be the folder a later routine finds. I empty it as part of ending, not as part of a rainy-day tidy. If a draft is the work product the client paid for, it belongs in their hands, not in the agent’s directory.

Shared drives are the version of this that outlasts your laptop. A profile synced through the vendor, a routine saved to an account rather than a file, a chat history on their servers. Local delete is not enough. Use the account’s delete and revoke, and assume a synced copy exists until the security page shows the app gone and the sessions list empty. I check that page the next morning. Friday’s feeling of done is not Saturday’s session list.

The order when the project ends

Logged-in browser profile, and the server-side sessions behind it. Then the saved routine, the skill, the cron, and any key the routine names. Then the chat and any hidden memory that would reload the client’s facts, after you have lifted out the non-secret decisions you still need. The chat feels like the memory. The profile is the one that can still do the job you are no longer supposed to do. Leave it, and the project is only quiet, not finished. Quiet still has cookies, and cookies do not care that the contract ended.