Why Venkai
Venkai and your existing AI stack solve different problems.
Memory is what the system knows. Continuity is what must survive so the work can actually continue. They are not competitors, and a multi-agent system often needs both.
Your AI stack
Memory, RAG, orchestration, continuity: four questions
Venkai does not require replacing your existing memory, retrieval, orchestration or model infrastructure.
| Layer | Question | Examples | Relationship to Venkai |
|---|---|---|---|
| Memory | What should the system remember about a user, a conversation or an entity? | Mem0, Zep, Letta, assistant memory | Complementary. Venkai does not replace it. |
| RAG | What information should the system retrieve from documents? | Vector databases, document indexes | Complementary. Venkai indexes no documents. |
| Orchestration | How are agents and steps coordinated? | LangGraph, CrewAI, AutoGen, custom loops | Stays in place. Venkai does not decide who runs. |
| Continuity | What context and work state must survive so the next agent, session, model or step can continue? | Venkai | The layer Venkai covers. |
The layers overlap in places: Venkai also stores facts and preferences, but attached to the state of a piece of work, not to a user profile.
Where it plugs in
Next to what already runs
- 01ApplicationYour product, unchanged.
- 02Agents and stepsYour orchestrator, models, memory and RAG stay where they are.
- 03Venkai — REST · SDK · MCPCalled by the agent, next to those systems rather than underneath them: read before the prompt, write after the decision.
- 04Typed work stateFact, decision, constraint, preference, event, relationship — versioned, isolated per organization.
- 05Work continuesThe next agent, session or model resumes from that state.
The principle
Not storing everything
A full history is easy to produce and expensive to use: you have to re-read it to know what it contains, and it grows faster than the capacity to process it. The temptation is then to send everything to the next agent as a dump, which moves the comprehension work rather than removing it.
Venkai starts from the opposite assumption. What has to survive an agent change isn't the conversation, it's what the conversation produced: the facts established, the decisions taken, the constraints set, what changed and what is still to do. That's a fraction of the volume, and it's the part the next agent needs before acting.
Writing is therefore an explicit act. An agent decides to keep something, with a type and an importance. That asks for some discipline on the agent side, and it is the accepted trade-off: the quality of what an agent finds depends on what the previous one bothered to write.
Honesty
When Venkai is the wrong answer
One agent, one session
With no handover and no interruption, the context window is enough.
The need is documentary
If the question is "what does this document say?", you need a RAG, not Venkai.
Search must be semantic from day one
Default embeddings are hashing-based; without an embedding model, synonyms aren't brought together.
Production scale is a prerequisite
SQLite is the engine validated today. PostgreSQL is planned but unproven.
Build a continuity layer for your agents.
Describe your multi-agent workflow and where context goes missing. We answer with a pilot scope, or with the reason Venkai isn't the right piece.
Describe your workflow