Get AI summaries of any video or article — Sign up free
How I'm Building a Second Brain: Logseq + Tana thumbnail

How I'm Building a Second Brain: Logseq + Tana

CombiningMinds·
5 min read

Based on CombiningMinds's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

A second brain is a workflow for trusted retrieval, not a single app; specialized tools should handle capture, reference, and action differently.

Briefing

A “second brain” isn’t a single app for storing notes—it’s a trusted workflow that decides what to keep, how to organize it, and how to resurface it when it matters. The core problem driving the approach is information overload: people bounce between email, bookmarks, highlights, and documents, then waste time re-finding what they already learned. The solution is to offload that mental work into a system built around personal knowledge management, so “reference” material becomes searchable and “action” material becomes scheduled.

The setup centers on Thiago Forte’s CODE framework—Capture, Organize, Distill, Express—then adds a crucial distinction between reference and action. When something is captured, it should be sorted by whether it’s actionable (needs time, tasks, or scheduling) or reference (needs to be reshaped and revisited later). Actionable items go to task management or calendar when a time component exists; reference items land in a notes/wiki layer where they can be tagged, linked, and summarized over time. The creator’s emphasis is heavily on the reference side: Logseq as the long-term knowledge base, with Tana as a complementary workspace for capture, structure, and project/task tracking.

Instead of trying to force everything into one tool, the workflow treats apps as specialized modules. Logseq is used as the “wiki” for learning and documentation—an open-source, offline-capable, true outline system that supports flexible tagging, reshuffling, and distillation. Tana is used for quick capture on mobile, AI transcription (via Whisper API), and structured templates that make frameworks repeatable. Incoming reading and web content is handled through Omnivore (read-later), which exports content as blocks that fit Logseq well. Readwise acts as the bridge for highlights and annotations, pulling Kindle highlights and other saved highlights into the system.

Capture is broken into four reference inputs: free-form writing/journaling, project-based scratch notes, reference banks (documentation, snippets, screenshots), and external inputs like newsletters, Twitter bookmarks, podcasts (via Snipd transcription), PDFs, and Kindle highlights. A key workflow preference is “daily journal first”: smaller highlights and quick notes start in Logseq journals, then get elevated into dedicated pages only after they’re distilled into core insights.

Organizing follows PAR—Projects, Areas, Resources, Archives—without requiring rigid folder hierarchies. The approach uses metadata (Logseq properties and Tana fields) and linking/search rather than strict namespaces, so information can be re-sliced as needs change. Distillation is handled through progressive summarization: highlights are progressively emphasized and reshuffled so the most important parts bubble up for later retrieval. Expressing can mean publishing, but it can also be internal value—turning distilled knowledge into checklists or reusable decision frameworks.

The practical takeaway is a system that reduces rework: capture quickly, tag and link for retrieval, distill what matters, and route action items into tasks and calendars. The specific stack—Logseq + Tana, supported by Omnivore, Readwise, and other capture tools—illustrates how a second brain can be built as an interconnected set of workflows rather than a single “all-in-one” database.

Cornell Notes

The second brain approach described here treats knowledge management as a workflow, not a single app. It separates “reference” from “action”: reference material goes into a notes/wiki system for later retrieval, while actionable items route to tasks or a calendar when timing matters. The workflow is built around Thiago Forte’s CODE method (Capture, Organize, Distill, Express) and uses PAR (Projects, Areas, Resources, Archives) for organization via metadata and linking rather than rigid folders. Logseq serves as the long-term reference layer, while Tana supports capture, AI transcription, and structured project/task management. Omnivore and Readwise handle inbound reading and highlight syncing so the system stays current without constant manual sorting.

Why does the workflow insist a second brain is not “one app,” and what problem does that solve?

The approach argues that forcing everything into a single tool can add friction. Even though Logseq can technically handle many workflows, the creator treats apps as specialized modules: Logseq is optimized for long-term reference and reshaping ideas; Tana is optimized for fast capture and structured work; Omnivore handles inbound reading; Readwise syncs highlights and annotations. This reduces app-switching chaos and prevents the notes system from becoming a dumping ground that’s hard to retrieve from later.

