Your Notes Have Three People Named Alex — the AI Merges Them

Three notes mention Alex. One is your manager, one is your cousin, one is a client. Ask your note AI what Alex said about the budget, and it may braid all three into one person. The fix is not a smarter model — it is writing each identity down unambiguously, at the moment you take the note.

This has a name in computational linguistics — two names, actually. Deciding that "Alex" in one note and "Alex" in another point to the same real person is cross-document coreference. Mapping an ambiguous name onto the right real-world entity is named-entity disambiguation, the task Johannes Hoffart and colleagues formalized at EMNLP 2011.¹ Both are decades-old research problems, and both are measurably hard — not because your notes are careless, but because a bare shared name genuinely underdetermines who is meant. A model reading your vault has to guess. When your notes have three people named Alex and never say which is which, it guesses wrong, confidently, and hands you a merged answer that reads like fact.

Why your AI braids three Alexes into one

Your AI merges same-named people because resolving identity across documents is one of the hardest tasks in language understanding — and it fails most on exactly the ambiguous cases your vault is full of. Even purpose-built, supervised systems top out around 70% on cross-document coreference benchmarks. A general model reading raw, untagged notes does worse, not better.

The numbers come from research on exactly this task. In a 2024 study presented at the Annual Meeting of the Association for Computational Linguistics, Qingkai Min and colleagues report that cross-document event coreference "remains a significant challenge for SLMs, as evidenced by achieving only around 70% CoNLL F1 score on the FCC dataset," and that "GPT-4 struggles to perform basic clustering when relying solely on the task description."² Seventy percent is the ceiling for tuned systems — and the AI in your notes app is not tuned for your vault.

The failure runs in two directions at once. Distinct things "may be portrayed in a very similar manner," the same paper notes, while "the portrayal of the identical event may vary significantly across different documents."² Translate that to your notes: three different Alexes can look like one person, and one Alex — written formally in a work log and casually in a journal entry — can look like two. Merge and split are the same bug seen from opposite ends.

The scale of the collision is easy to underestimate. In one research corpus alone, the ECB+ dataset, the same authors count "over 400 event types" competing for the same labels.² Your vault is smaller, but the mechanism is identical: a short, repeated surface form standing in for many distinct things.

The person-specific version is just as stubborn. Kellie Webster and colleagues built GAP, a benchmark of 8,908 ambiguous pronoun-name pairs, precisely because, in their words, "the resolution of ambiguous pronouns [is] a longstanding challenge."³ Their best baseline resolved the right person only 66.9% of the time. When the answer is "which Alex," a coin-flip-plus is the state of the art you are trusting.

The deeper task even has its own name. Mapping an ambiguous name onto the correct real-world entity is named-entity disambiguation, formalized by Hoffart and colleagues at EMNLP 2011 as the problem of resolving one surface name to the specific person, place, or organization it denotes.¹ It is a whole research subfield because the general case is genuinely undecidable from the name alone — you need context the name does not carry. Your notes either supply that context or leave the model to invent it.

The one habit: write the identity, not just the name

The single habit that fixes this is to disambiguate identity at write time — never let a bare, shared name stand alone in a note. Give each person, project, or client a distinct, spelled-out identity the first time it appears, and the AI never has to guess which one you meant.

You resolve the ambiguity once, in plain text you own, so the machine does not have to resolve it at all. This is the same move a good journalist makes on second reference. "Alex" is fine in conversation because context is shared and live. A vault has no shared context — it is hundreds of notes written months apart, read by software that sees them flat and all at once. The name that is obvious to you at your desk on Tuesday is a genuine ambiguity to a model reading Tuesday's note beside a note from last spring.

Disambiguation at write time is cheaper than every alternative. Cleaning it up later means re-reading old notes and reconstructing who you meant — which is precisely the information you had at your fingertips at the moment of writing and threw away. Spend three seconds now or thirty minutes in six months.

The five-minute version

The five-minute version is three moves and one command. Write full names instead of first names, tag any name that still collides with a short role in parentheses, and keep a single index note that lists who each person is. Then run one search to find every bare name you missed. Start forward-only today; retrofit the back catalogue later.

