This week in semantic tech, one idea kept coming up: instead of digging through raw material every time a question comes in, prepare it ahead of time and compile it into data an agent can use right away.

Each vendor came at it a little differently. Anthropic published a long post that takes Claude’s memory apart: what to remember, how to fix a wrong memory, and whether turning notes into a wiki actually helps. Google lets its Knowledge Catalog mine Jira and Confluence for context on its own, and data stewards can review and approve the proposed updates, with versioning and rollback. RAGFlow 1.0 is out, and the team calls what it does “knowledge compilation”: every fact it compiles carries a quote from the original. Zep compiles runs that worked into SKILL.md files, and every step says which run it came from. PowerContext shipped v1.5.0, where artifacts carry their lineage and a receipt shows which memories went into a given answer. Two papers poured some cold water on all this: memory gets delivered, but agents mostly don’t use it, and on fact-recall tasks, memory compressed into summaries helps less than the original.

So knowledge compilation can’t avoid three questions: what to compile, whether it’s still right afterward, and whether it was actually used.

The numbers here are public information as read on 2026-11-07 and may change. Numbers from papers and vendors are the publishers’ own claims, reported here the way the sources put them.

This week’s thread: raw material (session records, documents, tickets, run logs) goes through a compile step into wikis, evidence chains, context sets and Skills, then reaches the agent at use time. The core box holds three questions: what to compile, whether it’s still right afterward, whether it was used. Below, where each of this week’s six stories lands

Figure 1 | This week’s thread: compile knowledge ahead of time.

Memory architecture: Anthropic breaks down Claude’s memory

On November 6, Anthropic published a research post, “The components of agent memory,” sharing what it has learned building memory for Claude. A few of the experiments are interesting:

  • What to remember: Claude played Pokémon, one run each for Sonnet 3.7 and Fable 5, and the team compared the memory folders at around step 10,000. Sonnet 3.7 wrote down everything, with a separate file for each battle and each item: 413 files across 225 folders, and it earned one badge. Fable 5 wrote nine files plus a single global.md, and earned four badges. Anything visible on screen every turn, like money or position, doesn’t need to be remembered. What’s worth writing down is strategy the model worked out itself, and rules it has verified.

  • How to teach it: just tell the model what memory is for, and don’t dictate how to use it. That worked better. When the team imposed a hard rule of “record only failures,” Opus 5 and Opus 4.7 lost much of the boost they got from memory.

  • What if a memory is wrong: Claude wrote down the wrong side of the map for the PokéCenter, and fell back onto the same route three times. In an offline “dreaming” pass, Claude checked the note against the session transcript, the wrong entry was fixed, and Claude walked into the cave and on to the next city.

  • Turning memory into a wiki: on about 350,000 internal files, roughly 420M tokens of company documents, the team scaled “dreaming” from 2 sessions to 128. The score on 25 questions, answered from the wiki alone, went from 13% to 48% of graded criteria. With the wiki and search together, it went from 54% to 61% (search alone: 53%), and each question used about 20,000 fewer tokens. Not every case worked: on one task the wiki grew larger than the raw files, which means it abstracted nothing.

  • Keep the layer that loads automatically small: Claude Code’s auto memory loads only the first 200 lines or 25 KB of MEMORY.md, and uses it as an index. Everything else gets looked up when needed.

Screenshot of Anthropic’s research post: the passage comparing the Pokémon memory folders, where Sonnet 3.7 wrote 413 memory files across 225 folders and earned one badge, while Fable 5 wrote nine files in two folders

Figure 2 | Anthropic’s research post “The components of agent memory,” captured on 2026-11-07. The orange underline was added for this article. See reference [1].

My take: The number that jumps out is the file counts: 413 to 9. The classic storage mistake is “just save it, we’ll sort it out later,” and this post shows with an experiment that remembering more isn’t remembering better. You also pay to dig through your own old notes. (In the post, Sonnet 3.7 spent 17 steps creating and deleting files and didn’t move once in the game.) I like another detail too: the fix came from checking the note against the original. The contract experiment says the same thing. Several agents wrote summaries into one shared table, and only 41 of 57 contract terms survived. When they switched to one page per contract, with terms copied word for word, all 57 made it. From a semantic storage point of view, this is exactly the job: the distilled layers can stack up as high as you like, but every layer has to lead back to the original, or you can’t check anything when it goes wrong.

