Answers
I don't want AI tools remembering me. I keep context per project. Isn't that enough?
Keeping context per project is the right instinct, and it is the one this is built on — what gets remembered here is the project, never the person. The gap is not in the scope you chose, it is in what holds it. Per-project context that lives in a file you edit works while you are the only one reading it and the only one writing it; it starts costing the moment a second person, a second machine or a second assistant touches the same project, because nothing in the file says which version is in force or who decided. So this is not a personal-profile product with a project setting. The unit is the project's decision, a person sanctions it, and whoever opens that project next reads it — another teammate, another tool, or you in three weeks.
Last updated September 18, 2026
Per project is the scope; it is not the answer to what holds it
There are two separate decisions hiding inside "I keep context per project". The first is scope, and it is already right: what an assistant should know about this work does not belong to you, it belongs to the work. The second is what holds that scope, and a file you maintain is one answer among several. It is a good answer for what the project IS — the conventions, the structure, the things a reader could verify by looking. It is a weaker answer for what someone DECIDED, because a decision has an author, a moment and an end, and a line of prose carries none of the three.
The profile-shaped product is a different product, and this is not it
The objection is usually aimed at something specific and worth rejecting: an assistant accumulating a picture of you — how you write, what you asked last month, preferences inferred from chat — and carrying it into unrelated work. That design has real costs and being sceptical of it is reasonable. What is stored here is not that. It is what the project holds: a rule someone set, a decision with the name of the person who made it on it, a fact with a date and a condition that ends it. If you left the team tomorrow, everything in the project would still make sense and still apply, because none of it was about you.
One person is the case, not the reduced case
It is fair to ask whether any of this matters when it is only you. It does, and the reason is that the second reader is rarely a second person — it is the same work reaching a different session, a different machine, or a different assistant. You settle something on Monday inside one tool, and on Thursday another one has no way of knowing it happened. That is the same failure as two colleagues contradicting each other, minus the colleague, which is why a single-person project is treated here as the ordinary case rather than as a smaller version of a team one.
What it looks like in practice
A developer keeps a context file per repository and is happy with it. It describes the stack, the folder layout and the test command, and every assistant that opens the project reads it. Then a decision gets made in a conversation: this service will not take a dependency on the internal queue, because of a failure two quarters ago. It is a real constraint, it applies to every future change, and it is not a property of the code — nothing in the repository shows it, because it is about what is deliberately absent. It goes into the context file, as one line among sixty. Three months later an assistant proposes exactly that dependency, and the reason is easy to reconstruct: the line was still there, still true, and indistinguishable from the fifty-nine lines around it that describe the shape of the project. Nothing marked it as a decision, nobody's name was on it, and nothing said what would end it. The scope was right. The line just had no standing.
Questions people ask about this
- So does it store anything about me at all?
- It stores who sanctioned what, because a decision without an author is not auditable — you would have no way to tell a rule the team agreed to from a sentence an assistant wrote confidently. That is a name on a decision, not a profile: nothing is inferred about you from how you work, nothing follows you into another project, and nothing is used to shape how an assistant talks to you. The record answers what is in force here and who put it there, and it stops there.
- I'm the only person on this project. Who is the memory for?
- For every assistant that opens it, including the next session of the one you are talking to right now. That is the reader this is built for: it has no memory of Monday, no way to ask you what you meant, and no access to the conversation where the thing was settled. Writing the decision where it is read at the start of the work is how the next session starts from where you ended instead of from the repository.
- Isn't my context file already doing this?
- For part of it, yes, and that part should stay there. The split worth making is between what the project IS and what someone DECIDED about it. The first is verifiable by reading the code and belongs next to the code; the second has an author, a date and an end, and those three are exactly what a file cannot carry. Once the decisions move to something that carries them, the file usually gets shorter and stops being the thing nobody wants to reread.
Where this is verifiable
Product documentation on this site (How it works, Install), the answers comparing versioned context files with curated memory and on tracking AI facts without a spreadsheet, and the project-scope, sanction and expiry rules in the sanctioned product spec. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/ai-remembering-you-isnt-the-point-the-project-is