How the knowledge assistant was designed

The problem, service boundaries and tradeoffs behind a reusable knowledge assistant.

Design record. This story compares the used LiteLLM gateway baseline with a direct API source candidate; the candidate was not deployed.

Clients, execution, knowledge and tools in the accepted direct NIS target

Select a component for its responsibility and trade-off. This diagram explains the design, not measured performance.

Select a node to explore its connections.

View all component details

Nora / OpenClaw: A good conversation or voice interface can stay separate from the knowledge and model service. Fresh direct-client sanity checks remain pending.
Direct NIS API: Coordination owns Responses and Chat Completions plus existing HTTP, AG-UI and FastMCP interfaces. A supported protocol subset is not every possible client feature.
Deep Agents / LangGraph: LangChain connects models directly. Default execution uses one model, with at most two independent branches when requested. All branches share limits.
Three providers: The target retains three providers. Live synthetic compatibility passed; comparative quality, billed cost and client latency remain unmeasured.
Retrieval MCP: BGE encodes queries and documents. Qdrant finds passages; prepared text supplies source reads. Search and read pin the same release. This is vector RAG, not a knowledge graph.
Allowlisted tools: Composio brokers explicitly configured app accounts; MCP exposes explicitly selected tools. Schemas and action-specific approval constrain writes.
PostgreSQL: Checkpoints preserve conversation execution. Explicit confirmed memories have provenance. Neither replaces the prepared source corpus.
Manual ingestion: Four separate operator-triggered jobs update knowledge. They do not start from an ordinary conversation. Additions assemble with retained corpus; source meaning is not rewritten.

Michael Lvov’s independent engineering project, presented as a design record.

Purpose, shown by one ask

Take a question like: “Two migration options for a fictional service called Atlas — which fits how we decide things like this?” A model without the relevant sources cannot ground that answer in prior decisions. NIS provides a reusable knowledge and execution backbone across supported clients and eligible models.

Why not paste the corpus into every chat

Repeatedly pasting a large corpus into chats makes source identity and updates harder to maintain and spends bounded context on text most requests never touch. External retrieval over prepared text — BGE embeddings in Qdrant, aligned to each text release — solves this for independent clients. Codex can also use MCP, tools and external retrieval. The point is to reuse a knowledge service across supported clients, rather than tie knowledge to a single conversation.

Constraints that shape everything

One owner; a side-project budget in hours and money; conversation data and history kept intact with the legacy role chats never migrated or exposed; a conversational or voice interface that can be chosen separately from inference; tasks kept bounded. There is no enterprise recovery or rollback program here, and none is claimed.

What success means

A supported, grounded answer, follow-up continuity across turns, and correct tool behavior. Latency and cost are known only when measured; until the planned runs happen, this study states status, not benchmark results.

The build story continues in architecture evolution; tools and routing records components, providers, routing bounds, and integration approvals; AI-assisted work and evidence maps claims to evidence; market research and resume development shows a second application of the same evidence discipline.