Links: reading another team's memory

AiAkiv's memories are completely separated. Search never turns up the team next door. That's deliberate. Someone else's memories must not leak.

But real work doesn't stop at one memory. You want to pull an idea from your personal memory into a company project; a head office and a partner firm serve the same customer; a consultant can't bring accumulated case knowledge into a client. You know the answer is over there and there's no way to reach it. That's what a link solves.

In one line. Two memories are joined by entity aliases. The link is one-directional, and when memory content changes the aliases have to be updated too.

What a link is

One line of read permission that two teams agreed to. It has three properties.

• No copy is made. You aren't handed the data; you look at it live. Changes to the original show immediately, and cutting the link makes it disappear.
• It doesn't touch where you save. It isn't a project switch. You name the link when calling a tool and read only the other side. Saying ak save this in that conversation goes into your Main as usual.
• It's one-directional. Accepting means you read them, not that your memory opens to them. To open the other way, make a second link.

How this differs from importing

Linking to public memory is worth doing too

Public memory is readable by anyone already. But being able to read something and having it come up in your questions are different things. If it isn't tied to your memory, it won't surface when you ask. That's why making a link to a public memory and connecting aliases is worthwhile.

Making and managing links in the console

Console → Teams → Links. The screen is visible only to the team owner: opening memory outward isn't something to view alongside internal permissions.

The list is split into two groups. The two kinds are opposites, and mixed together they look like the same thing with a different status.

• Links we read through — we read the other team's memory. Five columns: partner team · status · contract · readable now · expiry. These are what the tools use during a conversation.
• Links we provide — the link opens our memory to the other team. There is nothing here for us to read, so there is no readable now column at all. Pausing, ending and aliases are done here.

Either way, pressing Details opens two tabs, Details and Aliases.

Making one: propose and accept

One side issues an invitation and the other side's owner accepts, which brings it to life. The acceptance dialog states the direction plainly.

Accepting means we will read ○○ team's memories. This is one-directional: our memories do not open to them. For them to read ours, we must issue an invitation.

Declining closes that proposal. Making one again requires a new proposal.

Cutting it: one side acting alone

Pausing cuts even a read in progress, immediately. And only the team that paused it can resume.

Making it takes agreement from both; cutting it takes one. Deliberately. If cutting required agreement, you'd be trapped whenever the other side stopped responding.

The Details tab: five conditions for reading now

Reading works only when all five hold. The screen shows them as a checklist.

If even one is off, the tools are blocked. It's the same determination as the readable now column, so start here when reading doesn't work. When re-consent is needed, it also shows which side (ours or theirs) hasn't done it.

A link we provide shows only four. The heading becomes What has to hold for the other team to read and the last row (This direction is open) drops out — that row is about the direction we read in, so a healthy link would carry a red mark. The real direction is right below, under Read direction.

The display name is a record from contract time. If the partner team renames itself afterwards, it isn't reflected. The generation number on screen means how many times this link has been established.

When and how the contract changed is in Teams → Link history. Who made, changed, and cut it is recorded for both sides: it makes no sense for your access to be cut without the affected party being able to see it.

Aliases: this is the crux

An alias is a path (but not a path for permissions)

The two teams' entities live in different id spaces. When your memory and theirs call the same thing by different names, a person knows they're the same and the system doesn't.

An alias is the bridge that joins the two as "the same thing." Traversal steps on that bridge to move between the two entities.

the name in our memory   ←── same thing ──→   the name in theirs

The most common misunderstanding here: an alias is not permission. A linked team's memories are already readable regardless of aliases. The table below is that boundary.

So with zero aliases you can still find things on their side. The bridge is needed for starting in your memory, crossing over, and coming back: and that's where a link's real value is.

What to connect and what to cut

The Aliases tab lists ours ↔ theirs pairs one after another. They come from automatic discovery and manual assignment.

• If it's the same name but a different thing, cut it with Exclude. A wrong connection creates a false link between two memories, and once that gets into answers it's hard to find later.
• If you cut one by mistake, use Reconnect; to defer the judgment, send it back to Candidate.

The system finds candidates, but the final call is a person's. A similar name doesn't mean the same thing.

⚠ Re-connect after saving new content

Bridges do not maintain themselves.

• Newly created entities are not connected automatically. After saving, press Connect same names again in the Aliases tab. It reports Connected M of N same-name pairs. If the result says it was truncated, run it again and it continues from there.
• Merging an entity kills the bridge. If an endpoint entity is absorbed by a merge, that alias becomes broken and stops working. Nobody cut it.

So re-connecting periodically is a good habit. If the link is alive but only your cross-traversal results have gone thin, this is almost certainly why.

Actually reading: five tools

Reading is done by tools during a conversation, not by a screen. The console is where you make, cut, and tune aliases.

list_partner_links                     which links exist and which work now (usable)
  ├ search_partner_memory(sentence, link_id)   search the partner memory directly
  ├ find_partner_memory_connections(link_id, sentence)    start in your memory, cross the bridge
  ├ query_partner_memory_graph(link_id, query) a graph query spanning both teams
  └ get_partner_memory_content           read a partner record's body

Start with list_partner_links. usable tells you which links will produce an answer right now, and for those that won't, blocked_reason points at what to fix.

Links we provide are not in this list at all. Links are one-directional, so the side that issued the invitation has nothing to read — and nothing to fix. Only the count comes back, as provided_link_count; they are managed in the console's Links we provide group. Passing one of their ids to a tool anyway is refused with principal_not_active.

What cross-traversal tells you

find_partner_memory_connections marks each result with which side it came from (side), and loads each bridge with how common the term is on each side. "1 on our side, 109 on theirs" means what's a passing mention to you is a central topic to them. That number can be the answer by itself.

Entry happens only from your side, so nothing coming back from their side doesn't mean "there's nothing there." It may be that there was no bridge to cross.

What doesn't work · things to know

• You cannot save through a link. A link is a reading capability.
• Cutting takes effect immediately: even mid-read. If a link is terminated while reading, it stops with an explicit error, not a truncated answer. You never receive a half answer.
• It can't stop what the reader remembers. You can't stop the other side from copying what they saw on screen into their own notes. What a link prevents is the system copying everything wholesale, not what's in someone's head. So who you link with is still a question of trust.
• Treat their results as theirs. When an AI mixes both memories in an answer, it's hard to retrace later unless which side each statement came from is kept distinct.

Scenario: a consultant and a client

Consultant A goes into client B. B decides to open their memory to A for three months.

1. Making it: B's owner issues an invitation to A, and A's owner accepts. Direction is B→A only; term is three months.
2. Connecting aliases: A presses Connect same names in the Aliases tab. When B's "payments module" and A's "payment gateway" come up as candidates, a person confirms and connects them, and Excludes anything that only shares a name.
3. Checking: A checks usable with list_partner_links.
4. Using it. A asks: "Retry policy for the payments module: have we done something similar before?" Traversal starts in A's memory, picks up the older case, crosses the "payment gateway" bridge, and brings back B's payment issues. Next to the bridge it reads ours 2 / theirs 87: a topic that came up twice for A is a central topic for B.
5. Reading bodies: the partner-side results open with get_partner_memory_content. Throughout, A's save target is unchanged, so writing it up with ak save this goes into A's Main.
6. The end: after three months it closes automatically. Before that, B can cut it alone.

Related

• Teams, projects, and the save target → Teams and projects
• Dividing visibility inside one team (sub-parts and roles) → Creating and managing teams
• The console menus overall → Console
• What you may store → What to store