An AI-Maintained "Enterprise" Brain: Insights from our 1-Day Hack

Target audience: Any organization seeking to harness its internal knowledge to improve decision-making, particularly valuable for SMEs in the service sector.

The starting Point: An AI-Maintained Knowledge Base

The project aimed to build an AI-maintained knowledge base that keeps organizational knowledge acquirable, retained, and exploitable with minimal manual upkeep, enabling effective knowledge retrieval: complete, to-the-point answers that require only a minimal prompt yet return the most complete response.

Upkeep, rather than structure, is the main difficulty with knowledge bases. Cross-referencing, updating summaries, and flagging contradictions are time-consuming tasks, and most individuals and teams eventually stop performing them, at which point the knowledge base becomes outdated.

The approach was based on a pattern published in early 2026 by Andrej Karpathy for using large language models to build and maintain personal knowledge bases (Karpathy, 2026). Karpathy notes that conventional AI tools, including retrieval-augmented generation (RAG) systems, retrieve from raw documents at query time and retain nothing between sessions, so knowledge does not accumulate. He proposes instead that an LLM incrementally build and maintain a persistent, structured wiki: reading each new source once, integrating it into existing pages, and keeping the content current, so that knowledge accumulates over time rather than being re-derived on each query.

The architecture consists of three layers: raw, immutable source material; a wiki that the AI alone writes and maintains; and a schema file that defines how the AI performs that task consistently. The approach gained attention (Gupta, 2026) because it addresses a recurring weakness of manually maintained knowledge bases — namely, that the maintenance effort is sustained by the AI rather than depending on ongoing human.

The best builders don't just know more. They forget less.

This was the foundation we built on. But an AI that reliably maintains a wiki still needs to know how to file what it reads. Karpathy's pattern gives you a self-maintaining engine; it doesn't tell you what the folders should be. For that, we needed an organizing lens.

Standing on Tiago Forte's Shoulders

The organizing lens we reached for was a method that has already reshaped personal knowledge management for hundreds of thousands of readers: Tiago Forte's Building a Second Brain (Forte, 2022). Forte's book lays out PARA: Projects, Areas, Resources, Archives, a way of filing information by how actionable it is rather than by topic, and CODE: Capture, Organize, Distill, Express, the four-step process that turns raw information into something usable (Forte, 2022).

PARA's insight is simple but powerful: most filing systems fail because they organize by subject, and subjects are infinite and ambiguous. Forte organizes by actionability instead: is this a Project with a deadline, an ongoing Area of responsibility, a Resource for later, or something Archived? And that four-way split has proven durable enough to be adopted well beyond individual users, reportedly reaching organizations from large enterprises to development banks.

Pairing Karpathy's self-maintaining wiki with Forte's PARA gave us a working combination: an AI that never tires of the upkeep, filing knowledge into a structure designed for actionability. We began applying the result to our own Business AI Service Line: training offers, workshops, proof-of-concept engagements, and the client relationships that run through all of them.

Where PARA meets its Limits in a Client-Facing Business

One friction surfaced almost immediately once we pointed the system at real consulting work.

• PARA has no first-class concept of a client. For an individual knowledge worker, that's a reasonable omission — but for a professional services firm, the client relationship is the connective tissue between everything else. A Project exists because of a Client. An Area's value is ultimately proven through Client engagements. Treating a client as, at best, a note inside Resources understates the one relationship the whole business runs on.

PARA had been the right lens to start organizing with, but client-facing consulting work needed a different structure. So we changed the method rather than force our work into it.

Our Contribution: PACA

We adapted PARA into what we call PACA: Projects, Areas, Clients, Archive. This is our own contribution on top of Forte's framework, built specifically for organizations whose knowledge management challenge centers on client engagements rather than purely personal productivity.

Three changes define it:

• In Karpathy's approach, resources are not held in a separate store but already reside within the wiki itself. Following this principle, we decided not to keep Resources as a standalone dimension and instead integrated it into wikis that are into Areas, so that reusable reference material lives inline within the Area it belongs to rather than in a disconnected folder.
• We also introduced a taxonomy within the Area dimension, organizing captured knowledge into sub-areas rather than treating each Area as a flat container. The sub-areas reflect categories of practice in our Business AI service line, e.g. AI trainings, AI workshops, Client engagement etc. Categorizing information into sub-areas assigns it additional, more tailored meaning — placing a given piece of knowledge in a specific context rather than a broad one — which in turn improves the precision of retrieval, since queries can be resolved against a more finely structured set of categories rather than a single undifferentiated Area.
• Third, we added a dedicated Clients dimension, and made the connections explicit rather than incidental: every Project must declare which Client it is for and which Area it belongs to, and every Client page lists its active and past Projects in return. When a Project closes, it moves to Archive without breaking either link — so the history stays reachable long after the engagement ends.

