I run a memory layer that injects relevant past context into an agent's prompt automatically, every turn. Yesterday I stopped assuming it worked and looked at what it actually injected, across seven consecutive prompts of a real working session.

prompt	what got injected	related?
"check reddit"	a websocket note, a competitor, a GitHub repo	no
"why specifically with claude code"	Claude Desktop, a person, an internal service	partly
"what if they don't have claude code"	Claude Desktop, Mem0, an internal service	partly
"what is the value of our product"	an internal service, Redis, another project of mine	no
"restart it and check"	Spring Boot, a former employer, another project	no
"so now?"	sentence-transformers, a former employer, a person	no
"what do you mean, relevance"	SQLite, another project, a GitHub repo	no

Five of seven had nothing to do with what was asked. A question about hook payloads came back with facts about a Java backend at a bank, stored in February for a completely different project.

The cause is not the ranking. It is that "nearest" is defined for every query, so the search always has an answer. Silence is not in its output set. There was a floor, min_score = 0.2 cosine, but 0.2 is noise. Two unrelated sentences clear it routinely, because they are both sentences.

The same system has a plain-files mode that retrieves by word overlap, and it never does this: zero overlap means nothing is injected. That property was lost the moment retrieval moved to embeddings, and nobody noticed, because this failure looks like a feature. There is always something in the context.

The fix only removes, never adds: before injecting, require the memory to share at least one content word with the prompt. I already had exactly that guard in another part of the system, where a learned workflow has to share a word with a shell command before it is allowed to interrupt the user with a confirmation. It never occurred to me that retrieval needed the same thing.

Two mistakes I made while fixing it, both instructive:

1. My first version passed everything through when the prompt had no content words at all, reasoning that if you cannot read the query you should not silence recall. Exactly backwards. The shortest prompts are where the search has least to go on, so the "safe" default left the worst cases untouched. "so now?" pulled three entities out of the store as confidently as a detailed question would.

2. I reused a tokenizer from elsewhere in the codebase that only matched ASCII letters. Plenty of my prompts are not in English. It found zero words in them, which would have silenced recall completely instead of filtering it: a much worse bug, and one that ships silently.

After the change: silent on 5 of 7, and the 2 that kept anything kept only the entity the question was actually about.

I did not touch the 0.2 floor. Picking a real number needs the actual score distribution from production, which is a separate measurement I have not earned yet.

So: does anyone here run an explicit "return nothing" path in production RAG? And what do you gate it on, an absolute score floor, the margin between top-1 and top-2, a lexical check like this one, or a reranker with a reject option?

There are a lot of markdown-memory projects now — EverOS, basic-memory, iwe, understory. The idea that an agent's memory should be plain files you own is not mine and I'm not pretending otherwise.

Two things kept bothering me anyway.

First, every one of them has its own layout, so nothing reads anything else's. Move between tools and you write a converter.

Second, and this is the one I actually care about: they all store what the agent should do, and none of them store whether it ever worked.

Here is a procedure file in the format I ended up writing down:

---
memfmt_type: procedure
version: 3
success_count: 11
fail_count: 1
---

# deploy to Railway (v3 · 86% reliable)

**When** — a change lands on main

## Steps

1. push to main — the webhook does the rest
2. watch the boot log
3. verify /health — expect 200 within 60s

## Evolution

- v1 → v2 (2026-06-02): added the health check
- v2 → v3: wait for the pool before probing

11 ✓ / 1 ✗ is the whole point. (The header says 86% rather than 11/12 because it is smoothed against a prior — one success must not read as 100%, and a fresh revision must not read worse than the version it was written to fix. The header is rendered from the frontmatter; editing it by hand changes nothing.) It is the difference between a workflow an agent should follow and something somebody wrote down once and never checked. An agent reading this can tell that step 3 has survived eleven deploys, and that the version it is reading exists because an earlier one failed.

The rest is boring on purpose. Entities are what is true, episodes are what happened and how it turned out, procedures are the above. Relations are [[wikilinks]], so Obsidian draws the graph with no configuration and git gives you diffs, review and rollback for free — git diff on what your agent learned this week, a PR when it learns something wrong, git revert when it learns something harmful.

pip install memfmt

memfmt stat ./memory        # what is in here
memfmt validate ./memory    # would any file lose data if a tool rewrote it?
memfmt context ./memory "why did the deploy fail"   # the relevant bits, to pipe into a model

