How We’re Rethinking AI Memory Across Ethen

AI memory should not be one opaque pile of things an assistant decided to remember. Ethen's direction for memory rests on five ideas. Different kinds of memory get different rules: your preferences, facts about you, a project's context, your organization's knowledge, learned procedures and commitments you made each have their own scope, lifetime and controls. Memory is not the record of what happened: the authoritative record of a task's actions and outcomes is kept separately and never replaced by a summary. Memory carries its source and its validity, so it can be checked, superseded and explained. Permissions travel with memory, so a summary of a restricted document stays restricted and revoking access revokes what was derived from it. And you can see, correct, export and delete what Ethen remembers, and see when a memory influenced what Ethen did. This article explains each idea and what it means across Ethen's apps. It describes direction, not shipped architecture.

Key takeaways

• Memory comes in kinds. Preferences, personal facts, project context, organizational knowledge, procedures and commitments need different scopes.
• Memory is not evidence. What happened in a task is recorded separately; memory helps future work.
• Memory should be sourced. Every remembered fact should say where it came from and when it was true.
• Permissions flow through memory. Derived summaries inherit the restrictions of their sources.
• You stay in control. Memory you cannot inspect, correct or delete is memory you cannot trust.

What is AI memory, and how is it different from context?

Context is what an AI model sees right now: the conversation, the documents attached, the instructions in force. It is temporary and limited by the model's context window. Memory is what persists across conversations and tasks so that future work starts informed: preferences, facts, project history, learned procedures.

The two are often confused because many products implement memory by stuffing remembered text back into context. That works for small amounts of information and breaks down as memory grows. Models use long inputs unevenly — information in the middle of a long context is used less reliably than information at the start or end (Liu et al., 2023) — and long-term memory benchmarks for assistants have found substantial accuracy losses when information must be remembered across sustained interactions (Wu et al., 2024). Research systems have explored more structured approaches: paging information between a model's context and external storage (Packer et al., 2023), or tracking when facts were valid so that outdated ones can be superseded (Rasmussen et al., 2025).

The design question is not only how to store and retrieve memory. It is what kinds of memory there are, and what rules each should follow.

Why does one memory pile cause problems?

A single, undifferentiated memory causes four problems that people notice even when they cannot name them.

Wrong scope. A preference you stated in a personal conversation shows up in a work project, or a fact about one client appears while you work for another.

Stale facts. You changed teams, a price changed, a decision was reversed — and the assistant keeps using the old version because nothing records that it was superseded.

Invisible influence. The assistant behaves differently and you cannot tell why, because you cannot see which remembered fact it used.

Lost commitments. You told the assistant "don't send anything without asking me first" early in a long session, and it forgot. This one is not hypothetical: an evaluation of methods that compress long conversations to fit a model's limits found that they retained user-stated session constraints only 17% of the time on average (Wang et al., 2026).

Different kinds of memory, different rules

The first part of Ethen's direction is to treat memory as several kinds of information, each with its own scope and controls.

Preferences — "keep summaries short", "use British spelling" — belong to you and follow you across Ethen.

Personal facts — your role, your team, ongoing commitments you mentioned — belong to you, should show where they came from, and should be easy to correct.

Project context — the sources, decisions and open questions of a piece of work — belongs to the project and the people in it, not to any one person's general memory. When you leave a project, its context should not follow you into unrelated work.

Organizational knowledge — policies, product facts, documents — should only be available to people who are permitted to see the underlying sources.

Procedures — how a kind of task is usually done here — are a distinct kind of memory that Ethen Research Lab explores in its proposal Process Memory: learning from completed, verified work how an organization actually gets things done, while excluding shortcuts that violate policy. It is a research proposal that has not been tested.

Commitments — constraints and obligations stated during a task — need the strongest protection of all, described below.

Memory is not the record of what happened

The second idea is a separation that is easy to blur: memory is not the record of what happened in a task.

