When one PROJECT_MEMORY.md is not enough: how to create a shared view across AI projects

How I turned individual project memories into a shared decision view, and why I separate source checks from AI interpretation.

Once I started keeping context directly with individual projects, returning to work became easier. Codex or Claude Code could read the current state, decisions and open questions. I no longer had to explain the full history from scratch in every new session.

With multiple projects, however, another layer of work remained.

Every morning, I still had to open one project after another and work out what had moved since the last review, what remained open, where a decision was missing and which project needed my attention.

Project memory solved continuity inside each individual project. To stay oriented across them, I needed a shared decision view.

That is how the portfolio layer of my AI Project Memory started to take shape.

Two different jobs for project memory

When I work across several projects, it helps me to distinguish between two layers.

Project memory holds the detail of one specific project. It captures the goal, current state, decisions, open questions and next step.

Portfolio memory does not repeat all of that detail. It selects only the information needed for decisions.

If I have five projects, I do not need five long summaries in the morning. I need to know which project changed, where my decision is waiting, where evidence is missing and which two or three things deserve attention.

When a shared layer makes sense

I would add portfolio memory only after the memory for individual projects is working.

If the inputs are outdated or unclear, a shared overview simply carries that uncertainty upward. The output may look convincing while still being built on weak foundations.

Before creating the shared layer, each active project should therefore make clear:

• its current state,
• the valid next step,
• which decisions have already been made,
• what remains open,
• which files or evidence those statements are based on.

New proposals should also stay separate from confirmed state. The portfolio view should reflect what is true today and openly show the places where that cannot be confirmed.

How to create your first PORTFOLIO_MEMORY.md

For the first version, you do not need a morning automation or validation scripts. It is enough for each project to contain a current PROJECT_MEMORY.md.

Above them, you can create one shared output:

PORTFOLIO_MEMORY.md

Its structure can look like this:

# Portfolio Memory

Review date:
[DATE]

Review window:
[FROM] – [TO]

## Project A

Status:
Updated / Confirmed no change / Needs confirmation

What changed:
...

Current next step:
...

Needs my decision:
...

Missing context or evidence:
...

Source:
[path to PROJECT_MEMORY.md]

## Project B

Status:
...

## My attention now

1. ...
2. ...
3. ...

## Projects with no action needed

...

The output should stay short. If I need technical detail, I open the specific project. The job of the portfolio view is to help me decide where to go next.

The first overview can be created manually with one prompt:

I am working on multiple projects.

Each project contains a PROJECT_MEMORY.md file with its current state,
decisions, open questions and next step.

Read PROJECT_MEMORY.md in these projects:

1. [PATH TO PROJECT A]
2. [PATH TO PROJECT B]
3. [PATH TO PROJECT C]

Prepare a draft PORTFOLIO_MEMORY.md.

For each project, include:

1. the current state,
2. what changed since the last update,
3. the next concrete step,
4. what requires my decision,
5. whether context or evidence is missing,
6. the source the information is based on.

Use one of three states:

- Updated,
- Confirmed no change,
- Needs confirmation.

Then create a section:

## My attention now

Select no more than three items across projects that require
my attention based on the available evidence.
When ordering them, consider:

- blocked next work,
- a missing decision,
- risk,
- deadline,
- impact on other projects.

Distinguish between:

- confirmed state,
- recommendation,
- missing information.

If you cannot confirm something, mark it:
NEEDS CONFIRMATION.

Do not invent missing context.
Do not edit the individual PROJECT_MEMORY.md files.
Show me the draft first.

For the first few runs, I would run this process manually. You will see whether the shared view is accurate, whether one project is receiving disproportionate attention and whether the input Project Memories contain enough current context.

How to evaluate the state of each project

Three simple states have worked well for me.

Updated

A relevant change occurred in the project. That may be an edited source file, a new output, a task change or a confirmed decision.

This status should not mean merely that any file in the project folder changed. We need to know that the change affects the project itself or its next step.

Confirmed no change

The project was included in the review and nothing relevant has changed since the last checkpoint.

This label matters. It shows the difference between a project that was checked and had no change, and a project that was simply forgotten during the review.

Needs confirmation

The state of the project cannot be evaluated reliably.

The current project memory, a source, access or evidence of what happened may be missing. That status should remain visible. The portfolio layer should not silently replace it with an estimate.

How to verify which projects actually changed

In the first version, you can start from the last modified date of PROJECT_MEMORY.md. Over time, however, it becomes clear that the timestamp alone may not be enough.

A project may appear updated because a build ran, a test output was created, a helper file changed or the previous automation generated its own summary. The actual work may not have moved at all.

That is why I gradually started using Git as an evidence layer.

Git helps me see which files changed, since which checkpoint, and what existed before and after the change. I can also distinguish source files from derived outputs that should not affect the project state.

The model no longer has to search the whole project for a change. It receives specific files or a diff whose meaning it needs to interpret.

That creates an important split:

1. a simpler check identifies where a change happened,
2. AI evaluates what that change means.

