Yet Another AI Memory: Only 2 of 222 Conversations Needed a Detailed Recap in a 250,000-Line Codebase

How I stopped retelling an AI agent the project’s history at the start of every new conversation—and what an analysis of 170 days of work showed.

At some point, I stopped thinking about which conversation to use to continue work on the project. I could open a new one, give the task briefly, and move on. The agent picked up earlier decisions and work.

For example, one conversation began with this message:

The request is just two sentences. I did not explain how authentication worked, why a new role should not get a separate login system, or that we already had a user-portal template to roll out. The agent read the saved rules and used them in its work. The shared-authentication rule was added to memory on February 3. Before the agent read it on April 23, 154 independent conversations and 78 days had passed.

By then, the project was substantial: a TypeScript ERP built with React, Next.js, NestJS, and Prisma, with three applications, CRM integrations, a system for generating estimate calculators, online document signing with a mini-blockchain, and 11 user portals. The source code was nearly 250,000 lines long.

Later, I decided to check my impression against the work history. The sample included 222 conversations with work tasks. In only two of them did I start with a detailed reminder of what had happened before. The logs also contained 1,451 reads of memory that had been updated in other conversations.

Below, I’ll explain what this changed in my work, how the memory was organized, and where the numbers came from.

The old conversation got confused; the new one had no history

Long-running work with an AI agent has a familiar problem: the old conversation gradually fills up with context, while a new one starts without the project’s history. So you usually have to choose between two inconvenient options:

• Continue the old conversation. Token use grows, the agent starts forgetting some of the context, gets confused, and makes mistakes.
• Open a new one. The agent can read the code, but does not know the project’s history or earlier agreements about architecture, constraints, and how the work should be done.

Continue working on the project

Old conversation

Token use grows. The agent gets confused and forgets parts of the exchange.

New conversation

The code is available, but earlier agreements have to be carried over.

What bothered me most was having to discuss decisions we had already made all over again. Why is authentication shared across roles? Which component should we use? Why did we reject the other option?

The code showed what we had built, but not always why we had chosen that particular approach. Those explanations stayed in the old conversation. I had to remember them myself and retell them to the agent.

Once memory was in place, this work gradually went away. I still set tasks, chose between options, and checked the results. But new conversations increasingly started with what needed to be done next.

Three times the project’s history came in handy

Separating companies in the system while accounting for earlier CRM decisions

In May, I asked the agent to review the plan for multitenancy and subdomains, then implement the first two stages. Multitenancy here means that different companies use the same system, each with its own data and users.

I gave it a link to the plan and a short instruction. I did not explain again how the CRM integrations worked. There were already important agreements on that:

• One company could have several CRM integrations—one for each sales pipeline. We had dropped the earlier limit of “one company, one integration.”
• Each integration needed a name and a head of sales responsible for it.
• The name had to be unique within the company; pipeline uniqueness was checked separately in the service.

These rules matter when data is separated between companies. They determine who owns each record and how a user gets access to it.

The agent read the note about how the integrations worked and which restriction we had removed. It then opened the Prisma database schema and checked it against the code.

The first two stages were implemented successfully. We did not have to redesign the architecture afterward.

The case review includes the request, the note the agent read, and what it did next. The agent also had a plan with the task requirements; memory supplied the earlier decisions.

Setting up plan reviews and recalling an old Cursor issue

In another conversation, I wanted subagents to review every new plan. Each one would have its own area:

• assign one subagent the database;
• assign another the business logic;
• then add checks for the interface and other parts of the project.

The checks had to run whenever a new plan was being prepared.

Earlier, when we introduced new Cursor rules, the editor did not always apply them automatically. We decided to temporarily move short launch commands into a User Rule—a user rule in the editor.

I did not retell that history in the new request. The agent found the earlier decision and reminded me about the alwaysApply bug in Cursor. While discussing where to put the command that launched the new checks, it suggested adding it to a User Rule, among other options.

A month and a half later, the agent recalled why we had set up the rules that way and took that into account when it was time to configure new checks.

Subagents did start reviewing plans in the project’s workflow. The materials include the note the agent read and its next question, showing how it used the earlier decision.

Creating another portal without duplicating authentication again

The third case is the request from the beginning of the article: create a portal for the head of sales at a management company.

The ERP already had a shared authentication system for different roles. But when we created the first portals, the agent bypassed it twice: it built separate login modules and duplicated the existing solution.

We saved a rule in memory to use shared authentication. After that, this did not happen again.

When we needed the head-of-sales portal, the agent read the rule and used shared authentication. I did not have to mention it in the request.

The portal launched without errors. No problems came up after launch either.

The case materials contain the original request and the rules the agent read. It kept working on the task after that; the logs contain another 133 tool calls.

