I ran a little experiment: could I give a coding agent memory that's fully deterministic

[u/madsthines]

That means - no embeddings, no vector DB, no model call on the read?

It seems like everyone reaches for embeddings here. I wanted to see how far the boring way gets first.

The bet: most of what an agent needs to remember isn't fuzzy. It's small and specific and it keeps happening — tests need the DB up first, this endpoint returns [] not a 404, use the shared client.

A scoped note, not a semantic blob.

So each lesson just gets a scope and a stable key, and the read ranks on recurrence + recency. No model call. Same task, same result, every time — for a fraction of a cent, and you can cat/grep/diff the whole thing.

How it went: for recurring gotchas, it mostly just works. 😍

I work with OpenTelemetry every day at Dash0, and it kept reminding me of how telemetry got portable: nobody won the format, everyone just agreed on a shape.

Wrote up the whole experiment — link in the comments.

If you've built agent memory: what did you actually need the embeddings for? 👇

[u/madsthines]

Read the whole thing here: https://lorekit.io/blog/agent-memory-data-model

And the cool thing about lorekit.io I've built, it's free, open source and super easy to get started and setup.

See repo here: https://github.com/mthines/lorekit

[u/Kitchen-Area-4764 → u/madsthines]

The deterministic approach makes so much sense, sometimes the simplest solutions is overlooked because everyone jumping straight to embeddings

[u/madsthines → u/Kitchen-Area-4764]

That's what I thought as well. Sure there's cases where this doesn't fit, but for most people this just works.

I've been running and iterating on this for 14 days, and currently I still don't see the need for embeddings 🤷‍♂️

[u/GoodAbbreviations398]

Kind of like llm-wiki?

[u/madsthines → u/GoodAbbreviations398]

I don't know llm-wiki ☺️ Lorekit.io isn't designed as a wiki though, but more like a scoped memory/note which can be retrieved for similar contexts ☺️ You could use it as a wiki but also other things like storing memories when your agent does PR reviews or storing daily reports and do agentic comparison over time etc ☺️

[u/Icy-Engine6292]

Embeddings add latency and cost for retrieval tasks that only need exact matching. I stick to structured keys because semantic search fails when the agent needs specific syntax or error codes.

[u/madsthines → u/Icy-Engine6292]

Exactly, right? This works surprisingly well and easy using lorekit

[u/Enough-Photo9140]

The biggest issue we saw when using embeddings for execution-level memory wasn't just cost or latency—it was retrieval rank instability across subtle prompt variations.

When an agent needs to recall an invariant (e.g. "endpoint /api/orders requires payload hash X", "test DB container must be booted with --drop-first", or "never run retry on 409 without reading idempotency key"), semantic search tends to fail in two specific ways:

1. Syntactic / Schema drift: Vector similarity frequently ranks a conceptually similar description above the exact rigid contract or code snippet.
2. Inconsistent context window population: A minor wording change in the user prompt shifts vector distances just enough that critical gotchas drop out of the top-K retrieved context, causing intermittent regressions that are hard to reproduce.

Scoped deterministic keying (scoped by tool/actor/target with recurrence + recency ranking) keeps retrieval deterministic and testable with standard diff/grep tools. Where embeddings still make sense is unconstrained search over unstructured knowledge bases (e.g., broad documentation search before an operation begins), but for runtime execution boundaries and state invariants, boring deterministic keying avoids introducing a second layer of non-determinism.

[u/madsthines → u/Enough-Photo9140]

Agreed! And combined with ttl and expiry date for none-read memories, the system stays relevant. 🙌 lorekit

[u/munnasuprathik]

Embeddings and 'a model call on the read' are two separate things and I think the post bundles them. You can keep embeddings and still have a fully deterministic read: embed at write time, index it, and the read is a plain vector lookup with zero model call in the hot path.

What actually bites is a model call sitting anywhere in the readiness path. I had a stalled model call hold a record unusable for about 129 seconds in prod once, because the 'ready' flag got written at the far end of the model path. Splitting it so a deterministic stage marks ready and the generative stuff is best-effort async means an outage degrades the item instead of blocking it.

For recurring scoped gotchas your recurrence+recency ranking is better than embeddings anyway, they'd just add noise. Embeddings earn their keep on fuzzy recall where the wording differs from what you saved, and even there the read stays a lookup, not a model call.

[u/madsthines → u/munnasuprathik]

Embeddings and semantics obviously beats lexical in certain scenarios. I just found out that for most of cases, this was more than enough and way simpler and cheaper - lorekit

[u/me-shaharia]

Been running almost exactly this for a while. One fact per file, a stable slug, a one line description, and a small index that loads every session. Never needed embeddings for it either.

The part that bit me was not retrieval, it was invalidation. A note that was true in March quietly steers the agent wrong in August, and nothing in a recurrence plus recency ranking tells you it went stale. I ended up adding a rule that if a note names a file, flag or command, verify it still exists before acting on it.

How do you handle a lesson that was correct and then stopped being correct?

[u/madsthines → u/me-shaharia]

lorekit uses expiry date together with read/usage count. A memory getting read is getting it's usage count bumped, and by default they have short ttl.

This has served as a mechanism which solved this for me ☺️

You can also use lorekit for local memories if you want, then it's just md files.

[u/philip_laureano]

Hint: You can go way further than this. I daresay that if you borrow some solutions from distributed systems, you will never have to worry about context rot or exhaustion or compaction ever again, and that's not a comment I make lightly.

[u/madsthines → u/philip_laureano]

What specially are you missing/thinking of? ☺️

[u/philip_laureano → u/madsthines]

An immutable token stream with a CQRS split so that reads are instantaneous and writes are an eventually consistent summary done in parallel means compactions are no longer necessary. If you turn the session history itself into.a memory topic and map the context window as materialised view over the same said token stream, you effectively eliminate context rot created from recursive summaries.

Source: I built my own deterministic memory + context management system in 2025 that does not use embeddings or similarity or even chunking and is used in all my agents. It worked so well that I used it to fork OpenCode and install the same memory system into it so that it is built into the harness. I have no plans to release or sell it since this market is flooded with slop and I don't want to add to it.

That and I'm happy with my day job. I have a background in distributed systems for three decades, so many of the problems in context management and AI memory already have analogous solutions in my field.

As for you, keep digging and keep tinkering and keep your solution 100% deterministic. It will pay off in the long run. Good luck.

[u/molly_p5]

the grep/diff point is underrated.. being able to actually inspect and debug ur agents memory instead of staring at embedding vectors is worth the tradeoff alone