I admit it, I hate paperwork, and I suspect many of you feel the same way. Still, we have to live with it: contracts, invoices, utility bills and documents of every kind are part of real life.

This is surely where AI can lend a hand: documents are essentially text, and LLMs are pretty good at handling text. Will local models be too? We’ll find out soon.

The result, right away

#

Before telling you how I got there, here’s what I get today. I write a question to my agent on Telegram and get the answer within a few seconds, sources included (personal and/or confidential information has been redacted):

User:
in which room Anna ***** was and in which year? 
How much was her rent? check the affitti wiki .

Assistant:
Done — answer from the wiki (log entry appended):

Anna *****, at via ** **********, **, in 2019–2020 (contract 
01/10/2019–30/09/2020, terminated early by mutual agreement on 
30/06/2020).

Room: no individual room — her contract was for the entire 
apartment, let jointly (in solido) to five students (A, B, 
C, D, E). Per-room ("stanza") contracts only began from Nov 
2020.
Rent: €****/month (€*****/year) for the whole apartment, 
shared by the five; deposit €****.
Sources: [[tenant-anna]], [[lease-xx-xxxxxxxxx-2019]], 
[[property-xx-xxxxxxxxx-xx]] (registered contract, Agenzia 
Entrate 15/10/2019, cedolare secca).

Notice one detail: the question started from a wrong assumption (a “room” that didn’t exist), and the agent corrected it, explaining when the per-room contracts began. Finding the same information by hand would have meant opening one PDF after another.

The problem

#

I took on the management of the rental contracts for a few apartments, which take up a considerable amount of my family’s (my wife’s) time. One of these apartments in particular, let to students, generates most of the paperwork: in fact, there’s a contract for each room. As we all know, students come and go; there are constant terminations, new contracts and renewals, and with 4 rooms the amount of paperwork is remarkable, and so is the effort of remembering all the deadlines.

What I want is a system that, whenever the documents I mentioned are added, builds and updates a knowledge base that can be queried. It’s not a database in the traditional sense, but something similar to a Retrieval-augmented generation (RAG) approach, without the need for (and the complexity of) embeddings.

A. Karpathy, one of the most influential researchers in the field, proposed the llm-wiki pattern. Instead of retrieving documents for every question as in traditional RAG, it’s the LLM itself that builds and maintains a knowledge base in markdown, persistent and growing richer over time. In practice, you put the raw sources in a folder and the model writes and indexes a wiki that you can then query, producing summaries of the sources, entries on concepts, articles and backlinks. Outputs such as slides, charts and answers are also filed in the wiki as new articles, so knowledge accumulates instead of starting from scratch at every session.

What I did

#

Let me say it candidly right away: I didn’t invent anything, I simply connected a few pieces together.

The heart of the system is Hermes, the agentic platform that runs in a dedicated VM on my local AI PC and uses Qwen3.8-27B as its model; I described the whole stack in the previous post.

The PDF documents are first stored in my Nextcloud. Every 6 hours, a cron job on the Hermes VM copies that folder into the ‘affitti/’ folder in the user’s home:

# cloning affitti folder:
0 */6 * * * rclone copy remote-cloud:"<Nextcloud_path>" ~/affitti 

Hermes comes with a ready-to-use ’llm-wiki’ skill. I opened a chat session and started asking Hermes to do what I wanted. Here are a few excerpts from the chat; personal and/or confidential information has been redacted.

A single line is enough to create the wiki structure:

User:
go to the 'affitti/' folder and create an llm-wiki.

Assistant:
Done. Initialized the llm-wiki at /home/hermes/affitti:

affitti/
├── SCHEMA.md        # domain: rentals — contracts, tenants, landlords, market data
├── index.md         # sectioned catalog (currently 0 pages)
├── log.md           # init entry logged
├── raw/{articles,papers,transcripts,assets}/
├── entities/        # properties, tenants, landlords
├── concepts/        # lease terms, rent increases, maintenance rules, utilities
├── comparisons/     # e.g. rent levels across properties
└── queries/

