Guide to Building a Second Brain with Claude AI: The Four-C Framework for Your Personal AI Operating System

A leading creator in the AI automation space, NateHerk, has condensed his entire life and business into a Claude-based "second brain" system. He shared the complete methodology behind his AI Operating System (AiOS), refined over several months, along with hands-on experience using Claude Fable (based on Claude Mythos 5). This methodology isn't just for boosting personal productivity — it's a systematic, replicable, and transferable framework.

Start with a Mindset Shift: Make Your AI Operating System the Default Entry Point

The first step in building an AI operating system isn't about technical architecture — it's about a fundamental change in usage habits. NateHerk admits that before using AiOS, he would open various AI tools, different paid subscriptions, and custom GPTs. While his efficiency wasn't bad, he always lacked a true "co-founder" that understood his entire business and life.

The core shift is this: close all those scattered tabs and default to handling everything through Claude Code. Claude Code is Anthropic's command-line AI programming tool that allows users to interact directly with Claude models in a terminal environment, executing tasks like code writing, file operations, and system management. Unlike traditional chat interfaces, Claude Code can directly read and write to the local file system and execute Shell commands, making it a natural fit as the carrier for an "OS-level" AI assistant. Whether it's sending emails, pulling reports, or brainstorming, everything is done in AiOS first — not by opening a browser or other tools. As usage deepens, the system gradually accumulates extensive context, memories, and preference settings, creating a true "second brain" effect.

The Four-C Framework: Core Methodology for Building an AI Second Brain

NateHerk proposed a clear "Four-C Framework" for building and maintaining an AI operating system — the first two Cs (Context and Connection) form the second brain, while the latter two Cs (Capability and Cadence) form the execution layer of the AI operating system.

Context: Defining "Who You Are"

Context is the routing layer of the entire system. NateHerk treats the cloud.md file as a router — it contains not just goals and processes, but more importantly serves as an index pointing to all rules, reference materials, skill libraries, and project documentation.

His system contains a massive number of files, but the criterion for judging whether there's "excessive accumulation" is simple: can the agent quickly find the file it needs? If it takes 5 minutes to search for a file you could locate instantly, the architecture needs optimization. He introduced a noteworthy new concept — "Architecture Engineering" — which he believes will become an emerging skill following context engineering and prompt engineering. Architecture Engineering refers to the ability to design optimal file organization structures, index paths, and information retrieval hierarchies for AI agents. This forms a progressive relationship with the previously popular "Prompt Engineering" (how to write high-quality AI instructions) and "Context Engineering" (how to provide appropriate background information to AI). As the volume of files and data processed by AI systems grows dramatically, how to enable agents to quickly locate needed information among hundreds or even thousands of files becomes a critical bottleneck determining system efficiency. Architecture Engineering essentially borrows from the Information Architecture concept in software engineering, but is specifically optimized for the retrieval and reasoning characteristics of AI agents.

One clever approach is that he moved all other Claude Code projects into a single "Other Worlds" folder within the main project. This offers two benefits: everything syncs when pushed to GitHub, eliminating the need to push multiple projects separately when switching devices; and the main operating system can be aware of all ongoing work, enabling centralized management.

Connection: Real-Time Data Access

Connection addresses the "dynamism" problem of data. Static data like background materials and meeting notes can be stored directly in the file system, but continuously changing data like revenue reports, team messages, and calendars require real-time integration.

The practical approach is to first inventory which apps you open each week, then establish connections through API keys and endpoints. NateHerk prefers using CLI and APIs over MCP servers because they offer more control and lower costs. CLI (Command Line Interface) and API (Application Programming Interface) are two classic methods of inter-system communication, where developers can write scripts to directly call data from third-party services. MCP (Model Context Protocol) is an open standard released by Anthropic in late 2024, designed to provide AI models with a unified protocol for connecting to external data sources and tools — similar to a "USB port" for the AI world. While MCP servers offer a more standardized connection method, they typically require additional middleware deployment and maintenance. NateHerk's rationale for choosing the CLI/API route is that direct calls mean fewer dependencies, more transparent data flows, and more granular permission control — which is especially important when handling sensitive business data. When establishing connections, always pay attention to permission control — request API keys with limited scopes, such as allowing only reading meeting notes but not editing or deleting them.

Capability: Building Reusable Skills and Workflows

With a knowledge base and data connections in place, the next step is building actual execution capabilities. NateHerk's system stores about 20+ custom skills covering image generation, content creation, data analysis, and more.

Key principles for building skills include:

• Skills don't have to be complex: They can be as simple as a prompt template. Whenever you find yourself doing something repeatedly, encapsulate it as a skill
• Iterate continuously: A skill is almost never perfect on the first try. After each use, provide feedback and update it
• Pipeline thinking: Let each AI focus on doing one thing well, then pass the output to the next step, avoiding context pollution

Context Pollution is an important concept in AI systems engineering, referring to when too much irrelevant information is mixed into an AI conversation or task, causing the model's attention to scatter and output quality to decline. For example, if the same AI is asked to both analyze financial data and write marketing copy, residual data from the first task might affect the creative expression of the second. NateHerk's "pipeline thinking" is precisely the solution to this problem — by having each AI instance focus on a single task and then passing structured output to the next step, it ensures output quality at each stage while enabling automated chaining of complex workflows. This design pattern is known as the "Pipes and Filters" architecture in software engineering.

