Weft Remembers What You Tell It To

Why Did I Make Weft?

If you want to send information to your agent in a new session, without a memory system, you have two choices:

• You can copy and paste a handoff each time you hit clear
• You try to save stuff to a handoff file and tell your agent to update and import it each run.

This works, until it doesn't.

Your memories are locked in that repo or platform, and if you switch to something else, that new agent might not be able to read them. Hunting for a specific memory? Your agent uses grep, and if it finds it, you'll end up loading a ton of context that you don't care about.

Every session starts from zero and you waste time trying to get the agent up to speed until the real work begins.

Weft helps fix that.

It's a private, local-first platform that treats your memories as a first-class data system.

When you end a session, Weft lets your agent hand off a summary of what they did and what comes next. In that new session your agent can prime itself with just the information it needs to get started.

Memories are stored in a database that allows for semantic search accessible by any agent connected to your Weft MCP.

Same agent, different agent, different machine — it doesn't matter.

Your memories belong to you, not your harness.

What's In A Weft Memory?

You have a breakthrough in how you work with your agent and say "Make this a rule: Whenever we push a PR, we don't consider it valid unless the GitHub CI checks all pass green."

Your agent sends the memory to Weft, with provenance about the conversation it came from. It looks like this:

content: "When pushing a PR to GitHub, do not tell the user the PR is valid unless all CI checks come back green"
type: "preference"
topic: ["pull-requests", "ci"]
confidence: 0.97
source: "conversation"

Then, the memory is persisted, converted to a semantic vector, and available for your agents. The next time it goes to push a PR, the instruction surfaces.

See how it works →

Weft Works In Ways That Are Hard To Benchmark

Weft doesn't benchmark well because it doesn't work the way most benchmarks test. Most "agent memory" benchmarks assume the system remembers everything and so they're designed to see how well a system can sift through hundreds of conversations to find the right answer. Weft intentionally doesn't do this.

Instead, it remembers the things you tell it to, and not a lot else. I want Weft to have an auto-memory function, but I don't want a gimmick. I want it to remember the stuff you'd tell it to remember without burying it with a ton of information you don't care about. Weft will never tell you how many times you told your system to "make no mistakes" — unless you tell it to.

For transparency, we ran it through LongMemEval-S (multi-session chat memory, ~40 sessions per question). We ran three checkpointed repetitions of the same full 500-question set using gpt-6-luna via the API, in "turn tier" mode — the version of Weft that aligns most closely with how LongMemEval works.

Judged accuracy averaged about 80.0% across the three runs, compared with a 67.5% historical baseline (+12.4 percentage points). The runs scored 395/495 (79.8%), 404/499 (81.0%), and 393/497 (79.1%); nine selected cases were not judged. These are repeated runs over the same questions, not independent samples. The largest gains were in knowledge update (+23.5 points) and multi-session recall (+18.7 points). Single-session preference averaged 55.6%, versus a 56.7% baseline, with run scores from 50% to 60% across the same 30 questions. Combined provider spend for the three runs was about $3.34. A preliminary case review suggests mixed causes for preference misses, but the causal split is unconfirmed.

LongMemEval measures a synthetic end-to-end agent workflow, not Weft retrieval alone or a personal-use success rate. Full results, limitations, and the reproduction harness are in the repository benchmark report: docs/benchmarks.md.