AI, My Extremely Knowledgeable, Terribly Forgetful Coworker

AI tools are amazingly powerful and can absolutely help you move faster. LLMs have an unimaginable amount of information and capability available to them when answering your questions. Unfortunately, they also have the memory of a goldfish. Not because the model isn't capable, but because it only sees what's in its current context.

Today, I'd like to share some of the pain I've encountered while working with AI on a daily basis, how I solved some of my biggest pain points, and how that solution speaks to general best practices that are emerging in the industry.

To begin, let me describe a scenario that occurred to me a few months ago. In the morning, I picked up a new story and spent some time analyzing it. Then I opened VS Code and the Copilot extension and started giving Copilot some details about what we were going to be working on in the story. I also gave Copilot a checklist of the tasks to be accomplished:

Add a new field to the model class and update indexes that need to query the field
Add a new field to the schema class and update schema population functions
Add unit tests for the new field validating population and retrieval
Update the infrastructure-as-code deployment stack with the database index changes

Copilot seems to understand the plan, so we start working. Copilot and I work all day making changes and finish up making the unit test changes. I tell Copilot,

"Great work today! I think we've made all of the changes we need. Can you go back over our task checklist and verify we covered everything?"

Copilot's response?

"What task checklist? I don't know about a task checklist."

Cue ominous music. Copilot has basically forgotten what we talked about that morning. Now that might be an oversimplification but that's what it feels like as the user. In this scenario, I could scroll all the way to the top and find that list for myself. Which is good because, if you didn't catch it, I had missed a critical final step on my example checklist. So, I wasn't dead in the water, but it wasn't the smoothest of interactions.

And the forgotten checklist wasn't a one-off. I often had to re-state coding conventions, remind the agent to update parallel files, and re-explain decisions when returning later to the same story. Even resuming an old chat only got me part of the way back. The details that mattered most still had to be reconstructed. This feels inefficient. If I have to keep re-explaining things, the value of the tool starts to disappear.

The Problem

The primary issue comes down to the context window. Copilot and Claude have a limit of how much information they can hold "at the ready" at one time. When conversations get long, the system may compress or summarize earlier parts of the conversation to stay within context limits. When this happens repeatedly, important details can be lost. Also, as the conversation grows, you're consuming more and more tokens with each request as you drag along more and more context with you.

This leads us to another failing of the context window: it is unstructured. That is strongly illustrated in my example of coming back to work on a story a few days later. If you try to resume a previous chat session you're going through the summation process again, but on steroids. The agent reads back in the entire chat session and tries to pull out the important bits so you're kind of left with a summary of a summary of a summary. The agent has to infer what's important, which doesn't always match what you consider important. Not only that, but you start the resumed session with a huge context load that costs more tokens/credits.

My Solution - The Reusable Context Pattern

After encountering this scenario one time too many, I decided to improve my workflow. I call it the "Reusable Context Pattern" and it is a simple way to give AI agents structured context they can reuse across sessions. This isn't the only way to structure AI workflows, but it's a simple pattern that has worked well for me and produced reliable results. It features these core concepts:

the agent is given detailed, well-structured information up front
that information and all context is held in persistent storage that the agent can access, rather than being limited to the chat session
the agent keeps the context updated throughout the work session with decisions made, assumptions, progress, etc and does so in a structured format
when work needs to resume the agent reads the context from persistent storage and is able to resume the work session seamlessly and with minimal reminding

This creates a lightweight workflow that mirrors ideas used in more advanced AI systems, like external memory and explicit task state.

I use stories as my primary unit of context, so I'll talk in terms of story files, but the same pattern could work for specs, bugs, features, or investigations.

Storage

I decided that the easiest way to store this context would be in files, one for each story/effort. Where the files get stored is optional and should be decided by your team. Ideally the files should become part of the repository so that they are backed up and another developer can pick up the story if needed. If that is not desired there are other options.

For Copilot, I stored them in the repository and used a simple entry in the .gitignore to keep them from being committed. Claude has a working directory that it can use that is outside of the repository folder but still separated by project. Exactly where you store them is your choice. What matters is that the agent can read and update them, and that you can reliably find them later.

Structure

As I stated above it is critical that the information in story files is structured. Below is the basic structure I follow for story files. Not all of it is filled out by me, however. I start with some sections and the agent fills others out as we go.

# Story NNN: [Title]

## Overview
[2-3 sentence description]

## Background
[2-3 paragraphs with details about bigger picture]

## Tasks
- [ ] ...

## Known Issues / Blockers
- [ ] ...

## Key Files
- [ ] ...

## Key Decisions
- [Decision and rationale — add entries as decisions are made]

## Progress
### Done

### In Progress

### Remaining

This structure is organized and human readable. Both the agent and I should be able to read, understand, and update the document easily. Again, massage this structure as needed. This is just what worked for me in general.

Capturing key decisions is especially important because AI systems can lose track of earlier reasoning and unintentionally contradict prior choices. It also gives me information for when someone invariably comes and asks why I chose XYZ path on a task I did two months ago. As AI does more of the hands-on work, our own memory of the details can get fuzzier too, so this helps keep both the agent and me informed.

