The AI Forgot My Instructions.
AI may not have forgotten your instructions. They may be stored in the wrong place. Why persistent project rules need more than a conversation to survive.
Except It Didn't.
by Prateek Sharma, MCA and Jana Diamond, PMP
Prateek's Story
I had rules.
Very specific rules.
Drop-in complete files. No unrequested refactors. Additive changes only.
These weren't suggestions I wanted the AI coding assistant to consider when convenient. They were working constraints for production code.
And I told it.
Then, later in a long session, it would wander away from one of them.
I'd already said not to refactor that code.
I'd already explained the constraint.
I'd already made the decision.
Why was I having to say it again?
My assumption was pretty straightforward:
The AI forgot my instruction.
Then I learned something that changed the way I thought about the problem.
The instruction wasn't necessarily wrong.
The model wasn't necessarily the problem.
The instruction might simply have been in the wrong place.
Jana's Story
I had rules, too.
Boy, did I have rules.
I use AI for work that can stretch across hours, days, and sometimes weeks. Proposals. Blogs. Documents. Images. A book.
And I had accumulated an instruction set to go with all of it.
Don't use this wording.
Use this terminology.
Refer to the document.
Don't invent information that isn't in the source.
Don't change things I didn't ask you to change.
For images, the instructions could get downright ridiculous.
Don't change the face.
Don't change the hair.
Don't change the body.
Change this one thing.
I'd give Chat a reference image and tell it to freeze everything above the mouth while changing only the jawline.
Next image?
Lovely new jawline.
Completely different face.
What?!
So I'd make the instruction stronger.
Then I'd repeat it.
Then I'd put it in the permanent instructions.
Then I'd repeat it in the prompt anyway, because by then I trusted the instruction set about as far as I could throw it.
And I’ve been known to toss that evil, evil, evil printer out the window at passing cars. Metaphorically speaking, of course.
With documents, I got even worse.
I had "Refer to the document" in my instruction set no less than three times, and I was still starting prompts with:
Open the document.
Read the document.
Tell me you read the document.
If you don't still have the document, tell me to reload it. Do not invent answers.
At some point, you've got to wonder whether you're working with an advanced AI system or trying to get a two-year-old to put on shoes.
My diagnosis was the same as Prateek's.
The AI forgot my instructions.
Except "Forgot" Wasn't Quite the Right Word
Prateek found the clue while learning how his coding assistant managed context.
Some information was loaded from persistent project files. That information could be loaded again as the session changed.
Other information existed only because it had been said during the conversation.
As a long conversation was compacted or summarized, those conversational details didn't necessarily survive with the same specificity.
That gave him a much better way to describe what had been happening:
"Claude forgot my instruction" stopped being a mystery and became a placement bug.
That distinction matters far beyond Claude.
Different AI tools handle memory, context, project instructions, uploaded files, and persistent information differently. There isn't one universal place where every instruction should live.
But there is a universal question:
Does this information need to matter right now, or does it need to keep mattering later?
Those aren't the same requirement.
Some Instructions Are Conversation. Some Are Infrastructure.
"Look at this error message" belongs in the conversation.
"Use this terminology throughout the project" probably shouldn't depend on whether the system still has a particular message from three hours ago available in useful detail.
The same goes for:
Project conventions.
Source-of-truth documents.
Writing rules.
Architecture constraints.
Definitions.
Decisions that affect everything that comes afterward.
If the information is important enough that the AI must keep using it throughout the work, repeating it louder isn't much of a strategy.
Neither is typing it three times.
Ask me how I know. 😉
The better question is whether the tool provides a more durable place for that information: project instructions, memory, configuration files, reference material, or another persistent source.
That's where the instruction has a better chance of surviving the work.
Persistent doesn't mean guaranteed. It means the instruction isn't depending entirely on the conversation to survive.
We Were Treating Conversation Like Configuration
That's the part neither of us had recognized.
We knew some instructions were important.
We just assumed that telling the AI made them durable.
It doesn't necessarily work that way.
A conversation is excellent for the work happening now. It's where we ask questions, examine results, change direction, test ideas, and make temporary decisions.
But some information isn't part of the conversation.
It's part of the operating environment.
And when we put operating rules into a place designed for an evolving conversation, then get annoyed because they don't behave like permanent configuration . . . well, we may be yelling at the wrong thing.
Prateek moved his recurring coding constraints into persistent project instructions.
I started paying much closer attention to what belonged in permanent instructions, what belonged with the source material, and what I still needed to verify during the actual work.
Neither approach makes AI infallible.
That's not the point.
The point is knowing what kind of problem you're trying to fix.
Because sometimes the AI didn't forget your instruction.
You left it somewhere temporary and expected it to stay put.
Originally published on Protovate.AI
Protovate builds practical AI-powered software for complex, real-world environments. Led by Brian Pollack and a global team with more than 30 years of experience, Protovate helps organizations innovate responsibly, improve efficiency, and turn emerging technology into solutions that deliver measurable impact.
Over the decades, the Protovate team has worked with organizations including NASA, Johnson & Johnson, Microsoft, Walmart, Covidien, Singtel, LG, Yahoo, and Lowe’s.
About the Authors
Share article
