01
Support agents
Signal
Policies, entitlements, tickets, and product behavior change while agents keep answering.
KyroDB result
Block stale strict reads, preserve tenant boundaries, and keep proof for support incidents.
Product
The context correctness runtime for production AI.
KyroDB serves context only when it can explain freshness, scope, provenance, and failure behavior. If a strict context boundary cannot be proven, KyroDB fails closed.
The same contract, wherever stale context hurts.
KyroDB stays narrow: one runtime boundary that decides whether context is fresh enough, scoped correctly, and explainable enough to serve.
02
Enterprise copilots
Signal
Internal assistants retrieve across systems with different ownership and permission boundaries.
KyroDB result
Enforce scope, map source boundaries, and separate freshness failures from relevance failures.
03
Coding agents
Signal
Agents act on old files, wrong branches, stale generated types, or missing test output.
KyroDB result
Make workspace context refreshable, scoped, and traceable before code-changing actions.
04
Realtime agents
Signal
Voice and workflow agents need low-latency reuse without hiding stale fallback.
KyroDB result
Reuse safely, degrade explicitly, and trace why context was served or blocked.
Freshness contract
KyroDB never claims a proof it cannot enforce.
Each retrieval declares what KyroDB actually controls. If the source boundary cannot prove freshness, strict mode blocks or downgrades loudly instead of pretending.
01
write_through
Control
KyroDB owns reads and writes
Proof source
runtime generation + mutation ACK
Failure
fail closed
02
event_feed
Control
KyroDB receives authoritative changes
Proof source
runtime generation + event ACK
Failure
fail closed after ACK
03
snapshot_bundle
Control
Reads pin immutable bundle versions
Proof source
bundle version + generation
Failure
fail closed if unavailable
04
best_effort
Control
KyroDB does not control all changes
Proof source
trace only
Failure
downgrade strict
Runtime anatomy
One serving envelope for HTTP and embedded callers.
The public runtime facade and gateway share serving semantics so embedders cannot bypass auth, evidence, limits, trace coverage, or fail-closed behavior.
Gateway
Auth, rate limits, request validation, public-safe error serialization.
Planner
Freshness resolution, reuse, proof validation, packet assembly.
Connectors
pgvector-first onboarding with supported Qdrant paths, scope enforcement, and hard caps.
Evidence
Durable traces, feedback, replay capture, proof reports, and health.
Developer surface
Ask for context. Get a packet with evidence.
The application does not recover failed packets and guess. It either receives proof-bearing context or a public-safe fail-closed error.
freshnessscopetraceomissions
POST /v1/context/retrievestrict
{"query_embedding": [0.18, -0.42, 0.77, 0.09],"scope": {"tenant_id": "acme","namespace": "support","entitlement_boundary": "enterprise"},"freshness_mode": "strict","top_k": 8}-> ContextPacket {status: "complete",freshness: {generation: 184},trace_id: "trc_7H2A...",omissions: ["stale_blocked: 3"],warnings: []}trace boundscope checkedfreshness proven
FAQ
KyroDB sits between AI agents and changing knowledge stores. It retrieves context only when it can enforce freshness, scope isolation, provenance, and proof; when strict context cannot be proven, it blocks or degrades explicitly instead of guessing.
Use KyroDB when your agent depends on business knowledge that changes: policies, tickets, docs, entitlements, product state, or repo context. It gives your AI stack a runtime gate for fresh, scoped, provable context, so you reduce stale responses, cross-scope mistakes, and debugging time without replacing your database, vector store, or memory layer.
Zep, Mem0, and Supermemory are memory or context platforms focused on storing, learning, and retrieving agent or user memory. KyroDB is a correctness runtime for your existing business-knowledge paths: it does not try to become the memory store; it enforces whether retrieved context is fresh, scoped, traceable, and safe to serve right now.
Vector databases store and search embeddings. KyroDB sits above the retrieval path and decides whether returned context is fresh, scoped, traceable, and safe for an agent to use. pgvector is the first-class KyroDB onboarding path today; Qdrant is supported as a secondary connector; Pinecone and other stores are connector candidates when they can enforce KyroDB's scope, filter, watermark, and freshness contract.
KyroDB addresses the runtime side of those problems. It prevents stale, wrong-scope, or unprovable retrieved context from silently entering the prompt, and it records warnings, omissions, freshness evidence, and traces so teams can see why context was served or blocked.
No product can eliminate every hallucination. KyroDB reduces a major cause of production hallucinations: agents using stale, unsafe, polluted, or untraceable context as if it were current truth.
No. KyroDB is a context correctness runtime that sits in front of existing stores. pgvector is the first-class developer path today; Qdrant is supported as a secondary connector.
KyroDB adds freshness checks, scope isolation, provenance, trace evidence, and fail-closed behavior so agents do not silently serve stale or unsafe context.
The runtime returns an explicit degraded or stale-blocked result with warnings, omissions, and trace evidence rather than pretending the answer is fresh.
No. The console uses server-side BFF routes. Runtime, observability, admin, database, and billing credentials stay on the server.
Pro is for individual developers shipping production agents that need fresh, scoped, provable context without building the evidence plane themselves.