First of all, this is more than just note taking. It appears to be a (yet another) harness for coordinating work between agents with minimal human intervention. And as such, shouldn’t part of the point be to not have to build that mental model yourself, but rather offload it to the shared LLM “brain”?

Highly debatable whether it’s possible to create anything truly valuable (valuable for the owner of the product that is) with this approach, though. I’m not convinced that it will ever be possible to create valuable products from just a prompt and an agent harness. At that point, the product itself can be (re)created by anyone, product development has been commodified, and the only thing of value is tokens.

My hypothesis is that “do things that don’t scale”[0] will still apply well into the future, but the “things that don’t scale” will change.

All that said, I’ve finally started using Obsidian after setting up some skills for note taking, researching, linking, splitting, and restructuring the knowledge base. I’ve never been able to spend time on keeping it structured, but I now have a digital secretary that can do all of the work I’m too lazy to do. I can just jot down random thoughts and ideas, and the agent helps me structure it, ask follow-up questions, relate it to other ongoing work, and so on. I’m still putting in the work of reading sources and building a mental model, but I’m also getting high-quality notes almost for free.

[0]: https://www.paulgraham.com/ds.html

I think there‘s a serious issue with people using AI to do an immense amount of busywork and then never look at it again. Colossal waste.

The few scientific studies out there actually show a degradation of output quality when these markdown collections are fully LLM maintained (opposed to an increase when they’re human maintained), which I found fascinating.

I think the sweet spot is human curation of these documents, but unsupervised management is never the answer, especially if you don’t consciously think about debt / drift in these.

Totally agree re note taking. We treat our notes way too lightly, just as an attic or a basement leads to hoarding more stuff than you'll ever need.

Most things do not need to end up in your notes, and LLMs add too much noise, one that you likely never personally verify/filter out at all.

JA Westenberg made a good video essay about it a few days ago:

https://youtube.com/watch?v=3E00ZNdFbEk

I thought this was parody at first as well for a redundant useless product as it was named after the redundant useless product of the same name from The Office (Wuphf.com)

Ditto.

It circles back to the question, is this unimportant enough for me to delegate it to a LLM that might get it wrong? If the answer is yes, why even do it to begin with. If the answer is no, you have to do it manually.

I personally though, see value in this type of automation. Stuff like tag categorization, indexing, that otherwise would've been lost seems like a good fit for LLMs. Whether or not they're an ideal solution and something else like a search engine would've been a better fit, is a different question.

I use my Openclaw setup to record notes I don't ever want to remember the details of. Here are some examples:

Storing my Health Insurance's Member ID, RxBin and other data. Recording the serial number of a product I will be calling technical support for. Organizing files to be more logical and deduplicating or consolidating as needed.

Whenever I want this info, I'll just ask my LLM to pull it up.

i've been running a variation of the _llm writes a wiki_ since late february. i run it on a sprite (sprites.dev from fly.io), it's public but i don't particularly advertise it. i completely vibe coded the shit out of it with claude. the app side and the content. the app side makes the content accessible to other agent instances, lists some documents at the root, provides search function, and let's me read it on a browser with nice typography if i want to, as opposed to raw markdown.

it's neat, i can create a new sprite/whatever, point claude at the root, and tell it to setup zswap and it will know exactly how to do so in that environment. if something changes, and there's some fiddling to make it work, i can ask it to write a report and send it in to fold into the existing docs.

Man, there's no point in replying. You are argueing with a non-human therefore the conversation is without meaning and impact and thus a waste of time and energy.

been thinking the same, but I imagine you could explicitly separate notes and slop, eg something as simple as cron job that goes through all your notes and creates a PR if there's some easy win: typos, inconsistencies, tags, etc

I've been coding like this lately: if I'm too lazy to review a new non-critical section/unit tests, I'll mark it as `// SLOP`; later, if I have to, I'll go through the entire thing, and unmark

shitty tests are better than no tests, as long as you your expectations are low enough

Then you have never worked at a large enough codebase or across enough many projects?

Just like NFTs, just like the blockchain before that, in some ways kind of like the Web 2.0 craze (though we at least built some things then and the tight financing at the time kept a lid on it).

This LLM stuff at least has some real possibilities and value, and is very fun tech to learn about and play with.

I long ago accepted that there’s money to be made, as long as it’s not unethical, then get involved. Can build cool things that do have value, while enjoying the VC/PE money sloshing around

Hey man, if it works it works. There's a reason everyone is creating AI tools. We're all buying them. I'm still waiting for someone to make a world-class cli harness that can replace Claude Code but solves the memory and design problem. Web design is still a nightmare with LLMs.

alright sir/ma'am/neither. we built an AI-native CRM backed by HubSpot founder Dharmesh Shah last year before this, had revenue, iterated to focus on context graph infra which looked like the right moat to focus on, did enterprise PoCs, and all of that distilled into this personal project i built on the side to help my own work. turned out to be right interface for making context infra usable.

