AI agents need shared memory. They may also need a way to forget

What changed

Two developments published on October 6 approach AI memory from different directions. Siena announced a $17 million Series A led by York IE, with participation from Joyance Ventures and existing investors Aglaé Ventures and Sierra Ventures. Siena says the funding will help it build an “Agent of Record” platform in which customer-facing agents, internal agents and brand staff can share and add to a common understanding of customers. That is a vision for memory across a business, not merely an assistant recalling an earlier chat.

On the same date, Jan-Peter Franke published a paper proposing “agent-controlled forgetting” for tool-using agents. The proposed agent can replace selected tool results in its active context with short notes while preserving the originals in a recoverable archive. Rather than asking how to share more information, the paper asks how much information an agent needs in front of it at any given moment.

These are not interchangeable developments. One is a company’s funding announcement and product direction; the other is exploratory research. Read together, though, they expose a useful tension. A good memory system needs information to survive beyond an individual interaction. A good working context cannot necessarily carry every detail of that information all the time.

Shared context is a promise, not proof of recall

Siena describes its planned platform as a way for agents and staff to build on a shared understanding of a customer. Its announcement connects the Series A to that “Agent of Record” direction. The important word is shared: if several agents encounter the same person, the design aims to give them continuity rather than make each interaction start from scratch.

That could be useful. A person contacting a business should not have to reconstruct the same issue for every handoff. But “shared understanding” also raises a harder question than simple storage: which parts of a customer’s history should shape the next response? A past support problem might be essential to resolving a current one. An outdated inference might be distracting. Treating both as equally authoritative would be a poor form of memory.

The distinction between an announced direction and a shipped capability matters here. Siena’s post says what it intends to build; it does not establish that every described capability was generally available when the announcement appeared. Funding can support development, but it is not a test of whether a system retrieves the right customer detail, corrects a mistaken one or handles a handoff well. Those are the questions by which the promise should eventually be judged.

It is also worth separating continuity from unlimited recall. A shared record could help an agent find relevant context without placing a customer’s entire history into every exchange. That is a design possibility, not a claim about how Siena’s system works. The point is that having a record and deciding what to use from it are different jobs.

Forgetting may mean moving information, not destroying it

Franke’s paper concentrates on that second job within an agent’s working context. Under the proposed approach, selected tool results are replaced by short notes in the active context, while the original results remain recoverable from an archive. In plain English, an agent could put a bulky result away, keep a reminder of what it contained and retrieve the original if the task demands it.

That is not forgetting in the everyday sense of losing something forever. It is closer to clearing a desk while keeping the documents in a file. The distinction matters because an agent that permanently discards a result may later be unable to check a detail. An agent that keeps everything immediately visible may spend its limited working space on material that no longer helps. Recoverability offers a possible middle path, provided the reminder is good enough to point back to the right source.

In an exploratory debugging-and-follow-up case, the paper reports 50% fewer cumulative input tokens and substantially lower estimated API costs. That is an interesting result, but it should not be read as a general saving available to every agent. The paper also documents cases where savings did not occur or quality was weaker. The evidence supports a narrower conclusion: selective removal can help in some workflows, while the trade-offs still need testing.

Cost is only one reason to care about the distinction between stored and active information. If a short note leaves out the one detail needed for a later decision, the system must recognize when to reopen the original. If it does not, a tidy context could produce a less reliable answer. Conversely, keeping a recoverable original makes it possible, at least in principle, to check a compressed account rather than trust the compression blindly. The research proposal makes that choice explicit; it does not settle how consistently an agent will make it well.

What the two developments mean together

A shared customer record and a recoverable archive serve different purposes. The first is about continuity across people and agents. The second is about deciding what occupies an agent’s immediate attention. An effective system might need both kinds of discipline: a dependable place for relevant history, and a way to avoid treating every stored detail as equally relevant now.

The unanswered questions are practical. When should an agent bring an old detail into a new exchange? How should it distinguish a customer-provided fact from an agent’s earlier interpretation? If a compact note proves misleading, can the agent find and check the original? And when a person corrects the record, will the next agent encounter the correction rather than the old mistake? Neither an investment announcement nor an exploratory case study answers all of those questions.

For readers evaluating memory claims, the useful test is therefore more specific than “Does it remember?” Ask what is retained, what is merely summarized, who or what can retrieve the original, and how the system decides that a detail matters. Also ask what evidence supports any promised benefit: a proposed architecture, a limited experiment and a broadly available product are different things.

This week’s developments show why AI memory should not be measured by how much an agent can keep. Siena’s announcement makes the case for continuity across a customer relationship. Franke’s paper explores a reversible way to reduce what an agent carries in its active context. The strongest version of either idea would make information available when it is useful—and leave room to question it when it is not.