He particularly recommends a skill called "Grill Me" — the AI interrogates you with 15 to 30 consecutive questions, extracting knowledge from your brain and storing it in the system. This is an excellent starting point for rapidly building an AI second brain.

Cadence: Automation and Safe Operation

The final step is enabling the system to run autonomously when you're away. But NateHerk specifically warns: higher autonomy doesn't mean hands-off management. He shared a painful lesson — a team agent misunderstood a task and mass-emailed 150,000 to 200,000 people with an incorrect discount code.

The core principle drawn from this incident: prompts should never serve as a permission layer. You must assume that if an agent can do something, it will. What you need are "keys" (actual permission control mechanisms), not "prompts" (verbal constraints). This principle has deep theoretical roots in security engineering — it's essentially the application of the "Principle of Least Privilege" to AI systems. In traditional software security, every program or user should only be granted the minimum set of permissions necessary to complete their task. Mapped to AI agent scenarios, this means that even if you explicitly state "do not send emails" in the prompt, you must revoke email-sending permissions at the API level, because the behavior of large language models is fundamentally probabilistic and cannot provide the deterministic guarantees of a hardcoded permission system.

Claude Fable in Practice: Capabilities and Limitations

Claude Fable is essentially the public version of Claude Mythos 5, with additional built-in cybersecurity safeguards. As one of Anthropic's newer high-end model releases, Fable is positioned as a flagship product with stronger reasoning capabilities and a longer context window, though with correspondingly stricter pricing and safety mechanisms. NateHerk used it to complete two impressive tasks:

Case 1: One-command personal introduction video. With a single slash command, the system accurately pulled channel data, business model, team structure, and other information to generate a complete personal introduction video.

Case 2: Building an interactive knowledge graph in 21 minutes. All YouTube video transcripts were consolidated into an interactive knowledge graph website, featuring creativity modules, tool modules, and technology modules, where users can click through to explore relationships between various concepts. A Knowledge Graph is a way of organizing information in a graph structure, where nodes represent concepts or entities and edges represent relationships between them. This data organization method is particularly suited for displaying the interconnectedness of elements within complex knowledge systems — Google Search introduced knowledge graphs in 2012 to enhance semantic understanding of search results. NateHerk's application of this to personal content management is essentially building his own "personal knowledge graph," turning knowledge points scattered across hundreds of videos into a visualized network structure.

However, Fable also has notable limitations:

• Expensive pricing: $10 per million input tokens, $50 for output — twice the price of OPUS. The $200/month subscription quota can be exhausted in as little as an hour. Tokens are the basic unit of measurement for how large language models process text, roughly equivalent to 3/4 of an English word or one Chinese character. AI service providers typically charge separately for input tokens (content sent to the model by the user) and output tokens (responses generated by the model), with output tokens usually priced much higher due to the greater computational overhead of generation. This pricing structure means that a single complex conversation with extensive file context can consume tens or even hundreds of thousands of tokens, with costs accumulating rapidly.
• Overly sensitive safety mechanisms: Frequently triggers unnecessary restriction warnings
• Inconsistent response speed: Occasionally experiences extended wait times

Building a Tool-Agnostic Personal AI Operating System

The most thought-provoking point is NateHerk's "tool-agnostic" design philosophy. His system simultaneously maintains multiple configuration files including .cloud, .codex, .agents, and others, ensuring free switching between different AI tools. These configuration files correspond to different AI programming tools — .cloud for Claude Code, .codex for OpenAI's Codex CLI, and .agents for other agent frameworks. By maintaining multiple configurations, the same knowledge base and skill definitions can be read and used by different AI tools, avoiding deep lock-in to any single platform.

He emphasizes: you're not building a Claude Code-exclusive AiOS — you're building your own personal operating system. Folder structures, Markdown files, skill definitions, and routing logic — these are your true digital assets that any coding agent can use. This mindset significantly reduces the anxiety of "chasing the latest AI tool releases." This design philosophy aligns with the "Separation of Concerns" principle in software engineering: decoupling the data layer (your knowledge and preferences) from the execution layer (specific AI tools), so that when more powerful models or tools emerge, you only need to swap out the execution engine without rebuilding your entire knowledge system.

Practical Tips for Building Your AI Second Brain

For those looking to start building their own AI operating system, here are several proven, pragmatic recommendations:

1. Zero coding experience required to get started: Start with an empty folder on day one, and you can have a basic system running within a day
2. Treat AI as a thinking partner but maintain skepticism: Have sub-agents debate each other, providing different perspectives to aid decision-making. This approach is known as "Multi-Agent Debate" in AI research, and studies show that having multiple AI instances examine the same problem from different angles can significantly reduce single-model bias and hallucination (the phenomenon where AI confidently generates incorrect information), thereby improving the reliability of final decisions.
3. Have AI verify its own work: This simple step can boost output completeness from 70% to 92%. The technical principle behind this strategy is that when AI is asked to "check and correct its own output," it effectively performs a second round of reasoning, equivalent to introducing a built-in quality review step. This mirrors the "Code Review" mechanism in software development.
4. Manage costs wisely: The $200/month plan is generally sufficient for daily use, but be especially mindful of quota consumption when using Fable
5. The key to team adoption is people, not technology: The biggest challenge isn't building the system — it's driving adoption. You must master it yourself first before you can effectively communicate its value

Key Takeaways