Here’s the loop y’all already know.
You spend two hours with an AI coding assistant working out why a build keeps failing. What you tried. What you ruled out and why. Then the session ends, and tomorrow you open a fresh one and it knows none of it. Everything that would have made the next hour cheap is gone.
Everyone says the same thing: these tools need memory. That’s why the fixes keep disappointing. Memory is one word covering two jobs, and they want opposite things.
History and handoff aren’t the same job
History is what did we do, when, and why. It should last, it should be filed by subject, and someone who wasn’t there should be able to read it in six months. It piles up on purpose.
Handoff is I’m stopping mid-thought and I need to start cold tomorrow. Everything loaded, nothing trimmed, the open questions still open. And it’s disposable the second you’re moving again.
| History | Handoff | |
|---|---|---|
| Answers | What happened? | Where was I? |
| Lasts | Forever | Until you pick it back up |
| Built for | Being found later | Being loaded cold |
Build one thing for both and you get something too heavy to be a log and too thin to be a handoff. So build two.
History: file by subject, not by date
The obvious design for a work log is one entry per session, dated. Easy to build. It’s what nearly everything does. It also gives you a folder of hundreds of dated files nobody ever opens again. To answer “how does our deployment process work” you’d have to remember which Tuesday you figured it out.
Dates are almost never how you want to find engineering knowledge. Subjects are.
So the log should ask where this belongs, not when it happened. Does this work belong to a system that already has a note? Put it there. A project? Put it there. Only when nothing fits does it get its own dated entry. Then your notes on the deployment process live in the deployment process note, getting better every time you touch it.
A journal you never reread is a diary. A note that improves every time you touch the subject is documentation. You want the second one.
Handoff: make it manual on purpose
Some tools watch continuously and decide for you what mattered. Useful, and a different thing entirely. The catch is that they decide by guesswork, and the thing you needed was the option you rejected an hour ago for a reason you never wrote down.
So the handoff should be something you ask for. You say save, and it freezes the whole picture. Where you are. What’s decided. What’s still open. What to do first when you come back.
Asking for it means you decide when a moment is worth keeping. It costs you two words, and it removes the entire category of “the summary dropped the one thing I needed.”
Both halves should write plain text files to your own disk. No database, no service, no account. If the tool vanished tomorrow you’d still have a folder any editor can open. Your work history is the last thing you want to lose to a shutdown notice.
The quiet payoff of plain files is where you point them. Point them at an Obsidian vault that syncs to the cloud and you get cross-machine context for free. Save a handoff on the laptop, load it cold on the desktop. And because it’s just markdown, it isn’t tied to one assistant. Switch tools next year and the thread comes with you.
What I built
I built it for myself and open-sourced it. It’s called throughline, it’s free, and it’s two small add-ons for Claude Code.
diary does history: past tense, filed to the most permanent note it can find. recall does handoff: a full snapshot you save on purpose and load cold in a new window. They share almost no code, because they’re solving different problems.
Then just work. Say diary when you finish something worth keeping. Say recall save when you stop mid-thought. The thread holds.
Cheers,