The Briefing Problem
Notes are written for the writer, not the reader. That becomes obvious the moment you need to hand your context to someone else.
You return from three weeks away. Someone needs you to brief them on a project you were running before you left. Your notes are all there. You were diligent about it. But as you open the files, something is off. The notes are perfectly formed and almost useless.
Not because they're badly written. Because they were written for someone who already knew what you knew the day you wrote them.
"Talk to Marcus about the pricing thing" doesn't mean anything to someone who doesn't remember who Marcus is, what the pricing thing was, or why it mattered. The note was never a document. It was a trigger — it assumed you'd be the one pulling the trigger, and that you'd still have the context needed to fire.
This is the briefing problem. Not forgetting to take notes. Taking notes that only work if you never forget.
What notes actually are
Most personal notes are reminders, not records. A reminder assumes context is already loaded in your head. A record contains enough to reconstruct understanding from scratch, without you present.
High-stakes industries understood this distinction the hard way. SBAR — Situation, Background, Assessment, Recommendation — originated in the US Navy for nuclear submarine duty handoffs in the 1950s, then spread to aviation and eventually healthcare. The reason it was developed wasn't that people were careless about information sharing. It was that unstructured briefings killed people. The 1977 Tenerife airport disaster, still the deadliest aviation accident in history with 583 dead, was partly caused by communication failures during a high-pressure handoff — not missing information, but ambiguous information, context assumed instead of stated.
SBAR exists because context doesn't transfer by default. You have to make it transfer deliberately, by structuring the briefing so the information is interpretable without the person who generated it in the room.
Most note apps have no such design pressure. Nobody dies when you can't find what you meant by "Marcus."
The curse you can't escape
In 1989, economists Colin Camerer, George Loewenstein, and Martin Weber described something they called the curse of knowledge: once you know something, you can't accurately reconstruct what it's like not to know it. Your baseline shifts. You write from that baseline, and the notes you produce assume knowledge the reader doesn't have.
This isn't fixable by writing more carefully. It's structural. The context that makes a note meaningful is invisible to you at the moment of writing — not because you're hiding it, but because you can't see it anymore. You're underwater in it.
So you write "Marcus — pricing — September" and it feels complete. It contains everything that seemed noteworthy. What it doesn't contain is the six weeks of accumulated understanding that made it noteworthy.
That understanding is what you're actually trying to hand off. And it's in your head, not your notes.
What structure changes
Here's where this stops being just a writing problem.
When you compress "Marcus and the pricing thing" into prose, you've encoded a relational structure into a sentence. Decompressing it requires the context you had when you encoded it. If that context is gone, the compression is lossy. You lose what you can't get back.
When you represent Marcus as an entity — a Person, with a name, a role, a relationship note, a last-contact date, open items attached to him — you've done something different. You've separated the information from the moment it was written. The structure holds its shape without you. Anyone who reads the record, including you three weeks later, can reconstruct what matters without having been there.
Gene Kranz's flight controllers at NASA wrote their flight rules this way by design. Each rule captured not just what to do but why, under what conditions, and what the acceptable tradeoffs were. The document had to make sense to any qualified flight controller, not just the author. Kranz understood that the ability to brief someone cold is the real test of whether knowledge was actually captured.
Most note apps never impose that test.
The reader you forgot to imagine
The Camerer experiment was done in economic settings, but the mechanism is general. The further you get from the moment of writing, the more context you've shed, the more your notes become artifacts of a mental state you can no longer access. This is why good notes from two years ago feel like notes someone else wrote. They were.
AI retrieval makes part of this worse before it makes it better. Feed an agent a note that says "talk to Marcus about the pricing thing" and it will find the note when you search for Marcus. But it can't brief you on what the pricing thing was, because that context was never written down. The retrieval quality is bounded by the write quality.
Structured knowledge changes the equation. An agent that can see Marcus's record (his role, the project you share, the conversation you had in September, the follow-up that's still open) can give you a coherent two-paragraph briefing before a call. Not because it's smarter. Because the information was written in a form that survived the context it was written in.
The real test of a knowledge system isn't how easy it is to write to. It's whether someone who wasn't there can pick up where you left off — a colleague covering for you, an AI agent you've given access, or the version of you who comes back from three weeks away with a meeting in an hour.
Almost nobody designs their notes with that reader in mind. That's why almost nobody passes the briefing test.
Asgeir Albretsen is the founder of Harbor.