Then I asked it to link the PDFs into the wiki via symbolic links, without copying them, and not to start the import right away. The interesting part is how it replied: before giving me its opinion, it went and looked at how the folders were organized and figured out on its own that this was a synced folder, one it must never write into.

Assistant:
Good question. Let me look at the actual nextcloud layout before I commit 
to a recommendation.

`Appartamento XYZ` — via *******, 4 PDFs (contract, registration, 2 
proroghe)
`Appartamento ABC` — via *******, ~50 PDFs organized by year 
(affitto 2017 … affitto 2026)
There's also a .sync_*.db file, confirming this is a managed sync dir 
— so we must never write into it.

My recommendation: yes, symlinks are the right solution — better than 
copying:
[...]
Read-only stays read-only. [...] anything written into the nextcloud 
folder (including a symlink created inside it) could be picked up by 
the sync client and re-uploaded. So the links go in the wiki, never 
in nextcloud.

It created the links, added the rule to SCHEMA.md, and only then waited for my go-ahead. I started with the smaller apartment:

User:
start with 'Appartamento XYZ'

Assistant:
****** ingested. All 4 PDFs were read through the symlink (none 
copied/modified); the main contract's body is a scanned image with 
no text layer, but page 1 (asseverazione) plus the 3 Entrate receipts 
contained all the key data.

Created 7 pages: [...]

Open questions (flagged on the pages, worth answering when you see 
the signed proroghe):

Did the rent change at the proroghe? The receipts don't restate it 
— assumed still €***.
Which landlord opted for cedolare secca, and does it carry to the 
proroghe?
2+1 renewal/proroga rules and deadlines — the receipts don't contain 
them.

The “open questions” are what I appreciated most: instead of making up what isn’t in the documents, the agent says so and flags it on the pages. I answered the first two questions, and the wiki pages were updated, citing my confirmation as the source.

By default, the skill generates text in English; you have to tell Hermes that all documents must be written in Italian: sorry not to have mentioned before, but the wiki text must be in Italian as the input documents.

I carried on like this until it had digested all the documents available at the time: 60 PDFs turned into 54 wiki pages, in about 4 hours.

Making it automatic

#

I want Hermes to regularly check for new documents and update the wiki accordingly. I also want checks to be run so that all the knowledge stays consistent (the lint or health-check feature typical of the llm-wiki). Any updates or inconsistencies must be reported to me via Telegram, so I can look at them right away and step in.

Once again I used cron, but not the system (Unix) one. Hermes has its own cron subsystem, which it manages by itself. In the picture you can see the prompt the default agent is invoked with, the days and time it runs, the skills to include and the folder the agent will have access to. Following the same principle, I set up a second cron job that runs on Saturday mornings to lint the wiki.

How do you use it?

#

In his original template, Karpathy used Obsidian to browse the wiki. In fact, you can use anything capable of reading markdown files.

I take a different approach: I don’t look at the wiki at all, I only use the chat with the agent, mostly via Telegram. When I need something, I just ask for it, as in the example you saw at the beginning.

Limitations and improvements

#

Since it relies on markdown documents, the scalability of the classic llm-wiki approach is limited. Realistically, up to ~100 source files and hundreds of wiki pages, performance is good even with a modestly sized local LLM like Qwen3.8-27B, which is exactly the one I use. So here’s the answer to the opening question: yes, for this task a local model is more than adequate. Beyond that threshold, you need something better than an index file.

Conclusions

#

For my specific case, the wiki is more than enough. I no longer have to rummage through folders of PDFs to find a date, an amount or the name of a tenant from a few years ago: I ask on Telegram and the answer arrives within a few seconds, with sources. And when a deadline is approaching, or a new document doesn’t add up with the rest, Hermes reminds me every Saturday morning.

I still hate paperwork, but at least now someone else takes care of it.