Competitive Intelligence with Karpathy's LLM Wiki Pattern

A few months ago I started working with Obsidian and Claude Code, treating the pair like an intelligent notes app. I had tried versions of this before. Over the years I started a few personal knowledge bases, good initial momentum but after a while things got complicated. The maintenance always outran the value: every new note was one more thing to file, link, and eventually forget, and the pile got heavier instead of smarter.

What changed was Karpathy’s LLM Wiki pattern. The idea is simple: instead of a pile of notes you maintain by hand, an agent maintains and interlinks the knowledge for you. Each new source gets read, dated, filed, and connected to what is already there. The base compounds (every source makes the whole more valuable) and self-improves, rather than decaying into files you wrote once and never reopened.

That is the part that made one finally stick. I use it actively now, and I have started expanding it beyond personal notes. Competitive intelligence was a natural next candidate.

I have done competitive intelligence on and off for years, with no formal background and always in a hacky way: a folder of links, a doc that was stale a week after I wrote it. Lately I do it actively for the space I am building, and it has been genuinely useful. The wiki pattern fit it unreasonably well, because competitive intelligence is mostly bookkeeping, the exact work I keep abandoning: dating claims, noticing when new data contradicts old, never letting a guess drift loose from the fact under it.

I did not want to write about my own competitors, for the obvious reasons. So I picked a category I have no stake in but enough exposure to judge: AI-native accounting and ERP. At a previous startup we had weighed Rillet against QuickBooks, so I knew the shape of the problem from the outside.

What I built

The wiki is a pipeline more than a folder. Raw sources come in at the bottom (websites, job feeds, reviews, podcasts). The agent turns each one into a cited summary, pulls dated signals out of those summaries, rolls the signals up into per-vendor hubs, and stacks cross-vendor analyses on top. Obsidian is the substrate, Claude Code (or any comparable agent harness) is the maintainer, and a few small scripts handle the mechanical parts. The rule that holds it together is provenance: every claim links back to a source, every link carries a date, and an inference can never quietly pass itself off as a fact.

This is not a copy-paste rig. Like Karpathy, I am sharing an adjusted idea file rather than my exact setup, because the value is in the decisions, not in my particular folder names.

The easiest way to see what “compounding” means is to look at the shape of the thing.

The graph covers five vendors, with six source types each: marketing sites, job postings, review sites, funding and press, founder podcasts, and product docs. 526 nodes, 1,916 links, no orphans.

What it surfaced

Read across all five vendors and a pattern shows up: the category is converging on the same foundations and differentiating on a few deliberate bets. Three of those bets are worth showing.

The first is who they sell to and how. Everyone is climbing up-market, away from the small-business base, but only Puzzle runs an embedded, partner-led motion instead of selling direct. Plot the five by customer tier and go-to-market, and one quadrant sits empty.

The second bet shows up in hiring, where the signal is densest. A job board shows the bets a vendor has actually funded, not the ones on its marketing site. The open-roles mix tracks maturity almost cleanly. Campfire and Puzzle are hiring roughly six or seven customer-facing roles (sales, success, and support) for every research-and-engineering role, which is what scaling a finished product looks like. DualEntry, Rillet, and Light sit closer to one-to-one, still building. The percentages are approximate (one snapshot per vendor, and role categories blur at the edges), so trust the direction, not the exact number. The sharper signal is the first-of-a-kind roles, where strategy leaks before any press release: an EMEA office, a compliance and IPO-readiness engineering team, a payments-rails engineer, a vendor’s first dedicated support hire.

The third bet is who they are fighting. QuickBooks is the common enemy, the incumbent almost everyone is positioned to pull customers off. NetSuite is the up-market version of the same story. Light, the European entrant, fights an entirely different incumbent set: the Nordic books, E-conomic, Dinero, and Fortnox, names the American vendors never mention.

A few things did not need a chart. “AI-native,” for one, turns out to mean four different things under the hood: an in-house model, orchestration over frontier APIs, deterministic agents, or managed APIs stitched together. Four architectures, one phrase on the marketing site.

And a few smaller things fell out along the way. Only one of the five publishes a price. The category has roughly four names depending on who you ask. G2 review counts span from 2 to 122. And the shared rails everyone plugs into, Ramp, Stripe, Brex, are increasingly also their competitors.

Is it robust? Does it scale?

I seeded some real-world mess on purpose, because the failure modes teach you more than the happy path does. On one vendor I skipped a chunk of recent news at first, then added it later, to see what the agent would do with a contradiction. It superseded the old read cleanly: it marked the prior claim as outdated, recorded what replaced it and when, and walked forward to the inferences that had rested on it, rather than silently overwriting the page. That self-correction is the whole reason to build it this way, and I wanted to watch it happen instead of taking it on faith.

Another vendor’s site would not clip at all. So I ran that one on news, founder podcasts, and job postings only, and still got a usable profile, explicitly flagged at lower confidence. That is exactly how it should degrade: less certain, clearly labeled as such, not silently thinner.

For now, I fetch and clip the sources by hand. Automating that is a separate step I can add later, and it is not the novel part: diffing a sitemap and scraping what changed is a proven technique. The hard part was never the fetching. It was the bookkeeping, and the agent already does that.

The method beats the model

This is the basic version of what the approach can do. The harder work sits further up, in the questions you ask once the base is dense enough to answer them.

What I take from it is that the method matters more than the model. An LLM does not out-think a good analyst. A sharp human will read the same job posting and draw a better inference from it. What the LLM does is out-baseline them. The edge is discipline, not brilliance: it reads the whole corpus instead of the part you had time for, dates every claim, and holds each inference to its source past the point a person would keep it up.

If you want to point one at your own category, the idea file is here.