No account, no server, no network, no dependencies. It reads and writes files.

The part I care about most is validate. A format is only real if two tools agree on it, so the library round-trips: parsing what it serialised gives back the same object, and serialising what it parsed is byte-identical. validate runs that against a real folder and names any file that would lose data. The test suite is the spec in executable form — if you want to propose a change to the format, the change to the tests is the proposal.

Honest about the limits:

• Relevance in memfmt context is word overlap. No embeddings, so it misses things phrased differently. Past a few hundred files you want a real index.
• Syncing a folder between machines is not solved here. It is a git pull only until two machines disagree.
• I build a hosted memory product, and it writes this format. But the library stands on its own and does not expire if you never touch the product — that was the condition for publishing it at all.

This is meant as a format, not a product. If you maintain one of the tools above, implementing it is an afternoon, and then your users can leave — which I realise is a strange thing to advertise, but a memory you cannot take with you is not really yours.

Repo link in the first comment (sub rule).

Question for people who have built this: does anyone store a success/failure count on learned workflows? I could not find one that does, and I would rather adopt an existing convention than add another.

Was setting up a proper backup of one of my bases and went to check what the export actually contains. Posting because I did not know this.

Attachment URLs expire two hours after the API returns them. It's in the docs (https://airtable.com/developers/web/api/field-model), along with the recommendation to download the files rather than store the links. So the attachment column in a CSV export is a list of links that are dead by tomorrow: the records survive, the files do not.

While I was in there, two more things I had assumed were covered and are not:

- Linked records export as bare rec... IDs, with nothing alongside them to rebuild the relations.

- Field types, select options and formula definitions are not in the export at all.

Not bugs, just what the export is. But if your backup plan is "I can export a CSV whenever I want", it's worth testing that assumption on a base you care about - specifically, open one of the exported attachment links tomorrow and see what happens.

If anyone has found a way to keep attachments through the built-in export I'd genuinely like to hear it.

Every agent I use has the same blind spot: hand it a log file bigger than its context and it reads the first few hundred lines, greps around, then reasons confidently about whatever it happened to see. A bigger model doesn't fix it — the file is just larger than the window.

So I built an MCP server that reads the whole file and hands back a summary of what actually happened in it.

{ "mcpServers": { "logsleuth": { "command": "logsleuth-mcp" } } }

brew install alibaizhanov/tap/logsleuth or pipx install logsleuth. Zero dependencies — pure Python standard library, nothing to pull in.

Measured on a 208MB log: 1,576,412 lines read in 9.1s using 58MB of RAM, returned as 12,646 characters. Memory doesn't grow with file size, so a 2GB log costs the same as a 2MB one.

No model runs in the server. Your agent is the model, and a much better one than anything I'd run locally. The server's only job is to make the file legible: it's all deterministic, so nothing leaves the machine and nothing is nondeterministic between calls.

Three tools:

- read_log_evidence — the whole file, or a window (last: "30m", or since/until)

- inspect_log_file — cheap check before you spend a turn on something that turns out to be a core dump

- log_parse_diagnostics — format diagnostics containing zero log content, safe to show a user

What "12KB" actually contains, because truncation would be useless: deduplicated line patterns with how often each occurs and where it first appears; near-unique lines ranked as candidate state changes; numeric trends across the file; how errors distribute across service/pod/host; and raw context around where new errors start.

The ranking is by rarity and position, not volume — a config line that appears once, thirty seconds before the first new error, outranks ten thousand timeouts. That's not a style choice. On an annotated benchmark of 30 microservice failures, "blame the service with the most error lines" gets it right 0 times out of 30, worse than chance, because the loudest service is the caller that timed out waiting rather than the one that broke. Write-up with the numbers: https://alibaizhanov.github.io/logsleuth/loudest-service/

Limits, so you don't find them at 3am: logs only — a failure that's invisible in logs is invisible to this. Timestamps parse on 87% of the 132 public corpora I tested against, so an exotic format will get you a thinner summary. And it never writes to the file you point it at — the only thing it ever creates is a temp file when you ask for a time window, which it deletes afterwards.

MIT, source and every benchmark script: https://github.com/alibaizhanov/logsleuth

Happy to answer anything, and if it produces a bad summary on a log of yours I'd genuinely like to see it — I have no telemetry, so a report is the only signal I get.