Instructions Files

Keeping the story file updated is a critical part of the process. I want the agent to manage that so I provide entries in the instructions files. The instruction file defines how the workflow operates. The story file captures the state of the actual work. I use entries in my personal instructions files to inform the agents that story files exist, where to find them and what the expectations from the agent are. Some agents are better at adhering to instructions files than others without prompting but the instructions need to be there for the agent to use. Below is the section about story files from my Claude user-level instructions file.

## Story Context Management

Story tracking files live **outside the repo** to avoid git pollution and
merge conflicts:
```
%userprofile%/.claude/projects//stories/story-NNN.md
```

### Story file format
```markdown
# Story NNN: [Title]

## Overview
[2-3 sentence description]

## Background
[2-3 paragraphs with details about bigger picture]

## Tasks
- [ ] ...

## Known Issues / Blockers
- [ ] ...

## Key Files
- [ ] ...

## Key Decisions
- [Decision and rationale — add entries as decisions are made]

## Progress
### Done

### In Progress

### Remaining

```

### Claude's responsibilities
- **At session start**: When user says "resume story NNN," find and read the story file
  before asking any clarifying questions
- **During work**: Proactively update the story file when decisions are made or tasks
  completed — do not wait to be asked
- **Suggest creating one**: When starting a new story branch, suggest creating a story
  file if one doesn't exist
- **Supplement with git**: Read `git log --oneline` and `git diff ...HEAD` to orient
  quickly when resuming

### Switching stories
User will say "resume story NNN" or "switch to story NNN." Read the appropriate story
file and summarize current state before asking where to pick up.

Planning Mode

Some tools, like Claude, offer a planning mode that generates a step-by-step approach before implementation. This is an incredibly useful feature that helps break down the work, identify dependencies, and devise an approach before writing code. However, planning is only one part of the big picture. This pattern isn’t meant to replace planning mode, but to extend it beyond the initial planning phase.

A plan captures what you intend to do. It doesn’t reliably capture what has actually been done, what decisions were made along the way, and what changed during implementation. That’s where the story file comes in.

The plan is an important starting point, but it’s not the full picture of the work as it evolves. The plan helps define the work up front, and the story file becomes the persistent source of truth as the work progresses. In practice, I often use planning mode to generate an initial plan, then copy or adapt that plan into the story file. From that point on, the story file is what gets updated as work progresses, while the original plan may become outdated.

Workflow

Compile the starting information for the story. Before I can communicate the details to the agent I have to compile them. Some of this may be able to be retrieved from the story documentation but the information must be gathered prior to starting work.
If I'm using an agent that has a planning mode or function, I use it to develop a plan and generate the initial version of the story file. Otherwise I conduct a chat-based planning session with the agent and generate the story file.
Make certain that the agent and I both understand what we're going to be doing and that all of the questions are addressed up front before we start work.
Work the plan starting new chat sessions often. Now that context is being stored in the story files I don't have to worry about starting a new chat session. As I wrap up a chat session I let the agent know and remind it to update the story file if it hasn't already done so. When I start the new session I tell it to resume story #123 and the agent reads the file and picks up where we left off. This gives me the confidence to close chat sessions at the end of a day, for example, and start with a fresh session in the morning without losing context. This helps the agent stay focused and prevents me from burning tokens unnecessarily.
Wrap up the session. Once I'm done with work on a story I'll let the agent know that we're wrapping up and to make any final updates to the story file.
Rework. If I need to pick up the story for some reason, e.g. addressing PR feedback, I resume the story just like I describe above and wrap up at the end as discussed.

Context Engineering vs Prompt Engineering

What I'm really doing here is shifting some of the work from prompt engineering to context engineering. Prompt engineering focuses on how you ask. Context engineering focuses on what the agent knows before it answers. Story files, instruction files, and planning artifacts all contribute to that context. In practice, that often matters more than the wording of the prompt itself.

For example, imagine asking an agent, "Add a new field to this model and update everything that depends on it."

If all the agent has is that prompt and a few recent messages, it has to infer:

which files matter
how the system is structured
what conventions to follow
what decisions have already been made

Now compare that to the same prompt with a story file.

The agent already knows:

which files are relevant
what changes have already been made
what constraints and decisions exist
what remains to be done

The prompt didn't change, but the context certainly did and the quality of the result changes dramatically. If prompt engineering is about asking better questions, context engineering is about making sure the agent is in the right room before you even ask.

Conclusion

Just because AI knows a lot doesn't mean it can read your mind or infer what matters most from a pile of unstructured information. Rather than using word vomit as your default way of interacting with an agent, take some time to structure the information and provide it in a way that is clear and easy to consume; just like you would with a human.

This approach does add some overhead, especially early in a task, but I've found the payoff in reduced re-explaining and more consistent results is worth it. Your agent coworker knows a lot but needs hand-holding to keep it working efficiently.

The Reusable Context Pattern boils down to three things:

Store context outside the chat
Structure it so both you and the agent can use it
Keep it updated as work progresses

Once you do that, you stop relying on the model to remember and start giving it the context it needs to do good work.