The Architecture of AI-First Knowledge Work
A lot of people have seen Andrej Karpathy's second-brain idea by now. The basic pattern is elegant: instead of relying on an LLM to rediscover what matters from a pile of raw notes every time you ask a question, you let the model help maintain a structured, interlinked wiki of markdown files. The LLM is not just a chat interface sitting on top of your knowledge — it becomes the mechanism that organizes, summarizes, links, and continuously updates that knowledge over time. That shift changes the role of AI from "search and summarize" to something closer to "maintain a navigable working memory."
What made Jay Khalife's Entropy system interesting is that he took that pattern in a much more operational direction. He didn't stop at building a second brain for himself. He built a system that applies similar ideas to customers, portfolios, product knowledge, scenario generation, and tailored playbooks — pushing the second-brain pattern out of personal knowledge management and into live decision support.
Karpathy's Core Idea: Pre-Compiled Knowledge Beats Repeated Rediscovery
At the heart of the Karpathy-style approach is a simple observation: many AI workflows waste effort by repeatedly re-reading large volumes of unstructured source material. The alternative is to maintain a layered system. The key insight is that compiled, linked, human-readable knowledge is easier for both people and models to navigate than a shapeless pile of documents.
This three-layer separation gives you portability across tools, concepts that can be updated rather than duplicated, a graph that gets denser over time, and a model that spends less effort rehydrating context from scratch.
Where Jay Extended the Pattern
Jay's work takes that seed idea and pushes it in four important directions — each one a meaningful architectural leap beyond the original personal knowledge management use case.
Personal → Operator-Specific Intelligence
Jay made the second brain explicitly role-aware — organized around his working context as a portfolio leader: sales frameworks, decision-making patterns, mental models, and personal tendencies. The system should know not just the domain, but the operator.
One Brain → Many Customer Intelligence Layers
Instead of stopping at a personal wiki, Jay created intelligence summaries for individual customers — pulling from email threads, meeting transcripts, Jira tickets, CRM context, support history, and stakeholder information. A normal second brain helps you think. A customer intelligence layer helps you act.
Customer Layers → Portfolio Brain
Once accounts are represented consistently, you can look across them for patterns: common friction points, shared risk signals, repeated pricing issues, recurring stakeholder dynamics. The knowledge graph starts behaving less like a notebook and more like an operational map.
Knowledge Organization → Scenario Simulation & Playbooks
Entropy uses the knowledge layers as the basis for generating strategic scenarios and playbooks — different sales frameworks, pricing strategies, outreach approaches, timing differences, channel choices, and stakeholder-aware recommendations. The output is a contextual playbook tailored to both the customer and the operator.
Why This Is More Than "Better RAG"
Jay contrasts his approach with traditional RAG. The strongest claim is not that this architecture eliminates retrieval problems forever. The stronger claim is this: a graph-structured, LLM-maintained knowledge base reduces the need to repeatedly reconstruct context from raw documents, and makes operational reasoning more targeted, portable, and cumulative.
What This Architecture Does
- Preserves conceptual structure between sessions
- Turns repeated source material into reusable pages
- Makes relationships explicit through links and hubs
- Separates raw evidence from synthesized knowledge
- Allows the model to navigate curated abstractions
The Feedback Loop: What Turns It Into a System
The most important addition Jay described may be the simplest: the feedback loop. The system proposes a likely path. Jay executes in the real world. The observed outcome gets fed back into the process.
Without feedback, you have a smart reference layer. With feedback, you have the beginnings of a learning operational system. That is the difference between "here is a plausible answer" and "here is a recommendation that can be calibrated over time." In operational work, that difference is everything.
Portability: A Subtle but Critical Design Choice
One subtle but important theme in Jay's presentation is portability. Instead of overinvesting in a custom application layer, he used tools already strong in their respective jobs:
Notion
Structured operational views and account management
Obsidian
Linked knowledge and graph-like navigation
Claude
Maintenance, synthesis, and execution support
If the knowledge is trapped in one proprietary interface, it is much harder to evolve. If the knowledge is represented as files, summaries, relationships, and conventions, the architecture can move. That is exactly what you want from an AI-native operating model.
The School-Side Reuse Proves the Pattern Is Real
One of the strongest signals in the whole story came after the original presentation. Someone on the school side took the core architecture and adapted it to a very different operational domain — with its own structured operational data, doctrine, and evaluation frameworks. The follow-on implementation showed that the architecture mapped almost perfectly, surfacing both actionable operational insight right away and practical implementation lessons:
Markdown-only workflows aren't always ideal
For pre-structured JSON data, a Python script was the better way to generate intelligence summaries and hub nodes at scale.
Existing agent scaffolding can be adapted
Rather than replacing everything, appending Entropy navigation to existing scaffolding was the practical path.
The structure holds across domains
A pattern hits another domain. The structure holds. The implementation bends where it needs to. That is what real architecture reuse looks like.
Three Valid Entry Points Into the Pattern
Not everyone begins from the same place. Jay's presentation seems to assume a culture where people already have some version of a second brain. In practice, there are at least three valid entry points.
What to Do If You Don't Already Have a Second Brain
Most people don't have a polished note system. They have a mess: files in Downloads, half-forgotten PDFs, meeting notes buried in folders, old markdown, random text files, and project artifacts scattered across machines and cloud storage. That is where an ingestion-first workflow becomes useful.
Set Up a Target Inbox
Create a dedicated place where potentially useful material can land for review instead of dumping everything straight into your knowledge graph.
Choose the Directories That Matter
Start with a small number of high-signal locations like Documents, Downloads, archived notes, and project folders.
Deduplicate Before You Think
Use content hashing so the same file does not get processed repeatedly just because it was moved, renamed, or copied.
Extract a Preview and Score It with AI
Pull a small text preview from each file and use a fast model to decide whether it is worth importing, why, and how it should be categorized.
Run a Dry Pass, Then a Real Ingest
Test the pipeline first, then import only the files that pass your relevance threshold into the inbox.
Review and Integrate at Human Speed
Let AI do the filtering, but let a person decide what becomes part of the long-term knowledge system, how it gets categorized, and what it links to.
For readers who want a concrete reference implementation of that ingestion-first pattern, one has been published at github.com/dp-pcs/second-brain-ingest
A Lightweight Blueprint for Building Something Similar
We do not yet have enough detail to publish a literal step-by-step implementation manual for Entropy, but we do have enough to describe a practical blueprint.
1. Raw / Source / Compiled Split
Raw sources are immutable. Compiled knowledge is maintained by the LLM. Schema/instructions govern how the system behaves. That separation is one of the cleanest ideas in the whole approach.
2. Role-Aware Second Brain
Shape the system around the operator: responsibilities, frameworks, recurring concepts, personal patterns, decision criteria. The system should know what kind of work you actually do.
3. Intelligence Objects for Key Entities
Create structured intelligence summaries around the core units of decision-making — whether those are customers, campuses, vendors, projects, or business units.
4. Portfolio-Level Graph
Once entities are represented consistently, connect them. This is where you start getting cross-case pattern recognition instead of isolated summaries.
5. Layer in Domain Knowledge
A useful system does not just know facts about entities. It also knows the rules, frameworks, and operating doctrine that shape valid decisions.
6. AI for Scenario Generation
The unlock comes when the system starts helping answer: what are the possible moves? What changes if a variable changes? Which strategy seems strongest? What would a playbook look like for this context?
7. Feed Outcomes Back In
Even if you do this manually at first, create a deliberate place in the workflow for reality to update the model of the world. Without that, the system is descriptive. With it, the system becomes adaptive.
8. Automate When Data Is Structured
If you already have structured JSON or database-style exports, do not romanticize manual note creation. Generate the pages, summaries, and hub nodes programmatically where appropriate.
The Broader Lesson
Karpathy's second-brain pattern is powerful because it gives LLMs a better substrate for working with knowledge. Jay's Entropy system is interesting because it shows what happens when that substrate gets attached to an operational loop. That is the important move — not just "build a wiki," not just "use Obsidian," not just "have AI summarize your notes."
Build a knowledge architecture that reflects how work is actually done, represents the entities and decisions that matter, supports navigation across context, generates actionable outputs, and learns from what happens next. That is how a second brain starts becoming an operational system.
A note on scope: This article describes a pattern and architecture, not a benchmarked reference implementation. The value is showing how an already compelling idea — Karpathy's LLM-maintained knowledge graph — can be extended into a practical model for AI-first operational work. That alone is worth attention.