Korely

Get Started

Platform Overview

The managed memory layer for AI agents, production-ready, EU-hosted.

Korely turns scattered agent conversations into typed, bi-temporal facts your agents can recall across sessions. We run the store, the embeddings, the entity graph, and the contradiction checks; you call add() and get_context(). One key authenticates three surfaces, the SDK, the CLI, and the REST API.

flowchart LR
  A([Your agent]) -->|add| K[Korely]
  K --> E[Embed memory]
  K --> F[Typed facts<br/>valid_from / invalid_at]
  A -->|get_context| R[Assemble active facts<br/>+ relevant memories]
  F -.-> R
  E -.-> R
  R --> P([Prompt-ready block])
One write call runs the full pipeline; get_context assembles active typed facts plus the memories most relevant to the query into a prompt-ready block.

Why it matters

  • Continuity across sessions. Memories and facts persist per end user and per agent, so your agent stops asking the same question twice.
  • Managed, nothing to host. Postgres + pgvector, the entity extraction, and the bi-temporal fact pipeline are ours to run. No provisioning, no tuning.
  • Current truth, not just nearest neighbours. Every memory is mined into (subject, predicate, object) facts with valid_from / invalid_at. When something changes the old value is invalidated, not deleted, and you can time-travel with as_of.
  • EU based. Stored in the EU, on servers in Helsinki (Hetzner), on every tier.

What you get

  • Three surfaces, one key. The Python and Node SDK, the CLI, and the REST API, all authenticated by one kor_live_ key.
  • Fact-assembled recall. get_context() builds one prompt-ready block: the currently valid typed facts most relevant to the query, then the memories most relevant to it, within a token budget. It is the primary recall path. Semantic vector search() returns the raw ranked memories when you want them. See Get context.
  • A real graph. The typed facts are the graph: each fact is an edge between its subject and its object, aliases join two names of one entity, and every fact points back to the memories that stated it. See The graph.
  • Retrieval, not generation. No LLM runs on the read path. Fact and graph reads are pure SQL; semantic search and get_context add only a fast query embedding. Nothing generates the answer, so reads stay fast and cheap. See Architecture.
  • Human in the loop. Every fact is readable and fixable: show a user what the agent knows, correct or forget one fact (from your UI or the dashboard), or erase everything about a user with one API call (delete_all). See Human in the loop.

Choose your path