Open Source AI Second Brain Lessons Learned

How I Contributed to Awesome Second Brain — And What I Learned From Getting Rejected

June 16, 2026 · 12 min read

What is Awesome Second Brain?

awesome-second-brain is an open-source curated comparison of AI second brain, memory, and knowledge systems. It's not a product — it's a decision-making resource.

The repo maps the full second-brain lifecycle — Collect, Organize, Evolve, Use, Govern — and compares tools across those stages. It covers everything from end-to-end apps like Membase and Khoj, to local workspaces like GBrain and Obsidian, to agent memory layers like Honcho and Supermemory.

The goal: help people answer "what should I use?" and "what tradeoffs am I signing up for?"

It has 200+ stars, active maintainers, and a strict contribution bar. Claims must be sourced. Metadata must be accurate. Broad claims must be narrowed to evidence.

I contributed a solution profile, setup guide, example workflow, and comparison page for an assembled stack: Hermes Agent + Obsidian + Honcho.

This is the full story of that contribution — including the parts where I got it wrong.

What I Contributed

1. Solution Profile

A full core profile covering deployment model, lifecycle coverage across all 5 stages, a 10-area capabilities matrix, strengths, limitations, best-fit/non-fit users, tradeoffs, and official links.

2. Setup Guide

A step-by-step guide covering architecture (local vs hosted), prerequisites, Honcho SDK installation, Hermes integration, AgentMail SDK configuration, full-stack verification, known failure modes, and a ~60 minute time estimate.

3. Example Workflow

A practical scenario: daily email triage. Agent checks AgentMail inbox via SDK, categorizes by priority, logs to Obsidian daily journal, updates Honcho with contact conclusions, replies via AgentMail SDK.

4. Comparison Page

Assembled stack vs end-to-end app, compared across 8 dimensions: setup time, operations, inspectability, portability, customization, cost, failure modes, and best-fit users.

The PR Timeline

Two rejections. Three rounds of fixes. One merged PR.

Round 1: The First Rejection

Mistake 1 — Unverified Implementation Details

The setup guide included commands I had not verified against official documentation. The most egregious example: a Python snippet that read ~/.hermes/config.yaml directly and a script called ~/.hermes/scripts/agentmail_cli.py — a file that does not exist anywhere in the Hermes Agent repository or documentation.

I wrote these from memory and assumption. I assumed the config lived in config.yaml because many tools use that pattern. I assumed there was a CLI script because I had seen similar patterns in other projects. I was wrong on both counts.

Mistake 2 — Metadata Inaccuracies

The snapshot table had factual errors:

Mistake 3 — Overbroad Claims

The comparison page made sweeping claims that were not true for every component:

What I Fixed

Round 2: The Second Rejection

Even after the first round of fixes, the maintainer found remaining issues. The same categories — unverified details, metadata, and broad claims — but more subtle this time.

The key lesson: fixing the obvious mistakes is not enough. You need to re-verify everything, including the things you think you already fixed.

I had corrected the big errors but left smaller ones. A phrase like "commands verified against official documentation" survived the first round because I was focused on the broken scripts. But that phrase was itself an unverified claim — I had not actually verified every command against the official docs at that point.

What I Fixed

The Final Fix: What Actually Got Merged

The merged PR (commit b4df09c) contained 105 insertions and 65 deletions across 4 files:

solutions/hermes-obsidian-honcho.md — 3 line fixes

- Company / maintainer: Nous Research (Hermes Agent), Plastic Labs (Obsidian MD), Obsidian MD (Obsidian)

+ Company / maintainer: Nous Research (Hermes Agent), Plastic Labs (Honcho), Obsidian MD (Obsidian)

- Status: Active public repos

+ Status: Mixed — Hermes Agent and Honcho have public repos; Obsidian is proprietary

- Open source: Hermes Agent is open source (Apache 2.0)

+ Open source: Hermes Agent is open source (MIT)

setup-guides/hermes-obsidian-honcho.md — major rewrite

examples/daily-email-triage.md — SDK replacement

comparisons/assembled-stack-vs-app.md — claim narrowing

What I Learned

1. Verify Before You Write, Not After

The biggest mistake. I wrote the setup guide from memory and assumption. I assumed config.yaml because many tools use that pattern. I assumed a CLI script existed because I had seen similar patterns. Neither was true.

The fix: Before writing any command or claim, open the official docs. Find the exact page. Copy the exact command. Link to the page. If you cannot find it, mark it as Unknown.

2. "Verified" Is a Claim That Itself Needs Verification

I wrote "commands verified against official documentation" in the original setup guide. The maintainer caught it. That phrase is a claim — and it was not true. I had not verified every command.

The fix: Either verify every single command against the official docs and link to each one, or do not use the word "verified." There is no middle ground.

3. Metadata Accuracy Is Not Optional

Mixing up which company makes which product (Plastic Labs = Obsidian?) is the kind of error that destroys credibility. It takes 30 seconds to check. I skipped it and it cost me a review cycle.

The fix: For every component, open the official website or GitHub repo. Confirm the maintainer name, license, and repo status. Write it down. Do not rely on memory.

4. Scope Your Claims to Your Evidence

The original comparison said "High inspectability — all data is local files." But AgentMail is hosted. The claim was too broad. The fix: "Varies by component — locally-run components are inspectable; hosted-service components depend on that service's audit surfaces."

The fix: When making a claim about a multi-component stack, ask "is this true for every component?" If not, qualify it. "Varies by component" is honest and accurate. "All data is local" is neither.

5. Read the CONTRIBUTING.md Before You Start

The repo has explicit contribution guidelines. Claims must be sourced. Metadata must be accurate. Broad claims must be narrowed. I read them after the first rejection. I should have read them before the first submission.

The fix: Before contributing to any open-source project, read the contribution guidelines. Twice. They exist for a reason.

6. Small, Accurate Contributions Beat Large, Sloppy Ones

The first version tried to do too much — setup guide, example, 7 comparison pages, capabilities. More surface area meant more places to be wrong. The final merged version is tighter and more accurate because it was smaller and more focused.

The fix: Start with the smallest contribution that delivers value. Get it right. Then expand.

7. Maintainer Feedback Is a Gift

Two rejections stung. But the maintainer was specific, fair, and actionable. Every piece of feedback pointed to exactly what was wrong and what needed to change. Without that feedback, the merged PR would have been lower quality.

The fix: When you get critical feedback, do not defend. Read it carefully. Fix what is wrong. Verify the fix. Resubmit.

The Stack Itself

For readers who want to understand what the contribution is actually about:

Together, they form a local-first second brain: Obsidian owns the knowledge, Honcho owns the memory, Hermes connects everything, and AgentMail brings email into the loop.

Links

Written by Alex (SaintChris). Open-source contributor, AI second-brain explorer, and someone who learned more from getting rejected twice than from getting accepted on the first try.