Human-in-the-loop memory

Human-in-the-loop memory means the person whose data is being stored can inspect every fact, correct what is wrong, and erase what they no longer want kept. Korely gives you the pieces: every fact is a typed, readable triple, and correcting or forgetting one is a single call. You put those calls behind a screen in your own product, and you can use the same controls yourself in the Korely dashboard.

The thesis

Agent memory about a person should be visible and correctable by that person. We hold this for two reasons:

Trust. A personal assistant that silently accumulates a dossier about its user is creepy. One that says "here is everything I know about you, fix what's wrong" is a product people keep using. Memory you can inspect is memory you can rely on.
Control. At some point your users will ask to see, correct, or erase what is stored about them (GDPR Art. 15, 16 and 17). With Korely each of those requests is one API call, not a database migration.

Memory that only machines can read works until it is wrong, stale, or about something the user wanted forgotten. Typed facts make it readable; the correct and forget calls make it fixable.

Show the user what the agent knows

korely.get_profile(user_id=...) returns every active fact about one end user, grouped by predicate family (preferences, people, places, work, ownership, health, financial, events, other). Each fact carries source_memory_id, so your screen can show why the agent believes it. Suppose Sofia changed jobs, but the store still has a live fact:

get_profile(user_id="customer-4812") → work

| Fact                       | Valid from | Live? |
|----------------------------|------------|-------|
| Sofia, works_at, Acme      | 2026-01-12 | yes   |

Let the user correct a fact

Wire an Edit button to korely.correct_fact(fact_id, object="Beacon Labs") (REST: PATCH /v1/facts/:id). The corrected triple becomes the current fact. The old one is superseded, not erased: it keeps its dates and gains invalidated_by, consistent with the bi-temporal model every fact carries (valid_from + invalid_at). The next read your agent makes returns the corrected row, and the chain stays queryable:

get_facts(user_id="customer-4812", include_invalidated=True)

| Fact                            | Valid from | Invalid at |
|---------------------------------|------------|------------|
| Sofia, works_at, Beacon Labs    | 2026-06-09 | null       |
| ~~Sofia, works_at, Acme~~       | 2026-01-12 | 2026-06-09 |

Whether the old fact was superseded by new information (automatic contradiction detection) or corrected through correct_fact, the mechanics are the same: old fact invalidated, new fact current, history preserved. The default read returns only the current row.

Let the user forget a fact

Wire a Forget button to korely.forget_fact(fact_id) (REST: POST /v1/facts/:id/forget). The fact stops being current and drops out of every default read at once. Say Sofia once mentioned an allergy and decides her assistant should not remember it:

korely.forget_fact("fct_9c1e")
korely.get_facts(user_id="customer-4812", predicate_family="health")

[]

Forgetting a fact closes it rather than deleting the row, so include_invalidated=True still shows it, strike-through, as history. When the person wants their data gone for good, use erasure below: that one is physical.

The same controls in the dashboard

You do not have to build anything to act on a request today. The Facts page of the dashboard at agent.korely.ai lists every fact your agents extracted, with Forget and Correct on each one, and the Graph page shows them as of any date. A support request like "your bot thinks I still work at Acme" is fixed there in a click, and your agent reads the correction on its next call.

What this means for your agents

Action (your UI, the dashboard, or the API)	What your agent observes
Correct a fact	The next `korely.get_facts()` call returns the corrected value. No cache to bust, no webhook to handle.
Forget a fact	The fact disappears from default reads at once. Your agent cannot leak it back into a conversation.
Dispute a memory	The invalidation chain is queryable with `include_invalidated=True`. Who believed what, and when, is reconstructable.

Propagation is immediate because reads are deterministic. No generative model sits between the fact store and the tool response: there is no reranking model and no answer synthesis on the read path, your agent's own model does the reasoning. A corrected fact is just a row, and the next read returns it. There is no "eventually consistent memory" window where the agent acts on a fact the user already removed.

Design your prompts for this. Don't tell your agent to cache user facts in its own scratchpad "for efficiency". A cached fact survives a Forget; a fresh korely.get_facts() call doesn't. Re-read facts at the start of each session. Reads are retrieval, not generation, and read quotas are an order of magnitude more generous than write quotas, so the read is effectively free.

Erasure over REST