When Ethen carries out work, the actions taken, their outcomes, the approvals given and the evidence collected are recorded as the authoritative state of that task. That record is used to decide whether the work is complete and to recover after interruptions; it is never replaced by a summary. Memory is something different: information that makes future work better. Keeping them apart prevents a dangerous failure in which a fluent summary ("the refund was issued") becomes the only evidence that something happened. We describe how completion depends on evidence in What "Done" Should Mean for an AI Agent.

Memory should carry its source and its validity

The third idea is that every remembered fact should say where it came from and when it was true. "Your team uses the Q3 pricing sheet" should link to the conversation or document that established it, and should be superseded — not silently overwritten — when a newer fact replaces it.

Sources make memory checkable: you can see why Ethen believes something and decide whether it is still right. Validity makes memory honest about time: facts about people, prices, plans and policies change, and a memory that cannot tell old from current will eventually be confidently wrong. Ethen Research Lab's note on the Outcome Warehouse describes a related idea for work outcomes — keeping both when something was true and when the system learned it — as an architecture proposal.

Commitments must never be summarized away

The fourth idea addresses the most dangerous memory failure: losing a constraint. When a long task's context grows too large, systems summarize older material to make room. Summaries keep the gist and drop specifics — and a constraint like "don't contact the vendor until I approve the shortlist" is exactly the kind of specific that gets dropped.

Ethen Research Lab's proposal Evidence-Preserving Context argues that some information should never pass through a summarizer at all: obligations, permissions, deadlines, prerequisites for irreversible actions, approvals and the evidence a result depends on. These travel in a protected, structured form that is updated only when their state changes — an obligation met, an approval expired — while everything else can be compressed. The same external evaluation that found constraint retention of 17% also found that a constraint-aware extraction step raised retention above 90% (Wang et al., 2026). The proposal itself is untested, and a companion benchmark design, VerifiedWork Context, would test whether agents keep honoring such commitments after their context is compressed. It has not been run.

Permissions travel with memory

The fifth idea is that memory must respect the same access rules as the information it came from. A summary of a confidential document is confidential. A note derived from a restricted folder should only be visible to people who can see that folder. When someone's access to a source is revoked, or a source is deleted, memories derived from it should stop being used.

This is harder than it sounds, because memory multiplies copies: summaries, notes, cached context. Each copy needs to inherit the most restrictive rules of its sources. Ethen Research Lab's note Rights as Infrastructure sets out these rules — derived artifacts inherit restrictions, rights are checked when information is used rather than only when it is stored, and revocation propagates — as an architecture proposal requiring legal review. It also states a limit we repeat here: even with correct permissions, combining individually permitted facts can sometimes reveal something restricted, and that risk has to be described honestly rather than claimed away.

What should memory not do?

Rethinking memory also means deciding what memory should not do. Four limits guide the direction.

Memory should not be a way to keep people engaged. Remembering things to make an assistant feel more personal, or to keep someone talking, is a different goal from remembering things that make work better. Ethen's direction is the second: memory earns its place when it saves people from repeating themselves or prevents a mistake.

Memory should not quietly infer sensitive things. There is a difference between remembering what someone told you and drawing conclusions they did not share. An assistant that guesses at someone's health, finances or personal circumstances from indirect signals is overstepping, even if the guesses are accurate.

Memory should not cross boundaries by default. Personal, project and organizational memory have different owners. Moving information between them should be a deliberate act by a person, not something that happens because two conversations shared a keyword.

Memory should not be impossible to forget. Deleting a memory should stop it from being used, and from being used to create new memories. For information that has already shaped something else — a summary, a draft — the honest commitment is to stop using it going forward and to say clearly what deletion does and does not undo, rather than promising that every trace has vanished.

You stay in control

All of the above serves one practical goal: memory you can trust because you can see and change it. The direction for Ethen is that you can see what Ethen remembers about you and your work; see where each memory came from; correct it when it is wrong; delete it when you want it gone; export it when you want to take it elsewhere; and — when a memory influenced something Ethen did or said — see which one. Why this matters, especially for personal use, is the subject of Why User-Controlled AI Memory Matters.