For all three cases, we checked exactly what the agent had read and what I had told it before then. That makes it possible to see which details came from memory.

What changed in my day-to-day work

It is important to understand that, although I’m describing these cases as significant now, I did not think about them while working with the agent. They happened in the background, without drawing my attention. I worked this way for months, and, as the study showed, requests to memory eventually added up to more than 1,400.

The study included 272 Cursor conversations from February 3 to July 22, 2026—a span of 170 calendar days. Of those, 222 involved work tasks, while 50 were informational or administrative.

Three changes mattered most to me:

1. I could close an overloaded conversation without worrying. The next one picked up the work. I no longer had to cling to an old exchange for fear of losing context.
2. I did not have to make the same agreements again and again. The agent could read which architecture we had chosen, which constraints we followed, and how we had agreed to work.
3. The agent could learn about earlier mistakes. In the next conversation, it could read what had gone wrong, why, and how we fixed it.

As a result, it barely mattered which conversation I used to continue the work. In a new one or an old one, the agent could pick up the saved work and continue where we had left off.

I could open a new conversation for the next task, or to continue the current work if the old conversation had run out of context.

On an active day, I could start up to 20 new conversations

To check this against the work history, I counted only new work conversations started on each day. Conversations that had been opened earlier and then reused are not included in this statistic.

The count includes 222 new work conversations across 45 active days. On an active day, I started an average of 4.93 new conversations. The median was 3 conversations. The gap between these figures came from a few especially busy days.

On 37 of the 45 active days (82.2%), I started two or more new conversations. On 25 days (55.6%), I started three or more. On 16 days (35.6%), I started five or more. The maximum was 20 new conversations in one day.

On those same days, I could also return to old conversations. The current data does not let us count those returns, so these figures show only a lower bound on the actual number of conversations in which work was happening.

Source: distribution of new work conversations across active days.

That was what I wanted from memory. I did not separately count the hours or tokens saved. The work history does let us check how often I had to recap the past and which notes the agent accessed in later conversations.

The memory now belonged to the project, not to a conversation.

How it worked: a protocol, Markdown, and Git

The system had four parts:

• A protocol—instructions on when to read memory and what to save after working.
• Markdown files—the project’s status, decisions, errors, and task history.
• Ordinary file tools—the agent read and edited memory just like the other files in the project.
• Git—versions of the notes and their change history.

No separate server, vector database, or special memory API was needed.

For me, that simplicity is one of the main advantages. Memory can be integrated easily into work with a repository. Any note can be opened, read, corrected, and compared with an earlier version.

If context was lost, I could check specific things:

• Was the needed fact saved?
• Which file did it go into, and could that file be found from the project map?
• Did the agent read it?
• Is the note still current?

Organizing the information took the most thought: what to treat as current state, where to keep the history, and how not to mix them up.

First the project map, then the details that matter

At the start of a conversation, the agent read a short summary: what we were doing, what was blocking progress, and where to find the details. Next to it was a list of decisions with links to their descriptions. A few recent conversation logs helped it understand what had happened lately.

After that, the agent moved on to the materials for its task.

The files were arranged like this:

docs/memory/
├── PROJECT_STATUS.md
├── DECISIONS.md
├── TECH_DEBT.md
├── status/
├── decisions/
├── errors/
└── dialogs/

These records need to be updated in different ways. Status should describe the project today, so it changes as the work changes. A decision may remain in effect for a long time, while an error history may be useful months later. The conversation log still retains every stage, including steps we have since abandoned.

I tried to keep each fact in one primary place. For example, describe a decision in a separate file and leave a short linked entry in the general list. If we reconsidered the decision, we updated that file.

This let the agent select records for its task. For CRM work, it could open the integration status and related decisions. For authentication, it could read the rules and known errors. Memory also let it follow a link to the relevant plan or source file.

Reading and updating became part of the work

The cycle was simple:

1. At the start of a new conversation, a short instruction pointed the agent to the protocol.
2. The agent read the overall status, the decision register, and the three latest conversation logs.
3. It opened the details relevant to the task and got to work.
4. At the end of an iteration, it recorded the request, the work done, and the result.
5. It checked what had changed and updated the relevant records: work status, a decision, an error, a deferred task, or a blocker.

New conversationSet the task

→

Read the relevant memoryOpen the context

Status, decisions, and task materials.

→

Work and check the resultDo the work and check it

Compare the result with the project requirements.

↓

Record the resultUpdate the relevant layer

Record the result, decision, error, or deferred task.

←

Version in GitSave the changes

Memory and project materials remain in the history.

←

Next taskContinue the work

↑

Git kept the versions. Later, that helped with the research: we could reconstruct which text existed at the time of a particular task.

What the work history showed

