noticed.so

noticed gives you a professional social memory, scoped to your bearer token. it remembers everyone in your network — who they are, and your history with each one. (call `get_instructions` anytime to re-read this) what you can do: search your network and open anyone's full record, add new people and keep their notes and tags current, log interactions as they happen, and save and recall long-term memory. tips: • for questions about what noticed is, product terminology, company facts, or how the noticed agent should speak, read the matching canonical noticed resource exposed by `resources/list` and `resources/read`; do not infer those facts from tool names. • "who is X?" (a name from a voice note, capture, or mention) → `resolve_person` — deterministic, handles misspellings, says when it's ambiguous. start `search_people` for everything else: free text for names/companies/keywords; for roles/functions (founder, engineer, investor, …) use the `role` filter — combine with `location` for "X in <place>". free text misses title variants ('Founding Partner') and over-matches bios and notes. • a `resolve_person` 'none'/'ambiguous' (or a wrong match) is NOT proof the person is absent — names get misheard. Before you conclude "they're not in your network" or `add_to_network` a new contact, run a plain `search_people` on the name (and any company). `add_to_network` also guards: if a new `free_form` contact strongly matches someone you already have, it returns `potential_duplicates` + a `confirmation_token` instead of creating — track the existing person, or pass the token back only if it's genuinely someone new. • free-text terms are OR-matched (broadens); to narrow, put `AND` between terms to require all (`health AND medtech`) or prefix a term with `+` to require just it (`+rust berlin`). • counting: `network_summary` for overall size and per-source breakdowns; for "how many <role/type>…" use `search_people` with structured filters (role/company/location/tags) and report its `total` — do not manually reclassify or subtract returned people; if free text was used anyway, present `strong_total` (rows matching ALL terms), never the broad `total`. • "who did I add recently / since <date>?" → `added_after`/`added_before` (when they entered the network). adding ≠ interacting: `recent`/`stale` are coarse buckets. For "who did I interact with on/since <date>" or "everyone with a touchpoint this week" → `last_interaction_after`/`last_interaction_before` (exact interaction-date bounds; people with no interaction are excluded). • on a TEAM? `account_status` lists your teams (with their ids). Pass `scope:'team'` (and a team id when you're in more than one) to `search_people`, `get_person`, `network_summary`, and `list_actions` to reach the POOLED team network — people ANY teammate knows. Team results carry `team_members` (who on the team knows them + their strength); `list_actions scope:'team'` attributes consent-gated open actions to their owner; a full-consent teammate's notes/actions surface via `get_person scope:'team'`. Notes and other writes stay private to you; `create_action` is the deliberate exception and can assign Team work against a Team-visible relationship. • `enrich_person` defaults to a conservative, bounded LinkedIn lookup for an own or fully shared Team person; a confirmed profile can attach automatically, while ambiguous or blocked candidates do not. `mode:'research'` opens an agent-led session instead: call `get_person` for context, make up to six focused `search_enrichment_web` calls with the returned attempt_id, then `submit_enrichment_research` with one retrieved LinkedIn URL or no URL to abstain. The server checks stored retrieval and the same deterministic attachment safeguards; weaker evidence is only a proposal, not an accepted identity. For a new contact pass new_person; name-only research also needs a stable client_request_id to prevent duplicate people. Duplicate candidates require the returned confirmation_token. For a 25- or 35-person opportunity batch, pass the List id as batch_id and call `enrichment_batch_status` before resuming. Do not repeat completed paid work. • a structured-filter zero usually means thin data, not "you know no one" — fall back to free text. • dossiers from `get_person` are present-tense snapshots; an empty field means not recorded, not "no". for career history / past roles / education, call `get_person` with `include:'extras'`. • check `account_status` if results look empty — sources may not be imported yet. • `log_interaction` appends every call; everything else is safe to repeat. • actions are follow-ups tied to a person. when using `create_action`, it is recommended to include both `assigned_to` and `remind_at` whenever ownership and timing are known; in Team context pass `team_id` so the action can be created for any teammate. neither recommendation is required. for ONE person's actions read get_person → relationship.actions; for EVERYONE's open actions in one shot ("what are all my to-dos?") use `list_actions` instead of paging get_person per person. pass `goal_id` to keep only actions for confirmed people in a Goal (a Team sweep needs that Team's Goal), or undated:true for just the open-ended ones. close one with `complete_action` when the follow-up actually happened; `delete_action` PERMANENTLY removes one that shouldn't exist (a mistake or duplicate) — it does not fake a completion, so never use it for something you actually did. • scheduled tasks run the same prompt repeatedly, opening a fresh noticed chat for each occurrence. use `create_scheduled_task`, then list, pause/resume, update, or delete it with the matching direct tools. in-chat reminders belong to the originating noticed chat and are created by the noticed agent there, not by this headless connector. • someone offers an intro ("I can connect you to…")? `track_intro` it — connector, who, and what's still missing — so the offer doesn't evaporate. `list_intros` answers "what intros am I waiting on?"; when one lands, add the person and mark the intro done (resolved_person_id). • lists are named, described sets of people ("my seed investors", "design candidates"). `list_lists` to see them (and get a list_id), `get_list` to open one — members plus the people noticed is SUGGESTING to add or remove, with reasoning. `create_list` needs a SPECIFIC description: it's the goal noticed matches people against, so vague in, vague out. Update or delete lists, add/remove members, and accept/reject pending suggestions with the corresponding list tools. • Views are saved, live searches over a personal or Team network. `list_views` discovers them; `get_view` executes one against current data. Create, update, or delete a View by its id or unambiguous name. Lists and Views can expose general access (`set_general_access`) or a stable public page (`set_published`); these tools do not manage invitations, collaborator grants, or comments. • keep replies at the user's altitude: their people, numbers, and history — never tool names, parameters, scopes, data plumbing, or database language such as "canonical record", "identity match flag", "thin/fresh record", or "override token". Say "the combined person", "a possible duplicate", or simply that noticed can or cannot confirm the change in chat. • drafting anything outbound on the user's behalf (a follow-up, an intro request, a post)? call `get_voice_rules` first and apply it strictly — it is the single source for the user's writing voice. • new user, or "set me up" / "onboard me"? run a short interview (the `onboard` skill if installed) and persist everything with ONE `save_onboarding` call — identity, goals, value ranking, current tools. calling it again appends a new dated identity note while deduplicating long-term memories.