In the demanding landscape of an 80-hour work week, merely jotting down thoughts isn’t enough. Our brains become fragmented, jumping between roles as a data lead, startup founder, and individual contributor. What I needed wasn’t just a note-taking app; it was a cognitive offload engine—a system that pre-processes my thoughts, links them to my existing knowledge graph, and even challenges my assumptions.

That’s precisely the vision for Thought Board 2.0. I’m building a system where an agentic layer isn’t just an “AI helper” but a concurrent background engine that treats my notes like live, actionable data. Leveraging Go’s robust concurrency model, a snappy HTMX frontend, and my custom MCP (My Custom Protocol) server, I’ll walk you through the architecture designed to offload some of that cognitive burden.

The Tech Stack

To build such an intelligent and responsive system, we carefully selected a stack optimized for performance, developer experience, and seamless integration with our existing tools.

• Go (Fiber Framework): The backbone of our backend. Go’s emphasis on concurrency via CSP (Communicating Sequential Processes) is paramount for handling asynchronous thought processing. The Fiber web framework provides a high-performance, minimalist approach for our API endpoints.
• HTMX: For the frontend, HTMX delivers a modern, reactive user experience without the complexity of a full JavaScript framework. It allows us to perform dynamic UI updates with minimal boilerplate, deeply integrated with our Go backend.
• MCP (My Custom Protocol Server): Our bespoke Go server acts as the central intelligence hub, providing agents with access to local project structures, tools, and external services. It’s the critical bridge between our thought board and our broader development ecosystem.
• Database Ecosystem: We’re not relying on a single database. Instead, Iwe embrace a multi-modal memory hierarchy:
  • SQLite / PostgreSQL: For Episodic Memory (“What was I thinking at 2 AM on Thursday?”).
  • Vector Store (Qdrant/Milvus): For Semantic Memory (“Find all thoughts related to Go concurrency patterns.”).
  • Knowledge Graph (Kùzu / Neo4j): For Relational Memory (“How does the ‘Shadow Mode’ idea from the Meta interview connect to my startup’s rollout strategy?”).

Key Features

Thought Board 2.0 isn’t just a place to store thoughts; it’s an active participant in our cognitive process. Here are its core capabilities:

• Concurrent Agentic Processing: Thoughts are immediately processed by a pipeline of specialized agents running in the background, ensuring real-time enrichment.
• Dynamic Contextualization (The Recursive Context): Every thought is a potential node in our existing ecosystem. The system actively links new notes to projects, codebases, and historical data, making fragmented context a thing of the past.
• Intelligent Peer Review (The Active Inference Board): Our agents don’t just categorize; they challenge. By mimicking a technical sparring partner, the board stress-tests ideas and proactively flags potential issues.
• Mental Bandwidth Dashboard (The Temporal Pulse Board): Thoughts are treated like a live ticker. The UI dynamically highlights and scales topics based on our mental focus, providing a visual dashboard of our current cognitive landscape.
• Multi-Agent Memory Hierarchy: Moving beyond flat vector stores, we leverage typed memory to store and retrieve information in a way that mirrors human cognition.

Implementation Steps

1. The Concurrent “Observer-Processor” Pipeline

At the heart of Thought Board 2.0 is a robust Go concurrency model. We implemented a Worker Pool pattern to asynchronously process new thoughts, ensuring the UI remains snappy and responsive.

When an HTMX POST request delivers a new thought, the Fiber handler commits it to the database and then, crucially, drops the ThoughtID into a buffered Go channel.

// Example: Fiber handler for new thoughts
func postThoughtHandler(c *fiber.Ctx) error {
    var thought Thought
    if err := c.BodyParser(&thought); err != nil {
        return c.Status(fiber.StatusBadRequest).SendString(err.Error())
    }

    // Save thought to DB
    result := db.Create(&thought)
    if result.Error != nil {
        return c.Status(fiber.StatusInternalServerError).SendString(result.Error.Error())
    }

    // Immediately push ThoughtID to processing channel
    processingQueue <- thought.ID

    // Render immediate UI feedback via HTMX
    return c.Render("partials/thought-card-processing", fiber.Map{"Thought": thought})
}

This processingQueue feeds a dynamic Observer-Processor pipeline:

• The Orchestrator: A long-running Go routine continuously listens to the processingQueue channel. For each new ThoughtID, it intelligently spawns or assigns tasks to a pool of specialized worker goroutines.

  func startOrchestrator(queue chan uint) {
      for thoughtID := range queue {
          // Fan-out to specialist workers
          go categorizerAgent(thoughtID)
          go synthesizerAgent(thoughtID)
          go actionAgent(thoughtID)
          log.Printf("Orchestrator dispatched thought %d to specialists.\n", thoughtID)
      }
  }
  

• The Specialist Workers: These independent goroutines perform specific, complex tasks.

  • Categorizer Agent: We implemented this agent to leverage our MCP server. It queries local project structures (e.g., git log, file headers, directory names) to intelligently tag the note. For instance, a thought about “Solana PDA” might be tagged #MemForge or #Blockchain.
  • Synthesizer Agent: This agent performs a “Graph Search” via our MCP server’s knowledge graph interface. It looks for “Sibling Thoughts”—notes that are semantically or relationally connected—to find contradictions, supporting evidence, or related contexts in our past notes.
  • Action Agent: We designed this agent to scan new thoughts for imperatives. If it finds phrases like “I need to fix the Solana PDA,” it uses a tool exposed by MCP to create a GitHub Issue or a JIRA ticket, automating follow-up tasks.

2. Multi-Agent Memory Hierarchy: Beyond Flat Vectors

