June 2026 - In 2025 I hacked together a markdown-file solution to avoid re-explaining my context every session. It worked. Up to a point. Here is why I ended up building something different.
The problem, still very real
You know the scenario.
Session 1:
- You: "I'm working on a FastAPI API with MySQL, deployed on a VPS..."
- The AI: understands everything, codes perfectly.
Session 2, the next day:
- You: "Continue yesterday's work."
- The AI: "I don't have context on your project. Could you describe..."
- You: π€
This is not a bug. It is the nature of LLMs: zero memory between sessions. Every conversation starts from scratch.
With a complex project (API, frontend, Docker, VPS, multiple repos), re-explaining the context takes 10 to 15 minutes per session. Over a week: an hour lost. Over a month: a full day of work gone.
And the worst part: it is not the code that evaporates. It is the why. The decisions, the traps you avoided, the paths you dropped. Exactly what separates "it compiles" from "it is maintainable."
My first answer: the /AI/memory/ folder (2025)
A DIY solution. One folder per project:
my-project/
βββ AI/
β βββ memory/
β βββ project_context.md
β βββ tech_stack.md
β βββ code_registry.json
At session start:
"Read the files in
/AI/memory/to load the context."
Thirty seconds. The AI knows the project, the conventions, the architectural decisions. It worked.
For months I ran like this. Multiple repos. Multiple folders. Markdown everywhere. Then the cracks showed up.
The limits: why DIY is not enough
Manual maintenance
Every new endpoint, every architecture decision: you have to remember to update the files. When you juggle between sessions, especially with a brain that jumps from topic to topic, "do not forget to update" is precisely the starting problem.
Drift
A few weeks later, the markdown describes an architecture that no longer exists. The AI works from stale information. You do not always notice until the prod bug or the incoherent PR.
Copy-paste persists
You ask the AI to read local files. Or you copy the JSON yourself. It is not fluid. It is not reliable. And it does not scale when you go from one repo to four.
Fragmentation
docksky-api, docksky-web, tda-assistant-ui, infra... Each repo its own /AI/memory/ folder. No overview. Impossible to switch context without reloading manually.
Verdict: the method treated the symptom, not the cause. Context lived in dead files, updated when I thought of it. That is, not often enough.
MCP: what changes the game
In 2025, Anthropic published the Model Context Protocol (MCP): an open standard for an AI agent to interact with external data sources in a structured way.
Before:
"The AI reads files I prepared."
After:
"The AI calls tools and interacts directly with my knowledge base."
It reads context. It writes a note. It creates a journal entry. Without my intervention. No copy-paste. No asking whether I remembered to update the markdown.
The difference is not just technical. It is structural. Context is no longer a static file. It is a living system.
What I built: DockSky
I answered the problem by building DockSky. Not another chatbot, but a shared external brain between me and my AI.
A desktop app plus MCP server. When Cursor or Claude connects via MCP, the agent gets native tools to:
- list my projects
- load a specific project's context
- read my facets (decisions, traps, patterns, technical info)
- create a journal entry
- update an action or a step
Two complementary layers:
| Facets | Journal | |
|---|---|---|
| What | What is worth keeping | What I did, day by day |
| When | Thematic, long term | Chronological |
| Example | TRAP: missing UpdateSourceTrigger on this binding |
"Fixed login bug, tested on staging" |
The base is persistent. It is the same one I use daily in the app. When the AI notes a decision, it writes where I will find it tomorrow, not in a forgotten markdown file at the bottom of a repo.
Concrete results (dogfooding, several months)
- Starting a session on an active project: under 30 seconds
- The AI no longer asks "remind me of the architecture"
- Decisions from one session are available in the next
- Zero markdown files to maintain by hand
- Git commits feed the journal automatically (post-commit hook)
It is not magic. It is discipline reinforced by the tool: one point done, one trace in DockSky, move to the next. Tech does not replace the habit. It makes it cheaper.
What I learned
- AI memory is not in the model β it must be structured and reloadable.
- Local markdown = good prototype, bad product β human maintenance is a guaranteed failure point.
- MCP = the right level of abstraction β standardized tools, not artisanal copy-paste.
- Intent over code β what matters is capturing the why as you go, not archiving 400 KB of transcript.
A recent dev.to post put it better than I could: "Agents write code, but they don't remember." Exactly. Generation is solved. Context persistence is not.
The minimal workflow (no DockSky required)
1 specific point β done β 2 lines of trace β next
A journal. A decisions file. Even a DECISIONS.md README. What matters: do not let intent evaporate.
DockSky is that workflow turned into a system.
Does this problem sound familiar?
DockSky is a project I am building because I needed it: a brain that jumps, multiple repos, AI sessions that restart from zero every time.
I am not looking for customers. I am looking for people who recognize this story and want to co-build, not just use a tool.
What I am offering
The crew (Γquipage): a private space (Discord plus Pro access while we build) where we talk about product direction. Sort ideas. Make design calls. Say what works or blocks in real usage. Not a support channel. A kitchen where founders think before anything goes public.
You do not need to be an expert at everything. What I care about:
- you live the same context / AI memory problem;
- you want to contribute: field feedback, code, docs, UX ideas;
- you accept we are building, not shipping a finished product.
What this is not
- Not a "download for free" pitch
- Not an obligation to test X hours per week
- Not open enrollment. The crew opens by invitation, after I read your application
How to reach me
If this article resonated, get in touch. Comment here, or apply at docksky.fr/equipage.
Tell me what hooked you and what you would want to bring to the table. No marketing funnel. I read every message myself.
No commitment. Just see if we speak the same language.
How do you handle AI context between sessions today: markdown, rules files, something else? I would genuinely like to hear in the comments.
Top comments (2)
One architectural split that helped me: separating episodic memory (conversation turns, what was tried in what order) from semantic memory (project facts, preferences, reference context). For the episodic side I use LangGraph's Postgres checkpointer attached to the graph state -- it means the agent resumes exactly where it left off without loading all prior turns into the MCP call at session start. The MCP tool layer handles semantic retrieval on demand. The risk of putting everything into a single knowledge base is that episodic context comes back without temporal ordering guarantees, and that ordering matters when the agent needs to understand what was attempted in what sequence.
Thanks for this comment, it landed at exactly the right time.
I'm on this thread to learn, not to pitch a finished solution. Every exchange like yours helps me mature DockSky and fill the gaps. This one in particular clicked: the episodic / semantic split is something I was already living without naming it this clearly.
What we already have:
What was missing (and what your message clarifies): a middle layer, not the full conversation history, not frozen facts either, but "where we are right now on this project", with the ordering that matters when picking back up without reloading everything.
We actually have a field for that on the project side (
current_status, a Markdown "where we are" note). It's in the app, but not wired enough into the MCP protocol yet: the AI loads facets well at session start, not yet this episodic anchor per project. That's a gap I intend to close.Next building block:
current_statusin the project context loaded via MCPYour LangGraph checkpointer, we're not reproducing it as-is (external MCP client, not an integrated agent graph), but the intent is the same: resume in the right place without re-injecting the full history at every session.
Does this approach sound coherent from your side? And I'm curious: do you keep episodic checkpoints indefinitely, or prune once you've extracted the semantic layer?