Continuing to Ride the Karpathy Wave

[well-noted]

Serendipitously, @jeremyruston’s post about the Karpathy-style LLM Wiki coincided with work that I was doing along the same line, but with MultiWikiServer (MWS). I thought it might be helpful to document my experience with the LLM-Wiki over the coming weeks, by posting updates and weekly snapshots of the “Second Brain.”

Week 1: https://secondbrain-week1.tiddlyhost.com

My Setup: MCP server connected to Claude Desktop and pointed at my MWS server.

Rather than designing this demo page, I decided to focus on actually using it as a second brain database and let the Wiki design the guided tour itself:

Claude’s training makes it want to be transparent about what it is and it chose and wrote the Guided Path with talk.tiddlywiki as context.

You’ll see it is calling its environment “NoteStreams” – that’s because it thinks it’s in my primary wiki.

Instead I have it partitioned in a set of agent-enabled bags in my MWS setup, which I view through a “Wiki-Live-View” Recipe.

_____________________________________________________________________________

As part of the experiment I’ll be letting Claude manage updating the technical documentation in the wiki itself:

As you can see in the above example, the agent is first checking the knowledge base and identifying an already existing walkthrough – then updating that with the new information.

You can see in the above that the wiki has generated a wealth of logs for itself that it can access via regular or vector search.

Since I have recently finished Before the Dawn by Toson Shimazaki , it was natural to pull in all my extracted notes and begin having conversations about my reflections (please don’t judge my bad interpretations of this work if you’re familiar with it)

This book is quite long, about 1300 pages and I acquired over 100 quotes from the novel while reading it – so this has been especially useful not only for reflection but for finding quotes that support or contradict my observations. I think this could be especially useful for building out and strengthening academic arguments, but I would recommend especially strict guardrails so the agent doesn’t delude itself into seeing connections that aren’t really there.

_____________________________________________________________________________

[JanJo]

Karpathy's LLM Wiki - Full Beginner Setup Guide

Thank you @well-noted Here is a short introductory video to illuminate the concept for the tl’dr s featuring - TW’s opponent obsidian.

[well-noted]

One thing I expected MWS to make easy — and that I’ve found surprisingly frustrating — is routing tiddlers into specific bags. The bag architecture is perfect for a layered second brain:

system configuration in one bag,
curated knowledge in another,
agent logs in a third.

But MWS only exposes bag selection at the recipe level: when you write a tiddler, it goes into the topmost writable bag of whichever recipe you’re writing to. There’s no way to say “create this tiddler in bag X directly.”

To work around this, I’ve built five single-bag write recipes, one per destination bag ,so that writing to a given recipe unambiguously targets the right bag. A sixth recipe then composes all five bags into a unified wiki for browsing.

This works, but it pushes the routing problem up a layer: now my AI agents need to know which of the five write recipes to use for each tiddler they produce. Without explicit, enforced routing rules, tiddlers land in the wrong bag, and because MWS also has no move operation, fixing a misplaced tiddler requires writing it to the correct recipe and manually deleting the original — there’s no atomic relocate.

The missing piece that would eliminate most of this friction is bag-addressed writes: a way to specify the target bag directly in the write request, independent of which recipe is being used.

Combined with a move/rename endpoint that can relocate a tiddler between bags atomically, this would make the bag architecture actually usable for programmatic, multi-agent workflows without having to use workarounds.

Has there been any decisive word from @Arlen22 as to whether target-bag writing and moving tiddlers between bags is coming to MWS in the future?

[well-noted]

Week 2 update

Second Brain

After playing around with this for a week, I’m beginning to worry that having an agent maintain a huge wiki full of tiddlers as a knowledge base may be a fad that could go out of style now that we’re leaving the token-maxxing era. I’m beginning to wonder if smaller, more focused wikis might be more sustainable… further experimentation may reveal.

Specifically, running “Dream Cycles” which were originally intended to merge/promote/review tiddlers to keep the contents trim are getting expensive, even when using lighter models. As such I’ve been rethinking the role of the dream cycle, and experimenting with connecting local models to the MCP server, not as a replacement for, but as a supplement to, the work I’ve already done with the Claude platform.

_____________________________________________________________________________

I added a fun little asset_upload tool to the MCP server that allows the agent to upload files directly to my server and link them in the wiki via canonical_uri. It can also handle creation of SVGs, allowing me to perform the famous “Pelican riding a bicycle” test. Here you can see the attempt by google’s Gemma4 model:

_____________________________________________________________________________

Surprisingly, I found no Android application that acted as a harness to connect local agents to an MCP server (Claude also doesn’t seem to allow this in their mobile app, for whatever reason). As a result, I had to build one.

OnGrid discovers Ollama servers on your local Wi-Fi network, lets you chat with any model they expose, and wires those models up to Model Context Protocol (MCP) tool servers.

As you can see above, I’ve chosen an Agentic paradigm for this app, rather than a purely conversational one. While OnGrid technically supports 3 modes (conversations, projects, agents), I think that the agentic model is better suited both to mobile and to local agents because a), local agents take longer (on average) to respond and b), mobile environments are already set up for asynchronous communication. Therefore, when in Agent mode, the user can assign models to different “agent personas” which they can message as if on a messaging platform, and which fetches the reply in the background.

With this I might create, for example, an “Archivist” personality, which is instructed to extract the information from any URL it’s sent and apply that to my very strict data structure for Source tiddlers:

I’ve also begun some very early experiments in Multi-Agent-Coordination, and we’ll see if that has any useful application in the wiki:

Given my concerns that a single source-of-truth wiki might be cumbersome, a multi-agent approach with multiple wikis might ultimately produce better results.

I don’t want to turn this into an advertisement for the app, but feel free to check the github page for more information.

_____________________________________________________________________________

Despite my continued dissatisfaction with the human navigability of the wiki (sorry about that), I am finding that, with the right orientation, even these relatively small models (gemma4:e4b in the case of Daemon, for example) are quite capable of making use of it as a knowledge repository – and it allows for an agent-agnostic bridge for all the different platforms I use (that have access to my MCP server).

This has me re-evaluating some of my initial assumptions about how a system like this should be built. Initially I thought a nightly dream cycle would correct for mistakes that were generated during a days work. Instead I’ve found that the unsupervised time is the least productive part of the cycle, whereas the supervised time of the Live agent tends to produce highly structured responses.

It also has me rethinking how I should approach knowledge documentation and accumulation in general – and I hope that I can gain some further insight into that as we move forward.