Memory-Driven Personalization at Scale

Most AI agents treat every user the same. The ones that don't — the ones that remember, adapt, and improve — are the ones users keep coming back to. Here's how to build that with access_count, confidence scoring, and a persistent memory layer.

The personalization problem in LLM applications

LLMs are stateless by design. A vanilla GPT-4 call has no memory of past sessions, no preference model for the user, no understanding of behavioral patterns. You can inject some context via the system prompt, but that context is static — written once, never updated based on what you actually learn about the user.

The traditional patches are expensive or fragile. Stuffing a growing "user profile" into every prompt consumes tokens fast. RAG pipelines help with knowledge retrieval but weren't designed for behavioral personalization. Custom user profile tables in your DB solve part of the problem but require schema changes and manual extraction logic every time you want to track something new.

What you actually need is a flexible, queryable store of what each agent has learned about each user — with a signal for which memories matter most. That's what access_count and confidence scoring give you.

Understanding confidence scoring

In Kronvex, every recalled memory comes with a confidence score between 0 and 1. It's a composite signal computed from three factors:

confidence = similarity × 0.6 + recency × 0.2 + frequency × 0.2

• Similarity (60%) — cosine distance between the query embedding and the stored memory embedding. High similarity means the memory is semantically relevant to what's being asked.
• Recency (20%) — sigmoid function with a 30-day inflection point. A memory accessed yesterday scores higher than one from 3 months ago.
• Frequency (20%) — log-scaled access_count. Every time a memory is recalled, its count increments. Frequently retrieved memories are weighted higher.

The frequency component is what makes agents self-improving. The more a memory gets recalled — because it's reliably relevant — the more influence it has on future recalls. This is a positive feedback loop you can exploit deliberately.

Building a user preference model

The simplest form of personalization is a user preference store. After every meaningful interaction, you extract preference signals and store them as semantic memories:

import kronvex

client = kronvex.Kronvex("kv-your-api-key")
agent = client.agent("sales-agent-001")

# After a call where the prospect mentioned their stack
agent.remember(
    "Prospect uses React + TypeScript on the frontend, FastAPI on the backend",
    memory_type="semantic",
    metadata={"user_id": "prospect-abc", "category": "tech_stack"}
)

# After they pushed back on a pricing slide
agent.remember(
    "Prospect is price-sensitive — emphasize ROI before quoting numbers",
    memory_type="procedural",
    metadata={"user_id": "prospect-abc", "category": "sales_style"}
)

Before the next call, inject context filtered by user and category:

ctx = agent.inject_context(
    query="prepare for prospect call",
    metadata_filter={"user_id": "prospect-abc"},
    top_k=8
)

system_prompt = f"""You are a sales assistant.
Known context about this prospect:
{ctx.context}

Always adapt your pitch to their preferences."""

Using access_count to surface what matters

The access_count field increments automatically every time a memory is recalled via /recall or /inject-context. You can query it directly to find your "sticky" memories — the ones that keep showing up as relevant:

# Via REST API — get high-frequency memories for a user
curl -X GET "https://api.kronvex.io/api/v1/agents/sales-agent-001/memories" \
  -H "X-API-Key: kv-your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"metadata_filter": {"user_id": "prospect-abc"}, "sort_by": "access_count", "limit": 5}'

High-access-count memories are candidates for promotion into the system prompt as permanent context. They've proven themselves relevant enough to be worth the token cost of always including them.

Personalization at scale: multi-user patterns

When you're handling thousands of users, per-user memory namespacing is critical. Kronvex uses agent + metadata to isolate memory spaces. A single agent can serve many users if you scope memories with a user_id metadata field and always filter on it at recall time.

from kronvex import AsyncKronvex
import asyncio

async def personalized_response(user_id: str, query: str) -> str:
    async with AsyncKronvex("kv-your-api-key") as client:
        agent = client.agent("support-agent")

        # Recall user-scoped memories
        memories = await agent.recall(
            query=query,
            metadata_filter={"user_id": user_id},
            top_k=5,
            min_confidence=0.45
        )

        # Build context block
        if memories.results:
            memory_context = "\n".join(
                f"- {m.content} (confidence: {m.confidence:.2f})"
                for m in memories.results
            )
        else:
            memory_context = "No prior context for this user."

        return memory_context

The min_confidence parameter is your quality gate. Setting it to 0.45 means you only inject memories that are reasonably relevant — preventing noise from low-signal memories diluting your prompt.

The compounding effect over time

The real payoff of memory-driven personalization is compounding. After 10 interactions, your agent has a rudimentary user model. After 50, it knows tone preferences, domain vocabulary, pain points, and decision-making patterns. After 200, the agent provides genuinely personalized responses that feel human — because they're grounded in actual interaction history, not generic persona templates.

This is qualitatively different from embedding a static user profile JSON. Static profiles require human curation and go stale. Memory stores update automatically with every interaction, and the confidence scoring ensures that recent, frequently accessed signals bubble up while old, rarely relevant memories fade naturally.

What to store and what not to

Not every piece of information deserves a memory. A good rule: store observations that change how you'd communicate, not raw conversation transcripts.

• Store: preferences, constraints, past decisions, communication style signals, domain-specific vocabulary
• Don't store: full conversation turns, raw JSON payloads, PII beyond what's necessary, ephemeral session state

Use memory_type to tag what kind of knowledge each memory represents. semantic for facts about the user, procedural for how to behave with them, episodic for specific events or milestones.