Use case · Legal assistant
A legal agent that keeps every matter in its own folder
Per-matter isolation so Deal A never bleeds into Deal B, deal terms that know what is true now and what used to be, and an EU-hosted audit trail. Reachable from any framework over the REST API or SDK.
The idea
Want to build a legal agent with a memory that never mixes up two deals? Here is how
Think about a great paralegal who has been at the firm for ten years. You hand her a new matter and she does not start from zero. She already knows that this client always wants the indemnity cap at twelve months of fees, that the partner hates passive voice in recitals, and that on the last deal we conceded the non-compete down to eighteen months.
But here is the part that makes her great. When she is working on the Acme deal she is thinking only about Acme. She does not accidentally drop a Beemark clause into an Acme contract just because she read it last week. She keeps each matter in its own folder in her head.
That is exactly the memory you want to give your agent, and it is the part that is genuinely hard to build. Korely is that per-matter notebook, scoped so nothing crosses over.
How you build it
Six steps, and the last one is the piece you skip
- 1
Pick your stack
You already have Claude Code or Cursor to write the agent, and your favorite framework to run the loop. The agent reads the matter file, drafts a clause, flags a risk. That part is the easy part and you can stand it up in an afternoon.
- 2
Decide what is worth remembering on every matter
Deal terms the client agreed to, the precedent clauses you reused, the partner drafting preferences, the positions you conceded last round, the counterparty habits. Each of these is a small durable fact, not a whole document.
- 3
Scope every memory to a single matter
This is the rule you cannot get wrong. The Acme agent must read Acme facts and only Acme facts. One leak of Deal A confidential terms into Deal B is not a bug, it is a malpractice problem. So you give each matter its own id and you isolate the store so nothing crosses over.
- 4
Make the facts time-aware
A negotiation moves. The cap was twelve months on Tuesday, the client agreed to twenty four on Thursday. The agent has to answer from what is true now, while still being able to show what it used to be, because in legal the history is the audit trail.
- 5
Handle contradictions on the way in, not on the way out
When the new position lands, the old one has to be marked superseded automatically, with both versions kept. Otherwise your agent will happily cite a term the client walked away from three rounds ago. Pair that with retrieval that actually finds the right clause: keyword search alone misses the paraphrase, vector search alone misses the exact defined term, so you want both fused, plus a graph that surfaces the related limitation of liability and the survival provision.
- 6
Skip the hard part with Korely
Now the honest part. Steps three through five are a bi-temporal graph-RAG memory layer, and building that yourself is months of work, a Postgres schema you will get wrong twice, a contradiction resolver, and a retrieval pipeline you have to tune. With Korely you skip all of it. You call one
addto store a fact scoped to a matter id, onesearchto read it back, and the isolation, the time-awareness, the contradiction handling, and the graph are already done. You keep building the lawyer-smart part. We keep the memory honest, for 19 euro a month after the free tier.
The shape of the fix
Write per matter, read back only what is true now
Round 1, the Acme deal
The agent records a deal term
- Client agrees: indemnity cap = 12 months
- Scoped to matter "acme-2026"
Korely memory
Acme matter, walled off
- cap = 12 months (superseded)
- cap = 24 months (current)
Round 4, drafting
The agent reads it back
- search(matter_id="acme-2026")
- Returns the current Acme fact only
Each matter sits in its own walled box. The Acme agent reads Acme facts and nothing else, and it answers from the cap that is true now, not the one the client walked away from.
How Korely fits
The one piece every legal agent needs and nobody wants to write
Korely saves you from building a bi-temporal graph-RAG memory store with hard per-matter isolation. That means the typed fact layer (this client wants the cap at twelve months), the two valid-time axes so a fact knows both when it was true in the negotiation and when you recorded it, the two-stage contradiction resolver that retires the superseded position the moment a new one arrives, the entity graph that links a clause to its related provisions, and the hybrid retrieval (FTS plus pgvector plus RRF plus a reranker) that finds the right precedent whether the agent searched the exact defined term or a loose paraphrase.
It matters specifically here because legal work is adversarial and auditable. You cannot ship an agent that quotes a walked-back term, and you absolutely cannot ship one that recalls Deal A confidential terms while drafting Deal B. The store is Postgres only, EU-hosted, and local-first, which is the right posture for privileged client data.
And it is fast where it counts. Reads are under 50 milliseconds with no LLM in the read path, so the memory lookup never becomes the slow step in a drafting loop. In a head-to-head at an equal token budget, a reader answered 76 percent of long-history questions correctly from Korely selected memory versus 42 percent from a same-size recent window. That 34 point gap is reproducible.
Show me the code
A minimal write-then-read, scoped to one matter
# ── The agent learns a deal term on the Acme matter ────────────
from korely_memory import Korely
korely = Korely(api_key="kor_live_...")
# Client agrees the indemnity cap. Scope it to this matter only.
korely.add(
"Client agreed indemnity cap at 12 months of fees. "
"Partner wants no passive voice in recitals.",
agent_id="matter-acme-2026",
)
# ── Round 4: the agent drafts the indemnification section ──────
context = korely.search(
"indemnity cap and drafting preferences",
agent_id="matter-acme-2026",
)
# context → the current Acme cap, never a Beemark term.
# The agent prepends this to its prompt before drafting.
# The Beemark matter lives behind its own agent_id and
# cannot be reached from here, by design.
The same memory is reachable from any agent, Claude Code, Continue,
n8n, LangGraph, or a plain HTTP client. A different
agent_id
per matter keeps each client knowledge separate and auditable, so
one deal can never read another deal facts.
When the term moves
The agent drafts from what is true now, and can still show the timeline
It is round four of the Acme acquisition. Early on, the client agreed to an indemnity cap of twelve months of fees. Two weeks later, after the disclosure schedules came back ugly, they pushed it to twenty four. Your associate asks the agent to draft the indemnification section.
A plain agent that just retrieves the most semantically similar paragraph might grab the twelve-month line, because it appears more often in the thread. The agent built on Korely answers from what is true now. The twelve-month fact was marked superseded the instant the twenty four-month position landed, so the draft comes back with twenty four months, and the agent can still show the partner the timeline of how the cap moved if anyone asks why.
Same scene, different matter. The moment the agent switches to the Beemark file, the Acme cap is simply not in scope. It cannot recall it, by design, so it never bleeds one client terms into another contract.
korely.add(
"Indemnity cap = 12 months of fees.",
agent_id="matter-acme-2026",
metadata={"effective_from": "2026-02-04"},
)
# Two weeks later the client pushes the cap up
korely.add(
"Indemnity cap = 24 months of fees.",
agent_id="matter-acme-2026",
metadata={"effective_from": "2026-02-18"},
)
korely.search("indemnity cap", agent_id="matter-acme-2026")
# → "24 months" (current). The 12-month fact is marked superseded.
# Retrieve the full audit trail via the REST API:
# GET /v1/memories/{id}/history -> timeline with effective_from Frequently asked
Legal assistant memory, common questions
How do you guarantee one client's terms never leak into another client's contract? +−
You scope every memory to a matter id when you write it, and every read is filtered to that same id. The Acme agent reads Acme facts and nothing else. There is no shared pool the agent can accidentally pull from, so Deal A confidential terms are simply not reachable while it works on Deal B. Isolation is the default, not something you have to remember to switch on.
My client agreed to a term, then changed it mid-negotiation. Which version does the agent use? +−
The current one. Facts in Korely are time-aware. When the new position lands, the old one is marked superseded automatically and the agent answers from what is true now. The old version is not deleted though, it is kept in the timeline, so if a partner asks why the cap moved you can show the full history. In legal that audit trail is a feature, not clutter.
Is this safe enough for privileged client data? +−
The store is Postgres only and hosted in the EU, and the architecture is local-first, which is the right posture for privileged material. You write and read over a REST API or the Python and Node SDK, nothing to host yourself, and you can export or erase a matter memory with one call. No data leaves the EU and there is no LLM sitting in the read path reading your facts.
Will the memory lookup slow down my drafting agent? +−
No. Reads come back in under 50 milliseconds and there is no model call on the read path, it is straight hybrid retrieval. The lookup is never the slow step in your loop. In a head-to-head at an equal token budget, a reader answered 76 percent of long-history questions correctly from Korely selected memory versus 42 percent from a same-size recent window, so you also get the right fact, not just a fast one.
Do I have to build the retrieval and the graph myself? +−
No, that is the whole point. You bring Claude Code or Cursor to build the lawyer-smart part of the agent. Korely is the memory layer underneath: the bi-temporal facts, the contradiction handling, the per-matter isolation, the entity graph, and the hybrid search are already built and tuned. You call add to store a fact and search to read it back. The hard infrastructure is done.
What does it cost to start? +−
There is a free tier so you can wire up a matter, write a few deal terms, and see the isolation and the time-awareness work end to end before you pay anything. Paid plans start at 19 euro a month when you need more. You can build the whole proof of concept on the free tier first.
Every matter already known, no two clients ever mixed up
If your agent should walk into every matter already knowing the deal, the precedent, and the partner style, start free and move to 19 euro a month when you are ready.
Looking for a different shape? See the other nine use cases →