Saanora Projects: give Mark your context once, not in every chat
A project is a repository for context — a client, a codebase, a thesis, a subject. Attach the files and the brief once, and every chat inside starts already knowing them.
Here is a pattern anyone who uses an AI seriously will recognise. You start a chat about something. It goes well. You open a second chat on a related question, and the first thing you do is paste the same background in again. Then a third. Then a fourth.
By the fifth conversation you are spending the opening two minutes of every session re-establishing things you have already explained four times — which codebase this is, who the client is, what the constraints are, how you want it written.
Saanora Projects exist to end that, and they are the largest thing in this release.
A repository for context, not a folder
A project in Saanora is a named space holding related chats, the files they all draw on, and a standing brief that applies to every one of them.
The obvious comparison is a folder, and it is the wrong one. A folder tidies your sidebar; it does not make Mark any better informed. If you write software, the closer analogy is a repository — not for code, but for context. Each one is self-contained, carries its own working assumptions, and you switch between them without carrying the last one's baggage into the next.
One project per thing you work on
The rule of thumb is one project per ongoing thing. What that means in practice:
- A codebase — architecture notes, conventions, the files that explain the rest. Mark answers in your stack and your idioms instead of generic advice.
- A client — the brief, brand guidelines, past deliverables. Nothing from one client's project surfaces in another's chats.
- A product or a launch — the spec, the roadmap, the research you keep re-reading.
- A book, thesis, or long report — the outline, the sources, the draft so far.
- A subject you are studying — the syllabus and every lecture deck, with a chat per chapter.
- Your own admin — CV, contracts, the documents you rewrite four times a year.
Files belong to the project, not to one message
Attach the files to the project itself and every chat inside it can use them. Not “can go and look them up” — Mark already has them, from your first message.
The text is read once, at upload. So the twelfth chat in a project costs exactly what the first one did, and you never re-upload anything. A spec attached in September is still known in December, in a conversation you have not started yet.
This changes the answers, not just the filing. “How should I structure this?” asked into empty space gets you the average of the internet. The same question inside a project holding your architecture notes gets you an answer that fits the thing you are actually building.
A brief you write once
Alongside the files, a project carries instructions that apply to every chat inside it. Write them once instead of retyping them at the top of each conversation:
- “This is a Rust codebase. Idiomatic Rust only, no unsafe blocks, and prefer the standard library.”
- “Client work — formal tone, British English, and never invent a figure I haven't given you.”
- “House style: short paragraphs, no bullet lists, no exclamation marks.”
- “Third-year syllabus — worked examples before theory, and show every step.”
Context that doesn't leak between clients
Some work genuinely should not bleed into everything else — a client engagement under NDA, a health question, a job application you would rather your other chats knew nothing about.
A project can be set to keep its memory to itself. What Mark learns inside stays inside, and inside that project it will not draw on what it knows from the rest of your account. That is a real separation, not a label: two clients in two projects do not see each other.
The same shape, for a term of coursework
The shape is the same for coursework, and it happens to be the clearest example of the payoff, so it is worth spelling out.
One project per subject, the syllabus and lecture slides attached to it, a chat per chapter inside. Because Mark carries the syllabus, “quiz me on this chapter” produces questions in your course's scope and your lecturer's notation rather than the internet's general idea of the topic. By the time revision starts, the project already is your revision plan, in the order you put the chats in.
Two things we deliberately did differently
Two smaller decisions worth knowing about, because each only matters once — and each is the sort of thing competitors get wrong.
Chats inside a project can be dragged into whatever order you want: build order, chapter order, priority order. They stay put instead of jumping to the top every time you answer a question in one of them.
And deleting a project asks what you meant by that. Keep the chats — they simply become ordinary chats — or delete them too. Keeping is the default, because tidying your sidebar and destroying six months of work should never be the same gesture with the same button.
The test for a feature like this is not whether the sidebar looks organised. It is whether you stop typing the same paragraph over and over. Make a project, put one file in it, and see how the next chat opens.