Enterprise context: Google lets agents fill in context, and data stewards can approve or roll it back

On November 5, Google Cloud announced a batch of updates to its Agentic Data Cloud. The part that matters here is Knowledge Catalog, which Google calls its “universal context engine”:

  • Self-learning enrichment (preview): it keeps mining Google Workspace, GitHub, Jira, Confluence and SharePoint for documents and tickets, fills context gaps based on the questions people actually ask, and packages the result into reusable context sets in Open Knowledge Format (OKF).

  • A new studio experience (preview): data stewards can review, audit and approve the proposed enrichment updates, with full versioning and rollback.

  • Business definitions aren’t left to the model: trusted semantic models from BigQuery, Looker (LookML), Databricks, Snowflake, dbt and SAP are now generally available. When an agent calculates net revenue or customer churn, it uses the same governed formulas the business teams use. In Google’s words: “critical business definitions cannot be left to an LLM’s guesswork” (LLM is large language model).

  • Google also says that in its internal benchmarks, Knowledge Catalog made agents nearly 4x more accurate, cut latency by up to 33% and used up to 75% fewer tokens. No test conditions were given.

Screenshot of the Google Cloud blog post: the passage about reviewing, auditing and approving proposed enrichment updates with full versioning and rollback

Figure 3 | Google Cloud’s blog post on the Agentic Data Cloud, captured on 2026-11-07. See reference [2].

My take: “Nearly 4x” is the eye-catching number, but with no conditions given, I’m treating it as a reference point only. What I care about more is the division of labor. Machines compile the stuff scattered across Jira and Confluence, humans can approve it, and if an approval was wrong, you can roll back. That’s an old rule from data warehouses: the data owner sets the definition, and not every SQL query someone runs counts as authoritative. From a semantic storage point of view, compiled context needs versions and an approval status too. Changing it should go through the same process as changing a table schema, and it shouldn’t change just because a model said so.

Retrieval: RAGFlow 1.0 ships, with knowledge compiled ahead of time

On November 6, InfiniFlow released RAGFlow 1.0.0, which the team says is ready for production after three release candidates. 1.0 is a complete rewrite in Go, and it includes a decision model that judges whether the evidence is enough. A day earlier, the team’s blog published a 35-minute post, “Context as Infrastructure,” on the thinking behind it, and moved RAGFlow’s positioning from an “end-to-end retrieval-augmented generation (RAG) engine” to an Agent Native Database:

  • Knowledge compilation: move the understanding from query time to indexing time, so the agent doesn’t start from zero on every question. What gets compiled includes tree navigation, entity relation graphs, timelines, wikis and ontology templates. The one that matters most is the atomic proposition: a one-sentence fact paired with a quote from the source, and the quote has to be a contiguous piece of the original text.

  • A lesson learned the hard way: just organizing documents into a tree didn’t help the agent much, and it kept relying on search and grep. What helped was the evidence chain hanging off the leaf nodes.

  • How much it saves, according to the team: when compiled evidence hits, a single question can save over 90% of tokens, and when it misses, the loss is only about 2%. On the multi-hop FRAMES benchmark, it saves 30% to 40% on average. Extracting evidence chains doesn’t need a big model; a small one is enough.

  • Evidence that’s not enough gets dropped as a whole block, not stuffed into the context. Every artifact records which document and which passage it came from, and when a document is deleted, its contributions are removed precisely. When an answer is wrong, you can tell “didn’t find it” from “found it but didn’t use it.”

Screenshot of the RAGFlow blog post: the passage saying that when compilation artifacts hit, a single question can save over 90% of tokens, and when they miss, the loss is only about 2%

Figure 4 | RAGFlow’s blog post “Context as Infrastructure,” captured on 2026-11-07. See reference [3].

