Remembering is not the same as knowing what should happen next.

That distinction is becoming more important as AI tools get better. A model that remembers your writing style, your company, your favorite stack, or the name of a project is easier to work with. It saves repetition. It makes the next answer feel less generic. It can reduce the cold-start tax that has made every new AI session feel like onboarding a temporary contractor.

But serious work does not only require recall.

Work has state. A decision can still be active. A blocker can be unresolved. A commitment can be overdue. A note can be useful but not actionable. A preference can guide future work without becoming a task. A fact can be true for one project and irrelevant or confidential in another. A memory system that stores all of those as flat text has preserved words, but it has not preserved the shape of the work.

That is why “AI memory” is useful, but incomplete.

Memory Is Getting Better

Native memory in AI products is improving quickly, and that is a good thing.

OpenAI describes ChatGPT memory as a combination of saved memories and reference chat history, with controls for viewing, deleting, and disabling what ChatGPT remembers (OpenAI Help Center). Anthropic describes Claude memory as chat and project summaries that help Claude build continuity across conversations, with separate project memory spaces and user controls (Claude Help Center).

These features are not trivial. They help each assistant become more personal and less repetitive. They are especially useful for durable preferences: “I prefer concise answers”, “our brand avoids hype”, “always quote prices in DKK”, “call this customer by their legal entity name”.

Eugene Yan makes a similar practical split in How to Work and Compound with AI: project facts and domain context belong in one bucket, while preferences, workflows, and personal taste belong in another. He also argues for periodically refactoring and pruning context as it grows. That is the right instinct. Memory is not just storage. It is upkeep.

I see this all the time on LinkedIn, Reddit, X. Someone fed up with Claude, ChatGPT, or whichever tool they’re using. It insists it’s Monday when it’s actually Friday. It forgets the file just uploaded. It repeats a corrected mistake two minutes later. Three small failures in one conversation, and that is with memory features turned on. Native memory is getting better at preference recall. It is still bad at being current.

The Work Moved Across Tools

The reason memory is not enough is that the work no longer happens in one place.

You might plan a launch in ChatGPT, draft the customer note in Claude, brief a designer in Figma, push the campaign brief into Notion, kick a comment thread back to a teammate, and make the final call after a meeting. The work feels like one stream. The tools see six separate sessions.

Platform memory starts inside a platform - and mostly stays there. ChatGPT memory helps ChatGPT. Claude memory helps Claude. What’s stored in a project helps that project. All valid and valuable boundaries, but they create their own pain. Who maintains the project data and context, and what if you have 10 projects? Are your projects shared with your colleagues, or are they private to you, so only you benefit from the curated memory?

If a decision was made in Claude and the work continues in ChatGPT a week later, the next agent should not need a human to re-explain it. If a blocker came up in a customer call and the next planning session happens somewhere else, the state should not be stranded in the meeting notes. If a meeting produced a commitment, the next AI assistant should know whether that commitment is still open, waiting, resolved, or overdue.

The durable object is not the chat. It is the work state.

Facts Are Not Commitments

The problem with the word “memory” is that it is intangible. A memory can be anything. For memory to be useful, it has to be both current and tied to the work in front of you.

You might remember the one sunny summer afternoon when your chocolate ice cream melted onto your new white shorts. Vivid. Permanent. But is that going to carry your work forward?

The same is true for AI. It might remember something you wrote in an old chat and treat it as fact, even when it has nothing to do with what you are working on right now.

That is why 3ngram distinguishes between facts, commitments, decisions, blockers, preferences, patterns, and notes - because each of these should behave differently in the tools you use.

“We close the books on the 5th of every month” is a fact. It can sit quietly until it becomes relevant. “Send Maya the revised onboarding plan once Legal signs off on the new MSA” is a commitment with a person, a condition, and a due date. “We decided not to add a second pricing tier until after the pilot” is a decision - the outcome matters, the rationale matters more. “Procurement is waiting on a signed DPA before we can roll out to the German team” is a blocker that stays visible until it clears. “Use direct language, avoid marketing adjectives” is a preference that shapes outputs without surfacing on a daily list.

The default experience today is the opposite. You open ChatGPT to draft a marketing brief and the first ten minutes are spent pasting context out of Jira, copying preferences out of Notion, and re-explaining what the brand sounds like. By the third reply the context window is bloated, the answers drift, and you start wanting to throw the laptop across the room.

