July 2025 - Foundation: Multi-Tenant Isolation and Hybrid Retrieval

Context

Start of R&D on Rose, an agentic platform for inbound marketing. The goal was an agent that engages B2B website visitors and answers complex questions from company knowledge. The first pilot client was a B2B experimentation-SaaS company.

Two genuine technical uncertainties opened in July and run through the whole foundation phase (July–September); most of the rest of the month built the apparatus those investigations run on, with only product delivery excluded. The first uncertainty is how to isolate tenant data on a retrieval stack whose components do not support multi-tenancy. The second is whether a hybrid graph-plus-vector retrieval approach can reach B2B production quality within a strict latency budget, given that no prior operating point exists for that combination on this kind of content.

Maps to 2026 R&D projects: Compounding Context Engine for Company, Industry, and Buyer Intelligence — both spines are inbound-context infrastructure the agent consumes at answer time.

Multi-Tenant Isolation for a Graph-RAG Stack

Project and lock

The technical lock (verrou technologique) is that the chosen retrieval engine, LightRAG over a Neo4j knowledge graph, has no native notion of a tenant: every client's entities and relationships live in the same graph, and the library offers no per-tenant filtering. Forking the library to add it was rejected — a fork carries permanent maintenance cost and blocks upstream updates. The uncertainty was therefore whether isolation could be injected around an unmodified upstream library, and whether such an injection could cover every query shape the library generates without breaking or leaking.

This month's work

The hypothesis was that tenant isolation could be enforced by intercepting LightRAG's Cypher queries at runtime and rewriting each one to add a tenant constraint, leaving the upstream library untouched. The experimental work built a Cypher parser that identifies the node variables and WHERE clauses in each generated query, injects a tenant-id filter, handles queries spanning multiple node variables, and covers the edge case of queries that carry no existing WHERE clause. The unknown going in was coverage: whether one rewriting layer could handle the full, dynamic range of query structures LightRAG emits.

Results, proof, and next step

Validation used a unit and integration suite across the different query patterns, exercised concurrent multi-tenant access, and checked for cross-tenant leakage; no leakage was observed and the rewriting overhead was not a concern in the test runs (no production-load benchmark was taken). Testing also surfaced query patterns the first parser did not yet cover — a named open thread. The result was runtime Cypher interception that adds multi-tenancy to a library lacking it, without forking — an approach with no standard prior pattern to follow. Next step: extend parser coverage to the remaining query shapes and validate isolation under cross-environment data transfer.

Hybrid Graph-Vector Retrieval at B2B Production Quality and Latency

Project and lock

The lock is that no established operating point exists for a hybrid retrieval system — one that combines a knowledge graph with vector search — that must simultaneously answer complex B2B questions well and respond inside a few-second budget. Standard single-mode RAG patterns are documented; the quality/latency behavior of the hybrid combination on B2B sales-and-product content is not, so the viable configuration had to be discovered rather than looked up.

This month's work

The investigation began with a baseline and a first candidate. The baseline — a standard LangChain retrieval chain with a single monolithic prompt and a vector store baked into the container image — was tested against real pilot questions and found inadequate: latency was several seconds (driven by the hard-coded store), context retention was poor, and one prompt could not adapt across user intents. This is a retained negative result: it established that the off-the-shelf approach cannot meet the requirement and motivated the hybrid direction. The candidate was LightRAG's hybrid graph-plus-vector retrieval, which qualitatively improved retrieval over the baseline and added graph-relationship retrieval the baseline lacked. Running this comparison required building its apparatus the same month: making the LLM provider and model selectable from configuration turned "which provider, which model, at which retrieval setting" into a runnable experiment rather than a code change; execution tracing became the instrument for observing retrieval behaviour and latency that the following months' tuning would read; and response streaming attacked the latency half of the lock directly. Only the adoption of one specific vendor on top of that abstraction is ordinary integration.

Results, proof, and next step

Both observations are qualitative — no measurement harness existed in July, so the percentage figures an earlier draft attached here (baseline-vs-hybrid relevance and quality) were pre-production estimates and have been removed. The finding is directional: standard RAG is insufficient, the hybrid approach is the promising direction, and the operating point and a way to measure it remain open. This is the start of the hybrid-retrieval quality/latency investigation that the following months carry forward. Next step: tune the hybrid parameters toward the latency budget and build the harness that can score quality.

Not retained as R&D

Frontend widget and loader and backend package scaffolding — product delivery and project setup with no nexus to a named experiment.

Next Work (August)

1. Extend tenant isolation to cross-environment data transfer with integrity guarantees.
2. Tune hybrid-retrieval parameters toward the latency budget.
3. Redis-based conversation history; scale to a second pilot client.