My take: The 90% token saving gets the attention, but the line that’s easy to skip is “the quote has to be a contiguous piece of the original.” Compilation tends to drift as it goes, and if a summary gains or loses a single word, an agent may still trust it. RAGFlow makes every proposition match the source word for word, and if it doesn’t match, it doesn’t count. That lines up with the conclusion of Anthropic’s contract experiment. I also like that it admits a plain directory tree doesn’t work, which is rare among all the projects saying “we have tree navigation too.” From a semantic storage point of view, compiled output is basically a materialized view: fast to query, but you need to know which rows it was computed from, and it has to refresh when the source data changes.

Skills: Zep compiles runs that worked into SKILL.md, and the agent’s word isn’t enough

On November 5, Zep launched Agent Skills. Founder Daniel Chalef wrote the announcement, and an arXiv preprint came with it:

  • It compiles an agent’s run records into versioned SKILL.md files. Similar tasks are grouped together automatically, and later runs keep refining the Skill.

  • It only accepts runs whose success was confirmed from outside: a tool or an eval has to say so, and the agent saying it succeeded doesn’t count. Before a Skill is admitted, code checks that every claim cites an event from the runs, and instructions that came from tool output are rejected.

  • Every change is an immutable version you can compare and restore. If a source run is deleted, every Skill that cites it is deleted too. Verified uses raise a Skill’s rank, and verified failures lower it.

  • Zep’s own test: Skills compiled from Opus 5.5’s run records, handed to DeepSeek V4.1 Flash, passed 58.3% of tasks on EnterpriseOps-Gym. That’s 10 points above the baseline without Skills, and ahead of Opus 5.5 at maximum effort. On τ³-bench banking, tokens per passed episode dropped by up to 45%. Zep also says that today it only learns from successful runs, and on tasks the model is already good at, the gain is small.

Screenshot of the Zep blog post: the passage saying Skills learn only from outcomes confirmed by a tool or an evaluation, and every step cites the run it came from

Figure 5 | Zep’s announcement of Agent Skills, captured on 2026-11-07. See reference [4].

My take: “The agent saying it succeeded doesn’t count” is getting a manual thumbs-up from me! When you let an agent summarize its own experience, the worst case is that it records one lucky run as a rule (survivorship bias). Another detail has a real database flavor: delete the source run, and the Skills that cite it go with it. That’s a foreign key with ON DELETE CASCADE, isn’t it? For semantic storage, a compiled artifact and its source need a real reference between them, so that when the source is gone, the artifact knows it has to be invalidated.

Memory platforms: PowerContext v1.5.0 can say which memories it used

On November 3, PowerContext released v1.5.0 under the slogan “Not only memory, but a full story.” These are the parts tied to this week’s thread:

  • Artifact plugins: you can define your own artifact types, like incident reports or ticket summaries, with versioned schemas and exact source lineage, searchable by text or by vector. If a plugin is removed, artifacts it already generated stay readable.

  • Context receipts: when preparing context, you can ask for a receipt (include_receipt) that shows which version of which memory was selected, which kind of retrieval ran, and what got left out. The receipt contains no query or evidence text.

  • Saving tokens: repeated evidence can use a shared JSON encoding that restores exactly, and it’s used only when it restores word for word and is actually smaller. It’s off by default. Prepared context can be reused, but permissions and evidence are checked again every time, so if a memory is forgotten or a permission is revoked, the reuse stops.

Screenshot of the PowerContext v1.5.0 release notes: the Artifact plugin entry with versioned schemas and exact source lineage

Figure 6 | The PowerContext v1.5.0 release notes, captured on 2026-11-07. See reference [5].

My take: The context receipt is a genuinely practical feature. Before, when an agent got something wrong, you could only guess: was it not found, found but never handed to the agent, or handed over and ignored? With a receipt, you can at least settle the first two. The token saving part is restrained, too: the encoding only turns on when it restores word for word, and it’s off by default. The release notes include a line I’ll quote: “exact restoration alone does not establish equivalent model understanding or lower total task cost.” That’s a refreshingly candid caveat. For semantic storage, an artifact has to remember where it came from, and every use has to leave a record, so that when something goes wrong you can trace it back.

Papers: memory was delivered, and the agent mostly didn’t use it

