Chronicle of building a second brain with a knowledge graph, bilingual pipeline, and agent endpoints — in days, not weeks, and what that teaches about the gap between theory and working systems.
On a Friday in March 2026, I watched a video by Nate B Jones titled "Why 2026 Is the Year to Build a Second Brain". His thesis: the second brain is no longer a passive storage system — it's an active system that works while you sleep. He defined 8 building blocks, and in a later publication an architecture with Postgres and MCP at a cost of $0.10-0.30/month.
I closed the video and opened my terminal. I wasn't going to take notes about how to build a second brain — I was going to build it. That weekend.
48 hours later, jonmatum.com existed. A Turborepo monorepo that transforms MDX files into a navigable knowledge graph. Over the following days, the system kept growing — and still is. At the time of writing:
/llms.txt, /api/knowledge, /api/graph, /api/mcpThe speed was possible because of an early decision: don't write 131 perfect concepts — write 131 seeds. A seed is a 150-word stub with valid frontmatter and status: seed. It doesn't need to be complete to exist in the graph — it just needs to be correct. The graph benefits from coverage as much as from depth.
But the speed was also possible because I used AI agents to assist generation. Without that assistance, 156 bilingual items in days would be impossible. Jones describes exactly this model: the human captures the thought, AI handles the rest. But in practice I found the line is blurrier — the human also decides what to deepen, which connections matter, and when the AI's output needs rewriting. It's not human capture + AI automation — it's a continuous cycle of human judgment assisted by AI.
Once the system existed, I evaluated it against Jones' framework. The results were revealing:
Jones: private Slack channel, zero friction.
jonmatum.com: MDX files in content/, AI-agent assisted.
Status: partial. Capturing a thought requires creating an MDX file with 11 frontmatter fields and committing. Content generation is AI-assisted, but capture friction remains high compared to typing in a Slack channel.
Jones: AI agent that auto-classifies without user intervention.
jonmatum.com: type: set by the author, tags and cross-refs suggested by agents.
Status: partial. Classification is a human decision — the author chooses whether something is a concept, note, experiment, or essay. Agents suggest tags and cross-references, but don't auto-classify.
Jones: fixed schema per type (name, status, next action).
jonmatum.com: frontmatter with 11 fields validated by pnpm validate.
Status: complete. Every content type has a strict schema. The pipeline rejects files with missing fields or incorrect types.
Jones: Notion databases for people, projects, ideas, admin.
jonmatum.com: content/{concepts,notes,experiments,essays}/.
Status: complete. Four directories by content type, each with its own maturation pattern.
Jones: Inbox Log documenting every classification and system action. jonmatum.com: Git history (264 commits) + GitHub Actions job summaries. Status: complete. Every change is recorded with author, date, diff, and message. Agent workflows generate summaries with each job's result.
Jones: confidence score 0-1; below threshold, the item goes to review instead of being filed.
jonmatum.com: validation pipeline (validate + generate:content + lint:content) + agent review before commit.
Status: complete. The pipeline rejects content that fails schema or linter checks. Agents create PRs — they never commit directly to main. The human is the final bouncer.
Jones: daily and weekly digests sent automatically with relevant information. jonmatum.com: weekly QA agent that audits content and opens issues with findings. Status: partial. The QA agent identifies concepts with missing references, broken cross-refs, weak sections, and incorrect headings — and opens issues automatically. It's proactive surfacing of quality problems, but not of relevant content for the user. The personalized digest Jones describes is still missing.
Jones: simple chat commands to reclassify misclassified items. jonmatum.com: three-agent system that audits, fixes, and upgrades content. Status: complete. The QA agent detects problems, the fix agent applies surgical corrections, the content agent generates full upgrades. All three create PRs for human review.
Blocks 3-6 and 8 are solid. Block 7 went from missing to partial thanks to the weekly QA agent — but it still lacks the personalized surfacing component (digests with relevant content, not just problems). Blocks 1-2 remain partial: capture has friction and classification is manual.
What the evaluation doesn't show is that the architecture already contained the right principles without having read them. Jones insists on separating memory, compute, and interface. The monorepo already did that:
content/ — plain text, portable, no vendor lock-inpackages/knowledge/ — parser, graph builder, llms.txt generator, embeddingsapps/web/This separation proved itself when semantic search failed in production. I could revert to keyword search without touching content or the graph — I changed the interface, memory stayed intact. The stack is deliberately generic: MDX, JSON, Next.js. If tomorrow I want to migrate to Astro or DynamoDB, the MDX content remains the same.
Jones also describes a "shared surface with two doors": the agent enters through one, the human through the other. At jonmatum.com the human door is the website; the agent door is /llms.txt, /api/knowledge, /api/graph. But the agent door is read-only. Jones proposes both doors read and write. That's the biggest gap — and the one I'm most interested in closing.
I attempted semantic search with @huggingface/transformers (Xenova/all-MiniLM-L6-v2) running via WebAssembly in the browser. It failed for three reasons:
tolist(), .data, and output[0] behave differently between Node.js and browser WASMI reverted to instant keyword search. Pre-computed embeddings are still generated at build time for future use.
This is what Jones calls the implementation gap. McKinsey reports that 88% of organizations use AI in at least one business function, but only 6% are "high performers" who attribute significant earnings impact to AI. Client-side semantic search is a perfect example: works in demos, fails in deployment. The gap isn't knowledge — it's practical integration.
Jones' block 1 — the Dropbox — requires zero friction. Capturing a thought in jonmatum.com requires: creating an MDX file, writing frontmatter with 11 mandatory fields, writing content in Spanish, creating the .en.mdx file with the translation, and committing. That's a 15-30 minute process per concept. Low-friction capture is the next problem to solve.
My native language is Spanish. Writing in Spanish is natural — ideas flow without the friction of mentally translating. But I wanted my team and technical community to read the content, and English is the industry's language. At the same time, I wanted my family and friends who don't speak English to access what I'm building.
That tension defined an architectural decision: Spanish as the primary language (the default site), English as translation (available at /en/...). Every concept has .mdx (Spanish) and .en.mdx (English). Frontmatter includes title_es/title_en and summary_es/summary_en.
The cost is real: ~244,000 total words across both languages — roughly double the content of a monolingual system. But the decision created something I didn't expect: a natural separation between Jones' two doors. AI agents consume /llms.txt in English — the language LLMs perform best in. Spanish-speaking humans read the site in Spanish — no barriers. One graph, two interfaces.
I found no other public second brains that are bilingual. The PKM ecosystem is overwhelmingly monolingual. Is it sustainable at scale? With AI-assisted translation + human review, yes. Without AI, at 500+ items manual translation would be a bottleneck.
What I didn't anticipate was how much work would come after the initial sprint. Creating 131 seeds was fast — bringing them to evergreen is another story.
The maturation process follows a pattern: I take a ~350-word seed concept and expand it to 700+. I add comparison tables with real tools, working code examples, mermaid diagrams with accTitle and accDescr for accessibility, and a "Why it matters" section written from a staff+ engineer's perspective. Every reference is verified with curl before committing. Then I replicate the exact structure in the .en.mdx file.
After upgrading 46 concepts to evergreen — from serverless to web components, from embeddings to agentic workflows — I discovered something: the value isn't in the initial seed but in the connections that emerge during expansion. While deepening prompt caching, connections to inference optimization appeared that didn't exist in the seed. While expanding RAG, the edges toward embeddings and vector databases strengthened with concrete examples.
But the manual process doesn't scale. At 10 concepts per week, the remaining 85 seeds would take over two months. So I built something that wasn't in the original plan: a three-agent system that automates the content lifecycle.
A QA agent audits the 46 evergreen concepts weekly — checks word count, references, cross-refs, diagram accessibility, headings in the correct language — and opens GitHub issues with findings. A fix agent applies surgical corrections: add a missing reference, diversify quality tiers, translate a heading. A content agent generates full rewrites to bring seeds to evergreen. All three use Strands Agents with Claude Sonnet 4 on Amazon Bedrock, run in GitHub Actions with OIDC authentication (no static secrets), and create PRs for human review.
The execution pattern is a "diamond": a plan job discovers work and generates a JSON matrix, parallel jobs process each item in isolation, and a summary job consolidates results. LLM workflows serialize jobs (max-parallel: 1) to avoid Bedrock throttling; the structural QA — which doesn't use an LLM — keeps high parallelism.
The result: the human shifted from writer to editor. Instead of expanding each concept manually, I review PRs generated by agents. Quality remains my responsibility — the agent proposes, I approve — but throughput multiplied.
The graph doesn't just grow in nodes — it grows in density. And density is what turns a collection of notes into a knowledge system. Today, after adding a tag system with 460 browsable tags, a dashboard with graph health metrics, loading skeletons for every route, and mobile-first design, the system is at 80% of what I imagined that Friday.
jonmatum.com runs on Vercel today — instant deploys, automatic SSL, global CDN. For a static site with 155 nodes, it's perfect. But the missing blocks — low-friction capture, proactive surfacing, agent write access — require stateful backend. And as an engineer passionate about AWS serverless, that suite is where I have the most experience and control.
The target architecture:
Each service maps to one of Jones' blocks:
| Jones' block | AWS service | Function |
|---|---|---|
| 1. Dropbox (capture) | API Gateway + Lambda | /api/capture endpoint — accepts text + URL, creates item in DynamoDB |
| 2. Sorter | Lambda + Bedrock | Auto-classifies type and suggests tags |
| 3. Form (schema) | DynamoDB | Schema validated in the write Lambda |
| 4. Filing Cabinet | DynamoDB | Content type tables with secondary indexes |
| 5. Receipt | DynamoDB Streams | Every mutation generates an audit record |
| 6. Bouncer | Lambda | Quality validation before persisting |
| 7. Tap on the Shoulder | EventBridge + Lambda + SNS | Daily cron that identifies forgotten seeds and sends digest |
| 8. Fix Button | Bedrock AgentCore | Agent with MCP tools to edit, reclassify, connect nodes |
What makes this architecture interesting is that it closes the remaining gaps without abandoning the principles that worked:
Estimated cost at current scale (155 nodes, ~100 queries/day):
| Service | Monthly cost |
|---|---|
| CloudFront + S3 | ~$0.50 |
| API Gateway + Lambda | ~$0.10 |
| DynamoDB (on-demand) | ~$0.25 |
| Bedrock (embeddings + chat) | ~$1-3 |
| EventBridge + SNS | ~$0.01 |
| Total | ~$2-4/month |
Comparable to Jones' $0.10/month with Postgres, but with the advantage of scaling to thousands of nodes without changing the architecture. And no server to maintain.
The most interesting step isn't semantic search or AI chat — it's what happens when the agent door stops being read-only.
Today, an agent can query my entire knowledge graph via MCP. But it can't add a node, connect two concepts, or flag a seed as stale. With Bedrock AgentCore exposing tools like add_node, connect_nodes, flag_stale, any AI client could not only read my second brain but contribute to it.
That changes the nature of the system. It's no longer an archive I consult — it's a collaborator that grows while I work on something else. An agent that reads a paper and adds a seed concept. Another that detects two nodes should be connected and creates the edge. Jones' block 7 — proactive surfacing — stops being a cron that sends emails and becomes an agent that reorganizes the graph.
EventBridge runs a daily Lambda: seeds not updated in 7+ days, concepts with few connections, orphan nodes. But instead of just notifying, the agent can act — propose expansions, suggest connections, generate drafts for human review. The human still decides what gets published. But the system stops waiting for the human to remember it has pending seeds.
That Friday, when I closed Jones' video and opened my terminal, I didn't know three things I know now:
The implementation gap isn't technical — it's editorial. Infrastructure was built in hours. Content takes weeks and is still incomplete. 85 seeds await maturation — now with agents accelerating the process. AI accelerates writing but doesn't replace the judgment of what's worth deepening and which connections matter. The second brain automates the system, not the thinking.
The graph is more valuable than the nodes. 156 individual concepts are a personal encyclopedia. 412 edges between them are a knowledge system. Density — the connections that emerge when you deepen a concept and discover it touches three others — is what makes the second brain more than the sum of its parts.
Bilingual isn't a feature — it's a stance. Deciding that my family can read the same thing my AI agents consume wasn't a technical decision. It was deciding who I build for. And that decision, more than any Lambda or endpoint, is what makes this second brain mine.
The next step — taking this prototype to production — I explore in "From Prototype to Production: A Serverless Second Brain".
Data structures representing knowledge as networks of entities and relationships, enabling reasoning, connection discovery, and semantic queries over complex domains.
Open protocol created by Anthropic that standardizes how AI applications connect with external tools, data, and services through a universal interface.
Field of computer science dedicated to creating systems capable of performing tasks that normally require human intelligence, from reasoning and perception to language generation.
Autonomous systems that combine language models with reasoning, memory, and tool use to execute complex multi-step tasks with minimal human intervention.
Proposed standard for publishing a Markdown file at a website's root that enables language models to efficiently understand and use the site's content at inference time.
Information retrieval technique that uses vector embeddings to find results by meaning, not just exact keyword matching.
Dense vector representations that capture the semantic meaning of text, images, or other data in a numerical space where proximity reflects conceptual similarity.
Architectural pattern that combines information retrieval from external sources with LLM text generation, reducing hallucinations and keeping knowledge current without retraining the model.
Open source SDK from AWS for building AI agents with a model-driven approach. Functional agents in a few lines of code, with multi-model support, custom tools, MCP, multi-agent, and built-in observability.
AWS serverless service providing access to foundation models from multiple providers (Anthropic, Meta, Mistral, Amazon) via unified API, without managing ML infrastructure.
React framework for full-stack web applications with Server Components, file-based routing, SSR/SSG, and built-in performance optimizations.
Code organization strategy where multiple projects coexist in a single repository, sharing dependencies, configuration, and build tooling.
Utility-first CSS framework enabling design building directly in markup using atomic classes, eliminating the need to write custom CSS.
Storage systems specialized in indexing and searching high-dimensional vectors efficiently, enabling semantic search and RAG applications at scale.
Practice of defining and managing infrastructure through versioned configuration files instead of manual processes. Foundation of modern operations automation.
Cloud computing model where the provider manages infrastructure automatically, allowing code execution without provisioning or managing servers, paying only for actual usage.
LLM capability to generate structured calls to external functions based on natural language, enabling integration with APIs, databases, and real-world tools.