How I Stopped Starting Over With AI

The four levels that turned my AI into a system that remembers my work, carries more of the load, and improves over time.

A few months ago, my AI system corrected me about a decision I was certain I had already settled. I described the matter one way, and it surfaced a note I had written weeks earlier saying the opposite.

I stared at it for a moment, trying to remember when my thinking had changed. I couldn’t. I had forgotten the conversation. The system had not.

What stayed with me was not simply that it had found an old note. It was the uncomfortable realization that, in that moment, it held a more reliable record of my own thinking than I did. That was when I stopped seeing AI as something I occasionally asked for help and began to understand what it could become around my work.

For months, I believed becoming better at AI meant learning to write better prompts. I asked clearer questions, provided more context, and became faster at getting useful answers. But every new conversation still began in roughly the same place. I explained myself again. I supplied the same preferences again. I reconstructed decisions the AI had already helped me make. I was using AI every day, but I was still starting over.

The real change began when I stopped thinking only about what I could ask the model and started thinking about what I could build around it.

Four levels of using AI

Looking back, that progression happened in four distinct levels. Each level changed more than what the technology could do. It changed what I was capable of doing with it.

These levels are not a scientific maturity model, and people may develop some capabilities before others. Think of the following as a kind of sequence through which my own system evolved in regard to progressing from prompts and workflows to knowledge bases, agents, and self-improving AI systems.

Over the last few months I’ve been building a personal AI system on top of Claude Code — a memory that consolidates and grades itself, agents that do the grunt work while I steer, tools I built by reverse-engineering existing systems.

Each one unlocks something the one below can’t reach, and the jump between them is a change in how you think about the tool, not how much you use it.

Level 1: You get help, then start over

At this level, AI lives inside a chat window. You open it because you need something in the moment. Summarise this report. Draft a response. Explain the difference between two ideas. Within a few minutes, you have something useful, close the window, and continue with your day.

Then you return tomorrow with another task.

The AI does not remember why you rejected an earlier option, how you prefer your reports structured, or what a good answer looks like in the context of your work. Before it can help, you have to rebuild the scene. You explain who you are, what you are working on, what matters, and how you want the answer presented.

It is a little like working with a brilliant assistant who arrives every morning with no memory of the day before. For ten minutes, the assistant can be remarkably helpful. But once the conversation ends, most of the working context disappears with it.

After a while, the repetition becomes difficult to ignore. You notice that you keep typing the same background, the same preferences, and the same instructions. That repetition is the first sign that the work is ready to change form.

Instead of explaining the process again, you begin preserving it. That is where Level 2 begins.

Level 2: You turn repetition into a system

For me, Level 2 began with a pile of bank and credit-card statements. Each month, I opened a new chat, uploaded the documents, and explained the same rules. Exclude transfers between my own accounts. Separate personal spending from business expenses. Flag anything that could not be classified confidently. Do not quietly discard a transaction just because the PDF was difficult to read.

The AI could do the work, but only after I had reconstructed the process around it. I was not analysing my expenses so much as repeatedly training a temporary assistant to analyse them. Eventually, I took the instructions out of the conversation and gave them a permanent home.

I created a reusable skill: a folder containing the rules, the expected report format, and a small script for extracting transactions from the statements. Now, when I run the expense tracker, the system already knows what to look for. It applies the same exclusions, follows the same categories, and produces the same structured report. When it cannot process something confidently, it flags the problem instead of allowing information to disappear silently.

The model did not change. The process around it did. That is the defining shift at Level 2. The prompt you once reconstructed from memory becomes a reusable command. The writing preferences you kept explaining become standing instructions. The steps you performed manually become tools the AI can call when the task requires them.

You are no longer relying on the quality of one conversation. You are designing the conditions that make a good result more likely every time.

This is what people mean by context engineering. Andrej Karpathy described it as the art and science of placing the right information inside the context window for the next step. In practice, it means deciding in advance what the AI should know, which instructions should remain fixed, what tools it should have available, and what a successful result should look like.

