Two projects, back to back.One context at a time
The 10:00 call is about the checkout revamp, the 11:00 one is about the billing migration, and the assistant you use for both remembers whichever one you explained to it last. Khint keeps a separate work session per project and hands your agents the live one, so the switch costs a click instead of a re-briefing.
The work is not what tires you.
The switch is
Two products in the same week is not twice the work, it is the work plus the cost of changing lanes eight times a day. Every time you open a chat window you re-explain which product this is, who the stakeholders are, and what was decided last Thursday. Half the time you forget a piece, and the answer comes back subtly wrong: the right format, the wrong project. The other half you paste in so much background that the actual question is buried under it. The failure mode is not a bad model, it is a context that belongs to nobody in particular.
One bucket for everything
Yesterday’s migration decisions bleed into today’s checkout answer.
You re-paste the same background at the top of every request.
Nobody can tell afterwards which project a note came from.
One session per project
The live project is the only one your agents are given.
The background is already there, so the request is just the request.
Each project keeps its own record, readable months later.
What “live” means
Several projects on the go, exactly one handed over.
From Checkout revamp only
Objective
Ship guest checkout for the December release.
Open threads
Waiting on the payment provider for the refund window.
Decisions
Guest orders stay guest, no forced account after the fact.
An illustration of the shape, not a promise about wording: the summary is rebuilt from your own entries as the project moves.
Setting it up
Once per project, then the switch is a click in the palette.
One session per project, not one per day
In Memory, create a session named after the thing that has a lifespan: the checkout revamp, the billing migration, the audit. It stays open for weeks, across as many meetings as the project takes. A session per day would split one project into twenty fragments, and a single session for everything is the mixing problem you started with.
Give each one an objective in its own words
Each session has an objective field at the top of its page. Write the one sentence you would say to a new joiner, something like “ship guest checkout for the December release, blocked on the payment provider”. That sentence is fed into every rebuild of the session’s summary, which is what keeps a long-running project from drifting into a list of unrelated notes.
Switch from the palette, not from the app
The palette header carries a chip with the name of the live session. Click it and you get the list: set another project active, start a new session with a name already suggested, or deactivate. It is the same keystroke you already press to run an action, so the switch happens where the work happens instead of pulling you into a window.
Let the project collect its own material
Everything you do while a session is live lands in it: the actions you run, the text you pull off the screen with Capture, the notes you type, the documents you drop into the entries list, the tickets and pages you push through your connected tools. You are not maintaining a project log, you are just working with the right session live.
Check what the active project actually looks like
The session page has a tab that shows what your agents are given: the objective, the open threads, the artifacts, the decisions. Read it once a week on a long project. If the summary has drifted, the fix is to adjust the objective or add a note, and the next rebuild takes it into account.
Deactivate for the work that belongs to neither
The expenses mail, the job description, the personal note: none of it should reach a project’s record, and none of it should be coloured by one. Deactivating from the chip leaves no session live, so actions run on the selected text alone, exactly as they do before you have ever started a session.
A Tuesday on two products
At 09:55 you set Checkout revamp live from the palette chip. The call runs, you type two notes as it goes, and you grab the error the developer flashes on the shared screen with a capture. At 10:45 you run your action-items agent on the notes: it already knows the refund window is the open thread, so the follow-up it writes points at the right person. At 10:58 you click the chip and set Billing migration live. Same shortcut, same agents, different project, and nothing from the previous hour comes with you. At 16:00 someone asks where the checkout work stands: you set that session live again, open its recap, and read back a week of your own record instead of reconstructing it from your calendar. The single-project version of this loop is covered in work session context, and the day-logs-itself side of it in the automatic work journal.
What it will not do for you
Worth knowing before you put three projects through it.
Nothing merges two projects for you
There is no cross-session question, no answer assembled from two records at once. When a steering meeting covers both projects, the honest move is to copy one session's recap, paste it as the input, and run your summary action with the other one live. The bridge is manual on purpose: you decide what crosses.
The working state is a summary, not an archive
What your agents see is a compacted picture that is rewritten as the session grows, so old detail gets folded away or dropped as the project moves on. The full entries stay readable on the session page, and search covers them, but do not treat the injected context as a transcript of everything that was ever said.
The active pack is a separate switch
Which project is live and which set of agents the palette shows are two different things. A project with its own vocabulary usually deserves its own pack as well, and that switch is made in Agents, not from the Memory chip. Two clicks rather than one, but they are independent on purpose: the same agents often serve every project.
It follows the machine, not the account
Sessions live in local storage on the device that created them and are not synced. That keeps the record of your work off the network, and it means a second machine starts empty rather than picking up where the first one left off.
When each project has its own vocabulary
Sometimes the projects differ by more than their history: one files tickets in Jira with a strict template, the other lives in Linear and wants three lines. That is what a pack is for. Group the agents a project needs into its own pack in Agents, and the palette shows that project’s list when the pack is active, which pairs naturally with setting its session live. Building those bundles is covered in AI prompt packs. The steps that always follow each other, draft the ticket then file it, belong in a workflow instead, so the whole sequence runs on the live project from one keystroke.
Common questions
Can two projects be active at the same time?
No, and that is the point rather than a missing feature. Exactly one session is active, and it is the one whose working state gets handed to your actions. If two were live at once, every answer would be a blend of two projects and you would have no way of telling which half came from where. Switching is cheap instead: the Memory chip in the palette header shows the current session by name, and one click sets another one live, so the cost of the rule is a click rather than a re-briefing.
Can one project's context leak into the other one?
Only the active session is ever injected, so the session you are not in contributes nothing to the run. There is a second control on top of that: reading the session context is an opt-in per agent, ticked in the agent editor, so an action you want kept neutral, a translation or a tone pass for instance, can be set to ignore Memory entirely and behave the same whichever project is live. And when a run did use the context, the confirmation says so explicitly instead of leaving you to guess.
What happens to a session while another one is active?
Nothing is lost and nothing keeps running in the background. It sits with the entries and the working state it had when you left it, and you pick it up where you dropped it by setting it active again. A project that ships gets ended rather than deleted, which keeps it readable afterwards: its entries, its summary and its recap stay available for the retrospective or for the next person who inherits the file.
Do these sessions follow me to another machine?
No. Sessions and their entries are stored in a local database on the machine that created them and are never synced to the cloud, so a second laptop starts with its own. That is a deliberate trade: the running record of what you are working on is the most sensitive thing Khint holds, so it stays on the device. When you do need to move a project's context somewhere, copy its recap and paste it where you want it, which keeps the export a conscious act rather than a background upload.
Give each project its own memory
Free with 300 credits a month, about 10 AI actions a day. No credit card. Start a session for the project you are on this afternoon and stop re-explaining it.