The result is more than a renaming: it is a structural adaptation of PARA to a services business, where reusable resources stay attached to the Areas that use them, knowledge is organized into practice-specific sub-areas for more precise retrieval, and the client relationship is given the same first-class status as the work itself.

From Concept to Product: A hybrid AI Implementation

PACA is the organizing method; the system that implements it is built on Claude Code¹. Claude Code can be replaced with another generative AI tool; we selected it because it currently offers the strongest performance among available options. A written schema file defines the AI's behavior — what to capture, how to classify it, and which workflows to run — while three folders (raw material, the organized wiki, and disposable outputs) correspond to the Capture, Organize/Distill, and Express stages of Forte's CODE process.

Each article in the wiki carries YAML frontmatter — tags, dates, sources, and explicit links to its Client and its Area — together with inline cross-references between pages.

As a result, the wiki functions as a navigable data graph rather than a flat collection of markdown files, allowing the LLM (or an AI agent) to traverse explicit links between pages rather than retrieving isolated passages as conventional RAG does. The knowledge base is stored centrally in a GitLab² repository, versioned and shared across the team, and can be browsed in Obsidian³, which renders the links as a graph for users who do not interact with it through code.

Solving Acquisition, Retention and Exploitation of Knowledge

Our proposed system directly addresses the three failures that typically undermine knowledge management solutions — the same that motivated this project.

• Acquisition: the raw folder removes friction from capture entirely. Material goes in unsorted — a transcript, a PDF, a screenshot — and the AI, not a busy consultant, does the classification work that would otherwise never happen.
• Retention: a mandatory, rewritten-not-appended summary block on every page prevents the slow decay that kills most internal wikis, while PACA's explicit Client–Project–Area links mean relationship context survives staff turnover, project closure, and time — rather than leaving with whoever held it in their head.
• Exploitation: the AI can be asked directly, audited for contradictions, and drawn on to draft new offers or onboarding material straight from prior work — turning stored knowledge into reused knowledge instead of an archive nobody revisits.

Technical Implementation and use of the "Enterprise" Brain

To implement the presented Enterprise Brain concept, we used two tools working together:

• Claude Code: to add new information and ask questions, and
• Obsidian: to browse and read what's already there.

The markdown file Claude.md contains the logic, thus reflecting the above-mentioned CODE method.

Figure 1 shows the resulting Data Graph after processing (i.e. compiling) the first 4 PDF files, one containing a consulting offer on 5 AI trainings and the remaining 3 containing our modules on Copilot Studio trainings. The left-hand side of the figure shows the folder structure following our above-described PACA method, and the right-hand side shows the dots (i.e. knowledge products) connected with each other. Each knowledge product is represented in a wiki, which means the user can click and explore it to learn more about it. The edges are stored as links in the wikis, which means one can navigate through the graph also via the wiki, just like you were browsing Wikipedia hopping from link to link.

Figure 1. Screenshot from the resulting Data Graph in the Obsidian tool

Figure 2 shows the automatically created Wiki about Module 1 of Copilot Studio that has been automatically generated, which is structured as follows: title, summary, key points, objectives and scope checklist, content highlights (e.g. Walkthrough – Web Search Agent, Prompt frameworks etc.), related articles and finally sources.

Figure 2. Screenshot from the resulting Wiki in the Obsidian tool

Figure 3 shows how one can use the "Enterprise" brain through Claude Code. As the figure shows, we inputted the prompt "Write a small summary about the latest AI training on Copilot Studio we proposed" and what Claude Code returns is entirely based on the enterprise documents that were entered. Sensitive data were covered on purpose in the screenshot.

Figure 3. Use Cloude Code for the quick knowledge retrieval of your Enterprise Brain

Our core Tech Innovation and why a traditional RAG was not sufficient

Retrieval-Augmented Generation (RAG) (Lewis et al., 2020) has become the default approach for grounding large language models in an organization's own knowledge. It pairs the model's generative capability with a retrieval layer: at query time, the system pulls relevant passages from an external corpus, typically through dense vector search over learned embeddings (Karpukhin et al., 2020), and uses that evidence to shape its answer, delivering responses grounded in current or proprietary information without the cost of retraining the model.

Despite its wide adoption, however, the approach carries limitations that directly affect business value. Because the answer is only as good as what the retrieval step surfaces, poor document chunking, weak embeddings, or noisy source data can feed the model irrelevant context that it nonetheless treats as fact. This is compounded by evidence that models attend unevenly to long inputs and often overlook information buried in the middle of the prompt (Liu et al., 2023), and that distracting passages can measurably reduce answer accuracy (Shi et al., 2023). RAG also introduces real operational overhead — an embedding pipeline, a vector store, and continual index maintenance — along with added latency. Most fundamentally, because standard RAG retrieves isolated passages, it struggles with questions that require connecting information across many documents or reasoning over relationships between entities, which is why hybrid designs incorporating structured knowledge and explicit logic are gaining traction (Laurenzi, 2026; Edge et al., 2024; Peng et al., 2024).

