MaJu Tech Notes

This guide groups the posts that document a personal AI operating stack: home-server choices, local inference, image pipelines, and the cost realities behind them. Recommended reading order Local AI Infrastructure Notes — Why I Chose a Mac Mini M4 as My Home Server Local AI Infrastructure Notes — Access Your Home Server with Tailscale VPN Local AI Infrastructure Notes — Building an Inter-Agent Message Hub Local AI Infrastructure Notes — Automating Services with launchd Local AI Infrastructure Notes — Home Server Dashboard Design Local AI Infrastructure Notes — Best Local LLM Setup on macOS Local AI Infrastructure Notes — Local LLM Acceleration and Quantization Deep Dive Local AI Infrastructure Notes — The Hidden Trap in Qwen3 Thinking Mode Local AI Infrastructure Notes — Replacing the Local LLM from Qwen3.5 to Gemma 4 Local AI Infrastructure Notes — Mac Mini M4 Local LLM Benchmark Local AI Infrastructure Notes — Auto-Generating Blog Images with Nano Banana 2 Local AI I...

This guide groups the posts that ask not “how do we make the agent smarter?” but “what do we still have to design so the agent stays usable, auditable, and recoverable?” Best entry path Agent Operations Design Notes — Agent Team Design 101 Agent Operations Design Notes — Agent Evaluation Is Closer to Regression Testing Agent Operations Design Notes — Where to Draw the Line Between Allow, Ask, and Deny Agent Operations Design Notes — How to Design an Approval Loop Agent Operations Design Notes — Why Sandboxing Is a Quality Structure Agent Operations Design Notes — What Teams Still Have to Design in the Managed Agents Era Agent Operations Design Notes — Four Things Teams Still Need to Own in the Managed Agents Era Agent Operations Design Notes — What a Good Agent Runtime Looks Like Agent Operations Design Notes — Multi-Subagent RAG Is a Role System Shorter paths by need Team boundary first: 1 → 6 → 7 Safety and control first: 3 → 4 → 5 Evaluation and runtime first: 2 ...

This series guide is for readers who do not want to treat notes, ontology, memory architecture, handoff, and post-RAG context design as separate topics. Who this guide is for Readers who want a structural view of Second Brain design, not app recommendations Readers whose understanding of ontology, graph databases, memory, and handoff is still fragmented Readers who want to connect classic knowledge-system design with context intelligence after RAG Recommended reading order Ontology and Memory Systems — What a Second Brain Is Beyond Simple Note-Taking Ontology and Memory Systems — Why Ontology Matters in Knowledge Management Ontology and Memory Systems — What Problem a Graph Database Solves Ontology and Memory Systems — What LangChain Actually Does in a Knowledge System Ontology and Memory Systems — What a Good Agent Memory Architecture Looks Like Ontology and Memory Systems — Handoff Design Comes Before Memory in Long-Running Agent Operations Ontology and Memory Syste...

← 10/13 What Problem a Graph D… 📚 Series Index 12/13 From Searchable Notes… → Why This Question Matters When people first hear about LangChain, they often think it is "the AI" itself. That is not correct. LangChain is usually not the model, not the database, and not the knowledge itself. In a knowledge system, its main job is orchestration. It helps connect separate parts so the system can move from a user question to a useful answer in a repeatable way. If an LLM is the brain that writes language, LangChain is closer to the workflow manager that decides: what information to fetch which tool to call how to format the prompt how to pass results from one step to the next So the real question is not "Is LangChain intelligent?" The better question is: "What work does LangChain coordinate around the model?" The Core Role: Orchestration In a knowledge system, many parts must work together: an LLM to generate or transform language a retriever t...

← 9/13 Why Ontology Matters i… 📚 Series Index 11/13 What LangChain Actuall… → Why This Question Matters When people first hear the phrase graph database , they often imagine a tool for drawing charts. That is not the main idea. A graph database is designed for a different problem: storing and exploring connections between things when those connections matter as much as the things themselves. If you are building a second brain, this matters quickly. Notes are not isolated. A book connects to an idea. An idea connects to a project. A project connects to a person, a deadline, and a decision. When knowledge grows, the real value is often hidden in those links. The Core Problem: Information Is Connected Many systems are good at storing individual items. A folder system is good at storing files. A spreadsheet is good at storing rows. A relational database is good at storing structured records in tables. But connected knowledge creates a harder question: How do we represent no...

← 8/13 What a Second Brain Is… 📚 Series Index 10/13 What Problem a Graph D… → When people first build a second brain, they usually focus on collecting more notes. They clip articles, save quotes, highlight books, and tag everything. For a while, this feels productive. But after enough material piles up, a new problem appears: the knowledge is stored, yet it is still hard to use. This is where ontology matters. Ontology sounds like an abstract word from philosophy or computer science, but in knowledge management it answers a practical question: what kinds of things exist in your system, and how are they related? If your notes are only a pile, retrieval depends on memory and luck. If your knowledge has an ontology, retrieval becomes easier because the system has shape. What Ontology Means in Plain Language In everyday knowledge work, ontology is the map of concepts and relationships inside a system. It defines things such as: what counts as a note what counts as a topic wha...

← 7/13 Handoff Design Comes B… 📚 Series Index 9/13 Why Ontology Matters i… → Many people take a lot of notes and still feel more confused over time. They wrote something down somewhere, but later they cannot find it, or they find it and no longer understand why it mattered. Then they end up thinking the same thought again from scratch. At that point, the problem is usually not that they took too few notes. The deeper problem is that their notes were designed only to capture information, not to support future thinking. That is where the idea of a Second Brain becomes useful. A Second Brain is not mainly about collecting more notes. It is about redefining the role of information you keep outside your head. Simple note-taking says, "Write this down so I do not forget it." A Second Brain says, "Shape this so I can think with it again later." This article does not start with app recommendations or productivity templates. It starts with the concept itself. What is ...

← 11/13 What LangChain Actuall… 📚 Series Index 13/13 What Comes After RAG?… → Korean original: https://maju-not.blogspot.com/2026/06/second-brain.html The next Second Brain will likely not be defined by how well it stores and retrieves notes. Its real advantage will come from assembling the right context for the current task, promoting repeated signal into durable memory, and coordinating small role-based units into action. For the last several years, the promise of the Second Brain was straightforward: capture more, organize better, retrieve later. Note apps, tags, linked notes, highlights, and search pipelines all fit that worldview. In an age of information overload, building a personal archive you could return to later was already meaningful progress. But knowledge work rarely breaks down because information is missing. More often, the problem is that there is too much of it. Old notes do not line up cleanly with the current problem. Search returns documents, but not judgm...

← 8/9 Why Sandboxing Is a Qu… 📚 Series Index (series end) Korean original: https://maju-not.blogspot.com/2026/06/rag.html It is easy to assume that wiring together many small RAG units will automatically produce a smarter system. What actually changes is much deeper. The problem is no longer that retrieval happens multiple times. The problem is that you now have to decide who is allowed to retrieve what, which evidence may cross boundaries, and which results deserve promotion into longer-lived memory. Single-pipeline RAG is easy to explain. A question comes in, the system retrieves a few relevant documents, and the model answers with that context attached. That structure still works well for document Q&A, internal wiki search, and FAQ-style tasks. But the moment work becomes longer-running, the document space splits into domains, and judgment has to happen in several stages, the simple pipeline starts to break down. Retrieval no longer ends in one pass, and even within the ...