Back to blog
Case study · AI Project Memory

How AI Project Memory helps me keep track of my own projects

Codex, Claude Code, Fireflies, Git and validation scripts now give me one shared view: what moved forward, what still holds true and where I need to step in.

6 min read · 2026-08-19
How AI Project Memory helps me keep track of my own projects

At first, it worked exactly the way I needed it to.

Codex helped with implementation. Claude Code brought another perspective. Fireflies captured tasks from meetings. Individual chats kept the context of a specific topic.

Each tool handled its part of the work well. But over time, I started missing one shared picture.

One task was open in a chat, named slightly differently in a project record and captured again from a meeting. In one place it looked in progress, somewhere else it looked finished. At the next morning review, I was once again figuring out what had actually moved and where I needed to step in.

So I started building AI Project Memory – a shared project memory for my personal project management.

If you only have 2 minutes

Five questions I need answered

  1. What actually changed?
  2. What is true today?
  3. What is only a proposal?
  4. What needs my decision?
  5. What is the next concrete step?

When I am working on several things at once, I do not need to keep every detail in my head. I need to know where to find it and whether I can trust the current state.

What the system is made of

AI Project Memory is not one app. It is a setup made up of several tools:

ToolRole in the system
CodexHelps with implementation and project files.
Claude CodeWorks in its own context and creates separate outputs.
Fireflies GPTCaptures proposed tasks from meetings.
GitKeeps the history of changes.
MarkdownStores states, tasks, decisions and working records.
Validation scriptsCheck sources and mandatory rules.
Morning and evening automationsPrepare a shared view across projects.

Each tool does a different part of the job. The shared memory between them keeps continuity.

What the system shows me on a normal day

Project details stay inside the individual projects. Above them is a shared layer with a current overview, morning and evening summaries, a task register and a change history.

In the morning, it should show me what was completed, what is still open, which three priorities make the most sense and where a decision is missing. In the evening, it captures confirmed outputs, unfinished work and the next step.

How the current overview is created

First, a validation script checks all registered projects. It assigns one of three states to each of them:

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

The model reads in detail only the projects that changed or need confirmation. It receives specific files, related tasks, the previous summary and protected outputs from another tool.

Then a draft control record is created with one row for every project. A rules-based check verifies that nothing is missing and that content the system is not allowed to overwrite has been preserved.

Only then does the model prepare the decision view.

This sequence gives me confidence that the overview was not created only from whatever the AI happened to find. Every project has to be included, and missing evidence has to remain visible.

The first version worked. And used far too many tokens

This is the part I have tuned the most over time.

The model repeatedly read working instructions, the full task register, old states and a broad history. The validation script also picked up files created by the previous run: management summaries, website builds or test results.

A project then looked as if it had changed even when only the system's own output had changed.

Regular checks also overlapped with a fallback AI-based recovery process. Two processes could read similar context and prepare a similar result.

So I gradually:

  • added a check of all projects before any detailed reading,
  • limited AI context to changed or unclear projects,
  • combined allowed inputs into one package,
  • excluded builds, helper files and the system's own management outputs,
  • stopped broad repeated reading and retry loops,
  • moved recurring cycles to a more cost-efficient model and setup,
  • paused repeated AI-based recovery.

What remains is an hourly check without AI. It can determine whether today's cycle is complete, still running or already has a fresh draft record. In those cases, it does not call the model at all.

Optimisation does not start only with a shorter prompt. Sometimes the best decision is not to call the model.

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

How I protect the main task list

The second part of the system processes proposals from Fireflies, chat, Codex, Claude Code or manual input.

A new proposal is first stored in a separate space. It includes the source, the proposed change, evidence, confidence level and review status.

The system compares it with existing tasks. The model can also flag the same task written in different words. Nothing is deleted or merged during this check.

A person then decides whether the proposal should create a new task, update an existing one, merge a duplicate or wait for more information. Only after that is the change written to the main register together with the original value, the new value and the source.

This mechanism is not the main point of the system. But it helps keep the picture clear. When a new proposal cannot silently become the accepted state, I can distinguish between what is already true and what is still waiting for me.

How to start smaller

You do not need Git or automation for the first version.

One document or spreadsheet with current tasks is enough, plus a second place for AI proposals. Choose one recurring problem, such as tasks from meetings or a weekly review of open items.

AI can read the inputs, compare them and propose changes. A person updates the main list only after review.

If you already work across several projects, add a project register, stable task identifiers and a change history. Automation only starts to make sense once you know which steps repeat and which decisions you want to keep with a person.

What I took away from it

AI Project Memory grew out of a need to stop losing track of my own work.

Over time, I realised that good project memory does not need to know everything. I need it to give me a clear view of what moved, what is true, what is waiting for review and where I need to step in.

If you are doing many things at once, try naming three places:

  • where you look for the current state today,
  • where you put new proposals,
  • where you decide what will become the accepted state next.

That is often where the overview gets lost. And that is also where even a simple project memory can free up the most attention.

Practical AI workflows, new articles and invitations to Women in AI Prague meetups.

Send me updates by email