Get Started

Vibecoding

Give your coding assistant a memory that survives the session.

You build by prompting an assistant such as Claude Code, Cursor or Windsurf. Each new session starts blank, so you explain the architecture again, and the library you rejected, and the convention you agreed. Korely gives the assistant one hosted memory for all of that, reachable with the same key from every assistant and every machine. The assistant reaches it through MCP, the standard that lets an AI assistant call outside tools. What the memory keeps are facts with dates, such as "ships on Fridays, since March", and not a transcript the assistant has to re-read.

Terms

The Glossary defines the words used across the docs. This page uses API key, MCP, hook, memory, fact, end user, as_of and search as defined there.

Set it up

1. Get a key

One command creates a free key and saves it in ~/.korely/config.json. You need Python 3.9 or later:

pip install korely-memory
korely init --agent --agent-caller claude-code

The key starts with kor_live_. Open ~/.korely/config.json and copy the value of api_key: you paste it in the next step. See Sign up as an agent for the whole flow, including what to do if a key is already saved.

2. Add the MCP server to your assistant

Pick one of the two ways. The hosted server needs nothing installed on your machine and gives the assistant six tools. The local server is a small program that runs on your machine and gives four.

Hosted. In Claude Code, one command connects the remote server. Replace kor_live_... with your key. It is the same setup as on the Claude Code page; for Cursor, Windsurf and Codex see Korely MCP.

claude mcp add --transport http korely https://api.korely.ai/agent/mcp \
  --header "Authorization: Bearer kor_live_..."

Local. The package you installed in step 1 also contains korely-mcp, a stdio MCP server. It reads the key from ~/.korely/config.json or from the KORELY_API_KEY environment variable, so you paste nothing:

claude mcp add korely -- korely-mcp

Restart the assistant. The hosted server shows six Korely tools, the local one four. There is no rules engine and no separate dashboard to set up.

To save every session without asking, run korely init --tool claude-code (or codex, or cursor) in the repository instead. It installs the local MCP server and hooks: one hands the assistant the repository's memory when a session starts, another saves the session to it. See Connect a coding assistant.

3. The tools your assistant now has

Tool	What it does
`korely_get_context`	The recall call. Returns the facts about the user that are true now and most relevant to the query, plus the most relevant memories, as one block of text ready for a prompt. Call it before answering.
`korely_add`	Remember a decision, preference or convention. Korely extracts the facts from the text. Call it after something durable is settled.
`korely_get_facts`	Read the facts as `(subject, predicate, object)` triples. Pass `as_of` for what was true on a date, or `known_as_of` for what Korely knew on that date.
`korely_search`	Search the saved memories by meaning, when you want the original text rather than the assembled block.

The hosted server also has korely_correct_fact and korely_forget_memory, to fix a wrong fact and to retract a wrong memory. They are described on Korely MCP.

A starter prompt

Drop this into your assistant's system prompt or rules file so it uses the memory on its own:

You have persistent memory through the Korely MCP tools. Use it instead of asking
the user to repeat themselves:

- Before answering anything about this project, the user's preferences, or past
  decisions, call korely_get_context with a short query to recall what is known.
- After the user settles a durable decision, preference, convention, or fact,
  call korely_add with one clear sentence so it persists across sessions. When
  something changes, say the new state in the present tense ("we now ship on
  Tuesdays"). Never save passwords, keys or other secrets.
- Use korely_get_facts to check the current facts (as_of for what was true at
  a date, known_as_of for what the store knew then); use korely_search to pull
  up the underlying memories.

Memory persists across sessions and is shared with any other Korely surface
(SDK, CLI, REST). Treat it as the source of truth for what was decided.

A read that names no user_id covers every end user of the project. If several people use the same project, have each person's assistant pass their own user_id on every call.

What it looks like in practice

You tell the assistant "we're standardizing on Postgres and shipping on Fridays". It calls korely_add, and about ten seconds later Korely has written two facts, for example standardizes_on Postgres and ships_on Fridays. The predicate names are chosen by the model that reads the text, so they can differ from run to run. Next week, in a fresh session, you ask the assistant to scaffold a deploy script. It calls korely_get_context("deploy cadence and stack") first and already knows.

If you later say "we now ship on Tuesdays", Korely closes the Friday fact instead of deleting it, and as_of can still show what the plan was before. In a test of this exact exchange on the Cloud, the Friday fact was closed and the new fact was recorded as the reason. Deciding that a new text replaces an old fact is a judgement made by a model, so it works best when the new text states the new situation in the present tense, as above. A change told as a past event ("we used to ship on Fridays") may not close the old fact. That is the difference between a memory layer and a chat log: the assistant is handed what is true now, and the history is still there.

Go deeper

Build it into your own agent: the Quickstart and the SDK reference show the same memory called from code.
Understand how facts change: temporal facts and the graph explain why a read returns what is true now, not just the nearest paragraph.
Use the CLI directly: the CLI reference has the same calls as korely context and korely add, for scripts and hooks.