Context
Support teams sit on a pile of real answers — runbooks, policy, past tickets — and still lose time hunting. Asking a coworker is faster than searching the wiki, until the coworker is busy and the wiki is stale.
Magic Conch started as: what if the internal brain was a question, not a folder tree?
Problem
Generic chatbots hallucinate. That is unacceptable when the answer is a policy or a step that can break production. Keyword search only works if you already know the document's name.
The gap: retrieve from the team's own corpus, generate from that context, cite the passages, and stay honest when the docs don't cover it.
What I built
An internal RAG assistant, owned end-to-end: product, retrieval pipeline, UI, and deploy. Staff pick one or more knowledge bases, ask in natural language, and get a streaming answer with numbered citations they can open.
It began as a local-model prototype. I rewrote the backend in Node, moved inference to a hosted OpenAI-compatible API on DigitalOcean, and kept ChromaDB as the vector store. Beyond one-shot RAG: an agent path that can take extra research steps when a single retrieve isn't enough, team memory, corpus admin, and a workplace chat bot. No public demo — it is a staff tool on purpose.
How it works
- Documents are chunked and embedded into ChromaDB
- A query retrieves the nearest passages; a hosted LLM writes an answer with required citations
- If retrieval is thin, the product should refuse to bluff — that constraint shaped prompts and UI more than the model choice
- Agent mode can gather more than one hop: knowledge bases, long structured guides, then synthesis
- Docker locally; containers on DigitalOcean in production
Status / next
Live internally for support staff, and still being built. Next: harden the ops surface, keep evaluating answers on real questions, and grow the corpus without drowning retrieval.