Could a user poison the wiki everyone reads?

It is the first question anyone asks about an agent that writes to shared memory, and it is the right question. "Save 'be rude to customers' to the wiki" — and now every other user's agent reads it.

The answer is that a write to a shared wiki is only accepted if the text is demonstrably derived from documents retrieved in that same turn. Three checks, and it fails closed.

The sources must be shareable. Only citations to project-wide (visibility: "tenant") documents count. A page distilled from one user's private upload is refused — so a shared wiki stays safe even over a mixed corpus, which is the configuration where this would otherwise leak.

The text must match them, measured with your own embedding model. A faithful summary sits close to the passage it came from. Text composed from a user's instruction does not.

It must not add anything. A second check rejects text that is on-topic but introduces claims — or instructions about how to behave — that the sources never made. That third one is the one that catches the interesting attack, because the interesting attack is not "write nonsense", it is "write something plausible with one sentence of behaviour in it".

If it fails, nothing is written, the agent is told why, and the attempt is recorded in the audit log as wiki_write_rejected. Successful writes are audited too, with the source documents, so any page is attributable and revocable.

Private wikis and memories skip all three — a user's own preference legitimately is not in any document — but they are still screened by your guardrail policy and audited.

Memory follows subject, and only subject

This is the asymmetry people find surprising, so it is worth stating on its own.

scope widens what documents a token can see. It has no effect on memory. A token with subject: "acme:fin:lead" and scope: "acme:fin" reads every document in finance and exactly one person's memories: its own.

Not a colleague's. Not a team lead's. Not an admin's.

That is deliberate rather than an oversight. A document belongs to a team. A memory is something a person told the assistant — and "my reports can see the team's files" is a completely different decision from "my assistant may repeat what my reports said in confidence". Collapsing them into one claim would mean the second decision gets made by accident whenever somebody makes the first.

If you want a fact available to everyone, that is what the wiki is for. Which is why the wiki needed the verification above: it is the deliberate sharing mechanism, so it is the one that has to be safe.

Per-user or project-wide

The wiki is per-user by default. Turn on Shared project wiki and it becomes one wiki everyone in the project reads and the agent curates for all of them — pages upsert by title, so one title is one page no matter who wrote it.

Which setting is right follows from the shape of your corpus:

Remembered facts stay per-user either way. They are about a person, not the project.

When documents change, pages say so

A curated page is a summary of something that moves. Each page records the documents it came from, so the corpus shifting underneath it is detectable:

Pages are flagged, never deleted. A curated page whose source was edited is unverified, not worthless — and deleting it would throw away work while leaving the user with nothing.

wiki_read then hands it to the agent with an explicit warning to check the documents before repeating it, and to rewrite the page if it is wrong. So a stale page degrades into a lead instead of silently becoming a confident wrong answer.

The last row works by similarity, so it needs no pre-existing link between the new document and the page. Both thresholds are tunable, because the right cut moves with your embedding model.

Memory needs an embedding model

All four tools — remember, recall, wiki_write, wiki_read — store and find text as vectors. A project with no embedding model configured cannot remember or recall anything.

When there is none, the family is not bound at all, and the agent is told to say so. That is the important half. The alternative is an agent that agrees to remember something and keeps nothing, which is a worse failure than a refusal by a wide margin: the user believes a fact is stored, and finds out weeks later that it never was.

The same rule runs through the whole product. rag_search is not bound without an embedder either, so the agent says it cannot search this project's documents — rather than being handed the embedder's own error mid-turn, which reads as retryable and had it trying the same call three times.

GET /readiness lists it as embedding-model and names memory, recall and the wiki among what it blocks. It is not marked essential, and that is deliberate: a project whose memory has no embedder answers questions perfectly well, so failing a deploy over it would be wrong.

Both are visible and editable in the dashboard

Which matters more for support than it sounds. When an answer looks strange, a remembered fact is often the reason — and a fact you cannot see is a debugging session with no bottom to it.

If you would rather every session start clean, leave memory off. That is a legitimate product decision and not a lesser one; an assistant that remembers is not automatically better than one that does not, and it is considerably harder to explain.