Sales reps are not bad at their jobs because they're lazy. They're bad at remembering because they're human, and they're talking to 50 prospects at once.

Here's what actually happens. You get on a call with someone you spoke to six weeks ago. You vaguely remember they had a concern about budget. You open your CRM notes and find one sentence from March that says "follow up Q3." You spend the first two minutes of the call re-establishing context you already earned. The prospect notices. The deal slows down.

The problem isn't the CRM. It's that CRMs store data but don't remember context. There's a difference. Data is "last contacted: April 3." Context is "she pushed back on the onboarding timeline, loved the ROI calculator, and asked specifically about data migration before agreeing to a pilot." One is a timestamp. The other is the actual state of the deal.

That's what we built SalesMemory to fix.

What it does

SalesMemory gives sales reps a persistent memory layer across every prospect interaction. Before a call, the rep types a name and gets a structured brief: key objections raised, what to focus on today, when the last interaction happened, and a Deal Health Score from 0 to 100. After the call, the rep logs 2–3 sentences about what happened. That note gets stored permanently. Every future brief for that prospect gets smarter because of it.

The memory layer powering this is Hindsight, a semantic memory system built by Vectorize that persists, recalls, and reflects across sessions. Without it, this is just another chatbot that forgets everything the moment the session ends. With persistent memory across sessions, the agent genuinely compounds intelligence over time.

The stack: React + Vite + Tailwind on the frontend (deployed on Vercel), Python + FastAPI on the backend (deployed on Render), Groq's llama-3.3-70b-versatile as the LLM, and no database. Hindsight is the only persistence layer.

The four user flows

Pre-call brief. Rep types a prospect name. The backend calls Hindsight to recall all stored memory about that prospect. The recalled context feeds into the LLM, which returns a structured JSON brief with key objections, a 2–3 sentence recommendation for the call, the last contact date, and the Deal Health Score.

Post-call logger. Rep types the prospect name, writes a few sentences, and selects an outcome: First contact, Objection logged, Positive signal, or Deal progressed. The backend stores the entry in Hindsight with metadata. The next brief automatically includes it.

Memory timeline. Rep types a name. The backend retrieves all stored interactions in reverse chronological order — call number, rough date, summary, outcome badge. You can scroll back and watch the deal evolve.

Weekly digest. The rep clicks "Generate my week." The backend retrieves all known prospects from Hindsight, recalls memory for each, and sends everything to the LLM in one call. The output is a prioritized action plan across three buckets: needs attention now (no response after 5+ days, stalled deal), follow up this week (active deal, clear next step needed), and on track (waiting on prospect, no rep action needed). Each item includes a concrete one-sentence action.

The Deal Health Score: how it actually works

This is the part that separates SalesMemory from a memory retrieval wrapper.

Every pre-call brief includes a Deal Health Score, generated by the LLM after reading all recalled memory for that prospect. We don't store this score anywhere. We have no database. The score is computed fresh on every request by feeding all recalled memory into the LLM and asking it to reason about momentum, risk, and confidence.

That means the score automatically improves as more memory accumulates. No schema migrations, no stale scores, no recalculation jobs. The score is always a function of everything the system knows right now.

The LLM returns six fields:

• score — integer from 0 to 100
• label — Cold / Warming up / Engaged / Hot / At risk
• momentum — improving / stalling / declining / new
• risk — single biggest risk in plain English
• recommended_action — the most important thing to do on this call
• confidence — low / medium / high (based on how much memory exists)

The scoring rubric we give the LLM:

• 0–20: Cold. No engagement or long silence.
• 21–40: Warming up. Early interest, objections unresolved.
• 41–60: Engaged. Active conversations, some positive signals.
• 61–80: Hot. Strong signals, near decision stage.
• 81–100: Closing. Verbal commitment or trial agreed.

Deductions: unresolved objections, budget uncertainty, long gaps since last contact, competitor mentions without resolution. Additions: pilot agreed, budget confirmed, multiple positive signals, clear next steps.

Here's what that looks like for a real prospect in the system. Priya Sharma, VP Sales at Rentokil, after four logged interactions (budget freeze flagged, onboarding concern raised, ROI calculator loved and pilot requested, pilot agreed with a new migration concern):

Score: 70/100
Label: Engaged
Momentum: ↑ Improving
Risk: "Data migration concerns may stall the deal"
Recommended action: "Provide a detailed data migration plan and timeline to alleviate Priya's concerns"
Confidence: Medium

That's not generic. It's generated from four specific logged interactions, pulled from Hindsight and fed into a scoring rubric. The rep walks into the call knowing exactly what to address.

How memory is stored and recalled

Storing an interaction after a call:

def retain_interaction(prospect_name: str, summary: str, outcome: str, timestamp: str):
    content = f"""
Prospect: {prospect_name}
Date: {timestamp}
Outcome: {outcome}
Summary: {summary}
"""
    client.retain(
        pipeline_id=PIPELINE_ID,
        content=content,
        metadata={
            "prospect": prospect_name,
            "outcome": outcome,
            "timestamp": timestamp,
            "type": "call_log"
        }
    )

