Notes an agent can read: the resolution gap between what you wrote and what you meant

It is Tuesday morning and you are trying to remember what you agreed to last week. Your assistant has access to your notes, so you ask it: what did I commit to in the planning meeting?

It answers in about three seconds. You committed to owning the Helios migration with Maya, targeting the end of Q1.

This is wrong three separate ways. You committed to reviewing the vendor shortlist, not owning the migration. The M in your note was Marcus, not Maya, and there is a third M on that team. Q1 is fiscal Q1, which starts in February. What you actually wrote, at 2:14pm while the meeting was still going, was:

- Yes to the thing w/ M, prob Q1

The note is not wrong. It is under-specified. And nothing in the answer you got back told you which one it was.

The resolution gap

Every note contains references it does not define: a person called M, a project called "the thing," a quarter called Q1. Somebody has to resolve those references to something real before the note means anything.

For years that somebody was you, and you did it from memory, instantly, without noticing. The gap between what the note says and what it means was invisible because you were always standing in it. Now something else is reading the note. The gap is still there. You are just no longer the one closing it.

Why the failure is silent

A model resolves references the way it does everything else: it produces the most probable continuation given the text it can see. When your note names Marcus Ellery, the reference resolves from the document. When it says "M," there is nothing in the document to resolve against, so the resolution comes from whatever else is retrievable plus the statistical shape of the surrounding text.

That second path is interpolation, and it is where confident wrong answers come from. Not because the system is careless, but because the output looks identical either way. Fluency and accuracy are produced by the same process. There is no marker in the response that distinguishes "I found this in your note" from "I filled this in."

Compare it to search, which fails visibly. Full-text search for "Helios" returns nothing if you never wrote the word down, and zero results is a signal you act on. A model asked the same question returns a paragraph. The paragraph is the failure mode, and it has the same shape as the success mode.

Calling this a model failure invites the wrong fix. Given a well-specified note, the same process resolves the reference correctly and quietly. The difference is on your side of the wire: your note relied on context stored outside the document, and only one of its two readers can reach that store.

So shorthand has changed price. It used to cost a second of squinting six months later. Now it costs an answer that is wrong in a way you cannot detect without opening the note yourself, which is the thing you asked in order to avoid.

The fix is not more words

The obvious response is to write longer notes. That is the wrong lesson, and if you take it you will stop taking notes within two weeks. Almost every property that makes a note resolvable to a model also makes it resolvable to you in six months, and to the colleague who inherits the project. Naming the person, dating the commitment, marking whether something was decided or merely floated: that is what a good note has always required, and none of it is a concession to a machine. We just never had a cheap way to check whether ours had any of it.

Note quality used to have a feedback loop measured in years. You discovered your meeting notes were useless during a performance review or a handoff, long after it was fixable. Now the loop is four seconds long, because you can point a reader at the note, ask a question, and see what comes back.

Try that this week, before changing anything about how you write. Pick five notes from the last two months. For each, ask your agent a question the note should answer, then open the note and check. The gap between the two is your list of what to fix, and it is shorter and more specific than any general advice, including this.

The five properties of a resolvable note

Resolvable references. Name the person, the project, and the document in full at least once per note. After that, use shorthand freely: the first mention anchors the rest of the file.

Before:

Synced w/ M re: the migration. He'll own the cutover, we're aligned on timeline.

After:

Sync with Marcus Ellery (platform eng) on the Helios billing migration.
Marcus owns the cutover. Timeline: cutover the weekend of Feb 21.

Note what the rewrite exposed. "We're aligned on timeline" contains no timeline. You knew the date when you wrote it, so the sentence felt complete. It never was. The agent only made that visible; the hole would have been waiting for you in six months either way.

Absolute dates. "Next Tuesday" is a reference anchored to the day the note was written, and that anchor is the first metadata to get lost: to a copy and paste, a transcript import, a chunk boundary in retrieval. The note outlives the week it was written in. Its dates should too.

Before:

Ship by end of next week. Follow up Thursday. Revisit in Q1.

After:

Ship by Fri Feb 27. Follow up Thu Feb 19.
Revisit in fiscal Q1 (Feb-Apr 2027).

Naming the fiscal year takes four characters and removes the single most common ambiguity in planning notes.

Stated status. A decision, a proposal, an action item, and a passing thought are four different objects, and in a bullet list they are visually identical. You can tell them apart because you were in the room. Nothing in the text can.

Before:

- move standup to 9:30
- drop the Android beta
- hire a second designer

After:

- Decision: move standup to 9:30, starting Mon Oct 5. Owner: me.
- Proposal, not decided: drop the Android beta from v5 scope.
  Raised by Priya Raman. Needs Marcus by Thu Oct 1.
- Idea, no owner, no date.

That took about twenty seconds, and it is the highest-value change for the question people actually ask their notes, which is some variation of "what did I commit to." A decision log is this property applied across a whole quarter: every entry labeled, dated, and owned, so the answer is retrievable months after everyone has forgotten the meeting.

Structural signals. Retrieval usually operates on pieces of documents, not whole ones. A section under a heading called "Decisions" carries that word into the piece; a bullet floating in an undifferentiated wall does not. For meeting notes, four headings cover almost everything: Context, Decisions, Actions, Open questions. Use the same four in every note of that type, so "what did we decide" has somewhere to land in all of them.

