Case Study

duSraBheja

Active build

I capture ideas, notes, and references constantly - across Discord, conversations, PDFs, voice memos - but they end up scattered and unfindable. duSraBheja solves this: 5 specialized AI agents (classifier, librarian, retriever, clarifier, storyteller) automatically categorize, embed, and merge everything into canonical knowledge notes with semantic search.

Last curated refresh: 2026-05-11 12:39 PM EDT

Project FramingProblem / ContextRole and OwnershipConstraintsArchitectureKey DecisionsIterations and StrugglesLearningsOutcomesNext Improvements

Case Study Map

Project framing

duSraBheja exists because my work, ideas, notes, screenshots, PDFs, and session context were fragmented across too many tools. I did not want another note app. I wanted a system that could absorb raw evidence, turn it into memory, and then make that memory usable both for me and for the agents helping me work.

Problem / Context

Manual note-taking systems fail me for the same reason most knowledge systems fail: they depend on consistent human organization at the exact moment when I am busy doing something else. The real problem was not storage. It was ingestion, promotion, retrieval, and the split between private memory and public-safe narrative.

Role and Ownership

I designed the system architecture, wrote the ingestion and public-surface code, shaped the agent prompts, and owned the deployment and operational guardrails.

Why now

Once I started using coding agents seriously, copy-pasting context became the bottleneck. I needed my brain to be toolable so the AI could read relevant history mid-session instead of waiting for me to reconstruct it manually.

Topline

Constraints

The bot could not block on LLM or extraction work.
Public answers had to stay hard-walled from the private brain.
Everything needed to run cheaply on a single droplet.

Outcomes

A Discord-native second brain with MCP access, public profile surfaces, and agent bootstrapping.
A production split between private knowledge and approved public facts.

What changed because of the project

A Discord-native second brain with MCP access, public profile surfaces, and agent bootstrapping.

Architecture

Capture

Drop text, files, screenshots, or session context into the brain

Discord and the collectors are the intake surfaces because they match the way I actually work.

Process

The worker extracts, classifies, and merges the evidence

The bot stays thin while workers do extraction, embeddings, and librarian merge work asynchronously.

Store

The private brain promotes it into canonical notes and retrieval state

Postgres, pgvector, and read models hold the durable memory layer behind the scenes.

Use

Agents, dashboards, and the public site read the right view of that memory

MCP and the private dashboard can use richer context. The public site only reads curated public snapshots.

OutcomeOne capture path feeds private memory, agent workflows, and a public-safe story without raw dump leakage.

Architecture narrative

I designed the system as a set of asynchronous lanes instead of one giant chat loop. Discord is the capture surface. The bot only acknowledges and enqueues. Workers do the heavy lifting: extraction, classification, embeddings, librarian merge, and story/read-model generation. The private brain sits behind PostgreSQL, pgvector, and canonical notes. MCP, REST, and the public site all read from curated interfaces, not raw intake. That separation is what makes the public clone safe.

System diagram

This is the secondary view: the system shape behind the flow above. It exists to explain the moving parts, not to substitute for the product story.

Capture

Discord inbox

text, files, voice, links

Collectors

repo history, browser, notes

Processing

ARQ queue

bot only enqueues

Classifier + librarian

extract, classify, merge

Embeddings

semantic retrieval

Brain

Canonical notes

Postgres + pgvector

Read models

projects, story, dashboard

Interfaces

MCP + API

agent tooling

Curated public snapshots

approved facts only

Safety wall

The public clone and website only read approved facts and curated snapshots.

Async boundary

Discord never blocks on LLM or extraction work; workers absorb the cost and latency.

Key Decisions

Discord as the intake surface

Use Discord as the always-open capture layer instead of building a custom UI first.

Capture needed to be frictionless immediately; Discord already matched how I actually drop thoughts and files.

I accepted less control over the initial UX to get better ingestion behavior faster.

Public/private split

Separate approved public facts and public snapshots from the private brain.

The public clone needed to feel rich without risking leakage from private notes or secrets.

It adds curation overhead, but that overhead is what makes the system trustworthy.

Async worker architecture

Keep the bot thin and push heavy work onto Redis-backed workers.

That gave me resilience, better cost control, and room for extraction pipelines and retries.

More moving parts, but far better operational behavior.

Build Journey

TypeScript and WhatsApp origin

The first version proved the concept, but it was too heavy and awkward for the always-on loop I wanted.

Python and Discord rewrite

I rebuilt the system around Python async, ARQ, FastAPI, and MCP so it matched the workflow and tooling I actually use.

Story-first public surface

The latest phase added curated public snapshots, dashboard views, and a public-safe clone instead of exposing raw memory directly.

Struggles

Structured classification output was inconsistent early on.

I tightened prompts, added confidence-based review thresholds, and treated sub-threshold outputs as reviewable instead of silently trusting them.

It was easy for public rendering to drift back toward raw dumps.

I introduced curated public payloads and snapshot precedence so the site reads designed narratives instead of raw fact bodies.

The system kept expanding in scope faster than its interfaces stayed legible.

I split the product into private brain, curated public surface, dashboard ops, and agent interfaces with different contracts.

Learnings

Agentic systems live or die on orchestration boundaries, not on the headline model.

A second brain is only useful if capture is frictionless and retrieval is trustworthy.

Public AI experiences need a real data contract; otherwise they drift into generic filler or accidental leakage.

Outcomes and Scale

Tests30+ test files covering critical paths

Agents4 AI agents (Classifier, Clarifier, Librarian, Retriever, Storyteller, WebsiteBuilder)

Services15+ services (digest, story, planner, query, knowledge, reminders, cognition, etc.)

LanguagesTypeScript (Phase 1-3), Python (Phase v2 onward)

Extractors6 file type extractors (PDF, Image, Audio, Excel, DOCX, Link, Text)

Lines Of Code~30K across src/ directory by final commit

Total Commits92 over 23 days (4/day average, with sprint days at 10+)

Database Tables8 core tables in v2 (Artifact, Classification, Chunk, Note, Link, Entity, Thread, Synthesis)

Latest Work

Latest evolution

Curated baseline

Canonical project snapshot

The problem: I have notes in Discord, bookmarks in the browser, PDFs on my desktop, voice memos on my phone, ideas in random text files. When I need to find something I captured three weeks ago, I can't. Every knowledge management tool I tried required manual organization - and I don't do manual organization consistently. duSraBheja is m…