A handful of things happened in semantic tech this week, and at first they look like they have nothing to do with each other. A cloud vendor shipped a search API. A model company open sourced an embedding model. Two more papers on agent memory showed up. Volcengine added a gateway to its open source context database for agents. Put them side by side and they’re all about the same thing: where an agent goes to find information.

The engagement numbers here are a public snapshot from 2026-10-10 and will change. Numbers from papers are the authors’ own experimental results, and vendor claims are reported the way the vendors put them.

This week’s thread: once an agent has a piece of information, it has to answer three questions: where it came from, whether it’s still valid, and who said it could be used this way. The public web, local data and agent memory each had news this week

Figure 1 | This week’s thread: there are more ways in now. What’s in short supply is what happens after the agent finds something.

Three entry points, and all three had news this week

The first entry point is the public web. On October 2, Cloudflare launched a beta of its Web Search API, which lets agents and apps search the internet through Cloudflare’s AI Gateway. The changelog says the point is to ground answers in live information instead of guessing URLs or leaning on what the model knew at its training cutoff. At launch you can pick from three search providers: Ceramic.ai, Exa and Linkup. Search requests show up in the gateway logs and are billed at each provider’s list price. The post got 593 points and 285 comments on Hacker News.

Screenshot of Cloudflare’s changelog: Web Search API runs through AI Gateway, so search requests appear in the gateway logs

Figure 2 | Cloudflare’s changelog, captured on 2026-10-10. The orange underline is mine. See reference [1].

My take: Which search providers it plugged in doesn’t matter much. The thing to watch is where search lives now. Web search used to be one more tool inside an agent framework. Now it sits in the gateway, on the same path as model calls and in the same log. That means there’s a clear record of which search results an answer used. After an agent answers, you can trace each conclusion back to a specific search and a specific result.

The second entry point is local data. On October 6, Google released EmbeddingGemma 2, a multimodal embedding model that can run on your own device. According to Google, it maps text, code, images, video and audio into one vector space. It has 740 million parameters, and if all you need is text you can run just the part that handles text, which is 270 million. It’s open source under Apache 2.0. Output vectors can be truncated from 768 dimensions to 512, 256 or 128, and Google says that can cut local vector storage by up to 6x. It’s at 435 points on HN.

Screenshot of Google’s blog: EmbeddingGemma 2 unifies code, images, video and audio in a shared embedding space

Figure 3 | Google’s blog post on EmbeddingGemma 2, captured on 2026-10-10. See reference [2].

My take: There’s one comment in that thread I really agree with. With an embedding model you end up computing thousands, maybe millions, of vectors and keeping them around for a long time, so a lot of people don’t want to tie that to a closed model they can only reach through an API. Once a vector is computed it’s part of your data, and switching models means computing all of it again. This is a storage problem, not just a model problem.

The third entry point is the agent’s own long term memory.

Volcengine’s open source OpenViking shipped v0.5.0 on October 9. It calls itself a context database for AI agents, and it manages memory, knowledge retrieval and skills in one place. This release adds a Gateway in beta. It’s a separate process that sits between the model client and the model provider. The client just points its base URL at the gateway and it gets OpenViking’s memory, with no plugin to install and no code to change. According to the release notes, each new user message kicks off a retrieval first, and the relevant memories get appended to the message.

Screenshot of the OpenViking v0.5.0 release notes: any model client that lets you change its base URL gets OpenViking memory through the gateway

Figure 4 | Release notes for Volcengine’s OpenViking v0.5.0, captured on 2026-10-10. See reference [3].

My take: Two details here are worth chewing on. One is permissions: by default, a new profile in the gateway only has the read tools turned on. The other is that Working Memory is now off by default. Hosts like Claude Code and Codex go back to managing their own session history and compaction, and OpenViking just handles archiving and pulling out long term memories. So it’s deliberately narrowing what it’s responsible for.

The same day, DeepSeek Harness put out an alpha release. One of the changes: global instructions can now be loaded from an AGENTS.md in a shared directory. That’s another kind of entry point. The rules an agent reads before it starts working are context too, and you have to keep track of where they come from.

Two papers on arXiv this week ask the same thing from different angles: can I still use this memory?

“Knowing the Store” asks how an agent can know, before it reads a memory, that the record shouldn’t be used anymore. Say a user cancels a plan, but the agent happens to read the older record from before the cancellation first. The authors only show the model a summary of the store, meaning how many records are in each lifecycle state and which attribute names exist, and then see whether the model can make the call. The result they report is interesting: when there are very few attribute names, none of the five language models consistently beat a lookup that just runs cosine similarity over the attribute names.

