\n
\n I’ve been coding with AI agents for about two years. Every major one. Cursor, Copilot, Codex, OpenCode. They’re good at generating code. They all share one problem.<\/p>\n
They forget everything.<\/p>\n
You finish a session, close the window, and the agent resets. Next time you open it, you’re starting from zero. “We use pnpm, not npm.” “The database is SQLite, not Postgres.” “Don’t touch the migrations folder.” You repeat yourself. Every. Single. Time.<\/p>\n
Some tools added memory features. Usually as an afterthought. A pinned file. A custom instruction. A context window that grows until it hits a wall and everything old gets silently dropped.<\/p>\n
I didn’t want a bigger context window. I wanted an agent that accumulates knowledge the way a colleague does. Not by being retrained. By taking notes, writing down what it learned, and reading those notes next time.<\/p>\n
That’s what Jean2 can do. Not through fine-tuning. Not through vector embeddings. Through files on disk that the agent reads and writes itself.<\/p>\n
But here’s the thing: none of this is on by default. By default, Jean2 is as bare as Codex or OpenCode. A blank prompt. No memory. No skills. No session search. You opt in to each layer in workspace settings. That’s the point. You build the agent you want, layer by layer.<\/p>\n
The Four Layers<\/p>\n
If you turn them on, Jean2’s agent has four knowledge layers that persist across sessions. They’re not features bolted on top. They’re part of the system prompt that gets composed every time a session starts.<\/p>\n
1. Workspace Memory<\/p>\n
Turn on workspace memory in workspace settings, and the workspace gets two files: MEMORY.md for shared knowledge and USER.md for your personal preferences within that workspace. Both live at \/.jean2\/.<\/p>\n
The concept is simple. Shared knowledge that’s useful for any agent working in that workspace. “We use pnpm.” “The database is SQLite.” “Don’t touch the migrations folder.” Whatever agent you bring in, coding specialist, reviewer, docs writer, they all get the same context.<\/p>\n
# Workspace Memory<\/p>\n
– Build system: pnpm (not npm, not yarn)
\n– Database: SQLite via bun:sqlite
\n– Test runner: bun:test for server\/tools, vitest for client
\n– Never modify files in packages\/sdk without updating version.ts
\n– The migrations folder is managed by a separate script. Don’t auto-generate migrations.<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
The agent writes this itself. You don’t manage it manually. When it learns something worth remembering, it saves it. When it makes a mistake and you correct it, it saves the correction.<\/p>\n
It’s not fancy. There’s no vector database, no embedding pipeline. It’s a markdown file on disk. And it works.<\/p>\n
2. Agent Memory<\/p>\n
Same concept. Same two files: MEMORY.md and USER.md. Different scope.<\/p>\n
Each agent in Jean2 has its own home directory: ~\/.jean2\/agents\/\/. The memory lives there. This is where the agent evolves its role. Its specialization. Its understanding of how it should work.<\/p>\n
Workspace memory is shared context: “this project uses pnpm.” Agent memory is identity: “I am the TypeScript specialist, and here’s what I’ve learned about how Daniel likes his code.” It travels with the agent across every workspace it participates in.<\/p>\n
The agent maintains these with the agent_memory tool. Same mechanism as workspace memory, just a different relationship to the knowledge.<\/p>\n
3. Skills<\/p>\n
Same split as memory. Workspace scope, agent scope.<\/p>\n
Workspace skills live in \/.agents\/skills\/. Shared playbooks for any agent working in that workspace. “This is how we deploy.” “This is our code review process.” Whatever agent you bring in picks them up.<\/p>\n
Agent skills live in the agent’s home directory. They travel with the agent’s role. “This is how I debug TypeScript.” “This is my approach to refactoring.” They belong to the agent, not the project.<\/p>\n
Both are SKILL.md files. Procedural playbooks the agent can discover and load when relevant. The skill tool lets it read existing skills. The skill_manage tool lets it create new ones. You have to enable skill management for the agent to use them.<\/p>\n
Here’s what that looks like in practice:<\/p>\n
You’re working on a deployment issue. The agent figures out the right Docker config through trial and error.
\nAfter the third time, it notices a pattern. “Every time we deploy, I need to check these three things in this order.”
\nIt writes a deployment-checklist.md skill.
\nNext deployment, different project, different session. It loads that skill and skips the trial and error.<\/p>\n
# Deployment Checklist<\/p>\n
## When to Use
\nBefore deploying to production or staging.<\/p>\n
## Steps
\n1. Run `bun run typecheck`. Must pass.
\n2. Run `bun run lint`. Must pass.
\n3. Run `bun run test`. All suites.
\n4. Check `packages\/server\/src\/version.ts` matches changelog.
\n5. Verify the binary builds locally: `bun run build:bin`.<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
That’s a real skill from my own setup. The agent wrote it. I didn’t ask it to. It noticed the pattern and saved it.<\/p>\n
4. Session Search<\/p>\n
Same split. Workspace scope, agent scope.<\/p>\n
Workspace scope: any preconfig or agent working in a workspace can search through all sessions in that workspace. “Did someone already solve this in this project?”<\/p>\n
Agent scope: the agent can search through sessions it participated in, regardless of which workspace they happened in. “Have I seen this kind of problem before, anywhere?”<\/p>\n
One tool, session_search, powered by SQLite FTS5. Turn it on, and the agent searches its own history:<\/p>\n
“Last week I worked on a WebSocket reconnection bug. Let me search for that.”<\/p>\n
The agent finds the relevant session, reads what it tried, what worked, what didn’t. Then applies that knowledge to the current problem. Without you having to explain the history.<\/p>\n
How They Connect<\/p>\n
The four layers don’t exist in isolation. They feed each other.<\/p>\n
Memory tells the agent what to remember.<\/p>\n
Skills tell the agent how to do things.<\/p>\n
Session Search gives the agent experience to draw from.<\/p>\n
Preconfigs let you swap the brain. Different model, different prompt, different tool set. While keeping all the accumulated knowledge.<\/p>\n
The result is an agent that gets better the more you use it. Not because the model improved. Because the files got richer.<\/p>\n
Day 1 vs Day 30<\/p>\n
On day 1, your Jean2 agent is a blank slate. It knows nothing about your project, your preferences, or your workflow. It’s capable, same model, same tools, but it has no context. And it stays that way unless you choose to evolve it.<\/p>\n
On day 30:<\/p>\n
It knows your build system, your test commands, your code conventions.
\nIt has skills for recurring tasks. Deployment checklists, code review patterns, common debugging steps.
\nIt can search past sessions for solutions to similar problems.
\nIt knows your personal preferences across projects.<\/p>\n
The model didn’t change. The knowledge accumulated. On disk. In files you can read, edit, version control, and share.<\/p>\n
That is what “evolving agent” means. Not a model that retrains itself. An agent that takes notes. But only because you opted in. You could also leave it bare and it would work like any other coding agent.<\/p>\n
What’s Next<\/p>\n
Jean2 is at v1.1.0. Still in active development, but very usable. I’ve been coding with it every day for months. The agent that helps me today is noticeably better than the one I started with, because it’s been accumulating skills and memory the whole time.<\/p>\n
If this sounds interesting, try it out. Got questions about how memory or skills work? Join the Discord or hit me up at @danielbilekq0.<\/p>\n
This post originally appeared on jean2.ai. Star the project on GitHub.<\/p>\n