Recalling that memory before the next call:

def recall_prospect(prospect_name: str) -> str:
    results = client.recall(
        pipeline_id=PIPELINE_ID,
        query=f"prospect interactions with {prospect_name}",
        top_k=10
    )
    return results

The metadata is important. Storing {"prospect": name, "outcome": outcome, "timestamp": timestamp, "type": "call_log"} is what makes the timeline view reliable. Without it, you're doing full semantic search on everything and hoping the right things surface.

The weekly digest collapses all of this into a single LLM call:

async def generate_digest() -> dict:
    all_prospects = get_all_prospects()
    prospect_contexts = []

    for name in all_prospects:
        recalled = recall_prospect(name)
        if recalled:
            prospect_contexts.append({"name": name, "context": recalled})

    prompt = build_digest_prompt(prospect_contexts)
    response = groq_client.chat.completions.create(
        model="llama-3.3-70b-versatile",
        messages=[
            {"role": "system", "content": DIGEST_SYSTEM_PROMPT},
            {"role": "user", "content": prompt}
        ],
        temperature=0.3,
        max_tokens=1200
    )
    return json.loads(response.choices[0].message.content.strip())

The alternative — one call per prospect, then merge — would be slower, more expensive, and less coherent. The LLM can only compare and prioritize prospects it can see simultaneously.

What the memory actually changes

The best way to see the value is to look at the same prospect at interaction 1 versus interaction 4.

At interaction 1, the brief for Priya Sharma says: no prior context, start fresh, no known objections. Confidence: low.

At interaction 4, after the budget freeze, the onboarding concern, the ROI calculator session, and the pilot agreement: the brief knows the deal health is 70, momentum is improving, the specific risk is data migration, and the recommended action is to come prepared with a migration timeline. Confidence: medium.

That delta is the entire product value made visible. The system didn't get smarter through retraining. It got smarter because it remembered.

The same pattern plays out across the other prospects in the system. James Okafor (Head of Revenue, Paysend) has three interactions logged — an API reliability concern, a technical deep dive where the SLA was well received, and a security report sent after a competitor pricing challenge. His brief knows he hasn't responded in 7 days since the security report went out. He lands in "needs attention now" in the weekly digest, with a specific action: follow up on the security report and address the pricing pressure directly.

Contrast that with Anika Patel (VP Growth, GoCardless), who has one interaction: GDPR compliance is a hard gate, the DPA needs signing before anything moves forward, and legal is reviewing it. Her brief says: no rep action needed yet. She's on track. The digest correctly leaves her alone.

Without memory, both of those would produce the same brief: "no context, start fresh."

What we learned

Semantic recall is not keyword search. Querying Hindsight with "prospect interactions with Priya Sharma" returns contextually relevant memories, not just exact matches. When reps log notes in inconsistent language — "she pushed back on timing" versus "onboarding timeline is a concern" — both surface for the same query. This matters more than it sounds. Real CRM notes are messy.

The prompt is the product. The quality of the Deal Health Score is entirely determined by the system prompt's scoring rubric. "Rate the deal" produces vague scores. Specific deduction and addition logic — unresolved objections subtract, budget confirmed adds, competitor mentions without resolution subtract — produces scores that match what a human sales manager would say. Prompt engineering here is not secondary to the engineering work. It is the engineering work.

One LLM call beats five. The digest endpoint sends all prospect contexts in a single prompt because the LLM reasons better when it can compare everything at once. It also cuts latency and API cost.

No database was a deliberate choice. Most developers reach for PostgreSQL immediately. We didn't. Hindsight is the only persistence layer — every interaction stored as a memory with metadata, recalled via semantic query, fed directly to the LLM. Zero schema design, zero migrations, zero ORM setup. The tradeoff: you can't run SQL aggregations like "sum all deals by stage." The gain: "recall everything relevant to Priya's budget concerns" works in a way SQL never could. For a sales context where the memory needs to be semantic, not structured, the tradeoff is worth it.

"No CRM update required" is what makes it sell. Every salesperson has been told to keep the CRM updated. Nobody does. SalesMemory works with informal, unstructured notes — "she seemed unsure about the onboarding" — because Hindsight documentation shows that the system stores and recalls semantic meaning, not structured fields. Reps log notes the way they naturally write. The system handles the rest.

The core idea behind agent memory isn't complicated: an agent that can't remember isn't really an agent. Every interaction should make the next one better. That's true for engineering incident response, for customer support, for sales.

In a sales context, the problem is acute because deals take months and reps carry dozens of them simultaneously. The rep who closes isn't the one with the best pitch. It's the one who shows up to every call knowing exactly where they left off, what the prospect cares about, and what still needs to be resolved. SalesMemory makes that possible without asking reps to change how they work.