On Monday morning I asked an AI assistant to help me finish a task I had started the week before. The answer came back in seconds, it was well written, and it was wrong. The approach it recommended was the one my team had dropped on Thursday, in a message thread the assistant had never seen.
The model did its job. It answered from the information it had, and that information was a week old.
I am a full stack developer, and I also support a product called Pryveo that works on this exact problem, so I have spent a lot of time looking at how developers deal with it. This post covers why it happens, how to spot it, a fix you can apply today with a plain Markdown file, and where that fix stops working.
Why a good model still gives an outdated answer
A model only knows two things: what it learned in training and what you put in front of it. Your project lives in neither place by default.
The current state of real work is spread across tools:
- the decision made in a Slack thread
- the requirement changed in a Notion page
- the ticket updated in Linear
- the feedback that arrived by email
- the reason behind a choice, which often lives only in someone's head
Every new chat starts without any of this. You either paste the background in again or the assistant fills the gap with a reasonable guess. A reasonable guess based on last week's facts reads exactly like a correct answer, which is what makes this failure hard to notice.
Five signs your AI is working from old context
- It suggests an idea you already rejected. The rejection happened in a conversation it never saw.
- It plans around an old deadline or scope. The date moved, and the assistant still has the first version.
- You re-explain the project at the start of every chat. The first ten minutes go to background before any real work starts.
- Its answer conflicts with the latest feedback. The client or reviewer changed direction and the assistant is still following the earlier one.
- It cannot tell you where an answer came from. Without a source, you have no quick way to check whether the answer is current.
If two or more of these feel familiar, the problem is in your context and a different model will not solve it.
A fix you can apply today: a decision log in the repo
The developers I have spoken to who handle this well all do some version of the same thing. One points every new chat at a folder of notes. Another finishes and tests each task before stopping, because he never knows when he will be back. He told me his last commit was 28 days old when he returned to a side project, and that habit is what let him continue.
The simplest version is a single file at the root of the repository:
# CONTEXT.md
## Current goal
Ship the invoice export by Friday. CSV only, PDF is out of scope.
## Decisions (newest first)
- 2026-10-02: Dropped the queue-based approach. Export runs inline because
files are small. Decided in the team thread after load testing.
- 2026-09-29: Dates are stored in UTC and formatted in the client.
## Rejected ideas
- Streaming the export: adds complexity we do not need at this size.
## Open questions
- Does the finance team need a totals row?
Three rules make this file useful:
- Write the reason with the decision. "Dropped the queue" helps less than "dropped the queue because files are small".
- Keep a rejected ideas section. This is the section that stops an assistant from proposing the same thing again.
- Update it before you stop work. The moment you close the laptop is the moment the context is freshest.
Then start each session by giving the assistant this file first. The quality of the answers changes immediately, because the assistant is now working from this week.
Where the manual fix stops working
I use this approach and I recommend it. It also has clear limits.
- It depends on discipline. The file is only as current as your last update, and the weeks when you most need it are the weeks you are too busy to maintain it.
- It covers one person. A decision made by a teammate in a thread you were not part of never reaches your file.
- The context is not all in the repo. Client feedback, meeting outcomes and changed priorities live in other tools.
- It raises a permission question. Once you start feeding an assistant more context, you have to decide what it should be allowed to see. A notes file gives you no control beyond what you choose to paste.
That last point matters more as teams adopt agents. Memory for AI is partly a storage problem and largely a permissions problem: someone has to decide what gets remembered and what gets shared.
How Pryveo approaches the same problem
This is the gap the Pryveo team is working on. The idea is to keep approved context ready, so you and your AI can pick up where you left off.
A few parts of the design are relevant to the limits above:
- You approve the sources. Pryveo works from the places you choose, such as Slack channels, Notion pages, Linear projects, documents, forwarded mail, calendars and local device folders. It updates within those boundaries.
- Answers show their source. A "Why I know this" trail shows where an answer came from, which addresses the fifth sign in the list above.
- Private context stays private. When people work toward a shared goal, an invite carries the shared context and not anyone's private memory.
- You stay in control. You can correct, forget, pause, or share only what you choose.
One honest limit applies to any tool in this space, including this one: if a decision was never written down anywhere, nothing can retrieve it. The habit of recording the reason behind a decision still matters.
You can see how it works at pryveo.com.
What does your setup look like?
I am collecting the ways developers keep their AI tools current, and the answers so far are more varied than I expected. How do you bring an assistant up to date at the start of a session: a notes file, a rules file, pasted threads, or something else?
Top comments (1)
I will start. My own setup is a CONTEXT.md file at the repo root with a decisions section and a rejected ideas section, and I give it to the assistant at the start of each session.
The part I still struggle with is decisions made in threads I was not part of. How do you handle that on a team?