I couldn’t find a conversation.
It happened three weeks ago in Discord - something about the newsletter redesign. I knew it existed. I knew roughly when.
But Discord’s built-in search is terrible for finding conversations that span multiple threads. And the work that came out of that conversation lived in a completely different system.
So I scrolled. Manually. Like it was 2008.
That’s when I asked Andy a simple question: “Do we have a skill for searching Discord threads?”
We didn’t.
The real problem isn’t search - it’s scattered context
Running a small business means your information lives everywhere. Email, texts, tweets, Discord conversations, work session transcripts, meeting notes, project files, relationship records, reminders, captured ideas, shared inboxes, cross-platform DMs, room bookings, and a deep email archive.
When I need to find something, I almost never know which source it’s in.
Was the newsletter conversation in Discord or email? Did I text someone about it or was that a Discord DM? Is the decision captured in a session transcript or did I file it as a note?
The answer to all of these is “maybe.” And running five separate searches to find one thing is the kind of friction that makes you stop looking.
The missing link
Before building anything fancy, Andy identified a structural gap: Discord conversations and Claude Code work sessions weren’t linked.
Two separate systems. When you found a conversation in one, you couldn’t reach the related work in the other.
The fix was boring. Two new fields in the sessions database. A backfill script to connect existing sessions with their Discord threads. Bidirectional links so every session knows its Discord thread and every thread can find its sessions.
This is the part most people skip. The flashy feature is unified search. The thing that made it possible was connecting two pieces of data that should have been connected all along.
Designing through an interview, not a spec
Instead of writing a requirements doc, Andy and I designed the search system through a structured interview in Discord. Andy asked a question, presented concrete options as buttons, I picked one, we moved on.
Eight questions, eight decisions.
What are you actually looking for? Finding past conversations, locating specific threads, tracing work across systems. All three.
Where should this work? Everywhere - Discord, command line, and automatically triggered by other workflows like meeting prep.
How deep should results go? Full context bundles. Not just “here’s a matching message” but the conversation it came from, the work session it triggered, the people involved, and what happened next.
How should we handle results from multiple sources? Cluster related hits together. If “newsletter” shows up in Discord, email, and a work session, group those into one cluster with source attribution.
Should it search everything every time? No. Fast by default with a handful of sources, with a one-tap button to go deeper across everything. Most questions are “where was that thing I just worked on” - those don’t need to search a years-old email archive.
Should person detection be automatic? Yes. If I search for someone’s name, pivot everything through that person’s lens - their relationship file, our email threads, Discord mentions, work sessions, reminders, texts.
How should I switch between modes? Auto-detect the best mode, return results fast, show one-tap buttons for the alternatives. “Go Deeper” and “Search as Person” are always one click away.
Should this replace existing search tools? No. Wrap them. The unified search coordinates existing capabilities without replacing them.
This interview-driven approach has become one of my most-used patterns with Claude. It’s faster than writing specs because you’re making real decisions in real time. Nothing stays abstract. And because it happens in Discord, you have a complete record of every decision and the reasoning behind it.
Three modes, one command
The design produced three search modes:
Find is the default. It searches fast local sources in parallel - semantic memory, work session transcripts, Discord messages, the knowledge base, and active reminders. Results come back in seconds.
Deep adds everything else - Gmail, the full email archive, tweets, text messages, cross-platform DMs, projects, tasks, ideas, shared inboxes, and bookings. Takes longer because some of these require reaching remote machines.
Person auto-activates when you type a name. It searches everything through that person’s lens - pulling their relationship file, filtering email for threads with them, finding Discord conversations that mention them, surfacing relevant sessions and reminders.
Results stream in as each source completes. You see fast sources immediately, and slower ones trickle in.
What this taught me
Connect your data before you build features. Two database columns and a backfill script unlocked the entire project. If your AI system feels limited, look at what data relationships are missing before adding more logic.
Design through structured interviews. Have the AI ask you questions with concrete options. You’ll make better decisions faster than writing specs, and you’ll have a record of why you chose what you chose. This works for any feature design.
Wrap, don’t replace. The unified search calls the same individual search skills that other parts of the system use directly. Meeting prep calls Discord search on its own. Session forensics uses it independently. When I improve any single source, every consumer benefits automatically. The temptation with “unified” anything is to centralize. Resist it.
Fast defaults, slow on demand. The quick mode is the right default because it answers most questions. Deep mode exists for the rest - the answer buried in an old email or a text from last month. If I’d made the thorough search the default, every query would take too long and I’d stop using it within a week.
Where this actually started
None of this was planned as a unified search project. It started with “can we search Discord?” and each answer revealed the next question.
The pieces were already there waiting to be connected.
Build the smallest useful thing, see what it reveals, and keep going.