Retrieve a bounded neighborhood of this team's reviewed, approved memory around a topic. Call this once at the start of a session, before starting work, so you inherit what teammates already learned instead of rediscovering it. anchor is the topic/title to search around (e.g. "Postgres connection pool exhaustion"); hops bounds how far the traversal spreads from it (default 2); hub_cutoff stops traversal through overly-connected "hub" nodes so one popular node doesn't pull in the whole graph. Returns a neighborhood list of memory nodes plus approx_tokens, what folding them into context would actually cost.

Preview what retrieve_context WOULD return, without paying for the bodies. Same traversal, same nodes, but each entry is just id, title, tier, tags and approx_tokens - what reading that one node would cost. Follow up with fetch_nodes(ids) for the ones worth reading.

Prefer this over retrieve_context when the topic is broad, when you only need one specific thing from a wide neighborhood, or when retrieve_context's approx_tokens came back larger than you want to spend. Prefer retrieve_context when the neighborhood is small or you intend to read most of it - two round trips to save a few hundred tokens is a worse deal than one round trip.

tags optionally narrows to nodes carrying any of them; the reserved ones are "decision", "bugfix", "security_alert" and "sensitive".

Fetch the full bodies of specific memory nodes by id, after retrieve_index showed you which ones are worth reading. Pass every id you want in ONE call rather than one call per id.

Ids you are not entitled to - a node still pending review, one that was rejected, or one belonging to another team - come back in missing rather than as an error. That is the review gate working, not a failure to retry.

What this team keeps searching for and never finds.

Worth calling at the START of a session, next to retrieve_context. If the thing you are about to work on appears here, the team has looked for it repeatedly and come back empty every time - which makes your log_session at the end of this session the fix for a standing gap rather than one more note.

Each entry carries a miss count. awaiting_review: true means something already written WOULD have answered it and is sitting unapproved, so the fix there is a human clearing the review queue, not you writing it again - don't duplicate it.

Read-only. This proposes nothing and changes nothing.

Log what happened this session as a memory node for the team to reuse. Call this once at the end of a session that learned something worth keeping - a root cause, a fix, a decision, a gotcha. The node starts PENDING and is invisible to retrieve_context until an admin approves it (or it matches an auto-approve rule) - this is a deliberate review gate, not a bug. title is a short, searchable summary (this is what future retrieve_context anchors match against); body is the actual content; tags and links are optional and help retrieval and review. agent_id/task_id are optional ids from create_agent/create_task - attaching them lets an admin auto-approve by agent (see create_auto_approve_rule, admin-only) and lets future retrieval be scoped to a task.

Register an agent identity with the team, so logged sessions can be attributed to it (pass the returned id as log_session's agent_id) and so an admin can target it with an auto-approve rule. name is how it shows up in the review UI; description and system_prompt are optional context for reviewers.

List the agent identities already registered with this team, e.g. to find an existing agent's id instead of creating a duplicate with create_agent.

Register a task with the team, so logged sessions can be scoped to it (pass the returned id as log_session's task_id) - useful when several sessions across one piece of work should be filterable together later. name is how it shows up in the review UI; description is optional context.

List the tasks already registered with this team, e.g. to find an existing task's id instead of creating a duplicate with create_task.