Core memory operations

Update a memory

Replace a memory's content. Korely re-runs fact extraction on the new text: changed values supersede prior facts, restated facts dedupe, and facts the new text no longer states are closed, so your typed knowledge stays in sync.

SDK: korely.update(memory_id, content=...). The update path re-runs the intelligence, embeddings and typed-fact extraction with bi-temporal contradiction checking, on the new content. Facts the new text restates stay active (deduped); facts it contradicts are superseded; facts it no longer states are closed at the time of the edit, unless another memory also states them. You never write supersede logic.

Authentication

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

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 hosted service extraction runs after the call returns, so the response carries status processing and an empty facts list; the facts re-extracted from the new content follow a few seconds later.

{
  "id": "mem_8f2c1a",
  "content": "Giulia now prefers in-person standups.",
  "user_id": "customer-giulia-4812",
  "agent_id": "onboarding-bot",
  "run_id": null,
  "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.
• Facts stay in sync. The PATCH re-runs fact extraction on the new content: changed values supersede prior facts (their invalid_at is set), restated facts are deduped, and a fact the new text no longer states is closed at the time of the edit, unless another memory also states it.
• 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. An unparseable value is treated as stale, so the write is rejected rather than allowed to clobber.
• 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.