1. Use the full name on first reference (about 2 seconds per note). "Alex" becomes "Alex Chen." A distinct surface form is the whole fix — two Alex Chens are rarer than two Alexes, and a full name is something you would write anyway.

2. Tag the collision with a role (about 3 seconds). When full names still clash, or when you only know a first name, append a short parenthetical: Alex Chen (manager), Alex Rivera (Nimbus client). The role travels with the name and survives being read out of context.

3. Keep one people.md index (about 5 minutes, once). A single note that maps each name to a one-line identity gives both you and any AI a lookup table. This is the identity analogue of keeping a plain-text glossary your AI can read — a glossary defines your terms; this defines your people.

Here is a four-note sample before the discipline:

# 2024-01-05
Met with Alex about the Q3 budget.

# work
Alex says ship it.

# clients
Client Alex from Nimbus signed the SOW.

Read flat by a model, those three "Alex" mentions have no reason not to collapse into one. Here is the same vault after:

# 2024-01-05
Met with Alex Chen (manager) about the Q3 budget.

# work
Alex Chen (manager) says ship it.

# clients
Alex Rivera (Nimbus client) signed the SOW.

And the index note that anchors them:

# People

- **Alex Chen** — my manager. Runs the Q3 budget.
- **Alex Rivera** — client contact at Nimbus.
- **Alex Nguyen** — my cousin. Nothing to do with work.

4. Run one search to catch what you missed. ripgrep will surface every bare "Alex" that is not already followed by a capitalized surname:

# Find every bare "Alex" NOT already followed by a capitalized surname
rg -n --pcre2 '\bAlex\b(?!\s+[A-Z][a-z])' /path/to/vault

In the four-note sample above, that command returns three lines — the three casual "Alex" mentions — while correctly skipping "Alex Chen" and "Alex Rivera." Your own count will differ; the number is not the point. The point is that a one-line search turns an invisible ambiguity into a short, fixable list. Swap Alex for any first name, client, or project that repeats in your vault.

The thirty-minute version: retrofitting an existing vault

The thirty-minute version applies the same discipline backward, over notes you already wrote. You do not re-read everything. You let the search tell you which names actually collide, fix those in place, and leave the rest alone. Ambiguity that never caused a merge does not need your Saturday.

Start by listing your repeat offenders — the first names, client names, and project codenames that appear across many notes. For each, run the rg pass above and read the hit list, not the whole vault. A name that appears once is not a collision; a name that appears in twelve notes across three contexts is.

Fix from the index outward. Write the people.md entry first, decide the canonical full name and role tag there, then find-and-replace the bare mentions to match. Doing it in that order means every note ends up pointing at the same spelled-out identity, which is exactly what a model needs to stop merging them. Editors and command-line tools both do vault-wide replace; the discipline matters more than the tool.

Timebox it and stop. Thirty minutes on your five worst-colliding names removes almost all of the merge risk, because ambiguity is not evenly spread — a handful of common names cause nearly all of it. This is a distinct repair from consolidating near-duplicate notes that poison retrieval, where the problem is one thing written many times rather than many things sharing one label.

Common mistakes

The common mistakes all share a root: solving a different problem and assuming it covers this one. Identity disambiguation is its own axis. Fixing your vocabulary, your dates, or your duplicates does not fix which real person a name points to, and treating any of them as a substitute leaves the merge bug fully intact.

• Assuming a glossary handles it. A glossary defines what a word means. It does not decide which of three Alexes a sentence is about. Definitions and identities are different jobs.
• Assuming recency handles it. Marking which note is current resolves contradictions about the same entity. It does nothing when the two notes describe different people who happen to share a label.
• Adding a tag but not a name. A #alex tag groups mentions; it does not distinguish them. If the tag itself is ambiguous, you have automated the merge.
• Full names everywhere except where it counts. People disambiguate in formal notes and stay casual in quick captures — but quick captures are where the collisions hide. The habit has to reach the messy notes to work.
• Retrofitting the whole vault at once. You will burn out before the payoff. Fix the five names the search flags most; leave the long tail.

Will a better model fix this for you?