Screenshot of the arXiv abstract page: “Knowing the Store” asks what a memory store must expose for an agent to know, before retrieving anything, that a record should no longer be used

Figure 5 | The arXiv abstract page for “Knowing the Store”, captured on 2026-10-10. See reference [5].

“DyadMem” is a new benchmark. Its premise is that an agent needs to remember more than facts about the user. It also needs to remember how the two of them work together. The authors report that when the model is handed the gold memories directly, question answering stays strong. When the model has to go through the whole process of capture, update and recall on its own, performance drops sharply.

Screenshot of the arXiv abstract page: “DyadMem” reports that Gold-Memory QA is consistently strong while Full-Pipeline QA drops sharply

Figure 6 | The arXiv abstract page for “DyadMem”, captured on 2026-10-10. See reference [6].

My take: These two papers are interesting to read together. One says you need to know whether a record is still usable before you read it. The other says having memory isn’t enough, because capture, update and recall each lose something along the way. Both point to the same thing: how good the memory is gets settled when it’s written and maintained, well before query time.

Cortrix is also putting its effort on the write side. On October 9 it published a post about running LLM inference at write time (the post calls it Write-Time LLM Inference). According to the post, when a document is written, an LLM adds context to each chunk, writes out the questions a user is likely to ask, and summarizes the whole document. At query time, each of those three becomes its own recall path, and this step doesn’t need another LLM call. The post also covers what kinds of content actually benefit from this, and how to check for yourself.

Screenshot of the Cortrix blog: Cortrix moves part of the work into ingestion and runs the LLM when a document is written

Figure 7 | The Cortrix blog post on LLM inference at write time, captured on 2026-10-10. See reference [7].

My take: This post and the two papers above are two halves of the same thing. The papers ask whether what got written down is still usable. Cortrix does a bit more work at write time. The post also spells out its own limits: this doesn’t help every corpus, and to know if it’s worth turning on you have to look at your own data and see what each recall path contributes.

Connecting the three

Three entry points, and they map to three sources of information: other people’s content on the public web, your own data on your own machine, and the memory the agent wrote down itself. All three are trying to work out what should actually happen after the agent finds something.

Cloudflare put search on a logged path, so you can trace what an answer was based on. OpenViking put memory behind a gateway too, and by default a new profile only has the read tools turned on. EmbeddingGemma 2 lets vectors stay local, and you can truncate them to fit your storage budget. The two papers say it directly: the weak spot in memory systems right now isn’t the Q&A at the end. It’s knowing what to write down, what to update, and what’s already expired.

My take: For agents finding information, the race is shifting from “how much did we recall” to “can we still use what we got, and where did it come from.” It’s a bit like the data lineage problem in data systems. Whether a record has a state, whether it has a source, whether it can be marked as expired, all of that is decided at write time, and no amount of cleverness at query time gets it back. I’ve been working on semantic storage for a while now, and this keeps hitting home.

Two counterpoints you can’t skip

On October 5, the Wikimedia Foundation published the results of an investigation. It confirmed activity on Wikimedia platforms from agents it believes came out of OpenAI’s environment: edits to its wikis, failed attempts to exploit a public notes tool, and a lot of traffic. The Foundation says it found no evidence that its systems or data were compromised, and that nearly all of those edits happened in sandbox areas and didn’t show up on pages regular readers see. It’s worried about how much work it takes to investigate and attribute this, and about whether this kind of activity becomes normal. This one is at 306 points on HN.

Screenshot of the Wikimedia Foundation’s post: the unauthorized bot activities included edits to its wikis

Figure 8 | The Wikimedia Foundation’s post on its investigation, captured on 2026-10-10. See reference [8].

My take: To me this is the flip side of everything above. Agents keep getting better at finding information on the public web, and the maintainers on the other end don’t know who’s showing up or whose permission they have. Cloudflare’s changelog makes a point of mentioning that all three search providers have committed to its verified bot crawling standards. I guess that counts as a response of sorts.

The other pushback comes from the HN comments on the Cloudflare post. The top objection is: why not just use those search providers directly, and does Cloudflare really need to be in the middle of everything? Others point out that the three providers promise zero data retention, but whether the gateway itself keeps anything hasn’t been spelled out yet. Pulling search into a logged path buys you traceability, but it also adds a middleman you have to trust. Whether that’s a good trade, time will tell.

This week’s verdict

Bottom line: Entry points keep multiplying, and connecting to them keeps getting easier. That puts more weight on the data foundation behind an agent, which has to answer three questions: where the data came from, whether it is still valid, and who allowed it to be used this way.

A question for readers

How many ways does your agent have to find information right now? If something it found has gone stale or been retracted, which layer is supposed to tell the agent: the search provider, the vector store, the memory system, or the agent’s own code?

References