Engram

Brain building
Page 3
Brain built
Landing page

Inspiration

Every company has that one person who knows where the bodies are buried. Why the client churned. Why the schema's weird. Why the API got redesigned twice. That knowledge lives in their head, scattered across Slack threads, Notion docs, and Jira comments nobody's ever scrolling back to find.

We've watched this exact problem play out firsthand. A new hire spends three weeks asking questions everyone already answered eight months ago, because the answer's buried in a thread from March. We didn't want to build another search bar that hands you ten links and calls it done. We wanted to build the thing that already knows, and actually shows you why.

What it does

Engram is a persistent memory layer for your company's brain. It pulls together scattered communication, messages, docs, tickets, notes, and turns all of it into one connected knowledge graph you can talk to directly. Same engine works just as well if it's one person trying to stop losing their own notes across five different apps.

Ingests communication across multiple sources and indexes it by meaning, not keyword overlap
Builds a live knowledge graph showing how people, decisions, and conversations actually connect
Answers questions directly and traces every answer back to its exact source, no black box guessing
Takes input by voice or text, so you can ask your own knowledge base a question out loud
Renders the whole thing as an interactive 3D graph that lights up and cascades in real time as it pulls context, built specifically so the system is legible, not just functional

How we built it

The backend runs on FastAPI. Ingestion normalizes every source into a shared document schema, runs it through chunking and entity extraction, then embeds it into a shared vector space so retrieval works on semantic meaning instead of literal keyword matches. A RAG pipeline sits on top, pulling the relevant chunks at query time and grounding the generated answer in them rather than letting the model freestyle from its own weights.

The frontend is React 19, with the knowledge graph rendered live in Three.js. Bloom post-processing on active nodes, cascade animations tracing the retrieval path through the graph as a query resolves, Zustand keeping the UI in sync with what the backend's actually doing underneath. Voice runs end to end through ElevenLabs, both for the spoken query and the response back.

We spent real time on the UI because a memory layer nobody wants to open isn't useful, whether you're a company onboarding a new hire or a single builder trying to stop losing your own context. If you can't see why the system retrieved what it retrieved, it's not doing its job, it's just vibes with extra steps.

Challenges we ran into

Normalizing wildly different communication formats, a short Slack message versus a long Confluence doc, into one structure that embeds and retrieves consistently took serious iteration. Chunking strategy alone went through multiple rewrites before retrieval quality held up. Getting the graph's cascade timing to actually match real retrieval latency was its own fight, too fast and the visual desyncs from what's happening, too slow and it looks frozen. Voice latency was the hardest problem in the build. Half a second is the gap between a tool that feels like a conversation and one that feels broken.

Accomplishments that we're proud of

Every answer Engram gives is traceable straight back to its source chunk. Most RAG demos either skip attribution entirely or bolt it on after the fact, we built it as a core part of the pipeline from the start. We're also proud the graph holds up under real interaction and not just in a polished screenshot, you can actually watch it trace from question to answer. And honestly, asking your own company's knowledge out loud and getting back a sourced answer still feels a little insane every time it works.

What we learned

A traceable answer builds trust in a way a confident-sounding guess never will, and that's the difference between a tool people actually use and one they open once. We learned voice interfaces are unforgiving on latency, and that designing the visual layer alongside the retrieval logic, not after it, is what makes a knowledge graph something people actually want to explore instead of just a feature checkbox.

What's next for Engram

Adding permission-aware retrieval so a shared company knowledge base respects who's actually allowed to see what, which matters the second this moves past a single team. Expanding the connector list so the graph keeps getting richer the more an org uses it. Pushing multi-turn voice so follow-ups don't reset context every time. And longer term, packaging this as something early-stage startups can drop straight into their stack, since the onboarding problem this solves only gets worse as a team grows, while still keeping the door open for individuals who just want their own second brain.