The workflow waits until you call it. It follows the instructions you preserved, but it does not extend them. It can use the tools you gave it, but it does not question whether the boundaries of those tools are the real boundaries of the work. And although it can repeat what you designed, it does not yet build on what it learns from one task to improve the next.

Once the process is stable, a different question begins to surface: What else could this system reach, remember, or accomplish if the interface in front of me were no longer the limit? That question opens Level 3.

Level 3: You give the system reach and memory

By the end of Level 2, the work has become repeatable. The instructions are saved, the tools are available, and familiar tasks produce familiar results.

But stability creates a new kind of frustration.

You begin to notice that the workflow can only operate within the boundaries you have been given. If an application has no button for the action you need, you assume the action cannot be performed. If the information exists across scattered documents, messages, and old decisions, you continue gathering it by hand.

Level 3 begins when you stop treating those visible boundaries as the limits of the system.

For me, that happened while using an internal web tool that required the same edit to be made a few hundred times. The interface allowed me to change one item at a time. There was no bulk-edit button, no import option, and no obvious shortcut. The work appeared simple, but the screen had turned it into several days of clicking.

I made one edit manually and watched what happened behind the page. When I clicked the button, the browser sent a request to the underlying system. The interface could only send that request once, but there was no reason another authorised tool could not send it repeatedly.

I asked the AI to help me write a short script using my existing access. The script sent the same request across the full list of items. A job that had looked like days of repetitive work was completed in about an hour.

Nothing new had been added to the original system. The capability had always been there. It simply had not been presented as a button.

That changed the way I looked at software. The screen was no longer the product itself. It was one doorway into a larger system underneath. Once I understood that, I could ask a better question: not only, “What does this tool allow me to do?” but, “What is the underlying system capable of doing if I connect to it differently?”

The same shift applies to information. At Level 2, the AI follows a repeatable process. At Level 3, it also begins carrying forward what the process teaches you.

I created a simple folder of notes. There was no elaborate architecture: one file for a person, another for a project, another for an important decision. But each note captured more than the final answer. It recorded why the decision had been made, which alternatives had been rejected, what assumptions were still uncertain, and what might cause the decision to change later.

The AI could read those notes before beginning a related task. Instead of asking me to reconstruct the history, it could begin with the history already present.

At first, the folder was too thin to make much difference. After several weeks, however, the effect became noticeable. New work no longer began at the same starting line. A correction made during one task could influence the next. A decision recorded in one month could reappear when it became relevant in another.

Then came the moment when I started telling this story. I described a decision as settled, and the system surfaced a note showing that I had previously recorded the opposite. I had forgotten the reasoning. The system had retained it. That is what accumulation looks like in practice. It is not simply storing more information. It is preserving enough of the thinking behind your work that future tasks can begin with what you have already learned.

At this level, the system starts to possess something an off-the-shelf model cannot: your working history. It knows the terminology your team uses, the decisions you have made, the exceptions you have discovered, and the reasons certain options were abandoned. Its usefulness becomes increasingly specific to you because the knowledge around it continues to grow. But the growth is still dependent on you.

You decide which insights deserve to be saved. You correct the notes when circumstances change. You remove outdated information, settle contradictions, and decide what should become part of the permanent record. The system can draw on accumulated knowledge, but you are still the person tending it.

Eventually, that maintenance becomes the next constraint. If the system can use its memory, could it also help decide what deserves to be remembered? Could it examine its own work, recognise recurring patterns, and show whether its performance is improving? That is the question that leads to Level 4.

Level 4: You build loops that learn

At Level 3, I had given the system a memory. But I was still its librarian. I decided what deserved to be saved, updated notes when circumstances changed, removed information that had become irrelevant, and watched for contradictions. The system could draw on what I had learned, but its knowledge remained useful because I kept tending it.

Level 4 began when I started building loops around that work.

The first runs every morning before I wake up. It reads the sources I have authorised it to access, including my email, calendar, and messages. It filters routine updates, groups related information, and prepares a short briefing containing only the items that appear to require my attention or a decision.

