Your agent shows up to call 3 like it's call 1

The notebook

Want to build a sales co-pilot that walks into call three knowing what happened on call one? Here is how

Think about the best account executive you ever worked with. Before every call she pulled out a little notebook. "Last time you said budget gets unlocked after the Q3 board meeting, did that land?" "You mentioned your VP hates long demos, so I cut it short." The prospect feels known.

That notebook is the whole trick. Your agent has perfect grammar and infinite patience, but no notebook, so every call it sounds like a stranger reading a script. The deal stage, the objection from last time, the fact that this buyer prefers email over a phone call, none of it carries forward. The buyer notices, and a relationship that is supposed to compound stalls instead.

Korely is the notebook. The rep writes a line after each call, and the agent reads it back before the next one.

How you build it

Five steps you already half-know, plus the one you skip

1. Wire your agent to the call

   You already have the easy part. Drop a transcript or live notes from Zoom, Gong, or a phone bridge into Claude Code or Cursor and let the model summarize what was said. This is a weekend of work and you have probably done it already.

2. Pick what is worth remembering after each call

   Not the whole transcript, just the durable facts: deal stage, who the economic buyer is, the objection that came up, the budget timing, that the contact prefers email over calls and short demos. The model is good at pulling these out of a transcript.

3. Write those facts to memory, one agent_id per rep, one user_id per account

   After call one your agent calls add() with "stage: discovery done, moving to demo", "objection: pricing vs incumbent", "buyer prefers email, hates long demos". The agent_id keeps Maria reads separate from Tom reads, and the user_id keeps each account apart, so pass both on every read.

4. Read the memory back before the next call starts

   When the agent opens call three it calls get_context() for this account and gets a block built from the facts open today: where the deal stands now, the objection it still owes an answer to, how this person likes to be sold to. It walks in warm.

5. Let the agent correct itself when things change

   The prospect said budget was Q3, now it is Q4 after a reorg. The agent just writes the new fact. The old one does not get deleted, it gets marked superseded, so the agent answers from what is true now and you still have the trail of how the deal moved.

6. The part nobody wants to build, this is where Korely saves you

   The notebook above is not a database row. It is a bi-temporal, typed-fact, graph-RAG memory layer: it has to know what is true now versus what was true in March, resolve the contradiction when the budget date changes, link the objection to the buyer to the account, and surface the right three facts without a generative model on the read path, with no generative model on the read path. That infrastructure is months of work and a research problem in its own right. With Korely you call add() and search(). You skip building the memory, keep building the agent, and it starts at 19 euro a month + VAT.

The shape of the loop

One line written per call, one timeline read back before the next

How Korely fits

You build the agent. We are the memory.

What Korely saves you is the entire agentic-memory backend, the part of the sales co-pilot that has nothing to do with sales and everything to do with hard infrastructure. A real sales memory is not just storing notes. It has to be bi-temporal: it must separate when a fact became true in the deal (budget moved to Q4) from when you recorded it, so the agent answers from the current state of the pipeline and not a stale one.

It needs two-stage contradiction handling so when the buyer changes their mind the new fact wins and the old one is kept as history, not silently overwritten. It needs a typed entity graph so the objection, the economic buyer, the competitor, and the account are linked and the agent can pull the whole picture of one deal in a single call. And it needs retrieval (pgvector search plus a lookup of the typed facts, Postgres only) that surfaces the right facts, not just keyword matches, with no generative model on the read path.

The selection is the point. Korely returns the facts and memories that match the question, not the most recent messages, in one block under a token budget you set, 800 tokens by default. For a sales co-pilot that is the difference between the agent recalling the one objection that actually matters and the agent dumping the last thing said.

Reads run no generative model, so memory adds a lookup to the conversation, not another model turn. The store is hosted in the EU; to extract facts, the text of each write, with up to ten earlier memories of the same account (300 characters each) and the earlier facts it is compared with, goes to the model of your project's region, Google's Gemini API by default or Scaleway in Paris if you choose the EU region.

Show me the code

Post-call write, pre-call read

# ── After call 1: the agent summarized the transcript ──────────
from korely_memory import Korely

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

korely.add(
    "Stage: discovery done, moving to demo. "
    "Objection: pricing vs incumbent. "
    "Buyer prefers email, hates long demos. Budget unlocks Q3.",
    agent_id="rep-maria",
    user_id=f"account-{account_id}",
    metadata={"call_date": call.date_iso, "contact": contact.name},
)

# ── Before call 3: the agent preps the brief ───────────────────
context = korely.search(
    f"current stage and open objection for {account_id}",
    agent_id="rep-maria",
    user_id=f"account-{account_id}",
)

# context → the closest notes, best first, each with its score and the first 280
# characters of the memory, scoped to Maria and this account