Four principles for building AI systems, drawn from a community's diverse second-brain implementations
A solo presentation by Nate B Jones analyzing what emerged when his community built second-brain AI systems in dozens of different ways.
Summary
Nate B Jones follows up his earlier video on building a second brain without code by analyzing what happened when his community implemented that architecture using tools he never recommended. Rather than summarizing the builds themselves, he extracts four transferable principles that explain why some builders succeeded quickly while others got stuck. The central argument is that architecture is portable while tools are not — and that the combination of a community pattern library with AI implementation muscle has fundamentally changed the economics of building complex systems. He also walks through the actual Zapier automation flow in detail, responding to community requests, and closes with a broader reflection on how these build patterns represent a genuine shift in how humans construct software.
Key Takeaways
FULL TRANSCRIPT
The four principles
Nate B Jones: There are four principles that separate people who successfully build AI systems from people who get stuck and then just give up. I didn't learn these from a textbook, and I'm not making them up. I learned them last week from watching dozens of people build the same system in completely different ways.
Last week I posted a video about building a second brain without any code at all, and it got a lot of traction. But what happened next was much more interesting than the video itself, because it taught me how building actually works in 2026. People took the broad strokes — the architecture I described — and they implemented it in lots and lots of different tools, including tools I never recommended. That meant they hit lots of interesting walls, they got around those walls in interesting ways, and they ended up using AI not just inside the system as I suggested, but also to build the system.
Today I want to dig into that story and specifically call out four building principles that emerged from watching the community go through dozens and dozens of builds over the last week. Here's the frame I want you to hold through all of this: the second brain is just a project. What we learned building it is about how complex AI systems get constructed today, in a world where you have AI as a collaborator and peer, and building communities end up functioning as pattern libraries.
Principle one: Architecture is portable, tools are not
So let's start with the first principle. When I laid out the original video, I mentioned a specific stack. I talked about Notion for storage, Zapier for automation, and Claude or ChatGPT for intelligence. I mentioned the different jobs that these tools do — how you have to have something that's kind of a Dropbox, something that lets you put things away, something that sorts, something that acts to structure data. I went through the different principles.
People were able to take those principles and build on them with any kind of tool. The tools could be very interchangeable, and the architecture itself stayed very stable across all of those tools. One community member built their system using Discord, Obsidian, and Mac Whisper. Mac Whisper is a tool that transcribes audio locally on your Mac, and Discord is really the capture point that replaces Slack. They set up a Discord server with a special structure and added timed prompts — they really built it out. They used very different tools, but they came from the same principles. You can see the capture point. You can see the sorting that happens. You can see the intelligence layer.
The implementation details may be unrecognizable. They connected Mac Whisper to automatically process their Zoom recordings, send transcripts to Obsidian, and then they run a slash command that processes and files everything by project. Super cool. Definitely not something in the original build plan, but something that follows the arc — the structure where you're actually trying to process from a capture point, store it, and then make sure you can retrieve it in an intelligent way later.
This underlines how important it is to think about architecture consistently in the age of AI. You can end up in a place, if you have a good architecture, where you have a completely different tool stack. I did not suggest using Mac Whisper and Obsidian, but it still works because the architecture holds.
The implication is that when you're learning to build with AI, don't necessarily memorize the tools — learn the patterns. The tools will shift. Zapier might not be the right choice for you. Notion might not fit your workflow. But the patterns — the idea of how the second brain is constructed, that it needs a place to drop ideas that's clean, it needs a way to sort ideas — those are sticky patterns. Those are steady. Once you understand them, you can implement them anywhere.
Principle two: Principles-based guidance scales better than rules-based guidance
The second principle is that when you're working with AI, principles-based guidance scales way better than rules-based guidance. This goes for whether you're coaching, whether you're teaching, or frankly whether you're trying to learn for yourself.
One community member built their system using Claude's computer use capability combined with Obsidian and a custom TypeScript agent. They had a custom agent running on a VPS — a virtual server in the cloud — with remote access so they can connect to it from anywhere. Here's the part that caught my attention: they wrote an architectural best practices document that guides the coding agent through fixes when things go wrong. But instead of hard-coding specific rules, they were smart. They said, "Let's write principles." Things like: use test-driven development, use dependency injection, don't swallow errors. They essentially tried to give the agent smart software development principles so the agent could interpret those principles rather than following rigid rules.
This matters because AI systems are very good at applying judgment in context. They're not just pattern matchers executing if-then rules. When you give AI a principle like "don't swallow errors," it can figure out what that means in a hundred different situations you did not anticipate. When you give it a rigid rule like "always log errors to this specific file," you're limiting it to do only that one thing — which sometimes you need, but if you're trying to build with AI, it's often more useful to go with the principles-based approach.
The implication for building is really interesting. When you're writing prompts to build, you're effectively creating guidelines for AI systems. When you're designing workflows that AI will execute, it often makes sense to have AI lean toward principles that scale rather than just writing rules — unless you have a very deterministic workflow you're trying to encode. Give the AI room to exercise judgment where that makes sense. You'll get more robust systems that handle edge cases you didn't think of.
I also want to call out a meta layer that is really interesting. This build required writing principles for an agent to build a second brain system that itself used AI. There's a meta-pattern here that I've seen over and over again in successful 2026 builds: people who are leveraging AI to build their AI tooling are going much, much faster. And it's another example of how principles can scale. If you can write an agent that builds your second brain for you, and your agent relies on good software design principles — don't swallow errors, use test-driven development, separate your concerns — you're going to be able to reuse that build agent in other places. Principles-based guidance scales in lots of different ways. It's a fractal principle. It helps us remember things better. It helps us build directly better. It also helps us build agents that can build more than one thing.
Principle three: If the agent builds it, the agent can maintain it
The third principle is that if the agent builds it, the agent can maintain it. One of the most ambitious community builds came from someone who created what they called a meta-agent framework. Instead of wiring up individual tools, they built an agent that coordinates between Claude Code, Codex, Copilot, and Goose — all different AI coding assistants. They implemented what's called a writer-critic loop for reliability, where one agent produces output and another agent validates it, catching errors before they propagate. The agent can then set up cloud infrastructure automatically and generate user interfaces on demand. This is much more than just a second brain.
The insight that really stuck with me is that they said their goal was to enable the agent to set up the infrastructure rather than doing it themselves — because if the agent sets it up, the agent understands it, which means the agent can self-correct and self-heal long after you've forgotten how the system works. This ends up being more like a second brain for an engineer who's coding a lot than a traditional second brain build. But by having the agent construct it, you have agent maintainability, which I think is going to be a big theme in 2026.
Think about what this means. If I build something myself, I understand it when I'm building it. But six months later, I have to pick up a lot of context to get back into it. Anyone who has worked with engineers or built something themselves knows there's something called switching cost — you have to get back into the mindset and understand the codebase before you can make meaningful changes. It's non-trivial time, and it doesn't look productive because you're just trying to recover your memory. The configuration details, the edge cases you handled, the reasons you made certain choices — all of that fades away.
When an agent builds something with you and you keep that conversation context, you keep the artifacts you created together. The agent can come back and return to debug and extend and maintain the system. And if you've prepared the memory environment correctly, you can reinstantiate the agent — reinvoke it with all of the memories associated with that particular build — and it's fresh. There's no context switching. The documentation ends up being the build process itself. You can re-bring it back to life, and the agent will just continue to go and do its work.
The implication is that when you're building with AI, consider involving the AI in the construction process, not just the execution. And I would go further than that. In 2026, you should be defaulting to involving AI in the construction process. Let it help you set things up. Keep the conversation going. When something breaks in six months, you can come back to that conversation and the AI will help you pick up the context you've lost.
Even if you're a non-coder, this has never been easier. Claude launched Co-work this past week, and Co-work can hook into the Claude extension in Chrome. You can just ask Claude Co-work to work with your Chrome instance and it will use your browser and build things. People were doing that as part of their build process for this second brain in the Substack chat.
Principle four: Your system can be infrastructure, not just a tool
The fourth principle is that your system can be infrastructure, not just a tool. Most people who built the second brain did treat it as a personal productivity tool — that was the original intent. You capture thoughts, you file them, you get digests. But at least one community member saw something different. They built a hybrid database approach using Postgres for structured data combined with a vector database for semantic search. A vector database lets you search for meaning rather than exact keywords, so you can ask something like "what did I capture about customer onboarding?" and find relevant entries even if they don't contain those exact words. Then they built an API endpoint that lets other applications query their second brain, and they're working toward a reusable SDK — a toolkit that other developers can use to connect any application to their personal knowledge base.
This is someone who saw that the second brain is not just a personal productivity tool, but a piece of infrastructure that they can build other tools and systems on top of. I think this shows the kind of higher-level systems thinking that we need a lot more of to build compounding advantage in 2026.
There's another build that illustrates the same principle. Another builder went deep with Qdrant for vector search, Neo4j for graphing relationships, and Postgres as the central system of record. They have multiple Claude agents coordinating with a layer they call a "skills plus evidence" layer, where generated content comes with built-in receipts showing what sources informed each output across the entire system. This is definitely not a non-technical build — it's an engineering build — but it demonstrates that you can take the same architectural patterns and they will scale from simple to very sophisticated, and the principles will not break.
The other thing I'll call out is that the engineering skills added here enable you to do and realize larger pieces of work. If you want to think about the second brain or any software project in a broader lens — if you want to say this is not just a personal productivity tool, this is a piece of infrastructure, I want to do something bigger with it — the more you're able to scale your technical skills, the farther you're going to be able to take that vision.
This is one of the things I keep emphasizing that is counterintuitive: technical skills have tremendous value in 2026. Don't listen to people who say that engineering is dead. Engineers over the last week were able to do much more interesting things with their projects because they can use AI to go further, and because they have the technical domain knowledge to know where to push AI to help them build. If you're trying to learn technical skills, it's never been easier. You can learn them with AI more easily than ever before. You can get custom AI coding instructions delivered to you every morning in ChatGPT if you set a scheduled task.
Zooming back to the broader implication: if you are building something, you should be asking yourself whether it's a tool or infrastructure. A tool solves a problem. Infrastructure enables others to build on top of the solution you've constructed. If you design with infrastructure in mind, you create much more leverage than if you're just building a personal productivity tool. That kind of systems thinking is going to be more and more valuable in 2026 as we're looking to hit another layer of abstraction as humans managing systems of agents.
Your second brain can power a daily digest, and that's super helpful. But if you're using it to power your entire workflow — your meeting prep, your email drafts, your project planning, an entire chief-of-staff operation — that initial investment pays much more dividends. You're going to need more technical skills to go after it, but it'll be worth it.
Minimalist builds and the session-based vs. always-on split
Let me add one more build that illustrates something different. One community member went super minimalist. They're using Notion's mobile export feature as their capture mechanism — not Slack. They capture thoughts on their phone, export to Notion, and Claude just processes their inbox on schedule and sorts everything into an outbox. The whole system is essentially just an inbox and outbox with AI processing in between. No Zapier, no automation chain — just Notion and a scheduled Claude call.
You can do another version of simple with YAML files, which are just declarative files that developers use to talk about business rules. Another builder swapped out Notion entirely for local YAML files — a simple text format for storing structured data — and kept Slack as the capture layer because they're in Slack all day anyway and it's frictionless from their phone. But instead of using Zapier as the automation layer, they used Claude Code, which lets you have a conversation with Claude while it reads and writes files to the computer. The key difference is that their system is session-based rather than always-on, which is what they preferred. When you sit down to work, you spin up a Claude Code session that processes your inbox, runs the classification, writes to local YAML files, and then gives you a fix button in that same conversation.
The point is not that you copy these builds. These different builds illustrate that you don't necessarily need complexity to get the benefits. You might be a non-engineer and say it's simpler to use Notion in and out. Or an engineer who just wants to do YAML files. Regardless, you can start very simple and the principles still work. The architecture supports something that simple as well as something as complex as some of the builds I discussed earlier.
How community plus AI changed the economics of building
Here's the pattern that emerged that I think represents something genuinely new about how building works in 2026. The people who got their systems working fastest were not the ones who followed my tutorial the most carefully. Instead, they were the ones who combined community knowledge with AI collaboration. They would hit an obstacle, post in the Substack chat, get a pointer from someone who'd solved a similar problem, and then work with Claude or ChatGPT to implement the fix in their own context.
One community member posted that she built the entire system in two hours by just having Claude do it in the browser for her. She gave the architecture document to Claude and said, "Just solve it." She'd already read through the community discussion, she had some idea of what to do, and she just said go. This is the new model. Community provides a pattern library for us to understand where common obstacles emerge. AI provides implementation muscle so we can do other things while builds happen. Our job is to provide the context and the judgment about what applies in our specific situation — and frankly to provide the intent, to say this is how I want to express these larger principles in a way that works for me.
This is why SaaS tools for second brains are so hard to build. Everyone's brain is different. The beauty of architecture is you can build your own second brain the way you like it. The tutorial alone will not adapt to all of the tools that are your favorites, and it doesn't need to. And even the AI alone will not know what other problems people have already solved. The community is going to be critical for you to be able to succeed building long-term. I don't mean my community in particular — find your build community that works for you. Having a community that has a pattern library is super useful because it can supercharge your ability to acquire context and strategically allocate that context with your AI to build faster. That's what I saw this week.
A tour of the Zapier automation flow
Now let me give you a quick tour of what the Zapier automation actually looks like when it's built. I got lots of requests for this, so I'm excited to show it.
The flow starts with a Slack trigger. When a new message is posted to your SB inbox channel, Zapier captures it, and the trigger gives you access to the message text, the channel ID, and all the details. The message text then goes directly to Claude via an API call. The Anthropic action in Zapier sends a classification prompt along with the raw message. The prompt specifies the JSON schema, tells Claude to classify into one of four categories, and asks for a confidence score, which I talked about in the last video.
After Claude responds, a "Code by Zapier" step in step three cleans up the response. This step removes any markdown formatting, parses the JSON, and flattens the nested structure you get from the LLM into fields that are easy to reference in later steps. If Claude returns something that's malformed or incorrect, this code step can handle it gracefully.
Next, we have to route. A path step checks the destination field from the parsed response. If it's "people," the flow goes down the people path — you get the idea. Each path does a few things. First, it creates a record in the appropriate Notion database based on the routing done in the previous split. Then it creates an entry in the inbox log with the original text, where it was filed, the confidence score, and the Slack thread — this is the receipt I talked about in the original video. Finally, it sends a Slack message back to let you know it processed everything. A Slack message might look like: "Filed as People — Sarah Chen — confidence 87 — reply 'fix' if I got it wrong."
That's how it works for people, projects, ideas, and admin. The needs-review path is a little different. Instead of filing to a destination database, it logs the item with a needs-review status and sends a Slack reply asking for clarification — something like, "I couldn't confidently classify this. Can you repost it with a prefix like 'person' or 'project'?"
That's really the complete flow. One trigger at the top, one AI call, then you parse it and run different parallel paths. You can build this in n8n. You can build it in Make. Again, the principle is what matters, not the tool.
Lessons specific to second-brain building
As a bonus, I want to share a couple of things that emerged from the community that are specifically relevant to how we think about these tools in the second-brain project.
First, Zapier has limitations that become apparent at scale. It was designed as an easy entry point and does that well, but it has trouble handling larger loops. It doesn't branch and reconverge for more complex workflows, so it doesn't work if you're trying to do more advanced work.
Second, the storage backend matters less than you might think. A lot of people are using Notion, Obsidian, YAML files. If you have an existing system that has a storage bucket, that's probably good enough.
Third, if you're building a second brain, capture interfaces really should just be where you already live. If you're in Slack, do it in Slack. Discord works. Google Chat works. Frankly, you can probably rig this up with text messages.
Fourth, there's an emerging split between session-based and always-on approaches. The Zapier flow I showed is designed to be always-on — messages get processed automatically whether you're engaged with them or not. The Claude Code approach is session-based — you process your inbox when you sit down to work in conversation with the AI. It doesn't pre-process for you. Both patterns are fine. Always-on is better if you really want to offload the mental load. Session-based gives you much more control and the ability to ask questions during processing and shape it. This is why one-size-fits-all second-brain solutions don't work. You have to decide what works for you.
Finally, and this is where things get interesting, there's movement toward AI agent-generated interfaces. Instead of building a fixed dashboard in Notion and hoping it will serve your needs forever, some builders are generating UI on demand. When they need a particular view of the data, they ask Claude to create it. I found myself doing this on a different application in Claude Co-work just this week. I can see this is going to be a pattern that starts to emerge more broadly.
What this reveals about how building is changing in 2026
Let me close with a reflection on how this all reshapes my own thinking on second-brain building and how AI is shaping what we as a species build and do in the coming year.
The second brain was just the project, but the way we built it revealed that we are changing build patterns we've held steady for a long, long time. As I shared in my previous video, we've had the same cognitive architecture for about half a million years — a few items in working memory, terrible retrieval. The second brain was designed to help with that.
What's different in 2026 is that the combination of community plus AI is really changing the economics of building. Community creates a shared pattern library that evolves in real time. Community helps us figure out a better way to handle a confidence threshold, to get around an obstacle, and everybody benefits quickly. AI is what provides the implementation muscle to adapt all of these community patterns to fit our particular context.
The gap between "I understand what someone else did" and "I can do the equivalent" used to be where a lot of projects went to die. Now AI can help us bridge that gap. You no longer need to be an engineer to construct sophisticated systems. And I'm beginning to think the more important thing is not to be an engineer, but to have a community and to have access to an AI you're willing to push — because you can acquire the technical skills you need with AI more easily than ever before.
This community proved that principles are portable. People can build in any tool they want — Discord, Obsidian, wherever. What matters is that you're able to understand what works for you, how you want to scale build principles, and how you want to use AI to build more quickly. That feels like a really big extension from the original idea in the video. In the video I was saying the second brain itself, the tool itself, is a big deal — and that's still true. But the build pattern we're seeing is an even bigger deal, because it means we can take this practice of building in community, using AI to leverage and accelerate our builds, being really flexible with the tools so they fit what we need, and we can build faster than we've ever built before.
For so long, building has been top-down. You get an instruction from someone at work, or you try a weekend project and you have to plan it out and do every single line yourself. It's how we built the pyramids and it's how we built software for a long time. That's not true anymore. Now we have the ability to very rapidly digest, meld, and understand the best of the build communities around us, and we can implement it quickly because AI is getting good enough to provide real implementation muscle. We have build superpowers we have never had before — and they are not technically gated. That makes 2026 a really exciting year to be a builder.