April 2026
How an AI companion for L1/L2/L3 support engineers at Orange Business converged, line for line, on the llm-wiki pattern Karpathy published in April 2026.
Andrej Karpathy posted a gist last week. Five thousand stars in seven days. The comment section is a parade of CLI tools, Obsidian plugins, Claude Code skills, research frameworks, knowledge graphs. Everyone's version of the same pattern, shipped in the week since the post went up. I read the gist on a Saturday morning, and I reread it three times before I believed the dates.
Three months ago, at Orange Business, I started building what Karpathy describes. Three layers, the same discipline, the same idea of a markdown knowledge base that the LLM reads, writes, and maintains for itself, with the schema living in a prompt the model reads on every run.
I didn't know it had a name. I didn't know dozens of other people were reaching for the same shape in the same quarter. I was just trying to solve a problem in front of me: how an AI companion should help a support engineer resolve a production incident at 3 AM. The shape that came out the other end is, almost line for line, what Karpathy published.
Here's what that looks like from the inside.
Orange's 2026–2030 strategic plan ("Trust the Future") commits to a new industrial model for operations, built on AI to make networks more effective and more resilient. That commitment has to land somewhere concrete: in code, in front of real users, with real incidents being resolved.
I'm an AI engineer at Orange Business. I build agentic AI products for operational teams. The one I want to walk you through (let's call it the Companion) is an AI companion for L1, L2, and L3 support engineers resolving production incidents. The shape it ended up having is the same shape Karpathy described, and I didn't get there by copying him.
Read the gist. I'd rather you hear it from him than from me. But here it is in one breath.
The system has three layers. A folder of immutable source material. A folder of markdown pages the LLM writes and maintains (summaries, entity pages, concept pages, a catalog, an append-only history). And a schema document that tells the LLM how the wiki is organized, what each kind of page should contain, and what workflows to follow.
On top of that sit three operations.
Retrieval run 1. The top three fragments miss the postmortem that answers the question; it is still in the store, ranked below the cut.
Karpathy's framing of why this is not RAG is the line I'd put on a t-shirt:
The wiki is built up. RAG isn't.
I want to be careful here, because "RAG doesn't remember" is the lazy version of this argument and it isn't true. Retrieval systems index and retain perfectly well. The problem isn't memory. It's that the right answer has to be found, every single time, in a pile of material that nobody curated — duplicate tickets, half-written runbooks, comments that contradict the runbook they're attached to. The knowledge is in there. Whether it surfaces is another question, and long retrieved contexts have a known habit of losing what's sitting in the middle of them.
In operational work that failure has a specific and expensive shape: conflict through time.
Take a real pattern. A problem gets solved one way in early 2025 — call it A1. For a year, every ticket, every comment, every runbook edit says A1. Then the fix changes: the correct answer is now A2. It's newer, so there's less written about it. Maybe one postmortem and a commit message.
Ask a retrieval system what to do and it finds both. It has no way to adjudicate, and the arithmetic is against you: there are nine documents saying A1 and one saying A2, so the stale answer has more corroboration, scores better on similarity, and comes back stated with total confidence. Recency isn't relevance. A pile of old evidence can outvote a sparse current truth.
The wiki settles this once, at write time. When A2 is learned, the article for that problem gets edited — A2 becomes the answer, A1 stays on the page as superseded history, with the date it stopped being right. Nothing is deleted; knowing what the fix used to be is exactly what you want at 3 AM when you find A1 in an old ticket and need to know why it's there. Every engineer who asks after that gets the reconciled answer, because a human supervised the reconciliation once instead of the system re-litigating it badly on every query.
The 3 AM question“What do we do when the export pipeline throws SU-014?”
ranks by similarity, at query time, every time
4 of 5 come from the thick old stratum. The postmortem is retrieved and outvoted.
reconciled once, at write time, by a human-supervised edit
currentRotate the expired service credential
supersededRestart the connector poolwas correct until Jan 2026
The postmortem did not join a pile — it edited this page. The conflict was settled here, once.
Before the postmortem existed, retrieval was right — and it has not changed since.
Today. 9 documents say A1, 1 says A2. Retrieval answers A1 — stale — with high confidence. The article answers A2, keeping A1 as superseded history.
That's the difference that actually matters to me. Not that the wiki remembers more. That it decides.
All of this happens inside a single conversation with a single agent. Karpathy recommends Claude Code (or Codex, or OpenCode) as the host. One chat, one agent, one set of filesystem operations, reading and writing the same wiki in the same session. The comment section is full of people building variations on exactly that.
The Companion is an AI companion for Orange Business support engineers. A support engineer opens an incident, asks the Companion "what do we do when the export pipeline fails with error SU-014," and the Companion reads its knowledge base and answers.
When the engineer resolves the ticket (maybe they discover a new workaround, maybe the fix updates an existing article, maybe a whole new known-error page needs to exist), they tell the Companion in the same conversation: "update the SU-014 article with the rollback command we just ran."
Same agent, same chat window, reading and writing on the same surface, driven by natural language from a tired human who wants to get home. One knowledge base, editable by conversation.
The schema, the thing Karpathy puts in his CLAUDE.md, lives in a system prompt the Companion reads at the start of every session. It tells the model what kinds of articles the KB contains (known errors, how-tos, diagnostic trees, routing rules, component descriptions, operational patterns), how articles cross-reference each other, and how to prefer editing an existing article over creating a new one.
And the single most important rule in the whole prompt:
One sentence of prose in a schema file. The KB is going to be consumed by people who run what the Companion tells them to run, so this rule matters more than any other part of the prompt.
Two design choices from the same schema do most of the trust work.
At the top of every page, the Companion writes down how many incidents the article was grounded in (evidence count), and how certain it was when it wrote it (confidence). When a support engineer asks a question, the answer comes back with that context attached: "this article is grounded in 43 resolved incidents, high confidence" versus "2 incidents, low confidence." With production down and a decision under pressure, that distinction matters.
It's also the concrete answer to a question I saw asked several times in Karpathy's comment section: how do you track provenance, handle contradictions, know when to invalidate memory? Evidence and confidence, declared per article, written by the model that wrote the article. A small, prompt-level trick that's been quietly doing the job for three months.
No retrieval filter, no verification pass, no external ground-truth check. The rule lives in the schema, the model reads the schema at the start of every session, and every article it writes is grounded in incidents that are in the same context window as the schema telling it not to drift.
That sounds fragile, and it is. We have caught hallucinations. We have found bugs. The Companion has written KB articles that slipped something in that wasn't in the source tickets, and we've had to go back and fix them. In the adversarial case the rule is even weaker: a prompt-injected ticket, a drift in the distribution of source material, and the schema alone isn't going to hold.
What the rule does well is make those failures visible. Every article declares its evidence, every claim points at a source ticket, and when something goes wrong it shows up on inspection. The design is a WIP and we know it. What it is not is a blind-trust system. The reason we trust it at all is that the failures have so far been the kind you can see.
Four things about the Companion are specific to where it lives (L1/L2/L3 support) and they shaped the implementation.
Karpathy's raw material is what he chose to read: papers, repos, web pages he's studying. Ours is generated as a byproduct of running a business: resolved incidents in ServiceNow, runbook pages in Confluence, commits in GitLab.
Nobody "chooses" to read an incident ticket. It happens because something broke. The Companion's KB compounds knowledge the team already produced doing its job, not knowledge the team went out and acquired.
Karpathy's gist introduces an append-only log to give the wiki a chronological audit trail. We didn't need to invent it. Confluence already does page history, ServiceNow already does ticket audit trails, GitLab already does commits.
The KB sits on top of enterprise systems that know who wrote what, when, and as part of which ticket. Karpathy's log is a clever workaround for a plain-markdown-folder limitation we don't have. We got versioning for free, because we chose to live inside the substrate our users were already living in.
Karpathy's wiki is personal. It's his wiki about his reading. The Companion is one system serving many customer teams, and it cannot leak across them.
Access control comes from the backing systems, not from a layer we built on top. Same pattern as history: we get the governance we need because we live where the governance already lives.
This is the one Karpathy's gist doesn't have to deal with. His raw material is what he chose to read: clean, intentional, curated. Ours is incident tickets, written by users under pressure. Users describe what they think happened, not what actually happened.
When someone misunderstands how a system works and files a ticket based on that misunderstanding, the Companion ingests that ticket and writes it into the KB. Now the support team's documentation reflects the user's wrong mental model.
The "do not invent" rule protects against hallucination, but it doesn't protect against the source material being wrong in the first place. That's a harder problem, and we don't have a clean answer for it yet.
None of these are contrasts with Karpathy's gist. The gist is deliberately abstract. It's an idea file, and he explicitly invites you to instantiate it for your domain. This is how ours turned out.
A personal wiki sitting on a laptop is one version of it. The Companion sitting on top of Confluence, ServiceNow, and GitLab inside Orange Business is another. Same shape, different substrate.
Two things from Karpathy's gist I don't yet have.
Right now the Companion edits the KB every time a support engineer asks it to. Over weeks, two engineers on two different teams might write two articles that quietly disagree with each other, and nothing notices. Karpathy's framing (the same LLM that wrote the wiki runs a health-check over it on a schedule) is better than what I have. It's cheap, it's mostly a prompt, and I can ship it next week.
The Companion currently goes looking for relevant pages when answering a question. It searches, skims, reads what looks promising. Karpathy's pattern is cleaner: read the catalog first, let the table of contents decide which pages to pull. The catalog also doubles as the landing page of the human-facing docs site we publish alongside the LLM-facing KB. Two wins for one file.
Neither of these requires changing the core loop. Both sit in the schema layer plus one naming convention. The reason I hadn't added them is that I wasn't looking for them. Karpathy's gist showed me they were there.
The wiki pattern works, and people are arriving at it from different angles. Dozens of implementations have surfaced in Karpathy's comment section in the week since the gist went up, built by people who've never met, using the same primitives to solve different problems.
RAG was a compromise. It existed because context windows were small, models couldn't be trusted to edit their own files, and we didn't have filesystem-shaped tools as a first-class primitive. All three of those constraints broke in 2025. The wiki-shaped answer is the natural one now.
But the interesting problem is not the wiki. It's what the wiki makes visible.
When the Companion ingests hundreds of tickets and builds a knowledge base from them, it also accumulates a map of how users understand the systems they're using. Every misunderstanding that makes it into a ticket, and then into a KB article, carries information about where users get confused.
If users keep describing the same system the wrong way, that's not a documentation problem. It's a product problem, or a training problem, or an experience problem. And the Companion is sitting on that data.
That's the version of this pattern I haven't seen in Karpathy's comment section yet.
If you're building something like this too, for research, for ops, or for a team at a company that happens to have a lot of Confluence pages and a lot of tired support engineers, I'd like to compare notes.