← AiAkiv MemoryCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to AiAkiv Memory
Snapshot Sep 30, 2026 · 23:09 UTC · version 2.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Read a LINKED partner org's memory through the partner memory tools. Use when the user asks what a partner/linked org/team knows, wants to compare their memory with a partner's, mentions a link or partner org, or when a probe candidate carries side=remote. Covers choosing between search_partner_memory, find_partner_memory_connections and query_partner_memory_graph, reading results, and what each error reason means.",
"included_files": [],
"name": "aiakiv-links",
"skill_md_contents": "---\r\nname: aiakiv-links\r\ndescription: >-\r\n Read a LINKED partner org's memory through the partner memory tools. Use when\r\n the user asks what a partner/linked org/team knows, wants to compare their\r\n memory with a partner's, mentions a link or partner org, or when a probe\r\n candidate carries side=remote. Covers choosing between search_partner_memory,\r\n find_partner_memory_connections and query_partner_memory_graph, reading results, and what each error reason\r\n means.\r\n---\r\n\r\n# AiAkiv links (partner-org memory)\r\n\r\nA **link** is a read capability two orgs agreed to — not a project you switch\r\ninto. You pass `link_id` per call; your own scope is untouched. Everything is\r\nread-only: you can never write into a partner org.\r\n\r\n**Always start with `list_partner_links`.** It is local (works even when the\r\npartner is down) and tells you which links are `usable` before you spend a\r\nremote call. If the tools are absent from the tool list, the server has links\r\ndisabled — say so.\r\n\r\n**Call link tools one at a time.** Your org may have only one link call in\r\nflight at once. Two link tools issued in the same batch — the habit that serves\r\nyou well everywhere else — means the second returns `error: busy` without\r\nrunning, even on a completely idle server. Await each call before starting the\r\nnext; `list_partner_links` is local and does not count.\r\n\r\n## Which tool for which question\r\n\r\n| Question shape | Tool |\r\n|---|---|\r\n| \"What does the partner know about X?\" — search THEIR memory directly | `search_partner_memory(sentence, link_id)` — entry happens on their side; results are their events only |\r\n| \"From what WE know, what connects to their side?\" — walk from your context across shared ground | `find_partner_memory_connections` — entry in YOUR org, expansion crosses through **aliased entities** (entities the link declared \"same thing on both sides\") |\r\n| Explicit relations across both orgs (shared entities, vector distance, ranked bridges) | `query_partner_memory_graph(link_id, query, params)` — same language as `query_memory_graph`; see the `aiakiv-graph-query` skill |\r\n| Read one partner event's body | `get_partner_memory_content(link_id, event_id)` — paged; `event_id` comes from the other tools' results |\r\n\r\n## Reading results\r\n\r\n- Partner events carry `side: \"remote\"` (or a `link_id`). **Keep them\r\n labelled as the partner's** when you reason or summarize — do not present\r\n partner knowledge as the user's own, and do not re-save partner content\r\n into the user's memory unless the user explicitly asks.\r\n- `find_partner_memory_connections` never claims something is *absent* on the partner side —\r\n entry is home-only, so the partner is only reached through bridges. Absence\r\n of remote candidates means \"no bridge found\", not \"they don't know\".\r\n- Aliased bridge entities carry `df_home` / `df_remote` (how common the\r\n entity is on each side). Asymmetry is a signal: \"1 here, 109 there\" means a\r\n passing mention for the user is a central topic for the partner — often the\r\n most interesting finding in the response.\r\n- `found: false` from `get_partner_memory_content` means the link does not\r\n surface that event — deliberately the same answer whether it is absent or\r\n out of scope. Don't retry; don't speculate which.\r\n\r\n## When a call returns `status: \"error\"`\r\n\r\nThe `reason` names what to do — an error here **never** means the user's own\r\nmemory failed:\r\n\r\n- `no_links`, `link_not_found`, `link_not_active`, `link_expired`,\r\n `org_not_party`, `principal_not_active` — this link cannot be read (or this\r\n direction is closed). Show `list_partner_links` output; fixing it is an\r\n owner/console action, not a retry.\r\n- `we_are_provider` — the user's org is the *providing* side; there is\r\n nothing to read in this direction. Normal state, not a failure.\r\n- `contract_version_too_old` — both owners must re-consent;\r\n `list_partner_links` → `reconsent` shows who is missing.\r\n- `budget_exceeded` — the remote row/time budget ran out mid-walk. Narrow the\r\n ask (smaller `top_n`/`k`/`LIMIT`, tighter relation params) instead of\r\n repeating it.\r\n- `busy` — a concurrency limit on **your** server (never the partner's). The\r\n `detail` says which of two: the per-org limit, which is almost always\r\n self-inflicted (two link calls issued together) — re-issue the refused one\r\n once the other finishes, it cost nothing and did not run; or the server-wide\r\n limit, shared with other tenants, where a short wait is the right response.\r\n Either way it is not a partner problem.\r\n- `remote_failure`, `internal` — infrastructure failed; try later.\r\n\r\nResults can also be `partial` (budget hit mid-walk): what came back is valid,\r\njust incomplete — say so instead of treating it as the full picture.\r\n"
}SHA-256 of public snapshot: f1647d2f0fa0e0f62db54a2852958bff3478d2ec79c51c7966cdff6f7245bf4f