Your business knows how to solve problems, prepare proposals and make decisions. Yet some of that expertise remains locked in completed project folders or in the minds of the people involved. The next colleague has to reconstruct the reasoning. The opportunity is to preserve reusable knowledge together with its evidence and its limits.
The starting point: the LLM Wiki idea
In his LLM Wiki, Andrej Karpathy proposes a persistent Markdown wiki maintained by an LLM. He uses Obsidian to browse it. Obsidian keeps notes in local text files, offering a practical example of readable, portable knowledge.
For Mintera, this raises a business question: how can a lesson become a shared asset without losing its provenance or reaching the wrong audience? The enterprise adaptation below is our consulting proposal.
An example: retaining the reasoning after a project
Consider a fictional engineering consultancy. A team has solved an equipment problem. The final report exists, but the selected approach and the rejected alternatives are spread across several files. To prepare the next project, we would propose a knowledge note containing the context, constraint, decision, justification and conditions for reuse.
The note would initially remain a proposal. A designated expert would check the original evidence, define where the lesson applies and approve its release. The next team could retrieve it and judge whether it fits the new situation. Later experience could extend or contradict it, with the history remaining visible.
Connect knowledge, methods and action
A useful knowledge base should also explain how its content may be used. We distinguish three mechanisms. They are not components of a single “Karpathy method”:
- A skill describes a reusable procedure, such as drafting a technical note using the company’s method.
- A hook triggers a check at a defined stage, such as checking publication conditions before sending a document.
- A classifier routes a request to the appropriate workflow or to a person when review is needed.
In this scenario, the approved note supplies knowledge, the preparation method defines the expected work, and the checks govern execution. Authority to publish still comes from the business process and the permissions enforced by its tools.
What to organise before expanding
We recommend keeping original documents, generated proposals and approved knowledge clearly distinct. Each shared knowledge item should have an owner, a review date and access rules. An appealing answer should not automatically become part of the authoritative memory.
Obsidian can help explore this approach within an appropriate scope. Choosing it does not, by itself, determine where a model processes data or which confidentiality rules apply. The architecture must reflect your users, volumes and operating constraints. The same applies to a proposed plugin or connector: assess the full data flow before adopting it.
Consulting with concrete deliverables
Mintera can define an initial scope, design the knowledge model, organise approval responsibilities and prepare business tests. Useful measures include time to retrieve a verifiable decision, corrections required, lessons reused and maintenance effort. These should be measured on your actual work rather than presented as automatic improvements.
The aim is a memory your company can understand, maintain and use beyond the first demonstration, with a clear path for extending it to additional teams.