not interested in a job at Anthropic as Principal Engineer (i used to be a HubSpot Product Manager with a healthy income, much better than what i am making now, or for the next few years).

took multiple bets and did iterations because we talked to customers and kept evolving while our old competition is still building an AI CRM "in stealth".

been around enough to know waves don't matter but there is still value behind those waves worth extracting away.

Your notes look really interesting, thanks. I'm curious --from the prose style it's clear they were written by an LLM. For design notes like this do you sort of have a mental TODO to go back and write them up in your own words to make sure they really capture your own opinions?

love the "Borrowable Ideas" section. would suggest to definitely borrow them.

full disclosure: we started as a context infra company (nex.ai) from long long before Karpathy even came up with the LLM wiki idea, and have barely exposed any of that stuff to WUPHF but starting to open some of that now. glad to see the concerns in the comparison are things that our context infra already built for.

still, happy to collab & share learnings, and of course avoid duplication.

yes, generative slot machines are isolating. You say you "wish there was a chance"? As if there isn't?

taking a look :)

I mean honestly this stuff is now in roll your own territory now. Run QMD on an obsidian vault and that's like 80% of the way there and you can probably do that in < 2 hours

(Disclosure: I originally created TiddlyWiki.)

For the single-file configuration you describe, there are already several LLM connectors — e.g. [1]. The appeal is exactly what you note: no dependencies, no installation, trivially archivable. A single-file agentic wiki wandering around and self-editing isfeasible today.

For something closer to Karpathy's LLM Wiki pattern, I've been working on twillm[2], which uses TiddlyWiki's Node.js configuration. That setup saves tiddlers as individual files, so you can point it at an existing Markdown vault and work alongside tools like Claude Code.

Some benefits of TiddlyWiki for this:

* Open source, so you can be confident it'll remain usable indefinitely.

* Web-based, so accessible anywhere.

* Computed views replace materialised index files. Karpathy's setup relies on an index.md that the LLM has to keep in sync as it adds notes — something LLMs are bad at, with staleness creeping in across sessions. TiddlyWiki views are live filter expressions: "tiddlers tagged concept, sorted by rating" computes its contents at render time.

* Frontmatter becomes queryable structure. Obsidian renders YAML frontmatter as boxed metadata at the top of a note. TiddlyWiki promotes frontmatter fields into first-class tiddler fields you can filter, sort, and aggregate over.

* LLM-authored applets, not just content. Beyond Markdown notes, the LLM can drop in wikitext tiddlers (.tid) that act as small interactive live views: dashboards, browse-by-tag tools, journal indexes, glossary pages.

[1] https://github.com/rimir-cc/tw-llm-connect [2] https://github.com/Jermolene/twillm

It’s also that agents and ML reach local maximima unless external feedback is given. So your wiki will reach a state and get stuck there.

Re classifier routing: text-shape signals (token count, syntactic markers) underspecify the boundary, especially for agent-generated queries. The signal that worked better in our policy-gated tool-call setting was the surrounding intent context the agent was operating under, not the query string itself. An agent in a "fact-check" context emits long, well-formed sentences that actually want exact-match retrieval; an agent in an "open research" context emits surprisingly short queries that need narrative retrieval. If the runtime can read the tool or skill context at query time, routing on that is less ambiguous than text shape. Doesn't help if the wiki is a black-box MCP server with no caller-side context, but it's worth offering an optional context hint in the lookup payload.

I read the durability thing as markdown files are very open, easy to find software for, simple and are widely used. All of this together almost guarantees that they will he viewable/usable in the far future.

I'm interested. At a glance this sounds a lot like Hurl[0]. What's the difference?

[0] https://hurl.dev/

i wanted to take a picture of my PDR - Physician's Desk Reference tomes, but i gave them to my wife to use at work. But, the publisher stopped publishing the PDR on paper and went to "app-only" and requires payment, now. Used to be you could go to those library "used book sales" or university used library book sales and get ones a couple years out of date.

but no longer.

I didn't even have to look at the (reddit op linked) site or an archive to know that it was going to be wrong, dangerous, a liability, and bordering on unethical.

do you want to pollute the context with blurbs for docs in disparate topics? cascade filtering, even with naïve bm25, helps reduce the amount of _noise_ that's pushed into the context window. if we reduce the amount of results to consider, further filtering or reranking, with more expensive options, becomes realistic. one could even put a cheaper model in front to further clean the results.

Hey, contributor to Wuphf here,

Right now this is setup to be run on your machine. Git is used to do versioning but we don't push that to GitHub, nor do we keep any insight into what you have or what you're doing.

If there is long term value people are getting out of Wuphf we'll be happy to build out a hosted business/enterprise compliant version.

supported via OpenCode, which is the runtime that speaks the OpenAI-compatible surface. DeepSeek exposes that surface, so the path is: point OpenCode at the DeepSeek base URL and key, then set OpenCode as your synthesis or runtime CLI in the WUPHF config.