Before: a note titled Sync, containing eleven bullets.

After: a note titled 2026-09-24 Helios billing migration sync (Marcus, Priya), containing the same eleven bullets under those four headings.

Same content, same writing time. The WLCS structure does this one level up, at the folder rather than the heading: the folder tells a retriever which domain to search, the heading tells it which paragraph to return.

Stated scope. One line at the top saying what the note covers and what it does not. This is the least intuitive of the five and it prevents the worst failure, which is a partial note being read as a complete one.

Before: a note from a 60-minute meeting where you stopped writing at minute 25. After, as its second line:

Scope: pricing decisions only. Packaging and the rename are in the
Helios positioning note. Notes stop at ~2:30pm; I dropped off early.

Without that line, an agent asked "what did we decide about packaging" answers from a note that never covered packaging, and the answer reads exactly like one from a note that did.

The Resolve Pass

This is the whole convention. It adds under 30 seconds per note, and it is deliberately not a template: it has to survive being applied to a note you type during a meeting you are also participating in.

1. Title, 5 seconds. YYYY-MM-DD subject (people). The date goes first so files sort, and so the note carries its own anchor even when the app's metadata never reaches the reader.
2. Scope line, 5 seconds. One sentence: what this is about, and what lives elsewhere. Add "notes stop at X" whenever they do.
3. First mention in full, 10 seconds. The first time each person, project, or document appears, write the full name. Every time, without exception. If you keep only one of these five steps, keep this one. After that, abbreviate freely.
4. Status prefix where ambiguous, 10 seconds. Not on every line. Only on lines that could be mistaken for a different kind of line: Decision, Proposal, Action, Open question. In practice, three or four bullets per meeting.
5. Absolute dates, no extra time. A substitution rather than a step. Every time you are about to write a relative date, write the calendar date instead. The habit sets in about a week.

Run it for five working days, then run the five-note test against those notes and against five older ones. The difference in answer quality is usually obvious enough that nobody has to talk you into keeping it.

The write direction

Reading is half of it. When an agent writes into your notes, four conventions keep the result reviewable rather than a wall of generated text you eventually stop reading.

Generated text goes in a marked block, never merged into your prose. A heading like ## Draft from agent, 2026-09-28, unreviewed is enough. You can then tell which sentences you wrote and which you approved by not deleting.

Require a source per claim. Ask for the note title or event each line came from. Lines that cannot cite one go in a list at the bottom under "unsourced." That list is short, and it is where the errors are.

Cap the length. A generated summary longer than what you would have written is not a summary. Ask for a line count. Six is a reasonable default for a meeting.

Clear the unreviewed blocks during your weekly review. Promote the correct lines into your own sections, delete the rest, remove the heading. This is the step that matters, because next week's agent reads this week's output as if you had asserted it. Without a review gate, a plausible guess gets laundered into a fact over three or four cycles.

Frequently asked questions

Does this not slow me down? It adds roughly 30 seconds to a note that took four minutes. The comparison that matters is not against your current notes. It is against the ten minutes you spend opening three files to check an answer you did not trust, a tax you already pay and do not count.

Should I use a rigid template? No. Templates die: the first meeting that does not fit produces a note with four empty headings, and after that nobody fills any of them. Conventions survive because they degrade gracefully. A note where you only reached step three of the Resolve Pass still beats a note where you reached none. Aim for something you can apply badly.

What about voice notes and meeting transcripts? Transcripts have the opposite problem: complete and unstructured, so every reference sits somewhere in nine thousand words and almost none are findable. Treat a transcript as raw material, not a note. Put a six-line summary at the top following the five properties, and keep the transcript below it as backing. For voice notes, say full names out loud. Dictation faithfully preserves "the thing with M."

Will models not just get better at this? They will, and it will not solve this. Better models resolve harder references, tolerate messier structure, and are better at flagging uncertainty. All of that is real. None of it recovers information that was never written down. No model can determine which of three people whose name starts with M was in a room in September 2026, because that fact is in no document. Better retrieval moves the boundary of what is recoverable. It does not move it past the edge of the record.

Do I need to go back and fix my old notes? No, and attempting it is how the habit dies in week one. Apply the convention going forward and repair old notes only when you happen to open one. The notes you reopen are the fraction that matter.

Closing thought

A note has always been a message to a reader who cannot ask what you meant. That reader used to be your future self, who at least had a chance of remembering the room. Now it is also every tool you connect to your notes, and those have only the file.

Try the Resolve Pass this week

Run it in whatever notes app you already use. All five properties are plain text conventions: they work in a text file, a wiki, or a doc, and none require a feature.

What changes when notes and calendar live in the same place is the anchor. A note attached to an event carries the date, the attendees, and the title without your typing them, which handles two of the five properties before you write a word. nocal has shipped a built-in MCP server since v3.1, so Claude, Cursor, and ChatGPT search and patch your real notes instead of a copy you pasted into a chat window. Setup is on the connect an agent page; the reasoning is in our earlier post on MCP.

Run the test before you change anything. Five notes, five questions, five answers you check by hand. Most people find the same thing: the notes are not disorganized, they are under-specified, and the fix is thirty seconds long.