Finally, RAG inherits whatever errors or biases exist in the underlying sources, since it surfaces flawed content faithfully rather than correcting it.

Our approach follows this hybrid direction, addressing the weaknesses above through two complementary mechanisms:

1. First, a Markdown file encodes the logic that governs the Capture, Organize, and Distill stages of the CODE method described above, defining in a transparent, human-readable format how incoming knowledge is captured, structured, and curated. Because this logic is expressed explicitly rather than left implicit in opaque vector similarity, domain experts can review, adjust, and maintain it without specialized tooling, reducing operational complexity while giving the business full oversight of how its knowledge is captured and structured.
2. Second, for the retrieval and reasoning stages, the LLM relies on the data graph underlying the wiki rather than ranked passages alone. This allows the system to follow a traceable traversal of explicit relationships to reach each answer, rather than depending on whether the relevant passages happen to be retrieved. Grounding retrieval and reasoning in the explicit relationships of the graph yields more consistent and controllable results than a traditional RAG pipeline.

Limitations: Usability Barriers and associated Risks

The current implementation has two usability barriers on the user side that could hinder broader adoption:

• Processing documents and running Q&A currently require familiarity with Claude Code. Both adding new material and querying the knowledge base are done through Claude Code, a developer-oriented tool. Users who are not comfortable with it face a barrier to both capture and retrieval, which limits use to more technically proficient staff.
• Maintaining the knowledge base properly requires Git know-how. The knowledge base lives in a GitLab repository, so keeping it up to date — committing changes, pulling updates, and resolving conflicts — assumes a working familiarity with Git (or a distributed version control system - DVCS). For users without that background, routine maintenance is not straightforward and errors are easy to make.

Neither limitation affects the validity of the core approach, but both indicate where further work is needed: making the wiki reliably reflect changes to its sources, and supporting concurrent use by a team.

If not addressed properly, the two presented limitations can lead to various risks. Namely,

Risks of neglecting the Claude Code barrier (capture and retrieval):

• Low adoption: non-technical staff avoid the system, so it is used by only a small subset of the team.
• Incomplete knowledge base: knowledge held by non-technical experts never gets captured, leaving gaps in the very content the system is meant to hold.
• Single points of failure: capture and retrieval concentrate on a few technical users; their absence blocks access.
• Underused retrieval: colleagues who can't run Q&A revert to old habits (email, drives, asking people), undermining the system's purpose.
• Bottlenecks: technical users become intermediaries for others' capture and queries, adding overhead.

Risks of neglecting the Git know-how barrier (maintenance):

• Divergence from the shared source: users who can't push/pull properly leave the shared repository outdated or work from stale copies.
• Data loss or corruption: mishandled commits, merges, or force-pushes can overwrite or erase content and history.
• Unresolved conflicts: merge conflicts handled incorrectly silently drop contributions.
• Inconsistent state across the team: without disciplined version control, members hold divergent local versions of the knowledge base.
• Maintenance avoidance: users uncomfortable with Git stop updating altogether, so the wiki drifts from reality while still appearing authoritative.

Cross-cutting risk of neglecting both:

• Erosion of trust: if the system is hard to use and its content becomes outdated or inconsistent, the team stops relying on it, and the effort invested in building it is wasted.

Conclusion

The problem this work set out to solve is a common one: organizations rarely fail for lack of information, but for lack of a system that keeps it acquirable, retained, and exploitable. Our response combines two existing ideas — Karpathy's self-maintaining LLM wiki and Forte's PARA/CODE framework — and adapts them into PACA, a structure tailored to a client-facing services business, where reusable resources stay attached to the Areas that use them, knowledge is organized into practice-specific sub-areas, and the client relationship is treated as a first-class dimension. Implemented on Claude Code and backed by a versioned GitLab repository browsable through Obsidian, the result is a navigable data graph rather than a conventional RAG pipeline — one that grounds retrieval and reasoning in explicit, human-readable relationships instead of opaque vector similarity.

Prototyped in a single-day bootcamp against live consulting work, the approach directly addressed the three failures that typically undermine knowledge management solutions, while remaining transparent enough for domain experts to review and maintain. At the same time, the current implementation has clear limitations: both use and maintenance presuppose familiarity with Claude Code and Git, which raises usability barriers that, if left unaddressed, carry real risks to adoption, data integrity, and trust. These do not undermine the core approach, but they define the possible next steps — lowering the technical barrier to capture, retrieval, and maintenance, and reliably supporting concurrent use across a team.

For organizations losing knowledge in scattered emails, departing staff, and drifting documents, PACA offers a concrete, extensible starting point, and we welcome the conversation.

Get in touch

If your organization faces similar knowledge management challenges, information scattered across emails, expertise lost when people leave, or offers that drift from current pricing, this is precisely what PACA and our hybrid AI implementation were designed to address. I would be glad to discuss how the approach could apply to your context.