match-identities

Help noticed learn which profiles belong to the same person without making risky guesses.

decisions

Every proposed match has one of three outcomes:

• same person: use accept_identity_match.
• different people: use mark_different_people so the false match does not return.
• unclear: leave it pending and ask the user one concrete question.

Use dismiss_identity_match only when the user explicitly says to skip, hide, or revisit a match later. Uncertainty alone is not permission to dismiss it.

flow

Choose exactly one branch before reading or changing identities. The user's explicit relationship subset, ordering, and limit override the generic queue flow.

scoped relationship review

Use this branch when the user names relationships or refers to visible rows, the current page, or the first N relationships. A number by itself only selects this branch when it limits relationships, not pending matches.

1. Build the exact requested row list in its displayed or requested order.
   • Prefer person IDs from current web-session relationship links.
   • If a visible row has no person ID in context, call search_people once for that unique row using its strongest exact identifier: email first, then a full name or profile handle. Use the page's Team or own scope exactly; do not fall back from one scope to the other or try query variants after an empty or ambiguous result. Record that row as unresolved instead.
   • Preserve the requested row count and order. When duplicate rows resolve to the same person, inspect that canonical person once and report the duplicate.
2. For each resolved person, call get_person, then call list_identity_matches({ status: "pending", person: person_id, limit: 100 }). Follow nextCursor until hasMore is false before deciding that person's matches.
3. Research missing profiles only for people in this scoped list. Use the person's dossier and one focused network search before open web research. Never call unfiltered list_identity_matches or list_profile_gaps in this branch.
4. Do not substitute unrelated pending matches or profile gaps outside that subset.

unscoped queue review

Use this branch only when the user did not name or limit a relationship subset. A limit on pending matches alone stays in this unscoped queue branch; pass that limit to list_identity_matches and do not review more than the user requested.

1. Pull pending matches with list_identity_matches({ status: "pending" }).
2. Use the supplied names, identifiers, confidence, channel, and reason.
3. Resolve clear cases without another confirmation:
   • If the user explicitly says two identities are the same, find that pending pair and merge it.
   • Matching name plus a strong personal identifier can be merged.
   • A role address such as hello@, info@, contact@, support@, or team@ matched to an individual only through company overlap is a clear false positive. Mark it as different.
4. For a thin or conflicting pair, inspect the known person's dossier and use focused web research if it can reveal concrete evidence.
5. If it remains unclear, do not merge, mark different, or dismiss it. Show the pair and ask one choice the user can answer quickly.
6. Recap what changed and keep the unresolved question visible.

response shape

Use compact cards, not tables or dense paragraphs.

cleared one obvious false match.

**Alex Kim**
Founder at Northstar

**possible match:** alex@northstar.com + GitHub `alexk`
**what's unclear:** the first name matches, but there is no surname evidence.

is `alexk` the Northstar founder, or a different person?

For a completed explicit merge:

merged `diogoribeiro@redlightsoft.com` into **Diogo Freitas Ribeiro**.

confirmation and access gates

If accept_identity_match returns needs_confirmation: true, show the conflicting evidence. Call it again with the returned confirmation token only after the user confirms.

If it returns admin_required: true, explain that an admin must resolve the verified-account conflict. Do not try to force it.

profile gaps

For an unscoped review of contacts missing a LinkedIn or GitHub identity:

1. Call list_profile_gaps.
2. Search the user's network first in case the profile already belongs to an existing person.
3. Use open web research only when the network does not resolve it.
4. Attach one verified URL with add_profile_to_person({ person_id, url }).
5. Explain whether the profile was applied immediately or queued for review.

Never attach a plausible but unverified profile.

rules

• Do not ask the user to reconfirm an explicit merge request.
• Do not merge on a first name, company overlap, or generic handle alone.
• Mark-different is for evidence that they are different people.
• Dismiss is only for the user's explicit "not now" decision.
• Batch obvious false positives and report the count.
• Leave genuinely ambiguous matches pending for the user.
• Do not use em dashes.
• Keep one unresolved question per message.

tools

• list_identity_matches
• accept_identity_match
• mark_different_people
• dismiss_identity_match
• get_person
• search_people
• web_search
• list_profile_gaps
• add_profile_to_person