To evaluate the memory, we compared Cursor’s history with the versions of files in Git: what the agent saved, what it later read, and what text it received. Scripts counted conversations, records, and reads. ChatGPT categorized the first requests. For selected cases, we also reviewed the content of the notes and the agent’s subsequent actions.

Here are the main findings. The detailed counting rules are in the method.

Almost every work conversation began without a detailed recap

The study covers 272 independent conversations: 222 with work tasks and 50 informational or administrative. The first message in each of the 272 conversations came from a person; work and other requests were classified by their content.

Memory was read in both groups:

Memory was used in work conversations and in informational or administrative ones. To count how often I had to manually reconstruct the previous state, the relevant part of the sample is the 222 work conversations.

The distribution was:

• 113 requests—no explicit reference to earlier context. That is 50.90% of work requests.
• 88—a link to a plan or another document.
• 19—a brief mention of earlier work.
• 2—a detailed reminder of earlier decisions or the project’s state.

The first three groups add up to 220 of 222 requests, or 99.10%. The opening messages in these conversations did not require a detailed recap of the past.

A link to a plan does, of course, provide context. But saying “implement the next stages in this plan” is much easier than explaining the project’s history all over again. The chart shows these cases separately.

This share shows how often I started a work conversation without a detailed reminder of the past. We did not measure the share of tasks completed successfully. In its work, the agent could use memory, plans, and code.

Source: summary of first requests by category and the independent conversation corpus.

Memory grew to 300 files

Over time, a large archive accumulated:

At the final snapshot, the total volume was 1,140,450 characters.

Most of that volume was in conversation logs: 263 files and 996,507 characters. The other 37 files contained status, decisions, errors, rules, architecture, and other working sections. Together they took up 143,943 characters.

Source: final memory-growth statistics.

The agent read a small part of the archive

In a given conversation, the agent usually read only a small part of memory. The median was 1.99% of the available memory files: in half of the conversations for which we could calculate it, the agent read no more than that share.

• In 90% of conversations, the share was no more than 12.82%.
• The largest share was 44.44%: in conversation 19, the agent read 8 of the 18 available files.
• In every conversation where the number of files available at the start was known, the agent used only part of the archive.

The maximum came at the very start, when memory was still being built. There were few saved files, so the next task required a substantial share of the experience already recorded. Across conversations 2 through 20, the median share was 27.78%.

As the archive grew, that share fell quickly. In the last 30 conversations, the median memory size was 289 files, while the agent read a median of four files, or 1.38%. The accumulated experience grew, but each individual task needed only a small part of it. The chart makes this clear.

The archive’s total volume is not the most informative measure here, though. Under the protocol, the agent had to read the three most recent conversations before starting a new one. The number of those logs kept growing, even though most older ones were no longer opened.