When a customer closes their account in your app, erasing everything about them is one HTTP request. DELETE /v1/users/:end_user/memories physically deletes every memory and every fact scoped to that user_id, superseded ones included, and writes one audit record with the counts:

curl -X DELETE https://api.korely.ai/v1/users/customer-4812/memories \
  -H "Authorization: Bearer kor_live_..."

// 200 OK
{
  "user_id": "customer-4812",
  "memories_forgotten": 218,
  "facts_invalidated": 64,
  "memories_deleted": 218,
  "facts_deleted": 64,
  "erasure": "permanent",
  "audit_id": "aud_91xb"
}

A single memory can be forgotten with DELETE /v1/memories/:id: that one drops the memory from reads and invalidates its facts, keeping them as history. Full details in the API reference.

Why this matters, per use case

Healthcare and legal assistants. Correction and erasure requests are not optional here. Korely gives you the data-control primitives, correction, forgetting, erasure with an audit record, EU hosting; the regulatory review of your application stays yours. The request path is "the user clicks in your app and you call one endpoint", not "support files a ticket and an engineer runs a manual delete".
Personal AI. Trust is retention. A user who finds a wrong fact and can fix it stays; a user who finds a wrong fact and can't gets uneasy and churns. A "what do you remember about me" screen turns that question from a fear into a feature.
Customer support agents. Wrong account facts ("user is on the Team plan" when they downgraded months ago) cause wrong answers. Correct the fact once, from your UI or the dashboard, and every subsequent agent interaction is right, with no escalation loop.

Worked example: agent reacts to a user correction

The full cycle in code. The agent writes a fact, the user corrects it through your UI, which calls correct_fact, and the agent's next read picks up the corrected value. No cache to invalidate, no webhook to handle.

from korely_memory import Korely

korely = Korely(api_key="kor_live_...")

# 1. Agent stores what it learned during the session.
#    Korely extracts the fact triple automatically.
mem = korely.add(
    "Sofia told me she works at Acme Corp as a product manager.",
    user_id="customer-4812",
)

# 2. Sofia opens "what you remember about me" in your app and fixes it.
fact = korely.get_facts(user_id="customer-4812", predicate="works_at")[0]
korely.correct_fact(fact.id, object="Beacon Labs")

# 3. Agent's next turn, reads back what is current.
facts = korely.get_facts(user_id="customer-4812", predicate="works_at")
print(facts[0].object, facts[0].invalid_at)
# Beacon Labs None
#
# The old "Acme Corp" fact is invalidated and absent from the default read.
# Pass include_invalidated=True to see the full correction chain.

import { Korely } from 'korely-memory';

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

// 1. Agent stores what it learned during the session.
await korely.add(
  'Sofia told me she works at Acme Corp as a product manager.',
  { user_id: 'customer-4812' },
);

// 2. Sofia opens "what you remember about me" in your app and fixes it.
const [fact] = await korely.getFacts({ user_id: 'customer-4812', predicate: 'works_at' });
await korely.correctFact(fact.id!, { object: 'Beacon Labs' });

// 3. Agent's next turn, reads back what is current.
const facts = await korely.getFacts({ user_id: 'customer-4812', predicate: 'works_at' });
console.log(facts[0].object, facts[0].invalid_at);
// Beacon Labs null

# 1. Agent stores what it learned.
curl -X POST https://api.korely.ai/v1/memories \
  -H "Authorization: Bearer kor_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Sofia told me she works at Acme Corp as a product manager.",
    "user_id": "customer-4812"
  }'

# 2. Your UI corrects the fact the user flagged.
curl -X PATCH https://api.korely.ai/v1/facts/fct_... \
  -H "Authorization: Bearer kor_live_..." \
  -H "Content-Type: application/json" \
  -d '{"object": "Beacon Labs"}'

# 3. Agent reads the current facts on the next turn.
curl "https://api.korely.ai/v1/facts?user_id=customer-4812&predicate=works_at" \
  -H "Authorization: Bearer kor_live_..."
# => { "facts": [{ "subject": "Sofia", "predicate": "works_at",
#        "object": "Beacon Labs", "invalid_at": null, ... }], "total": 1 }

Next steps

See the full get_facts() parameter surface in the API reference.
Not connected yet? The quickstart gets you from zero to a working integration in five minutes.
Correct, forget, erasure, the graph, and temporal facts are included on every plan. See pricing. Your data is EU-hosted, on every plan.