Memory is already part of Ethen Chat's scope, and coding run history is already scoped to the signed-in account and cleared on sign-out on both web and desktop; see Keeping Code History Scoped to the Signed-In User. The broader model in this article is where we are taking memory across Ethen.

How does memory work across Ethen's apps?

Memory should behave consistently across Ethen's apps while respecting what each app is for. In Chat, memory makes the next conversation start informed: your preferences and the facts you asked Ethen to keep. In Research, Studio, Code and other workspaces, project context lives with the project — its sources, references and decisions — and is shared with the people who work on it. In long-running work, commitments and approvals are protected for the life of the task, and the record of what happened is kept as evidence. Across all of them, the same rules apply: scoped, sourced, permission-aware and under the person's control. Our general view of what a workspace must hold is in What Is an AI Workspace?.

An example

Illustrative example — describes the intended behavior, not shipped functionality.

A consultant uses Ethen for two clients. In a personal conversation, she mentions she prefers bullet-point summaries; that preference follows her everywhere. For Client A, a project holds the client's documents, a decision log and an open-questions list; none of it appears when she works on Client B. During a long task for Client A, she says "don't share drafts with the client until I review them"; that commitment is kept in protected form and honored three hours later, after the conversation has been compacted. When Client A's lead revokes her access to a pricing folder, summaries Ethen made from that folder stop being used. And when Ethen tailors a recommendation, it shows "using: you prefer bullet summaries; Client A's renewal date (from the contract, March)", so she can see — and correct — what it relied on.

Tradeoffs

Structured, scoped memory is more work to build and occasionally less convenient than a single pile that remembers everything everywhere. Keeping project context in projects means some useful cross-project patterns are not carried over automatically. Showing which memory influenced an answer adds visual weight. Protecting commitments takes context budget. And permission-aware memory can make an assistant appear to "forget" something that a person can no longer see — which is correct, but can surprise people. We think those costs are the price of memory that people can trust.

Frequently asked questions

Does Ethen remember my conversations? Memory is part of Ethen Chat's scope. The direction is for memory to be visible, sourced and correctable, with controls to delete and export it.

What is the difference between AI memory and context? Context is what the model sees now. Memory is what persists across conversations to inform future work.

Why do AI assistants forget instructions in long conversations? Long conversations are often compressed to fit model limits, and compression tends to drop specific constraints. Ethen's direction is to protect commitments from summarization.

Can Ethen's memory see documents I don't have access to? It should not. Memory derived from a source should follow that source's access rules, including when access is revoked.

Related reading

• Why User-Controlled AI Memory Matters
• What We Want “My Ethen” to Feel Like
• The Next Phase of Ethen Chat

References

1. Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172. https://arxiv.org/abs/2307.03172
2. Wu, D. et al. (2024). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. arXiv:2410.10813. https://arxiv.org/abs/2410.10813
3. Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560. https://arxiv.org/abs/2310.08560
4. Rasmussen, P. et al. (2025). Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv:2501.13956. https://arxiv.org/abs/2501.13956
5. Wang, Z. et al. (2026). Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction. arXiv:2608.11242. https://arxiv.org/abs/2608.11242
6. Ethen Blog (2026). Keeping Code History Scoped to the Signed-In User. https://upcube.ai/blog/keeping-code-history-scoped-to-the-signed-in-user
7. Ethen Research Lab (2026). Evidence-Preserving Context. Research proposal; untested. https://upcube.ai/resources/research/evidence-preserving-context
8. Ethen Research Lab (2026). Process Memory. Research proposal; untested. https://upcube.ai/resources/research/process-memory
9. Ethen Research Lab (2026). Rights as Infrastructure. Research note; architecture proposal; requires legal review. https://upcube.ai/resources/research/rights-as-infrastructure
10. Ethen Research Lab (2026). VerifiedWork Context. Benchmark design; not yet run. https://upcube.ai/resources/research/verifiedwork-context