A better model narrows this problem; it does not remove it. Stronger systems resolve more identities correctly, and knowledge-graph grounding helps further. But the research is consistent that gains depend on good inputs, and performance still collapses on the hardest, most ambiguous cases. The durable control is the input you write, not the model you wait for.

Knowledge-graph grounding, when a tool offers it, is really just this same discipline moved into a data structure — an explicit table of who is who, handed to the model instead of left for it to infer. That helps for the same reason a people.md index does. It is the write-time habit in another shape, not an escape from it.

The honest, balanced finding is Nghia Le and Alan Ritter's, in a 2023 preprint: "prompting for coreference can outperform current unsupervised coreference systems, although this approach appears to be reliant on high-quality mention detectors."⁴ Read that carefully. The model does better when it is handed clean, well-marked mentions — which is precisely what disambiguating at write time gives it. You are not fighting the model; you are supplying the input it depends on.

And the drop on hard cases is measured, not hypothetical. Lior Forer and Tom Hope report that a strong prior system scored 76.46 F1 on a full cross-document coreference test set but only 64.34 F1 on the hardest 10% of cases — because language models "can struggle when faced with many long-tail technical concepts with nuanced variations."⁵ Your three Alexes are that hard case: subtle, context-dependent, easy to confuse. The place performance falls is exactly the place your vault lives. Reduces is not eliminates.

How this works in a plain-text vault

This fix belongs to you because it lives in plain Markdown, not in a feature. A full name, a (role) tag, and a people.md index are just text in files stored on your own device. Any tool that reads Markdown inherits the disambiguation automatically, because the identity is written into the note rather than inferred by the software.

That is the quiet argument for keeping your notes as open text you control. Today's note app, tomorrow's, or an AI you have not chosen yet all read the same resolved identities — nothing is locked inside one app's index. The discipline is portable, auditable, and outlives any single model's guessing ability. In a plain-text vault, you can grep your own identities, diff your own index, and carry all of it somewhere else without asking permission. The AI is a reader of your files; you decide what the files say.

Frequently asked questions

These are the questions people actually type when their notes app fuses two people or two projects into one. Each answer is short enough to lift on its own — the fix is a write-time discipline you own, and it stays the same whether the confusion is about people, clients, projects, or places that share a name.

Why does my AI mix up two different people with the same name in my notes? Because deciding whether "Alex" in one note and "Alex" in another mean the same person is cross-document coreference, one of the hardest tasks in language understanding. Supervised systems top out near 70% F1;² a general model reading untagged notes does worse and merges them.

How do I disambiguate people or clients with the same name in my notes? Write the full name on first reference, and when names still collide, add a short role tag: Alex Chen (manager), Alex Rivera (Nimbus client). Keep one people.md index mapping each name to a one-line identity. Do it at write time, so the AI never has to guess.

Why does my note AI think two different projects are the same one? Same mechanism as with people. A shared short label — a first name, a client, a codename — underdetermines which real thing you mean, so a model reading your vault flat collapses distinct projects that share a name. Give each a distinct, spelled-out identity and the collision disappears.

Does using full names really fix it? It fixes most of it, cheaply. A distinct surface form removes the ambiguity a model would otherwise have to resolve, and clean mentions are exactly what coreference systems depend on to do better.⁴ Add a role tag only where full names still clash, and an index note as the lookup of last resort.

Will a better AI model solve this on its own? It helps, but it does not eliminate the problem. Performance still falls hardest on the most ambiguous cases — one strong system dropped from 76.46 to 64.34 F1 on the hardest 10%.⁵ The reliable control is disambiguating identities in the notes you write, not waiting for a model upgrade.

Do I need a knowledge graph or special tooling? No. The whole method is plain text — full names, (role) tags, and a people.md index — plus one rg search to find bare names. Knowledge-graph grounding can help a model further, but it is an addition to the write-time discipline, not a replacement for it.

A model reading your notes will always guess when a name is ambiguous — the only question is whether you leave it something to guess about.

Write the identity down once, in plain text you keep, and the three Alexes stay three people — in mnmnote.com or anywhere else your files travel.