Core memory operations

Update a memory

Replace a memory's text. Korely extracts the facts again from the new text: a changed value closes the old fact, a restated fact stays open, and a fact the new text no longer states is closed.

SDK: korely.update(memory_id, content=...). The edit replaces the whole text of one memory and runs the extraction again on it, with the same contradiction check as a new write. Three things can happen to an open fact of the memory: the new text restates it (it stays open), the new text gives the same subject and relation another value (it is closed, and its invalidated_by names the new fact), or the new text no longer states it (it is closed at the time of the edit, unless another memory also states it). You write no code to close old facts. The guide shows the call with a runnable example.

Authentication

HTTP header, required: Authorization: Bearer kor_live_.... The key must carry the memories:write permission.

Path parameter

Request body

Any other field is refused with 422 invalid_request (a memory's user_id, agent_id, run_id and metadata do not change with an edit). Field names are snake_case.

Example request

curl -X PATCH https://api.korely.ai/v1/memories/mem_8f2c1a \
  -H "Authorization: Bearer kor_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Giulia now prefers in-person standups.",
    "expected_updated_at": "2026-03-01T09:14:22.418093+00:00"
  }'

from korely_memory import Korely

korely = Korely(api_key="kor_live_...", region="eu")

memory = korely.update(
    "mem_8f2c1a",
    content="Giulia now prefers in-person standups.",
    expected_updated_at="2026-03-01T09:14:22.418093+00:00",
)

print(memory.id)   # "mem_8f2c1a"

import { Korely } from "korely-memory";

const korely = new Korely({ apiKey: "kor_live_..." });

const memory = await korely.update(
  "mem_8f2c1a",
  {
    content: "Giulia now prefers in-person standups.",
    expected_updated_at: "2026-03-01T09:14:22.418093+00:00",
  },
);

console.log(memory.id); // "mem_8f2c1a"

Response

200 OK. The updated memory. On the Cloud the extraction runs after the reply, so the response always carries status processing and an empty facts list; the facts follow about ten seconds later. A Self-hosted install started with WRITE_ASYNC=false (an environment variable of the server) extracts inside the call and returns them.

{
  "id": "mem_8f2c1a",
  "content": "Giulia now prefers in-person standups.",
  "user_id": "customer-giulia-4812",
  "agent_id": "onboarding-bot",
  "run_id": null,
  "client": null,
  "kind": "note",
  "metadata": {"source": "slack"},
  "status": "processing",
  "created_at": "2026-03-01T09:14:22.418093+00:00",
  "updated_at": "2026-03-02T11:02:10.183112+00:00",
  "facts": []
}

Errors

Notes

• It's a write. Update requires the memories:write scope and does not meter the read query quota.
• On a memory in error. An edit puts the memory back in the queue, and the extraction runs again on the new text. If it fails again, the memory is in error again and its old facts stay open.
• A new value closes the old fact. If the new text gives a fact a new value, the old fact is closed (invalid_at is set, invalidated_by is the new fact), even when another memory still states the old value. A fact the new text no longer states is closed at the time of the edit, unless another memory also states it. Write the new text as a current state (“costs 55 euro per month”), not as a story of a change.
• An empty extraction closes the facts. If the model finds no fact in the new text, the edit closes every fact of the memory. The memory is still ready and no error is reported, so read the facts after an edit. Since 1.0.9, an edit with the text the memory already has, once extracted, changes nothing: no model is called, no fact is written or closed, and the reply is the memory as it is. It still counts as a write against your monthly writes. Facts that such an edit closed before 1.0.9 stay closed. A text that changed by only a comma is read again, and if that read finds no fact it closes the facts, because Korely cannot tell it from an edit that took the value away.
• When the facts start. A new fact's valid_from is the timestamp of the original add if it had one, otherwise a date the text states, otherwise the time of the edit. The edit cannot change the timestamp.
• History. Memory history keeps one updated event: the last edit.
• Optimistic concurrency. expected_updated_at is compared to the microsecond, with no tolerance: two edits made from the same read, even in the same second, cannot both win; the second gets 409 stale_write. The check holds at the write itself, so an edit that lands between your request's check and its write is not overwritten either. Send back the string you read: a value rounded to the millisecond (a JavaScript Date, for example) is another version. A value that cannot be read, or an empty one, is refused with 422 invalid_request, and nothing changes; a date with no time of day is another version and gets the 409.
• Webhooks. The PATCH emits no memory.created. When re-extraction runs, each fact it closes fires fact.invalidated: invalidated_by is the new fact, or null with reason: "memory_updated" for a fact the new text no longer states.

Related

• Update a memory, guide, the narrative walkthrough with context.
• Add a memory, store a new memory.
• Get facts, read back the re-extracted typed facts.