How to separate source checks from AI interpretation

Before involving the model, several things can be checked without any need for language understanding:

• which projects are registered,
• whether their sources are available,
• whether they changed since the last checkpoint,
• whether they have current project memory,
• whether another review run is already in progress.

Only then does AI interpret the meaning of the changed material.

A simplified flow looks like this:

PROJECT A → PROJECT_MEMORY.md ┐
PROJECT B → PROJECT_MEMORY.md ├→ source check
PROJECT C → PROJECT_MEMORY.md ┘
                                  ↓
                    Updated / No change / Confirm
                                  ↓
                      relevant files and decisions
                                  ↓
                         AI interpretation
                                  ↓
                       PORTFOLIO_MEMORY.md

This split reduces the risk that a project is left out of the review or that the model repeatedly reads projects where nothing relevant happened.

Where I use AI and where I use fixed rules

For each step, this question helps me:

Does this step need to understand meaning, or does it only need to verify a clear condition?

I use AI mainly to interpret changed files, combine context from several sources, distinguish an outcome from a blocker, prepare a short summary and suggest priorities.

I use fixed rules or scripts to check whether every project was included, whether a project exists, whether it changed, whether the output has the required sections and whether another run is already in progress.

The model gets room where judgement is needed. Code holds consistency where the rule is unambiguous.

Why the first version consumed too much context

The first automated version of the morning and evening review produced a useful overview, but it read too much.

The model repeatedly received the working instructions, the entire task register, old summaries, broad history and projects where nothing relevant had changed. Some projects also looked updated only because the previous run had generated its own output.

I gradually changed the flow so every project is first checked without detailed interpretation. AI now reads only changed or unclear projects and receives a specific package of relevant material. Builds, helper files and management outputs are excluded from the review.

The system also checks whether another run is already in progress. A duplicate process can therefore stop before sending the same context to the model again.

The most efficient AI run is the one that does not need to start.

For me, that sentence does not mean using AI as little as possible. It means using it where we actually need to understand meaning. Checking whether a file exists or when it last changed can be done more reliably and cheaply by a simpler mechanism.

I am not giving an exact percentage saving yet. I have validated the architectural change; I am still measuring the financial result.

Which changes are still confirmed by a human

Portfolio memory can prepare a strong decision input. I still do not want the model to change a priority, owner, deadline, primary task status or confirmed decision without review.

Merging two tasks, changing their meaning or marking work as complete without sufficient evidence should also remain under human control.

The reason is practical. If a working proposal gets mixed with confirmed state, the next AI tool can very efficiently continue in the wrong direction.

So I split the system into three steps:

1. AI reads and interprets the evidence.
2. AI proposes a change or priority.
3. A human confirms what will be considered valid from that point on.

New inputs from meetings, chats or other AI tools in my setup first go into a separate review area. They reach the primary state only after comparison with existing tasks and confirmation.

This intake process is a separate branch of the system. The portfolio view should work primarily from confirmed project state.

How I use the morning and evening view

The shared memory has two practical uses for me.

In the morning, I need to see what moved since the last review, what remains open, where a decision is missing and which maximum of three priorities make sense.

In the evening, I want to capture confirmed outputs, unfinished work, new open questions and the next step.

The detail stays inside the specific project. The shared view should help me decide where to go next.

This is where the difference between a summary and a decision view becomes clear. A summary can contain everything that happened. A decision view selects only the information that changes my next action.

Recommended implementation order

1. Validate project memory on one project

The portfolio layer will only be as reliable as its inputs. First verify that another AI tool can correctly understand the project and continue from PROJECT_MEMORY.md.

2. Extend the same principle to other active projects

Individual projects do not need an identical technical structure. But they do need the same basic types of information: current state, decisions, open questions, next step and sources.

3. Create the first manual portfolio view

Run the prompt over two or three projects and check whether the result actually helps you make decisions. Watch whether the selected priorities are based only on the latest change or whether they also account for blockers, deadlines and required decisions.

4. Watch for repeated checks

Over one or two weeks, notice what you keep verifying in the same way. It may be the existence of a file, the time of the last change, project coverage or required parts of the output.

5. Only then add scripts and automations

Automation makes sense once you understand the manual flow and know what output you need. Otherwise it may simply accelerate the creation of an inaccurate or low-value overview.

Limits of shared project memory

Portfolio memory helps me stay oriented, but it is still not an autonomous project manager.

A validation script can confirm that a project was included. It cannot guarantee that the model understood the meaning of every change correctly.

Even the selection of three priorities remains a recommendation. The model may not know the wider business, personal or team context that affects my decision.

Human approval protects the primary state, but it also adds another step and can become a bottleneck. In a team or production setup, I would therefore also address technical permissions: who can read the context, who can propose a change and who can approve it.

For me, the value of AI Project Memory does not come from the amount of information stored. It appears when I no longer have to open five projects in the morning just to figure out where I am the one who needs to act.

If you are starting with this, I would keep the sequence simple: reliable memory for one project first, then a manual shared view, and automation only at the end.