How does the reference-vs-action distinction change what happens after capture?

Each captured item is evaluated for whether it’s actionable. If it needs time or scheduling, it goes to task management or the calendar. If it’s not actionable, it becomes reference and is reshaped for later retrieval inside the notes/wiki layer. The workflow also notes that the boundary isn’t perfectly universal—for example, PDFs may be stored in Logseq so annotations are available in a dedicated page.

What does “Capture” mean in practice, and what are the four reference inputs?

Capture focuses on storing key insights and quick notes, not hoarding everything. The reference inputs are: (1) free-form thinking/writing (journaling, observations), (2) project-based scratch notes and meeting notes, (3) a reference bank of documentation/snippets (including screenshots), and (4) external inputs such as newsletters/Substack recommendations, Twitter bookmarks, podcasts (via Snipd transcription), PDFs, and Kindle highlights. External links and reading are routed through Omnivore; highlights are routed through Readwise.

How does “Organize” work without rigid folder hierarchies?

Organization uses PAR—Projects, Areas, Resources, Archives—implemented through metadata and search/linking. Projects have clear goals and due dates; Areas represent ongoing responsibilities; Resources are items like books, articles, and PDFs; Archives are older material no longer actively managed. Instead of strict namespaces/folders, the system relies on Logseq properties and Tana fields (plus tags/super-tags) so items can be re-sliced as needs evolve.

What is “Distill,” and why does it matter for retrieval later?

Distill turns raw highlights and notes into reusable core insights using progressive summarization. The workflow emphasizes bubbling up the most important parts—e.g., progressively emphasizing key highlights with markdown-style emphasis—so later searches surface the essence quickly. It also supports a “daily journal first” habit: small highlights start in journals, then only become dedicated pages when they’re distilled enough to justify elevation.

How do “Express” and “CODE” connect to everyday knowledge work?

Express can mean publishing, but the workflow treats it more broadly as making distilled knowledge usable—like turning insights into checklists or internal reference frameworks. For many knowledge workers, the value is not public output but creating artifacts that reduce future decision-making time. The practical emphasis remains on Capture and Organize, with Distill and Express as the steps that convert stored information into action-ready understanding.

Review Questions

  1. How would you decide whether a new note belongs in the reference system versus task/calendar routing?
  2. What metadata strategy would you use to implement PAR in a notes tool that supports properties and linking?
  3. Describe a “daily journal first” workflow and explain when you would elevate a note into a dedicated page.

Key Points

  1. 1

    A second brain is a workflow for trusted retrieval, not a single app; specialized tools should handle capture, reference, and action differently.

  2. 2

    Use a reference-vs-action filter at capture time: reference goes to notes/wiki for later retrieval, while action routes to tasks or calendar when timing matters.

  3. 3

    Build around CODE (Capture, Organize, Distill, Express) and treat distillation as progressive summarization so the most important parts surface quickly.

  4. 4

    Implement PAR (Projects, Areas, Resources, Archives) using metadata and linking/search rather than rigid folder hierarchies.

  5. 5

    Start with Logseq for long-term reference and reshaping; use Tana for fast capture, structured templates, and project/task management.

  6. 6

    Route inbound reading and highlights through Omnivore and Readwise so external information arrives already structured for later use.

  7. 7

    Adopt a “daily journal first” habit: keep small highlights in journals, then elevate only after distillation makes them worth dedicated pages.

Highlights

The workflow’s central sorting rule is whether captured items are actionable; non-actionable knowledge becomes reference designed for retrieval.
Logseq is positioned as the long-term reference wiki—open source, offline-capable, and built for reshuffling ideas—while Tana handles structured capture and project/task work.
Distillation uses progressive summarization so key insights become easy to find without re-reading entire sources.
PAR is implemented through properties and fields, letting users slice information dynamically instead of relying on strict folder trees.

Topics