My work AI can see the work. My Editorial Intelligence AI can remember it.

I asked my work Copilot a simple question: what do you actually remember about my work?

The answer exposed a gap I had already spent months trying to solve in my personal Editorial Intelligence system. Copilot could retrieve current evidence from the places where my work actually happens: email, Teams, calendar, SharePoint and OneDrive. If I asked about a live project, it could go and look for the latest material instead of relying on an old summary.

What it did not have was the same kind of running account I had built elsewhere: what changed, what was decided, which route was rejected, what is still unresolved and what should happen next.

That is the distinction I was initially overcomplicating. My work AI can find the evidence. My Editorial Intelligence system is better at preserving the state of the work.

System	What it does well	What it struggles with
Work AI / Copilot	Retrieves current evidence from email, Teams, files, calendar and SharePoint	Does not automatically preserve a rich running account of what the work now means
Editorial Intelligence system	Preserves decisions, project state, history and context between conversations	Cannot and should not access confidential employer systems

The two systems do not have equal and opposite strengths. The important difference is simpler: live evidence can be retrieved; maintained state has to be made.

Retrieval is not the same as knowing the state

Imagine I return to an event project after a few days away. The evidence might be spread across a brief, a Teams conversation, two emails, a calendar invite and a working document. A good work AI can retrieve all of those things, which is already a huge improvement on manually hunting through them myself.

But retrieval still leaves another job. Which version is current? Which comment changed the direction? Which question was already answered? What am I waiting for? What is the next useful move?

The evidence exists. The current meaning of the work may not exist anywhere in a compact form.

That is why search and memory are not the same thing. Search can recover what people said and what files exist. A useful work-memory layer should also preserve what survived those conversations and documents.

Question	Retrieval helps	Maintained state helps more
What did people say?	Yes	Sometimes
Which files or messages exist?	Yes	Sometimes
Which route did we choose?	Only by inference	Yes
Why did we choose it?	Only by inference	Yes
What changed most recently?	Sometimes	Yes
What is still unresolved?	Only by inference	Yes
What should happen next?	Weakly	Strongly

This is close to the argument I made in Context is capital. The useful advantage is not simply having more information. It is having enough maintained context around that information for previous work to improve the next decision.

The scarcer part is the part somebody has to create

The first version of this article treated the two systems as almost symmetrical: one had access without continuity; the other had continuity without access. That was neat, but it missed something important.

If an email, Teams thread or document still exists and the AI has permission to reach it, the evidence can be retrieved again. Another model with the same access could retrieve it tomorrow. Better enterprise search could retrieve it more accurately next year.

Maintained state is different. Somebody has to notice that a decision matters enough to preserve, that one route has been abandoned, that another is now authoritative, or that a particular open question will matter when the project resumes. That judgement has to happen while the work is happening, or be reconstructed later from the evidence with some uncertainty.

That is why I now think the continuity layer is the scarcer part. It is not simply another storage feature. It is the result of judgement applied to the work over time, which connects directly to Editorial judgement is becoming infrastructure.

The memory layer was empty, not absent

There was another useful correction. My first reaction was that the work AI did not have a memory layer. That was not quite right.

The layer existed. It already contained some Editorial Intelligence context because I had deliberately given it that material. What it lacked was a useful record of much of my day-to-day work state.

That changes the problem. It is less about whether the product can remember and more about whether anyone is taking responsibility for deciding what should be remembered.

Diagnosis	What it means
Absent memory layer	There is nowhere for useful context to persist
Empty memory layer	A place for persistent context exists, but the useful state of the work is not being maintained there

The second problem is more interesting because organisations already preserve enormous amounts of information. They have emails, documents, chats, meeting notes and project systems. What they often do not have is a small, maintained account of what all that activity now means.

What the missing layer actually needs to contain

I do not think the answer is to save everything. A giant memory would quickly fill with old decisions, weak assumptions, superseded versions and details that mattered for three days and then stopped mattering.

What I need is much smaller: enough information for a person or AI to return later and continue without rebuilding the whole project. In practice, that usually means a short record of what changed, what was decided, what remains open, what matters next and where the authoritative evidence lives.

That is what I mean by a save point. I explored the idea more fully in Your AI work needs a save point, but the practical version is straightforward.

Context layer	What it contains	Where it should live
Stable background	Role, recurring responsibilities, long-running workstreams and ways of working	Work-owned context document or approved memory layer
Current project state	What changed, what was decided, open questions, blockers and next step	Save point or project-state note
Live evidence	Emails, Teams conversations, files, meeting invites, briefs and current documents	The Microsoft 365 systems that already own the work

Those three layers do different jobs. Stable background should change slowly. Project state should change when meaningful work changes. Live evidence should stay in the systems where it belongs and be retrieved when the latest facts matter.

I am building a bridge, not copying one system into the other

My practical experiment is deliberately small. I created a work-safe bridge from Editorial Intelligence into my Microsoft environment. It explains the public method and the way I think about recoverable work, context, evidence and editorial judgement, but it does not expose my private personal repository.

On the work side, I am creating a work-owned context document that can hold the stable background and a current save point. Copilot can use that to understand what it is looking for, then retrieve the latest evidence from the systems that actually own the work.

The direction of travel matters. I do not want confidential company information copied into my personal GitHub merely because it might be useful to an AI later. The personal system can learn from public and generalisable observations about how knowledge work behaves, while company evidence stays inside company systems. The method can be public; the inputs still need boundaries.

This makes the problem much easier to describe. I am not trying to synchronise everything. I am trying to put each kind of knowledge in the place where it belongs.

Should the work AI eventually infer all of this itself?

There is a fair objection. If enterprise AI can already retrieve email, meetings, files and chat, perhaps I should not maintain a project-state note at all. The model could simply infer the current state whenever I ask.

Sometimes it can, and that will probably improve. But projects routinely contain obsolete versions, abandoned options, conflicting messages and decisions that were obvious to the people involved but never written down cleanly afterwards. Retrieval can reconstruct some of that, but reconstruction is still inference.

A short maintained note can say: this is the route we chose, this is why, this is what remains open, and these are the sources that now matter. That is not duplicating the project. It is preserving the judgement applied to the project.

There is also an organisational limit to my personal workaround. If this kind of state becomes important, it should not depend on one employee remembering to maintain a private note. The useful version should eventually be team-owned, governed and embedded in the work itself.

That is where the empty-versus-absent distinction becomes important. If the memory layer already exists, the challenge may not be to buy another tool. It may be to establish responsibility for keeping useful state current.

The work needs somewhere to resume from

This is the same problem Editorial Intelligence has been circling for months, but I understand it more simply now. I started using save points because conversations were temporary. I became interested in repositories because models were replaceable. I started thinking about editorial memory because finished outputs were preserving less knowledge than the work had created.

The enterprise version adds one more lesson: being able to see the work is not the same as preserving what the work now means.

I do not need one AI that remembers everything. I need the work AI to retrieve what is true now, a small maintained layer to preserve what is worth carrying forward, and a clear boundary around where company and personal knowledge are allowed to live.

The work happened. The evidence still exists. The harder question is whether anyone made the useful state of the work survive the conversation.