Every new Cursor session, same ritual: re-explain the architecture, re-state the constraints, watch it suggest the approach I rejected two weeks ago. Rules files help but they're static — they hold what I remembered to write down, not what actually happened in sessions. And they drift: my .cursorrules said "3-step deploy" for a month after the process became 4 steps.

What ended the ritual for me is a pattern, not a product (though I'll disclose mine at the end): **memory as an MCP server + one paragraph in your rules telling the agent when to use it.**

The mechanics:

**1. An MCP memory server** exposes `remember` / `recall` / `search` tools to Cursor (Settings → MCP, or `~/.cursor/mcp.json`). Any memory backend works — a self-hosted store, a hosted one, even a homegrown SQLite wrapper. The point is the memory lives *outside* the context window and *outside* static files.

**2. One rules paragraph** makes it automatic. Mine says roughly:

> Before starting significant work, call `recall` with the task topic. After completing significant work or when the user states a decision/preference/constraint, call `remember` with a one-line summary.

Without this paragraph, MCP memory is a tool the agent forgets to use (ironic). With it, capture and recall become part of every session's rhythm — no manual bookkeeping.

**3. The unexpected payoff is cross-tool.** Because it's MCP, the same memory server plugs into Claude Code, Windsurf, or a Codex setup. Explore a codebase in one tool, and the understanding is there when you open another. The "re-explain everything per tool" tax disappears — for me that was worth more than the per-session persistence.

**Honest limitations, because this isn't magic:**

- Capture quality depends on the agent actually calling `remember` — rules-driven invocation is ~reliable in Agent mode, less so in quick edits. (Claude Code solves this with hooks that fire deterministically; Cursor doesn't have an equivalent yet — if Cursor ever ships lifecycle hooks, this whole pattern gets strictly better.)

- Retrieval adds a tool call of latency when the agent decides to recall.

- A memory full of stale facts is worse than no memory — whatever backend you pick needs decay/versioning, or you're rebuilding .cursorrules drift with extra steps.

If you're hand-rolling: SQLite + a tiny FastMCP server gets you a working remember/recall in an evening, and honestly that's the right way to feel out whether the pattern fits you.

---

Disclosure (rule 6): I build Mengram (mengram.io) — a hosted/self-hostable memory backend that speaks MCP and does the extraction/decay/versioning part (free tier exists). The pattern above works with any backend; the rules-paragraph trick is the actual takeaway.

Yesterday I nearly declared a production retrieval emergency that didn't exist, and the mechanism is general enough that anyone running hybrid search should check for it.

**Setup:** hybrid retrieval over personal memory — vector similarity + BM25, fused with Reciprocal Rank Fusion, optional cross-encoder rerank on top for some tiers. Every search logs `top_score` for quality monitoring.

**The scare:** analyzing 10,706 logged searches, I applied the obvious threshold — top_score < 0.3 = weak retrieval. Result: 62% "failures," a dozen users at "100% failure with avg score 0.017," and a terrifying month-over-month "degradation" trend. One of the "100% failed" users was a paying customer with a thousand searches. I was halfway into incident mode.

**The tell:** a search for an exact entity name — a guaranteed hit — logged top_score 0.0426. And those "failing" users all averaged 0.016–0.021. Then it clicked: RRF scores are 1/(k + rank) with the standard k=60. Top rank = 1/60 ≈ 0.0167. My "catastrophic" users weren't failing — **their top result was rank-1 almost every time.** avg 0.017 is what perfect RRF retrieval looks like.

What actually happened: requests that go through the reranker log cosine-style scores (0–1 scale, 0.3+ = good). Requests on the raw RRF path log fusion scores (0.016–0.05 scale, where 0.017 = excellent). Both landed in the same `top_score` column with no scale tag. Every aggregate over that column — means, z-scores, my failure thresholds, even the health monitoring cron — was averaging apples with orbital velocities. The "month-over-month degradation" was just the RRF-path share growing as more traffic moved to hybrid.

**What survived scale-correction:** true failure (zero results) was 9–13%, driven mostly by two accounts whose agents were querying literally empty stores — a real integration problem, but a completely different one than "retrieval is broken."

**Lessons, generalized:**

1. **A fused ranking score is not a similarity.** RRF outputs rank information, not confidence. The moment you fuse, your score's absolute value stops meaning what your dashboards think it means.
2. **Never store scores from different scoring regimes in one unlabeled column.** Log a `score_kind` (or a scale-aware quality label computed at write time, which is what we shipped: strong/weak/no_match with per-scale bands). Analysis-time guessing is how you get 3am false incidents.
3. **The only scale-free failure signal is emptiness.** Zero results means the same thing on every path. When in doubt, count zeros, not thresholds.
4. **Validate your alarm against a known-good query before believing it.** One exact-match search that "scored 0.04" saved me from paging myself.

Sources for the RRF math: Cormack, Clarke & Buettcher (2009), "Reciprocal Rank Fusion outperforms Condorcet and individual rank learning methods" — the k=60 default everyone inherits comes from there.

Disclosure per rule 3: the production system is Mengram (mengram.io), a memory layer for AI agents — but the trap applies to any RAG stack mixing rerankers with fusion scoring. Nothing here requires my product to check: grep your score column and look for a bimodal cluster around 1/60.

Most "agent memory" today stores facts and events: what the user said, what the project is, what happened last session. Useful — but watch where an agent actually burns tokens and retries: it re-derives the process every single run. Wrong step order, forgets the migration, retries the exact thing that failed on Tuesday. The context was in memory. The know-how wasn't.

Psychology has a name for this split: episodic memory ("I remember going to the dentist") vs procedural memory ("I remember how to ride a bike"). Nearly every memory framework ships the first kind and skips the second — because the second is structurally harder. A workflow isn't a fact you extract once. It's a procedure that must CHANGE when it fails.

There's fresh academic backing. A recent paper from Zhejiang University + Alibaba (Memp — arXiv 2508.06433) built procedural memory from agents' own past trajectories, tested on GPT-4o, Claude Sonnet and Qwen. Their strongest mechanism wasn't storing successes — it was reflecting on failures to revise the stored procedure. The failure is the signal.

From running this in production, three arguments:

1. Session recall and workflow learning are different problems. Perfect episodic memory still pays the full process tax every run.

2. Procedures need version history, not overwrites. v1 from a session → v2 adds the missing migration step after a failed run → v3 reorders after an env-var race, 11 successes since. An agent loading v3 doesn't repeat the two mistakes that produced it.

3. A procedure that never failed is a procedure you can't trust yet. Success count alone is survivorship bias — you want fail_count, what changed after each failure, recency. That's also your pruning signal.

The uncomfortable implication: hand-maintained instruction files (CLAUDE.md, AGENTS.md, rules) are static snapshots of procedural knowledge — they rot because updating them requires a human to notice the failure, remember to edit, and phrase it as an instruction. Nobody does that reliably.

Curious what others do for workflow-level memory: hand-rolled? Fine-tuning? Just eating the re-derivation cost every run?

I run a remote MCP server (memory for AI agents — disclosure at the bottom) that serves streamable HTTP at a single /mcp endpoint behind gunicorn with multiple workers. Getting it stable taught me three things that aren't obvious from the SDK docs, and I haven't seen them written up anywhere, so here they are.

1. Session-based transport breaks the moment you have >1 worker

The Python SDK's default flow assumes the session that handled initialize sees the follow-ups. With 2+ gunicorn workers there's no such guarantee — the follow-up lands on a worker that's never heard of your mcp-session-id, and clients get intermittent failures that are miserable to reproduce (works locally with one worker, flakes in prod).

• Fix: Run the transport stateless (mcp_session_id=None, stateless=True) and build a fresh server per request. Any worker serves any request.

2. Starlette silently wraps route functions — mount an ASGI class instead

A plain async function route gets wrapped by request_response(), which expects a returned Response. But transport.handle_request() drives the ASGI cycle itself and returns None → intermittent TypeErrors and dropped connections that look like client bugs.

• Fix: Mount a real ASGI callable (class MCPStreamableHandler: async def __call__(self, scope, receive, send)) — Starlette leaves the cycle alone.

3. StreamableHTTPSessionManager can't do per-request (multi-tenant) auth

It takes a single Server instance up front — nowhere to inject the tenant when every request carries a different Bearer token.

• Fix: You need a per-request factory: parse auth header → construct a Server bound to that tenant → fresh stateless transport. Rock-solid for months since.

Happy to answer questions or share more of the setup — took embarrassingly long to figure out from symptoms like "MCP works in Claude Desktop on Mondays."

Disclosure / showcase: The server is Mengram (mengram.io) — long-term memory for agents (semantic facts + episodic events + procedural workflows, ~29 MCP tools). I'm the founder. Free tier 40 adds + 200 searches/mo, paid from $5/mo, core Apache 2.0 / self-hostable. This week it also landed in the official MCP registry as io.github.alibaizhanov/mengram.

Vapi assistants are stateless across calls. The standard solutions are mem0+n8n tutorials, Synthflow's bundled memory, or rolling your own with a database and webhook. I spent the last week building a webhook adapter for this and ran into 5 things that weren't obvious from the docs. Sharing in case it saves someone else the trial-and-error.

1. Vapi sends BOTH toolCalls AND toolCallList — different shapes

When your custom tool fires, Vapi posts BOTH arrays on the same message:

• toolCalls: OpenAI-spec nested — [{id, type, function: {name, arguments}}]
• toolCallList: flattened — [{id, name, arguments}]

"arguments" in toolCalls arrives as a JSON STRING (per OpenAI spec); in toolCallList it's already parsed. If your webhook only reads one shape, you'll silently get undefined names or empty args from the other. Handle both — and JSON.parse the string variant.

Source: github.com/VapiAI/docs/blob/main/fern/tools/custom-tools.mdx

2. The server URL receives EVERY event, not just end-of-call

If you wire one Server URL for the assistant, you'll get: status-update, conversation-update, partial transcript chunks (streamed mid-call, transcriptType: "partial"), end-of-call-report, hang, speech-update, transfer-destination-request, etc.

If your memory-save handler doesn't filter on message.type == "end-of-call-report", it will fire on every partial transcript — running your extraction pipeline dozens of times per call, duplicating data, and burning quota. The fix is a 2-line type guard.

3. Final transcript lives at TWO paths

End-of-call-report has the transcript at BOTH message.transcript AND message.artifact.transcript. They're identical for completed calls, but on transfer/hangup edge cases I've seen one populated and not the other. Read whichever is present, don't assume.

4. For "known caller" recall, semantic search is the wrong primitive

I started with vector similarity for the recall webhook ("find facts relevant to this caller"). The query "important facts about caller +1555" matched basically nothing against real fact embeddings like "prefers morning slots."

For a phone-keyed caller you want EVERYTHING you know about them, not "most relevant to a query." Direct fetch by sub_user_id=voice:phone_number returns deterministic results. Then sort: persons by fact count desc so the actual caller surfaces ahead of mentioned people (their daughter, their doctor, the clinic agent — all get extracted as type=person).

5. Web "Talk to Assistant" calls have NO customer.number

If you're testing via Vapi's web button, call.customer doesn't exist. You can't phone-key web calls — fall back to call.id as the namespace, or surface a "no phone number, can you tell me your name?" path in the assistant prompt. For real end-to-end testing, just buy a $1/mo Vapi number and call yourself.

What I'd actually benchmark next

Latency. End-of-call extraction is async (fine), but recall is in the greeting hot path. Single recall on my setup is ~800ms p50; under 20 concurrent calls it climbs to ~1200ms p95. For sub-1s SLAs you need either a smaller summary (skip rerank, return fewer facts) or precompute caller summaries via cron.

Anyone running voice memory at production scale (>1000 calls/day) — what were your retrieval-latency tricks?

Disclosure: I built an open-source MCP memory server (Apache 2.0) that does the above; if anyone wants reference code, the Vapi adapter is at github.com/alibaizhanov/mengram. But the gotchas above apply to any implementation.

I've been building an MIT-licensed memory layer for LLM agents (disclosure: I'm the author, repo at the bottom). Sharing two implementation choices that moved retrieval quality the most, in case useful for anyone working on similar.

Problem

Vector similarity alone ranks "I bought milk in 2019" the same as "I bought milk yesterday" if embeddings are close. Agent memory needs recency AND salience biasing retrieval, not just semantic match.

Approach 1 — Ebbinghaus decay for facts

For semantic facts (e.g. "User lives in Berlin"), exponential decay:

decay = e^(-k * days_since_last_access)

Here, k = 0.03, tuned so facts halve in salience in about 23 days.

>

Final score:

final = rrf_score * decay

Approach 2 — Importance weighting for episodes

Inspired by Stanford's Generative Agents (Park et al. 2023,https://arxiv.org/abs/2304.03442). At extraction time, the LLM scores each episode 0–1 on emotional/factual salience. At retrieval, importance modulates score with bounded range:

boost = 0.8 + 0.4 * importance (range: [0.8, 1.2])

final = rrf_score * decay * boost

Bounding to [0.8, 1.2] is critical — wider range (e.g. 0.5–2.0) drowns out vector similarity. Tight band lets importance break ties between similar-quality results without overriding semantic match.

What didn't work

• Linear decay (too aggressive past day 7).
• Importance multiplier >2x (overrides semantic match badly).
• Decay on episodes without importance signal (loses old but important memories).

Hybrid retrieval base

Decay/importance sits on top of Reciprocal Rank Fusion (RRF) over [vector, BM25]. Pure vector misses keyword queries ("what was the API key?").

>

Stack

• Python (FastAPI)
• Postgres + pgvector
• OpenAI text-embedding-3-large (1536-dim)
• MCP server frontend

Full implementation (MIT):

https://github.com/alibaizhanov/mengram

Relevant files: cloud/store.py — search_episodes_vector, search_procedures_vector

The choices around k = 0.03 and importance bounding [0.8, 1.2] took the most iteration. Would love to hear what others tuned for similar memory systems — especially how you handle procedural memory (workflows/skills) vs declarative.

I've been operating an AI memory layer for the past year, watching what shapes agent memory actually takes in production. Most tutorials stop at "add fact, retrieve fact." Real production agents combine these primitives into wildly different products. Here are 5 patterns I keep seeing, with the architecture for each.

1. The Daily Brief

Shape: Agent runs on cron, pulls fresh sources, diffs against memory, emits digest only if something changed.

Common variants: morning news brief, KPI report, dependency update digest, security alert summary.

Why memory matters: without persistence, every run starts blind. The agent re-summarizes the same article you saw yesterday.

Architecture: cron → fetch sources → search memory ("what did I report yesterday?") → diff vs memory → if delta > threshold: emit brief → save to memory.

>

2. Multi-Tenant SaaS Memory

Shape: Each end-user has their own memory scope, but the application uses a single backend.

Why memory matters: without per-user isolation, Alice's history bleeds into Bob's. Search returns wrong context. Trust collapses.

Architecture: Every memory operation takes a user_id derived from your auth layer (NEVER from LLM output — that's a data leak waiting to happen).

The deep design rationale: a multi-tenant agent needs two-tier identity — your API credential authenticates the application, while user_id inside each call scopes the end-user. MCP spec doesn't define this out of the box, you have to build it on top.

3. Non-Developer Knowledge Work

Shape: Workflow has nothing to do with code: drafting briefs, reviewing documents for sensitive language, cross-referencing meeting notes, organizing coalition working groups.

Who builds it: researchers, organizers, lawyers, journalists. Not engineers. They use Claude Desktop / Cursor with memory as MCP server, no custom code.

Why memory matters: knowledge work is fundamentally about connecting current input to remembered prior context. Without persistence, AI is souped-up Ctrl+F.

Interesting wrinkle: these users structure memory differently. A developer's entity is "AWS Lambda" with config facts. A knowledge worker's entity is "Partner Working Group" with attendees, decisions, linked documents. Same primitives, totally different shape.

4. Cloud Infrastructure Automation

Shape: Agent manages a sprawl of cloud resources — AWS roles, DNS records, certificates, billing alerts, deployment pipelines.

Why memory matters: cloud accounts accumulate state at a rate humans can't track. By month two there are 80+ IAM roles, 200+ DNS records. Without memory, every change is fresh archaeology.

Architecture: entities = cloud resources, facts updated on every describe-* API call. Procedural memory captures repeatable workflows ("monthly billing report upload," "rotate IAM keys").

>

5. Personal Life Dashboard

Shape: Assistant that knows your routines, relationships, projects, preferences. Surfaces what matters. Smart triggers when something contradicts memory.

Why memory matters: the original "personal AI" promise. Without long-term memory it's a chatbot that forgets your spouse's name between sessions.

Trap: over-collection. Memory grows fast — a few weeks in, search results dilute with stale facts. Need decay (Ebbinghaus-style weighting) plus periodic curator passes.

How patterns combine

Real production agents are usually two or three patterns stacked:

• Daily Brief + Personal Life Dashboard — your morning agent that already knows what you care about.
• Multi-Tenant SaaS + Cloud Infra Automation — internal tool where each engineer has their own scoped AWS memory.
• Non-Developer Knowledge Work + Multi-Tenant SaaS — coalition platform where each working group has isolated memory.

Most common architectural mistake I see: starting with "I'll add memory to my chatbot" (chatbot pattern), but actually needing the Daily Brief pattern — where memory is the diff against past output, not conversation history.

Pick the pattern that matches your workflow shape, not your interface shape.

What patterns are you seeing? Curious if there are shapes I'm missing — especially anything outside the dev/knowledge-work axis.

Solo dev here. I build an open-source memory layer for AI agents. Just hit a small milestone (paying customers, modest MRR — not Twitter-flexable yet), but I felt it was worth sharing something that almost killed the product before I even noticed.

== The hidden bug ==

A customer in Russia pinged me: "The AI agent keeps asking me my name every conversation, can you fix it?"

Memory writes were succeeding and logs were clean. However, search reads were returning empty. From my dashboard, everything looked fine. I almost told him: "User error, save your name first."

But I decided to test with his actual queries and saw retrieval scores like 0.03 (basically random) for non-English queries. The bug was in the embedding model, not the agent code.

== The Industry Default Bias ==

OpenAI's text-embedding-3-large is the industry default. It's also English-first by design. On non-English queries, the cosine similarity drops off a cliff:

• English: 0.70 cosine — Works
• Spanish: 0.30 cosine — Weak
• Russian: 0.25 cosine — Weak
• Chinese: 0.03 cosine — Basically random

If your SaaS serves international users and uses OpenAI embeddings, you likely have this problem. You probably don't know it because:

• Memory writes succeed silently.
• There are no errors in your logs.
• Native English testing passes perfectly.
• International customers just churn quietly.

== What I changed ==

Switched to Cohere's multilingual-v3 model. The same query/data went from 0.03 to 0.77 on Chinese.

The migration took a weekend. Total cost: under $1 in API fees for backfilling 80k+ embeddings.

== Lesson for solo founders ==

The metrics that look fine to you are filtered through the language YOU use. If your customers churn quietly and you don't know why, look at the parts of your stack that have known biases toward your own context.

Embedding models, content moderation APIs, OCR — all are biased toward common-locale English-speaking users. If your product crosses that boundary, all of them silently underperform without throwing a single error.

I should have caught this 6 weeks earlier than I did.

I built a memory layer for AI agents. Recently, one of our paying customers came back with a frustrating bug: "The agent keeps asking me my name every single session."

The memory was being saved correctly in the database. Search just wasn't finding it.

The Bug

Their queries weren't in English. The agent was using OpenAI's text-embedding-3-large (the industry default), which is English-first by design. On non-English queries, the embedding quality drops off a cliff.

Look at the cosine similarity for the same data, same model, just changing the query language:

• English query → 0.70 cosine (finds the right fact)
• Spanish query → 0.30 cosine (weak match)
• Chinese query → 0.03 cosine (basically random)

The customer's agent was retrieving zero relevant memory on every query. From the agent's perspective, the user had no history, so it just started over. Every time.

Why this matters for anyone building agents

If your agent serves non-English users (or users who code-switch), you likely have this problem and don't know it. Memory writes work. Memory reads silently fail. Your agent looks "dumb," but you’ll see zero errors in your logs.

The Fix

The fix is the embedding model, not the agent code. Switching to Cohere's multilingual-v3 closed the gap immediately (Chinese cosine went from 0.03 → 0.77 on identical data).

Don't just look at dimensions. Pick a model trained for multilingual parity, not one fine-tuned mostly on the English internet.

Practical Takeaways

1. Test in native languages: The bug isn't visible in English-only evals.
2. Measure Cosine Similarity: If you use OpenAI for non-English data, measure real queries against real data before assuming RAG works.
3. Zero-Downtime Migration: Add a new column to your DB, route queries by vector dimensionality, and backfill asynchronously.

The migration cost under $1 in API fees and took one weekend. The agent now finally remembers its users.

Happy to share the technical migration details (dual-column schema, backfill script, and two production gotchas) in the comments if useful!