Instead of beginning the day by opening several applications and searching for what matters, I begin with a prepared view of the day.

This is the execution loop. It takes a process with a clear beginning and end and carries it through on my behalf. I still decide what the system may access, what it should ignore, and which actions require my approval. What changes is the amount of the process I have to carry myself.

But a process can run perfectly on schedule and remain unchanged for months.

The morning briefing could appear every day without ever noticing that it repeatedly included messages I ignored, buried decisions I needed to see, or relied on assumptions that were no longer true. Regular execution creates consistency. It does not, by itself, create improvement.

That work belongs to a second loop.

At the end of each week, the system reviews the work it helped produce. It looks for decisions, corrections, and explanations that appeared repeatedly. Information that continues to shape the work can be promoted into longer-term notes. Material that appears temporary can be marked for pruning. When the same task keeps returning, the system can turn the method into a reusable procedure rather than reconstructing it each time.

It also examines whether its memory was useful when the moment arrived.

The system selects a sample of earlier tasks and checks whether the relevant context appeared. Did it retrieve the decision that should have shaped the answer? Did it overlook something I had already recorded? Did it surface an old instruction after a newer one had replaced it?

Those results become a score I can compare from one week to the next. When the score falls, I can trace the failure back to what the system stored, how it labelled the information, or how it searched for the right context.

That is the point where repetition begins to compound.

A system that only executes performs the same process again. A system with a learning loop allows the outcome of one run to influence how the next one is handled.

The underlying AI model is not retraining itself or quietly becoming more intelligent. Today’s foundation models do not generally carry their learning from one session into the next. The change happens in the structure around the model: the knowledge it preserves, the context it retrieves, the procedures it reuses, and the way its performance is measured. Level 4 is therefore not simply Level 3 running on a schedule.

The system is now helping to maintain the conditions that make its future work more useful. It still operates inside boundaries I define, and consequential changes still require oversight. But I am no longer the only one noticing patterns, organising what was learned, or checking whether the system is becoming more reliable. The work now moves through a cycle: perform, observe, evaluate, adjust, and return to the work with more than it had before.

What are you still carrying?

Looking back, these four levels tell the story of what I gradually stopped carrying by myself.

At Level 1, I carried the context. Every useful conversation depended on me remembering what to explain, which decisions had already been made, and what kind of answer I needed.

At Level 2, I began moving repeated processes out of my head and into the system. The instructions stayed. The format stayed. The tools were ready when the work returned.

At Level 3, I stopped allowing useful knowledge to disappear at the end of a task. Decisions, corrections, and the reasoning behind them began to accumulate. New work could start with some memory of the work that came before it.

At Level 4, I was no longer the only person tending that memory or examining whether the system was becoming more useful. The work could run, produce evidence about its own performance, and influence how the next cycle was handled.

Seen this way, the levels are not really a ranking of how advanced someone is with AI. They are a way of noticing where useful effort continues to evaporate. So the most revealing place to look may not be your list of AI tools. It may be an ordinary week of work.

Where are you still explaining the same background? Which process depends on you remembering every step? What decisions keep disappearing into old conversations? Which recurring task produces an answer but leaves nothing behind for the next time it returns?

The answer may place different parts of your work at different levels. You might have one sophisticated system that operates with memory and feedback, while most of your daily AI use still begins inside an empty chat window. That is normal. Not every task deserves to become a permanent system.

The better question is which repeated work is valuable enough that starting over has become wasteful.

For me, progress with AI did not come from finding one perfect prompt or handing everything to an autonomous agent. It came from noticing where I was repeatedly supplying the same thought, judgment, or effort, and then building a way for that work to remain.

The models will continue to improve. But the part that becomes distinctly yours is the structure built around them: the instructions you preserve, the knowledge you carry forward, the boundaries you define, and the loops that allow experience to shape what happens next.

Many thanks to Tremis Skeete, Executive Editor of Product Coalition, for his invaluable contributions to this story. A special shout-out to founder Jay Stansell for creating an environment that enhances product management education.