can also do llama.cpp server, LM Studio, LocalAI, OpenRouter, Together, Anyscale, and anything else with the OpenAI surface. i am using ollama already through OpenCode.

if you hit a specific endpoint that does not work, please file an issue.

yes, and we should expose it. today the wiki location is hardcoded to ~/.wuphf/wiki/. making it a config field is a quick change. just filed an issue: https://github.com/nex-crm/wuphf/issues/310

karpathy's llm wiki tweet and gist: https://x.com/karpathy/status/2040470801506541998?s=20

i used this idea to create a version that works for a team of ai agents

Nice

had fun while building this and love "The Office". fwiw i used to be a stand up comic and did lots of satire, but this one is not a shell/slop project to take on the craziness of slop agents being shipped as world-changing (while all they did was asked AI to write smart md files).

there is real substance in the product itself and something that i use myself for work. feel free to ask any questions.

fair. the post title leads with the wiki because the Karpathy framing is the angle i think this audience cares about, but the wiki ships as part of WUPHF (an open source collaborative office for AI agents) and the repo README naturally leads with the broader product. i should have surfaced "ships as part of WUPHF" earlier in the post body.

if you want the wiki only, install WUPHF and only use the wiki layer. the promotion flow, fact log, and /lookup work without the multi-agent office around them.

Feels like disliking musician for fanaticism towards musical instruments.

I have the same feeling ever since his infamous LLM OS post

Probably just envy.

Even though I did not know about Andrej Karpathy's tweet from earlier this month, I ended up converging on something very similar.

A couple of weeks ago I built a git-based knowledge base designed to run agents prompts on top of it.

I connected our company's ticketing system, wiki, GitHub, jenkins, etc, and spent several hours effectively "onboarding" the AI (I used Claude Opus 4.6). I explained where to find company policies, how developers work, how the build system operates, and how different projects relate to each other.

In practice, I treated it like onboarding a new engineer: I fed it a lot of context and had it organize everything into AI-friendly documentation (including an AGENTS.md). I barely wrote anything myself, mostly I just instructed the AI to write and update the files, while I guided the overall structure and refactored as needed.

The result was a git-based knowledge base that agents could operate on directly. Since the agent had access to multiple parts of the company, I could give high-level prompts like: investigate this bug (with not much context), produce a root cause analysis, open a ticket, fix it, and verify a build on Jenkins. I did not even need to have the repos locally, the AI would figure it out, clone them, analyze, create branches using our company policy, etc...

For me, this ended up working as a multi-project coordination layer across the company, and it worked much better than I expected.

It wasn't all smooth, though. When the AI failed at a task, I had to step in, provide more context, and let it update the documentation itself. But through incremental iterations, each failure improved the system, and its capabilities compounded very quickly.

I remember the personal wiki was a bit of trend 5 years ago but it kind of died because it had an unclear purpose for the most part. I kept one but never really referred to any of the notes and then just went back to a paper and to do list. I’m sure this is useful for those who kept up the habit.

Hey, contributor to Wuphf here,

We have been using it as a sounding board. I think that in its current state it's actually more useful for someone to learn about how to run a business - "what does a CEO vs PM do" and/or learn about the pros/cons of running a bunch of agents at once.

let's talk about real stuff. we built an AI-native CRM backed by HubSpot founder Dharmesh Shah last year before this, had revenue, iterated to focus on context graph infra which looked like the right moat to focus on, did enterprise PoCs, and all of that distilled into this personal project i built on the side to help my own work. turned out to be right interface for making context infra usable.

the team is of 4 HubSpotters who built HubSpot's largest platforms - search, nav, notifs, permissions, AI.

we are in the process of opening up large pieces of our enterprise context architecture to WUPHF and also ship the cloud enterprise version of WUPHF (https://nex.ai/new-home).

+100 for this comment.

The problem with your comment is that the word "real" is just there to move the goalposts. There are people building high-quality stuff like this, yes.

I built a tiny utility like this that works very well yesterday:

https://github.com/skorokithakis/gnosis

Two structural reasons. 1. Obsidian is a single-user editor. It does not have the concept of "agent A drafted this, agent B promoted it, the team approved it." The promotion flow needs a state machine that lives outside the editor. a plugin can simulate it but the source-of-truth has to be a process the agents talk to instead of a vault file. 2. Agents need an MCP surface. An Obsidian plugin API won't do. /lookup, entity_fact_record, notebook_write, and team_wiki_promote are MCP tools the agent runtimes call directly. Obsidian's plugin API targets human users and the Electron app. You would be reimplementing the MCP layer to bridge. Practical compatibility: you can absolutely point Obsidian at ~/.wuphf/wiki/ and use it as a vault (we got someone from our Reddit post do this). Obsidian can be reader while WUPHF stays the writer.

He presumably wanted the result to be good.

what plugin are you using?

srsly tho this looks slick & love the office refs / will go play with it :)