AI Project Memory under the hood: a technical case study

How I check sources, where I involve the model, what I changed when token usage was too high and which limits remain open.

This part goes deeper into the system architecture. It captures the exact order of checks, the boundaries between the model and fixed rules, and the parts I still do not consider fully resolved.

The foundation is a shared folder of text files whose changes are tracked by Git. Git acts as history here: it shows what changed, when and by whom. Markdown is a simple way to structure text using headings, bullets and tables.

In this technical section

1. Architecture and tools
2. Flow from source to overview
3. What I tuned around token usage
4. Task intake and approval
5. Model, rules and human judgement
6. Open limits

What each tool does in the system

Two levels of memory

Detail stays with the project. The decision view is created above the projects.

Layer 1 · Project memory

Work logs, current state, decisions, open items, risks and the next step.

Source projects remain read-only.

Layer 2 · Portfolio memory

A shared overview, task register, validation records and morning or evening decision views.

It selects only the information that changes the next action.

From a project change to the morning overview

The morning and evening review follows a precise order.

1. The check verifies the sources first

A script goes through the project register and assigns one of three states to each project:

• Updated — updated,
• Confirmed no change — confirmed with no change,
• Needs confirmation — needs confirmation.

This check does not use a language model. It looks at change times, source availability and the specific location of new files. It does not understand what those changes mean. But it helps confirm that no registered project was skipped and reduces the amount of material AI has to interpret.

2. The model receives a tightly bounded context

If a project is confirmed with no change, AI does not read it in detail again. For Updated or Needs confirmation, it receives the specific changed files and related active tasks.

The current version of the system creates one tightly bounded evidence package. It contains the project register, evidence list, previous summary, protected content from another tool, related tasks and changed files.

Previously, the same material was opened across several rounds. The model repeatedly read the instructions, the full task register and far too much history. The output was similar, but the path to it was more expensive and less predictable.

3. A pending review record is created

After the source check, a record is created with the status Pending.

It captures one morning or evening run: the review window, how it was triggered, the executor and one row for every project. This lets me verify that nothing was forgotten.

The record also has a protective function. If the next check sees a fresh pending run, it stops without starting AI again. Two automations therefore do not begin generating the same summary at the same time.

4. A fixed-rule gate validates the evidence

Before the shared overview is updated, the system checks, for example:

• whether the review record exists,
• whether it contains all required data,
• whether every project has exactly one row,
• whether gaps in the evidence are explicitly named,
• whether content belonging to another tool has been preserved.

If this gate fails, the current overview does not change. That matters to me. I do not want to open a summary that looks current when the underlying evidence check has failed.

5. The model creates the decision view

Only after the check succeeds does the model interpret changes across projects. It prepares the morning or evening view, and a final fixed-rule check verifies the required sections, their order and completion of the process.

The next run then continues from the last confirmed checkpoint.

The first version worked, but used too many tokens

This was one of the moments when I realised that a functional AI workflow is not necessarily a good workflow.

The first versions of the morning and evening reviews could create a useful overview. But the route to that overview used more tokens than made sense. The model repeatedly read working instructions, the full task register, old states and far too much change history. Sometimes it reopened material it had already received once.

Another problem was what the system treated as a change. The validation script also picked up its own management outputs, helper files, website builds or browser test results. A project could therefore appear updated simply because the previous run had generated a summary.

Scheduled reviews could also overlap with an AI-based fallback recovery process. Two processes would then read similar context and prepare similar results.

I gradually changed several things:

• the script checks all projects first, and the model reads only Updated or Needs confirmation projects in detail,
• allowed evidence is combined into one tightly bounded package,
• derived outputs, builds, libraries and test files are excluded from the review,
• second source checks, broad repeated reading and retry loops are prohibited,
• the morning and evening cycle use a more efficient model and settings,
• repeated AI-based fallback recovery is paused,
• an hourly check remains that can make a decision without starting the model.

For me, that last boundary is the most useful one. The most efficient AI run is the one that does not need to start.

A local check can determine before the model starts that:

• today's review record is complete,
• the scheduled cycle is still running,
• a pending record is less than 90 minutes old,
• the system is still inside a protective time window,
• the network is unavailable,
• another process is already performing the same recovery.

In these cases, the model does not start.

There is one important clarification. The regular 08:00 or 18:00 cycle already begins as an AI automation. The script reduces how much it reads, but it does not remove the first model call. Skipping AI entirely works only when the check happens before AI is started.

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

From an AI proposal to the primary recorded task

A second branch of the system handles tasks coming from Fireflies, direct chat, Codex, Claude Code, a review process or manual input.

If every tool writes directly into the primary task list, parallel tasks, identifier collisions and status changes without a clear reason can appear very easily. So this process has four steps.

1. Proposal intake — The source and evidence remain visible.
2. Duplicate check — The model flags possible duplication; it deletes nothing.
3. Human approval — A person decides what the task means and what its state should be.
4. Write the change — Both the original and new value are stored.

Proposal intake

Fireflies GPT writes into its own Fireflies Input section. Proposals from chat move, after confirmation, into Intake & Review.

The input contains the source, proposed change, optional task identifier, evidence, confidence level and review state. The primary task does not change at this point.

Checking for equivalent tasks

The system compares a proposal with existing tasks using an exact identifier, the same project title, the same source and outcome, and finally a semantically equivalent goal.

The model is especially useful for the final point: it can flag the same task written in different words. A possible duplicate is recorded in Dedupe Review. Nothing is deleted or merged while the system is searching for duplicates.

Approval and write

A person can merge the proposal into an existing task, update it, keep both with a clearer scope, mark the newer row as a duplicate or request additional confirmation.

The owner, priority, primary status or deadline does not change simply because the model suggested it.

Only the execution step changes the primary recorded task. When an approved change is written, the system stores the original value, the new value, the source and the approval. That preserves data correctness and consistency as well as the history of decisions.

In one real case, I found multiple meanings under the identifier T-038 and a duplicate row for the same website work. The approved merge kept the older identifier. The historical row was not deleted, and an unrelated task with the collision received a new identifier.

The result was less ambiguity without losing history.

Where I use the model and where I use fixed rules

A simple question helps me: does this step need to understand meaning, or does it only need to verify a clearly defined rule?

I use the language model to interpret different pieces of evidence, distinguish an outcome from a blocker, prepare a summary, compare tasks by meaning and suggest priorities.

I use fixed rules to check coverage of all projects, required data, the number and order of sections, stable identifiers and change history.

The model gets meaning and room for judgement. Code holds the boundaries and consistency. A human remains responsible for decisions that change the valid state.

Where the practical value appears

Looked at individually, each part can seem like a small administrative layer. The value appears when multiple projects and tools are connected.

The system helps me:

• reduce repeated reading of projects where nothing changed,
• lower the risk of recording the same task more than once,
• separate a confirmed change from a new proposal,
• catch a project where evidence or a decision is missing,
• preserve outputs from multiple AI tools without silently overwriting them,
• continue from the last confirmed checkpoint,
• understand later why a state or task changed.

It makes the most sense when a person or team is running several projects in parallel, uses multiple AI tools and needs to return to work that lasts longer than a single chat.

For one short project, the full setup would be too heavy. There, I would stay with one main task list, a simple work log and a clear rule for who can change the state.

What the system still has not solved

AI Project Memory is a functional working system, but it still has limits.

A review record can confirm that projects were included and that the format is correct. It cannot guarantee that the model understood every piece of evidence correctly. Human approval protects sensitive changes, but it also adds waiting time.

Comparing semantically similar tasks remains a judgement task. I need to measure cases where AI merges two different tasks, misses a real duplicate or a human changes its recommendation.

Protection of the primary records is currently largely procedural. A production version should have separate accounts and technical permissions for proposing, approving and writing changes.

The exact cost saving also remains open, as does fully automatic recovery with reliable remote storage of history.

These limits help me distinguish a functioning personal work system from the idea of fully autonomous project management.

What I take away from the technical layer

A functional AI workflow is not necessarily reliable or efficient. In my case, it helped to separate source checks from interpretation, narrow the context and require human confirmation before changes to the primary state take effect.