Skip to content

PKM Person

Creates or updates person profiles in AnyType with rich org context — role, relationship to the user, org affiliations, and links to other people and projects. Designed for rapid org mapping during onboarding.

When to use

  • "Add person: Sarah Chen, my skip-level at Stord, VP Engineering"
  • "Update my notes on Marcus — he owns the infra team"
  • "Link Alice to the platform project"
  • "Who do I know at this company?" (query mode)
  • Post-meeting: capturing new contacts or updating relationship notes

What you produce

  • One AnyType person object (created or updated)
  • Org links between people (reports-to, peer-of) where provided
  • Audit-log entry per write

MCP tools used

  • mcp__anytype__API-list-spaces — resolve space ID
  • mcp__anytype__API-search-space — check if person already exists before creating
  • mcp__anytype__API-create-object — create new person profile
  • mcp__anytype__API-get-object — read current fields before update
  • mcp__anytype__API-update-object — update fields or add relations

Procedure

Add a new person

  1. Check for existing record via mcp__anytype__API-search-space (search by name, type_key: person).
  2. If a match exists, switch to Update flow rather than creating a duplicate.
  3. Classify data — people records are internal by default; set private_sensitive if the person is part of a sensitive hire, negotiation, or NDA context.
  4. ⚠️ Never write a person record to Sensitive · Human only space via MCP. Tell the user to add it manually there.
  5. Resolve space ID via mcp__anytype__API-list-spaces. Default: Agent · LLM wiki.
  6. Create the person object via mcp__anytype__API-create-object:
  7. type_key: person
  8. Fields (per schemas/object-types.md):
    • name — required
    • org_role — job title / role at their org (e.g. "VP Engineering")
    • relationship_type — one of: manager, peer, report, stakeholder, recruiter, external, unknown
    • notes — any context from the conversation (how you met, what they own, agreements made)
    • last_contact — today's date if met today
    • tags — org name, team, domain (e.g. ["stord", "infrastructure"])
  9. Optional: aliases for nicknames or handles
  10. Link to projects if the person is associated with a known project:
  11. Read existing affiliations first; merge before writing.
  12. Wire org edges if the conversation revealed who they report to or work with:
  13. reports_to (directed) — set on this person, pointing at their manager. Do not mirror onto the manager.
  14. collaborates_with (symmetric) — set on both ends.
  15. Delegate the actual write to pkm-link (handles read-before-write merge, directionality, and audit). These two relations are what populate the organization graph for export.
  16. Audit log — append to knowledge/anytype-integration/runbooks/audit-log.md. Action: write. Object type: Person.

Update an existing person

  1. Find via mcp__anytype__API-search-space. If multiple matches, ask to disambiguate.
  2. Read via mcp__anytype__API-get-object — capture current field values.
  3. Update via mcp__anytype__API-update-object:
  4. Append to notes — do not replace existing notes.
  5. Merge any new affiliations or tags with existing values.
  6. Update last_contact to today if this was a recent interaction.
  7. Audit log — action: write. Rationale: what changed and why.

Use this when capturing reporting relationships or team membership. These person↔person edges are the data the Glovebox graph tier analyzes, so capture them deliberately.

  1. Find both person objects via mcp__anytype__API-search-space.
  2. Choose the relation:
  3. Reporting line → reports_to, directed: set on the report, pointing at the manager. Never mirror it (mirroring inverts the org chart).
  4. Peer / working relationship → collaborates_with, symmetric: set on both ends.
  5. Use pkm-link skill to establish the relation — it handles read-before-write merge, directionality, and audit logging.
  6. Add a note on each person's profile summarizing the relationship if useful context.

Query people

  1. Use mcp__anytype__API-search-space with type_key: person and optional tag filter.
  2. Return: name, org_role, relationship_type, last_contact.
  3. Useful prompts: "who do I know at Stord?", "list my direct reports", "who owns the security team?"

Org mapping workflow (new job onboarding)

During the first weeks of a new job, run this skill after each meeting or introduction:

  1. One pkm-person call per new contact (or update if they exist).
  2. Note relationship_type and org_role immediately while fresh.
  3. At end of week: run a query to review the full person graph; use pkm-link to wire any missing reports_to (reporting lines) and collaborates_with (peer) edges. Complete edges are what make the graph worth exporting.
  4. Tag people by team so queries like "who's on the platform team?" work.

Privacy note: real colleague data should not be exported to a cloud-bound graph analysis until the Glovebox graph tier's no-leak contract is proven against synthetic data. Capturing colleagues in your local AnyType is fine (it stays local/encrypted); exporting the graph for agentic analysis is the step that waits on the contract. See docs/use-cases/graph-relationship-analysis.md.

Anti-patterns

  • Don't create duplicate person records — always search first.
  • Don't overwrite affiliations, tags, or notes — read and merge.
  • Don't mirror reports_to — it is directed (report → manager). Use collaborates_with for symmetric peer links.
  • Don't conflate relationship_type (to the user) with reports_to/collaborates_with (person↔person) — they answer different questions.
  • Don't write to Sensitive · Human only space via MCP.
  • Don't capture comp, offer, or NDA-related details about a person here — direct the user to Sensitive space for manual entry.
  • Don't set relationship_type to unknown if you can reasonably infer it from context.

Compatibility

  • Requires AnyType Local API key (agent-scoped) injected via env var.
  • Requires the anytype MCP server configured.
  • Local-only network egress.