Two papers this week ask the same question: did the memory actually get used?

  • “Delivered, Not Used” ran 8,000 episodes on SWE-bench Verified and compared three memory systems. The authors say that by resolve rate, having memory or not differed by less than 0.4 percentage points. Following each memory delivery down to what happened next, they found that most delivered entries were irrelevant, most relevant entries went unused, and in two of the systems most deliveries restated content the agent could still see.

  • “What Is This Memory Useful For?” doesn’t give each memory one fixed importance score. It looks at whether a memory helps a specific task. The authors say that on factual recall tasks, memories compressed into summaries or structured records helped less than the original, even at the same total context. On software engineering and scientific coding tasks, even the original memories showed no measurable effect.

Screenshot of the arXiv abstract page for “Delivered, Not Used”: the sentence saying most delivered entries were irrelevant, most relevant entries went unused

Figure 7 | The arXiv abstract page for “Delivered, Not Used,” captured on 2026-11-07. See reference [6].

My take: The first paper really stings. Look only at resolve rate and a memory system seems like decoration. Break it down, and the problem is that most of what gets delivered is off target. That’s the same idea as RAGFlow telling “didn’t find it” from “found it but didn’t use it”: evals have to see the delivery layer, because scores alone will fool you. The second paper reminds us that compression has a cost. A summary saves tokens, but it may drop the exact sentence that held the answer. I’ll say it again: accurate information matters more than the few tokens you save. So in semantic storage, the original text can’t go. Compiled output is a shortcut for the agent, and it can’t replace the original.

Other semantic tech news from around the world

  • On November 3, Snowflake previewed Business Ontology (public preview coming soon): every business term has an owner, a scope and an approval status. When a definition inferred by AI conflicts with an approved one, agents use the approved one. In its words, “accountable owners decide what becomes official.” [7]
  • On November 5, MongoDB open sourced its memory integration for the Vercel AI SDK (software development kit), generally available under Apache 2.0. It has five kinds of memory: episodic memory expires after a year of inactivity by default, and scratchpad memory after an hour. It also gives a fair warning: by default the model decides when to save, and it can occasionally skip a turn, so for production it recommends saving every turn from application code. The day before, MongoDB released a memory integration for Google ADK (Agent Development Kit). [8]
  • On November 4, Redis added MemoryETL (extract, transform, load) to Iris: it builds memories from documents and knowledge bases, organizes them in hierarchies, traces each memory to its source, and can forget personally identifiable information. [9]
  • On November 3, Hindsight (from Vectorize) released three small models. One of them, a decision model with 0.8B parameters, handles the small judgments in the memory flow, like whether an item is new or whether the evidence is enough. By its own evaluation, on some configurations it cuts cost by 2.5x. [10]
  • On November 2, LangChain founder Harrison Chase went through the new problems in context engineering, and said the hardest part of memory is “figuring out what to remember.” On October 28, LangChain also used its own OpenWiki as a memory layer and reports about 5x the accuracy of grep alone on questions that span sources. Adding an evidence graph, with edges like supersedes and amends to record which document replaces which, gave a further 27% over the wiki alone. [11]
  • A Microsoft Foundry blog post on October 26 split memory into four capabilities: Remember, Retrieve, Revalidate and Forget, and quoted the company’s own guidance: “memory is useful context, not automatic authority.” A second post on October 29 covered how to put governance around memory. [12]
  • On November 2, Qdrant explained the performance of 1.20: two new vector datatypes, turbo8 and turbo16, which take a quarter and a half of the storage of float32. In Qdrant’s own tests (the latency chart uses three 1536-dimension datasets), latency stayed within 10% of float32, and the float32 originals are no longer kept. [13]

My read on this week

My overall take: Lately everyone has noticed that digging through raw material for every question is slow and expensive, so they’ve started compiling ahead of time: wikis, evidence chains, context sets, Skills. But the lessons from this week’s vendors are fairly consistent. Remembering accurately beats remembering a lot. What’s compiled has to trace back to the original, and someone has to run an eval to confirm it. And after it’s written, you need to check whether it was used. So what Semantic Storage has to manage goes beyond just storing things: for every compiled layer, where it came from, who approved it, when it needs a refresh, and what it was used for this time. That’s what lets knowledge compilation actually work.

A question for readers

How much of your agent’s memory has never been used? If you deleted all of it, would the answers get worse, or better? Let me know in the comments.

References