So I separately looked at the main memory sections, excluding docs/memory/dialogs/**. Their volume grew from 14,539 to 143,943 characters—almost tenfold.

At the start, across conversations 2 through 20, the median volume of these sections was 20,800 characters. The agent opened them in only 5 of the 19 conversations. When it did, the median amount read was 4,400 characters—about 21% of the median available volume.

In the last 30 conversations, the main sections had grown to a median of 136,000 characters. The agent read them in 22 of the 30 conversations, but the median volume read across all 30 was 4,260 characters—about 2.96% of the available volume. Looking only at conversations where the agent read something, the median was 5,400 characters, or about 4.0% of the available volume.

The relationship between the size of the main sections and the volume read was weak: the Pearson correlation coefficient was 0.26, and the Spearman rank correlation was 0.27. Memory grew, but the volume read did not grow with it: the agent selected the notes it needed for a particular task.

For an integration task, the agent could open the relevant notes without loading the entire history of interfaces and infrastructure. The project map helped it choose what to read.

The share of files is not the same as token savings: files have different lengths. The history snapshot does not contain total token use.

Sources: share of memory files read and memory volume and reading, excluding conversation logs. The starting Git snapshot for the first conversation was unavailable, so the share read could be calculated for 271 conversations.

Notes returned to the work months later

The logs contained 1,451 reads of memory notes that had previously been updated in another conversation. These reads occurred across 240 conversations.

Recent notes were needed more often. But some knowledge came back much later:

• median distance: 4 conversations;
• 90th percentile: 50 conversations;
• maximum distance: 191 conversations.

For most reads, the gap was short: in 90% of the cases where we could determine it, no more than 20 full days had passed since the file’s last change. The maximum was 81 days. Sometimes the agent had to go back almost three months.

These tasks included new portals, plan reviews, interface themes, and integrations. It therefore made sense to keep decisions and errors for longer than the last few conversations: an old note could become useful again when a different part of the system was being developed.

Source: calculation of reads and distances between conversations. A conversation distance could be determined for 1,384 of the 1,451 reads.

Fixed errors stopped coming back

In my experience, recurring errors became much less frequent. I cannot remember a case where an error that had been properly recorded in memory happened again.

Something else did happen: after I corrected the agent, it did not recognize the problem as an error and did not save it. Then the same issue could return. Once I directly asked it to add a rule to memory, those repeats stopped.

The duplicate-authentication history is a concrete example of this behavior.

I did not separately measure the percentage reduction in errors.

The work history also lets us check how often the agent read notes about errors and decisions:

The read log has a separate row for each time a file was accessed. The chart below is based on that log:

The chart counts file reads. A single file may contain several errors: by opening it once, the agent can learn about several issues at the same time. So the number of file reads and the number of error records read, counting repeat visits, are different measures.

Chart source: Cursor’s log of cross-conversation reads.

A few more tasks from the same history

In seven work episodes, the agent read an earlier note that was relevant to a new task. Before it read the note, I had not retold it the important details.

The last column shows what happened next. Some of the follow-up is visible in the logs. I confirmed the outcomes of multitenancy implementation, plan reviews, the head-of-sales portal, and PDF signing from my own work on the project.

Detailed reviews of the first three episodes are available in the corresponding case materials above.

Where I still had to step in

The two conversations that began with a detailed reminder of the past concerned the same task: renaming “Regions” to “Cities.”

In conversation 227, I reminded the agent that we had already agreed on the name and changed it in the admin interface. In conversation 249, I again said the page and element names had not changed and asked it to fix them.

I clearly had to remind it of the agreement twice. The messages alone do not show why: the agent may not have saved the decision, may not have read it, or may have left the old name on some screens.

Memory itself also needed checking. The final archive contained 300 files. We searched all of them for duplicates and found no identical record text or descriptions of the same error across different files. The automated check did find other things worth reviewing:

There were 149 findings in total. Eighteen simply flagged a decision repeated in the register and its card; the other 131 required review. For example, an old status could still be correct, and a path could point to a file intentionally kept outside Git. The findings list contains each case.

Memory needs to be kept in order. If an agreement remains only in the conversation, the next agent may not learn about it. And if a status contains a wrong conclusion, that can affect later tasks. I believe regular memory audits need to be built into future solutions.

What I would do again in the next project

1. Keep memory alongside the project. Then the next agent or another person doing the work gets both the files and an explanation of what happened with them.
2. Keep status, decisions, and history separate. The next conversation should make clear what applies now and what describes the past.
3. Start with a short map. It helps find the relevant details once the archive gets large.
4. Record the result as soon as the work is done. It is easier to remember why a decision was made, how an error was fixed, and where we left off.
5. Tell the agent what to save. If it does not record an important decision, error, or other project-specific detail, I would directly ask it to add that to memory. The agent does not always know what matters to me in this particular project.

Trying this approach is simple: you need files, Git, and instructions for the agent. Everything can be read and edited with ordinary tools. If something more complex is needed over time, it will be clear which problem it needs to solve. A little further down, I’ll explain how and when you may be able to use my work.

In conclusion: the work continues where it left off

I noticed the main change before I started counting: a new conversation no longer needed preparation. I could finish one conversation, open the next, and continue the project.

The work history contained both short requests with no recap of the past and returns to decisions months later. Files, a clear structure, and rules for reading and writing were enough.

This solution became the starting point and first layer of my work in the public 0→AGI experiment. The next question I want to solve is how to organize agents’ work so that people no longer have to manage its continuation through chat windows themselves.

Next layers of 0→AGI

Layer 01 — Yet Another AI Memory → Next: Work-Centric AI → Then: Accumulating Experience

Follow what comes next

I have already packaged this approach as a separate skill called Memomy. I plan to release its public alpha in a few days, together with the next piece about a new layer in the 0→AGI hypothesis: how to stop managing conversations and focus on tasks instead.

I created a separate Telegram chat to discuss this article and future work. That is also where I’ll announce releases of Memomy and other materials. If you are interested in the experiment, join us so you do not miss the updates.

Research details

This section lets readers check what the numbers represent.

Data and protocol

Materials for checking and reproducing the findings

Materials for checking the results are collected alongside the article:

• First requests: corpus of 272 conversations, category summary.
• Memory and reads: memory-growth statistics, reads by conversation, share of files read, volume of the main sections and reads, cross-conversation reads and distances.
• New conversations by day: activity by date, distribution across active days, and summary.
• Reproducibility: case-distance register rebuild script and package checksums.

All figures in the article were produced using the protocol I worked with in Cursor. How a more general version will perform on other platforms remains to be tested.

A redacted public copy of the materials accompanies the article; the package README documents its contents, redactions, and limits. The full corpus-recalculation script is not included because it requires non-public source data.