It should not work like that. When you open ChatGPT, Claude, Codex, or whichever tool you are using, it should already know what you are working on - the patterns, the preferences, and the commitments around that work. Like a colleague on the project who already knows you are stuck on the brief because the graphics have not landed yet.

Knowing what kind of context you are dealing with is half the work. Knowing whether it is still current is the other half.

State Needs A Lifecycle

A commitment is not a static fact. It is open, then waiting on someone, then resolved, or it goes stale, becomes overdue, gets superseded by a later decision, or is deferred until next quarter. The same is true for blockers and decisions. They have a life.

An open commitment should appear in a briefing. A resolved one should stop nagging the user. A stale blocker should be checked against the source before it is carried into a new session. A superseded decision should keep its history without pretending to be current. A waiting item should know who or what it is waiting on.

That is the difference between memory and state. Memory remembers the words. State knows where the work is.

Akash Bajwa’s writeup on the future of software engineering with Anthropic captures the current gap well. In the roundtable he summarized, context management at scale was still unsolved, and participants agreed that human-authored context can help while stale or agent-generated context can actively hurt. That is exactly the risk. The wrong memory can be worse than no memory because it gives the model confidence in outdated state.

Useful context should be able to answer a few practical questions about itself:

  • Who or what supplied this?
  • When was it captured?
  • What source does it point back to?
  • Is it still current?
  • Is it private, team-visible, or safe to share with an external agent?
  • Has a human confirmed it?
  • What should happen because of it?

Without those answers, memory becomes a pile. Search can still help, but the user remains responsible for interpreting, filtering, and ferrying the result into the next tool.

There is a difference between an assistant that remembers you prefer concise emails and an agent that carries customer details, contract terms, internal decisions, support escalations, and hiring notes across tools. The second one needs governance, and it needs it from day one. Not as an enterprise add-on bolted on at the end, but as part of how the product behaves.

That cuts in three directions. The user needs to know where a piece of context came from, who can access it, which tools can receive it, and how to remove or correct it. The team needs audit trails, permission boundaries, retention rules, and human control over what an agent is allowed to do. The agent itself needs enough access to be useful without having so much ambient authority that every saved memory turns into a quiet leak path.

Brian Scanlan’s thread about Intercom’s internal Claude Code platform is a useful signpost. Intercom gave Claude production visibility through MCP, but paired it with read-only replicas, blocked critical tables, Okta auth, audit trails, skill gates, OpenTelemetry events, and lifecycle hooks (Thread Reader). The lesson is not that every team should copy Intercom’s setup. It is that serious agentic work needs governed visibility, not just bigger memory.

Useful context without controls is a liability waiting to happen.

Shared Context, Not Another Notebook

The product category after memory is shared, governed work context for every AI and agent.

Memory is the substrate: facts, preferences, and experience that keep future sessions from starting at zero. The structure on top is a work graph - the same recollection turned into typed objects with owners, due dates, source links, and state, so a sentence like “we agreed to delay the second pricing tier” becomes an object the next agent can act on, not a string it has to interpret.

That is what makes the experience feel different. A useful system does more than answer “what did we say before?” It can answer what needs attention now, what changed since last time, what the next AI should know before it starts, and which open loops can finally be closed.

Governance sits underneath the whole thing. Who can see it, who can use it, what can be changed or forgotten, what gets logged, and what an agent is allowed to do on your behalf. As context becomes more useful, those controls stop being optional.

That is the shift 3ngram is built around: shared context for every AI and agent, backed by a governed work graph underneath. The user should direct the work, not ferry context between tools.

In practice, that can look simple. A Tuesday meeting produces a decision and two commitments. A Claude session turns one commitment into a plan. Two days later, ChatGPT picks up the same plan and drafts the customer email. By Friday, a briefing surfaces the open commitment, the unresolved blocker from procurement, and the source notes behind the original decision - without anyone having to paste five transcripts into a new chat, remember which assistant saw the rationale, or dig through a passive notebook to reinterpret it by hand.

That is why follow-through is the product. Not because recall is unimportant, but because recall alone does not close loops.

The models will keep getting better at remembering. That will make individual AI products more useful. But serious work needs continuity that survives across models, tools, documents, meetings, and source systems.

AI memory helps an assistant remember.

Work context helps the next agent know what should happen next.