docs: add a multi-agent coordination guide

[reemsabawi-mystenlabs]

Closes BEDU-1121. Eight builder questions asked how several agents share memory, and no page tied the pieces together.

The gap

Delegates and namespaces are each documented well on their own concept page, but nothing says how they combine. That leaves the reader to infer which one is an identity boundary and which is a visibility boundary, and getting it backwards is expensive: any delegate the account authorizes decrypts everything that account owns, across every namespace. So namespaces organize an account's memory, and they cannot separate users. The guide states that outright, in a warning, rather than leaving it to be deduced from two pages.

What the page covers

• One delegate key per agent. The keys grant identical access, so this is not an access-control boundary. It buys labelling in the dashboard and per-agent revocation.
• Three sharing patterns, as a table: shared namespace, per-agent namespace, and the common case of a shared namespace plus a private one per agent.
• Handoff as a write followed by a recall, with the two properties of recall that change how you write for one: it matches by meaning rather than by key, and it returns whole memories, so each fact needs to stand alone.
• Choosing a boundary, including the case that must not use namespaces: agents serving different users need separate accounts.

Also fixes the concept page it contradicted

A review pass found that fundamentals/concepts/memory-space.md said the opposite of this guide, in the direction that gets people hurt. It called a memory space "the isolated unit of storage" offering "full isolation between users, apps, and deployments", its goal promised namespaces "prevent cross-namespace data leakage", and it closed with "each is fully isolated". A reader arriving there first would conclude namespaces separate users, which is exactly the mistake this guide exists to prevent.

Neither page stated a falsehood; they described different layers. That page's own App ID section already says the vector database scopes queries by owner + namespace while encryption and blob discovery scope by package ID, which is precisely why a delegate reads across namespaces. The isolation language just overstated what that buys you.

Reworded its description, goal, answer, and body to say scoping rather than isolation, and added a warning beside the boundary definition that states the decryption behaviour outright and links here. Fixing it inside this PR rather than filing a follow-up, so the contradiction never ships.

That page also carried twelve pre-existing style gate violations, which surface on push once the file is touched at all: eight em dashes, SEAL for Seal, a future tense, a quoted frontmatter title, and unbolded table headers. Cleared them in a separate commit. They are mechanical and unrelated to the wording change.

Sources

Claim	Source
An account has one owner and any number of delegates; a delegate is a keypair the owner authorizes	docs/fundamentals/concepts/ownership-and-access.md, "Delegates"
Delegate keys are registered onchain and verified on every request	same page, "Access Control Enforcement"
Only the owner and authorized delegates can access the encrypted content	same page, "Ownership"
Namespaces group memories within an account, and one user can hold several	docs/fundamentals/concepts/memory-space.md, "Namespace"
The vector database scopes queries by owner + namespace, while encryption and blob discovery scope by package ID	same page, "App ID" — this is what makes the delegate warning true
MemWal.create fields key, accountId, serverUrl, namespace	MemWalConfig in packages/sdk/src/types.ts
recall({ query, limit })	RecallParams and RecallOptions in the same file
rememberAndWait waits for the background job to complete	packages/sdk/src/memwal.ts, the method and its doc comment
remember returns once the relayer creates the job, with embedding, encryption, upload, and indexing continuing after	docs/sdk/api-reference.md, remember

Prose written fresh. The code samples use only fields and methods verified above.

Verification

Re-run against current dev rather than relying on the original checks, since the branch was 182 commits behind when this pass ran:

• The branch merges cleanly into dev; this push brings it up to date.
• Style gate passes on both changed pages.
• node scripts/check-docs-freshness.mjs passes: docs freshness OK (94 pages, 44 routes, IDs, URLs, versions, limits), which covers the four reference links.
• Every SDK claim above re-checked against packages/sdk/src at current dev, not against the versions current when the page was drafted.

[jessiemongeon1]

Style Guide Audit

All 2 file(s) pass the style guide audit.

[jessiemongeon1]

what is the source of this code?

[jessiemongeon1]

what is the source of this code?