Leonardo Brain
We are building this one for ourselves first: a wiki that a working agent feeds and queries, so that the knowledge a session produces accumulates instead of evaporating when the window closes.
It is a work in progress and we say so. What is in scope today is the shape of the thing — a wiki as the store of record, an agent that can write to it and read back from it, and the discipline of leaving something behind. What is not claimed is production readiness, broad availability, or fitness for anybody else's workflow.
The problem
Agent sessions are disposable. You explain the context, you get a useful answer, and the thread is gone; the next session starts from near zero. A research group has the opposite problem with the same shape: a corpus of a hundred thousand files that only a few people can navigate, and a great deal of knowledge living in chat transcripts and half-finished notes. Both are the same failure — work that is not written down where it can be found again.
The wrong turns
We started by pointing the index at everything, because the corpus was already there and a wide scope looked free. It is not free: browser exports and saved pages contribute hundreds of files of markup and script, and one presentation file can enter the index as an enormous text blob, so a tidy-looking "2,400 documents embedded" turned out to be a mixture largely composed of rubbish. The first guard we wrote was a list of file extensions to ignore, which is a suffix filter and catches neither an extensionless file nor a folder of exports whose artefacts have no extension at all.
What worked
A wiki as the store of record, an agent that can both write into it and ask it questions, and a habit of writing things down while the work is happening rather than after it. Three ordered passes — catalogue the corpus, compile the wiki, embed the text — with each embedding scope writing to its own output root, so a later scope cannot damage an earlier result. Judge an embedding by the mix of what it contains, never by its document count, and let one deterministic pass be the only writer of the compiled pages. That last rule is what keeps a wiki trustworthy: several authors may contribute, but exactly one process folds what they contributed into the pages people read.
What it costs
Embedding a real corpus is hours of work on somebody else's hardware, and the run is unsupervised — nothing restarts it, so a reboot ends it silently and a partial result looks like a plain result. Somebody has to be awake for the long parts, and somebody has to decide what does not belong in the index before it is built, because removing it afterwards is slower and never quite complete.
What it would look like for a client
A corpus that answers questions with citations, an agent that can add to it while it works, and the whole thing behind the team's own credentials rather than ours. The parts worth copying are the boring ones: one writer for the compiled pages, scoped and measured ingestion, and a written record of what the machine decided and why.