Build a small LLM wiki in an AgenticOS project

A team accumulates project briefs, meeting notes and product decisions. Answering the same question repeatedly is useful, but it leaves another opportunity: keep a readable set of notes that connects the sources and improves as new material arrives.

An LLM wiki is a practical scenario for AgenticOS Projects. The project holds shared files and instructions across chats, and an agent can work on those files. The useful output is a knowledge artifact the next colleague can open and maintain. Drafted with AI assistance.

The walkthrough uses fictional company documents. The screenshots come from a real wiki I built from Hacker News stories on a test instance. I build AgenticOS at Vstorm.

Choose a topic a teammate would ask about

Start with a synthetic product launch. Prepare a launch brief, a meeting note and a later decision that changes part of the plan. Ask a concrete question: "Which launch decision changed, and what source explains why?"

That question gives the wiki a job. Its value is the connection between the source, the decision and the current summary. A directory of attractive summaries is insufficient if the colleague cannot tell which claim is current.

Andrej Karpathy's LLM Wiki idea file describes persistent linked Markdown knowledge maintained from preserved sources and a set of working conventions. It is an abstract pattern, not a specific application or an endorsement of AgenticOS. The implementation below uses AgenticOS project files for that purpose.

Agree the project with Architect

Ask Architect to plan an LLM wiki for the chosen topic. Describe the material, who will use it and the output you want to maintain. Review the proposed project, its instructions and its audience before approving creation.

Creating the project creates its shared workspace and instructions. It does not automatically write the planned files or start a scheduled maintenance process. Follow the project link and create a new chat there. An existing chat cannot simply be moved into the newly created project.

The current Projects documentation describes this planning path explicitly, including an LLM wiki workflow. That is a useful foundation for a reproducible walkthrough.

Give the files clear responsibilities

Keep original material in sources/, with provenance such as the source name, author, source date and the date it was retrieved. New material can wait in inbox/ until it has been reviewed and processed.

Use notes/ for the maintained topic pages. Keep an index.md that links to the relevant notes and sources, and a CHANGELOG.md for updates and checks. These names are a proposed layout for this example, not a mandatory product schema.

Project instructions should explain those responsibilities. An agent starting a new chat needs to know where to look first and how to distinguish an original source from a generated interpretation. The original files should remain available for review.

What this layout looks like in practice

I built one from a real feed: Hacker News stories from 21 October to 4 November. The project has inbox/, notes/ and sources/hn/ folders. Every topic note is linked from index.md, and the index lists the source files behind each line, so a statement can be traced back to the story it came from. CHANGELOG.md and state.md record what changed and where the last update stopped.

The graph view shows the structure at a glance: 33 notes and 80 links, with the index at the centre and the topic notes around it.

This is one wiki on one test instance, not a benchmark.

Process the first source into a useful note

Upload the synthetic launch brief into the project's shared files. Ask the agent to read it, create a topic note and link the note to its source. The note should distinguish stated facts from inferences and unresolved questions.

Inspect the result in the project's Files tab. Open the generated note and its source. Check a specific statement against the original brief. A source link is useful only when it leads to material that supports the nearby claim.

Then inspect index.md. It should help another conversation find the topic without knowing the path of every file. Do not assume that a file tree alone gives the agent the conventions the team intended.

Add a source that changes the answer

Now add the later synthetic decision. Ask the agent to identify which existing note it affects, propose the update and preserve the source of the change. Review the revised note and the change log.

The result should let a colleague understand both the current decision and why it changed. It should not rewrite the original launch brief as though the earlier plan never existed. If the sources conflict without settling the issue, keep the conflict visible.

Compare the original source, the new information and the linked note that changes. The saved update should explain how the current answer differs from the earlier plan.

Ask from a fresh project conversation

Start a new chat inside the same project. Ask which launch decision changed and where that conclusion comes from. The shared files and project instructions persist across chats. Other chat transcripts are not automatically supplied as context.

Have the agent read the index and the relevant notes, then inspect the cited source in its answer. This tests whether the workspace carries the knowledge the example is meant to preserve. It avoids relying on the first conversation's temporary context.

In the HN Wiki project I started a new chat and asked "What's new in AI world?". The agent worked for 17 seconds in 3 steps and answered by topic, with a link on each item. It also said it had read only the headlines, scores and comment counts, not the articles themselves. An answer that states how deep it went is easier to trust than one that does not.

A knowledge collection can add indexed retrieval. It does not replace the maintained project files or automatically turn every chat attachment into a wiki. Keep those roles separate when explaining how the example works.

Make maintenance an explicit task

Ask for a check of the current notes: source support, contradictory statements, stale dates and broken links. Have the result record what was checked and what remains unresolved. A successful file write is not proof that every statement was verified.

A scheduled update needs a separate routine and the appropriate approval. Do not imply that merely creating the project starts an autonomous maintenance system. First make the manual task useful, then decide which repeated part should run in the background.

If a maintenance step needs code execution, the project must have a suitable service sandbox and permitted tools. Stored project files can support reading and writing without supplying a shell. The example's requirements should say which behavior it uses.

Share the result as team knowledge

Invite the relevant colleagues using the project's access controls. Ask another person to locate the current decision, open its source and continue the work. Keep simultaneous editing expectations realistic: shared files do not imply automatic merging of two agents' changes or a collaborative document editor.

The result to check is specific: preserved sources, a linked current note, an index, a recorded update and an answer from a fresh project chat.

The team can then use a maintained explanation of its work, with the evidence still attached. Another colleague can follow the changed launch decision back to its source.