Skip to content
VENKAI
Pilot

Architecture

A layer, not a system.

Venkai sits next to what you already run. It doesn't decide which agent speaks, calls no model, and indexes no documents.

Position

Where Venkai plugs in

  1. 01Your agent frameworkorchestration, tools, models — unchanged
  2. 02Venkai — API / SDK / MCPwriting and reading typed context objects
  3. 03Structured contextfact · decision · constraint · preference · event · relationship
  4. 04Persistent storageorg-isolated, versioned on every write

The call is synchronous and has no side effect on your flow: an agent writes when it has produced something that must survive, and reads when it needs to know where the work stands. Nothing forces an agent through Venkai to function; what goes through Venkai is what has to be found again later.

Responsibilities

What Venkai takes on

  • Context typing

    Six types, chosen at write time. An agent can ask for "all decisions" without re-reading the rest.

  • Ranked retrieval

    A query returns objects ordered by similarity, recency, importance and access frequency.

  • Isolation

    API key → organization. Every read and write is filtered through that chain.

  • Versioning

    Every update snapshots the previous state, restorable over the API.

  • Access lifecycle

    Rotatable and revocable API keys, JWT for browser sessions.

  • Data exit

    Full export and cascading deletion at organization level.

Boundaries

What Venkai does not do

This list matters as much as the previous one. A component whose edges are unknown doesn't integrate.

  • It doesn't orchestrate

    Venkai doesn't decide which agent runs, or in what order. Your orchestrator stays yours.

  • It calls no model

    No LLM call is issued by Venkai. It doesn't summarise, rephrase or invent.

  • It doesn't index your documents

    This is not a RAG. It stores context objects produced by agents, not document chunks.

  • It isn't a vector database

    Ranking uses similarity, but the stored unit is a typed object with its history, not a bare vector.

  • It doesn't remove hallucinations

    If an agent writes a wrong decision, Venkai keeps it faithfully. It makes the error visible and reversible; it doesn't prevent it.

  • It doesn't judge write quality

    What agent B finds depends on what agent A bothered to write.

Real state

Limits of the current implementation

  • VERIFIED

    SQLite

    The engine validated today. Single-process: concurrency is bounded.

  • PLANNED

    PostgreSQL

    The code is configurable and Alembic migrations are written, but nothing has been tested for real.

  • LIMIT

    Default embeddings

    Hashing-based, so no semantic generalisation to synonyms. A real embedding model is required for that.

  • PLANNED

    Docker deployment

    Dockerfile and compose exist; the build was never executed in this audit.

  • LIMIT

    Monitoring

    Telemetry is in-process, with no external export and no alerting.

  • EXPERIMENTAL

    External MCP client

    The MCP server passes its tests but hasn't been wired to a real third-party client yet.

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

The system

What happens between a workflow and a better workflow.

Forge runs the agents. Venkai keeps what they establish. Cervelet looks at what worked. Mutation changes the workflow. Then it runs again — and it is the loop, not the run, that is the product.

Your businessThe workThe dataForgeorchestratesSalesOperationsResearchVenkairemembersCerveletevaluatesMutationchangesA better system

The output feeds the input. That is the loop.

A diagram, not a screenshot: it describes the architecture, it does not show a real run.