Teams repeatedly brief AI tools because useful project knowledge is fragmented across Drive, Slack, Notion and local files. Latently began as an attempt to make that context available without asking people to rebuild it in every conversation.
The problem
The same project may be discussed in a Slack channel, documented in Drive, planned in Notion and supplemented by uploaded files. AI tools begin each session without that working context, so team members either repeat themselves or accept answers based on incomplete evidence.
The product problem was not “search all company data.” It was narrower: give an AI tool access to the sources that belong to one project, keep them current and make the boundary understandable to the people using it.
What I built
I founded the product and owned customer discovery, product direction, architecture, implementation, testing and deployment.
The working pilot includes:
- OAuth and source selection for connected providers;
- background ingestion and refresh workers;
- Slack backfill, events, edits, deletions and reconciliation;
- recursive Notion ingestion;
- file upload, parsing and complete source records;
- source-level access control;
- read-only, project-scoped MCP tools for compatible AI clients.
The implementation uses TypeScript, Next.js, Hono, PostgreSQL, Drizzle ORM, pg-boss, Clerk and Render.
Where reality disagreed
It was tempting to treat context as a semantic-search problem and begin with embeddings. Building the provider connections exposed more basic constraints first. Sources change. Messages are edited or deleted. Permissions differ by project. Provider APIs fail or rate-limit. Parsed content must remain attributable to the source that produced it.
More context did not automatically mean better context. A fast retrieval layer would be of limited value if the underlying record was stale, incomplete or impossible to inspect.
Semantic indexes can be rebuilt. The canonical context record must remain complete, attributable and easy to inspect.
How I investigated it
I tested the system through live provider connections and real synchronisation paths rather than static document fixtures alone. That meant observing backfills, incremental events, edits, deletions, retries and reconciliation as project sources changed.
I also tested access from external MCP-compatible tools. This made permission boundaries and returned source material visible at the point where a model would actually consume them.
What changed
I chose canonical, complete source records as the foundation instead of making a vector index the primary representation. Ingestion and refresh became explicit background workflows. Each project received a scoped read interface, and access control stayed attached to the source record.
Semantic retrieval can remain a derived capability. The source of truth stays readable, attributable and debuggable even if an index is rebuilt or the retrieval strategy changes.
What I learned
In this system, reliable context began with synchronisation, provenance and permissions—not ranking. Retrieval quality only becomes meaningful after the product can explain what it knows, where that knowledge came from and whether it is still current.
This changed how I approach context systems: build the inspectable source layer first, then optimise how models retrieve from it.