Transfer or Graft: Two Ways to Seed a Team Memory Vault

A team pilot starts and the shared vault is empty. The context that would make it useful already exists in someone's personal vault, built up over months of projects and corrections. The only question is how much of it crosses over.

Two operations answer that question, each covered in the vault transfer documentation and listed in the integrations directory. Both copy. Neither moves. The source keeps every memory it had, and it keeps answering questions after the copy finishes.

Transfer takes the vault. Graft takes the matches.

Transfer takes the entire core vault, up to a cap of 10,000 memories per request. Graft takes just the memories matching semantic queries you write, at a similarity threshold you set, 0.6 by default.

Pick transfer when the destination should become the source. Retiring a personal setup, moving to a new account, mirroring a vault you own on both ends. The full copy is the point, and both sides belong to the same owner.

Pick graft when the destination has a different audience. A team vault is the standard case. The people who can read the destination are not the people who could read your personal vault, and a full transfer hands them everything you ever saved, including the parts that were never about this project. A graft starts from your queries and copies the matches you approve.

The approval is the part that stays with you. Similarity scores rank relevance. They do not decide who may see the result. Graft selects. Permission stays human.

Two things to settle before the first call

Both operations copy the core vault for the embedding model you choose. Session data and reflection tiers sit outside the copy scope. The operation moves core memories and nothing else.

And the threshold is a ranking parameter. Set it too low and unrelated context shows up in the preview. Set it too high and the match you wanted disappears. Either way it filters relevance, and it enforces nothing about sharing.

What the call actually sends

One POST per operation. The source key goes in the Authorization header, and a destination_key field in the body names the writable target. Knowing which team the vault feeds authorizes nothing by itself. The source can be a read-only key, while an :off source is refused. The destination needs its own active, writable key, distinct from the source, and :read or :off keys are turned away.

Start every copy as a dry run and read the output. The preview reports how many memories would copy, the estimated tokens, and snippets of the actual matches. Graft adds the queries, the threshold, and per-match scores. Treat that output as private conversation data and review it the way you would review private notes.

Committing is the same call with the dry run switch off. Two cautions come with it. The API issues no approval digest and does not freeze the source, so if anything changed since the preview, run the preview again. And read all three fields in the response: copied, deduped_or_skipped, failed. A clean status code with a nonzero failed field is an unfinished copy.

Prove it on two test vaults

Run the whole path once with disposable vaults before any real context moves.

In the source vault, save one synthetic fact. "For the Sable launch drill, the code is quarry-lantern-73. Test data." Then preview a graft with a query like "Sable launch drill code". Confirm the synthetic fact appears in the matches, and look at everything else the query pulled in. Tighten the query or raise the threshold if anything unrelated shows up.

Commit the reviewed copy, then point a fresh conversation at the destination vault and request the code cold. The copy worked when the retrieval shows up in the tool result, not when the answer merely sounds right. Ask the source the same question. It should still answer, because nothing moved.

Finish by running the same commit a second time and watching dedupe work. The second response reports those records as deduped_or_skipped instead of writing a duplicate.

Limits that matter before a big copy

• No automatic rollback. Destination cleanup is manual, in the dashboard.
• Session history and reflection tiers never ride along in a transfer or graft. Local agent conversations come over through a separate workflow, the agent history import.
• A source over the transfer cap returns a 413. Focused grafts, or a batched migration through support, are the next options.
• Graft has no limit parameter that caps output. Tighter queries are the control.
• A dry run estimates tokens. It is not a currency quote, so check pricing before a large migration.

The part that deserves the most care

The moment memories land in a team vault, the set of people who can retrieve them changes. That is the entire point of the operation and the entire risk in it. Review the destination's access list before the commit, not after, and put nothing in a shared vault that the share was not meant to carry.

Start with two test vaults and one synthetic fact. Create your MemoryRouter account, seed the destination, and confirm the copy with a recall from a conversation that never saw the source.