Instead of a flat vector store, we implemented a sophisticated Typed Memory system, which we anticipate becoming the standard for advanced agentic systems by 2026. This allows our agents to interact with our knowledge in a more nuanced, human-like way.

Memory Type	Storage Mechanism	Agentic Use Case
Episodic	SQLite / PostgreSQL	“What was I thinking at 2 AM on Thursday?” (Temporal recall)
Semantic	Vector Store (Qdrant)	“Find all thoughts related to Go concurrency patterns.” (Conceptual similarity)
Relational	Knowledge Graph (Kùzu)	“How does the ‘Shadow Mode’ idea connect to my startup’s rollout strategy?” (Causal/Linked entities)

When we input a new thought, the agent first performs a Hybrid Search. This combines vector similarity searches with knowledge graph expansion. It doesn’t just find “similar” notes based on embeddings; it finds “related” entities, concepts, and temporal connections, providing a richer context for each new idea.

3. The Tool-Use Layer: Empowering Agents with MCP

Our custom Go MCP server acts as the Command Center, providing our agents with specific, powerful tools that interact with our local environment and external APIs. This is where the board truly becomes an extension of our workspace. The existing MCP protocol was perfectly suited for exposing these capabilities with minimal extension.

Here are examples of tools we exposed to our agents:

• tool_search_codebase: Allows the board to read our actual Go files, useIful for verifying if a thought about a bug or feature is already implemented or discussed within the code.
• tool_fetch_market_data: If we jot down a note about TQQQ, the agent can call this tool to append the current RSI, MACD, or other relevant financial metrics directly to the note for real-time context.
• tool_cross_link: Automatically creates an HTMX hx-get link between two thoughts that share a strong causal or contextual relationship, making navigation between related ideas seamless.

4. Streaming UI Updates with HTMX and WebSockets: The “Ghost” Preview

To maintain a minimalist yet “agentic” UI, we implemented Streaming UI Updates using HTMX and WebSockets. This provides immediate feedback while the background agents do their work.

1. Immediate Feedback: As soon as we hit Enter after typing a thought, the note appears instantly at the top of the list, thanks to hx-swap="prepend".
2. The “Ghost” State: This newly added note initially displays a “Processing…” spinner, indicating that the agents are actively working on it. This is our “Ghost” state.
3. WebSocket Push: As the Go specialists complete their tasks (categorizing, linking, critiquing), the backend pushes a partial HTML fragment containing the agent’s insights over a WebSocket connection. Fiber makes WebSocket integration incredibly straightforward.
4. The Reveal: HTMX intercepts the incoming WebSocket message and uses hx-swap to seamlessly replace the “Processing…” spinner with the rich, agent-generated insights and links.

<!-- Initial HTML for a new thought (via hx-swap="prepend") -->
<div id="thought-{{.Thought.ID}}" class="thought-card" hx-ws="connect:/ws">
    <p>{{.Thought.Content}}</p>
    <div id="agent-insights-{{.Thought.ID}}" class="processing-spinner">
        Processing agent insights... <span class="spinner"></span>
    </div>
</div>

<!-- WebSocket message from backend (partial HTML fragment) -->
<!-- Example message for thought-123 -->
<div id="thought-123" hx-swap-oob="outerHTML">
    <div id="agent-insights-123" class="agent-insights">
        <span class="tag">#MemForge</span>
        <a hx-get="/thought/456" hx-swap="outerHTML" hx-target="#sidebar">See related: "Solana PDA architecture"</a>
        <div class="critique">Risk: Solana’s account-based model will break your ERC-20 Factory logic. Have you mapped the PDA requirements yet?</div>
    </div>
</div>

Pragmatic implementation tip: For the Action Agent, we employ a “Reflection Pattern.” Before it suggests a “Novel Solution” or flags an action, we have a second, independent agent—the “Critic” agent—review and “Criticize” its output. This prevents the board from becoming an echo chamber and ensures the insights are as rigorous as the technical sparring I valued during my Staff-level interviews.

Challenges and Solutions

Building an agentic system that feels truly assistive rather than just informative presents unique challenges:

• Challenge: Avoiding Information Overload & “Echo Chamber” Syndrome.
  • Solution: The “Reflection Pattern” for agents (Critic Agent) ensures that suggestions are critically reviewed, providing balanced and challenging perspectives rather than just confirming existing biases.
• Challenge: Seamless Integration with Disparate Data Sources.
  • Solution: The MCP server serves as a unified gateway, abstracting away the complexities of interacting with the local filesystem, external APIs, and various database types (vector, graph, relational). This allows agents to operate at a higher level of abstraction.
• Challenge: Maintaining Responsiveness with Complex Background Processing.
  • Solution: Go’s CSP model, worker pools, and buffered channels guarantee efficient, non-blocking asynchronous processing. HTMX and WebSockets then ensure that these background operations are reflected in the UI with a real-time, streaming experience.
• Challenge: Providing Relevant Context Across Diverse Cognitive Tasks.
  • Solution: The Multi-Agent Memory Hierarchy, combining episodic, semantic, and relational memory, allows agents to perform sophisticated “Hybrid Searches” to retrieve context that is truly relevant to the current thought’s mode (organize, challenge, track).

Conclusion

Building Thought Board 2.0 has been an exhilarating journey, transforming a simple note-taking concept into a powerful cognitive offload engine. By meticulously architecting with Go’s concurrency, HTMX’s reactivity, and our custom MCP server’s integration capabilities, we’ve created a system that doesn’t just store our thoughts but actively processes, contextualizes, and challenges them.

This multi-specialist worker approach, deeply integrated with our existing MCP, is not only feasible but profoundly effective. It’s the perfect playground for our stack, turning an 80-hour work week from a cognitive burden into a streamlined, highly intelligent workflow.

Happy coding!