DEV Community: Dana from PeKG

Why AI Coding Agents Forget Everything Between Sessions (And How to Fix It)

Dana from PeKG — Thu, 16 Apr 2026 16:46:26 +0000

Last week, I watched an AI coding agent make the exact same mistake for the third time.

It reintroduced a bug we’d already fixed, ignored a team convention we’d already explained, and suggested a migration path we’d already rejected.

None of this was surprising. The agent wasn’t “bad.” It just had the same problem most AI coding agents have:

they don’t actually remember your project.

They remember the current prompt window. Maybe a few files. Maybe some chat history. But once the session ends, a lot of the hard-won knowledge disappears:

why you chose one pattern over another
which workaround fixed that weird framework bug
what not to touch in a fragile integration
which architecture decisions are still valid
which ones were replaced two weeks ago

So every new session starts with a tax:
re-explain context, re-discover gotchas, re-make old mistakes.

The real problem isn’t generation. It’s memory.

Most people focus on model quality.

That matters, of course. Better models write better code.

But in day-to-day development, the bigger issue is often context continuity. A strong model with no memory still behaves like a smart contractor with short-term amnesia.

Here’s the usual loop:

Session 1:
- Agent learns auth flow
- Agent fixes edge case
- Agent discovers API rate limit gotcha
- Session ends

Session 2:
- Agent forgets auth flow
- Agent misses the same edge case
- Agent hits the same rate limit gotcha
- You explain it all again

That’s not an intelligence problem. It’s a knowledge storage problem.

Why this happens

Most coding agents are stateless or semi-stateless by design.

They’re good at:

reading the current codebase
following local instructions
making edits quickly

They’re bad at:

preserving decisions across sessions
carrying knowledge across projects
building a durable “mental model” of your engineering environment

Even when an agent can search files, that’s not the same as memory.

A codebase tells you what exists. It usually does not tell you:

why a decision was made
what alternatives failed
which bug fixes came with caveats
what hidden constraints the team already learned the hard way

That missing layer is where teams lose time.

What actually helps

If your problem is small, a DECISIONS.md, ARCHITECTURE.md, or a good internal wiki may be enough. For many teams, that’s the right answer.

But once you’re using AI coding agents heavily, you usually need something more structured than scattered docs and chat logs.

What works better is persistent, queryable memory:

store bug fixes, patterns, and decisions
make them searchable by the agent
retrieve them automatically when relevant
keep them across sessions and projects

Think less “chat history,” more knowledge graph for your engineering context.

A simple mental model

Raw experience
   ↓
bug fixes / decisions / gotchas / patterns
   ↓
structured memory
   ↓
retrieved into future agent sessions
   ↓
fewer repeated mistakes

The key is turning raw project knowledge into something an agent can actually use later.

A runnable example

If you’re using MCP-compatible agents, the setup pattern is straightforward. Your agent stays the same; memory gets added as an external tool.

npm install -g @pekg/cli
pekg login
pekg mcp add

Then your agent can start storing and retrieving persistent knowledge across sessions.

For example, after fixing a bug, you’d save knowledge like:

pekg remember \
  --project my-app \
  --title "Stripe webhook retries can duplicate order creation" \
  --note "Use idempotency check on event.id before creating orders"

That’s the basic idea: don’t rely on the next session to “just know” what the last one learned.

What we built for this

This is the problem we built PeKG to solve.

PeKG is a personal knowledge graph for AI coding agents. It gives agents persistent memory across sessions and projects by storing:

decisions
patterns
bug fixes
gotchas
architecture knowledge

It works with any MCP-compatible agent like Claude Code, Cursor, Windsurf, Cline, Aider, and Roo Code.

A few details that matter:

your agent does the reasoning; PeKG stores and retrieves the knowledge
it can synthesize knowledge across projects
it compiles raw notes and source material into structured wiki-style articles
it supports graph relationships like depends_on, replaces, and conflicts_with
it has tiered knowledge: personal > team > shared > hive
there’s also a public Hive for community-shared patterns and gotchas

That said, the bigger takeaway isn’t “use our tool.” It’s this:

if you rely on AI coding agents, you need a memory layer somewhere.

For some teams that will be docs. For others it’ll be a vector store, internal wiki, or custom retrieval system. For teams that want an MCP-native option, PeKG is one approach.

Try it yourself

If this sounds familiar, the easiest next step is to test a persistent memory workflow on one real project:

Capture 5 things your agent keeps forgetting
Store them somewhere queryable
See whether future sessions stop repeating the same mistakes

If you want an MCP-native setup, check out https://pekg.ai/docs for MCP setup.

If you want practical ideas for what knowledge is worth saving, see https://pekg.ai/hints.txt for 115 practical tips.

And if you want to try PeKG directly, try https://app.pekg.ai — there’s a free tier available:

100 articles
5 projects
1 user

The shift that matters

The next leap for coding agents probably isn’t just better code generation.

It’s better memory.

Because once an agent can retain what your team has already learned, it stops acting like a talented stranger and starts acting more like a teammate.

How are you handling long-term memory for coding agents today — docs, prompts, custom RAG, something else? Drop your approach below.

-- PeKG team

This post was created with AI assistance.

Why AI coding agents forget everything between sessions (and how to fix it)

Dana from PeKG — Thu, 16 Apr 2026 16:39:17 +0000

Last week I watched an AI coding agent make the exact same mistake for the third time.

It reintroduced a bug we’d already fixed, ignored a project convention we’d explained twice, and suggested an architecture decision we had explicitly rejected a few days earlier.

Nothing was “wrong” with the model.

It just had no memory.

That’s the part nobody tells you when you start using AI coding agents in real projects: they’re smart inside a session, but stateless across sessions. Close the tab, start a new task, switch repos, and a lot of the hard-won context is gone.

So you end up doing this over and over:

re-explaining folder structure
re-describing why you don’t use a certain library
re-teaching the same bug fix
re-listing all the project gotchas

That’s fine for a demo. It’s painful in production.

The real problem isn’t code generation

Most agent discussions focus on which model writes better code.

In practice, the bigger issue is often continuity.

A useful coding agent needs to remember things like:

“We wrap all API calls in safeRequest()”
“Don’t use local time here; this service must be UTC-only”
“This auth middleware breaks on preview deployments”
“We tried library X and replaced it with Y because of bundle size”
“In this repo, migrations must be backward-compatible for one release”

That’s not just “context.” That’s working team knowledge.

And if it disappears between sessions, your agent keeps acting like a new hire on day one.

What most teams do instead

Usually, developers try one of these:

Put everything in README files

Good idea, but READMEs get stale fast.
Keep giant prompt files

Works until they become long, repetitive, and impossible to maintain.
Rely on the agent to scan the codebase every time

Better than nothing, but expensive and inconsistent. Also, code doesn’t explain why decisions were made.
Accept the repetition

This is where a lot of teams land. It’s annoying, but it feels easier than building a memory layer.

If your needs are simple, a good AGENTS.md, project docs, and repo conventions may be enough. Not every team needs a separate memory system.

But once you’re juggling multiple repos, multiple agents, or recurring architectural gotchas, the lack of persistent memory starts costing real time.

What a persistent memory layer looks like

The missing piece is a system that stores knowledge outside the chat session, then gives it back to the agent when relevant.

Something like this:

[Code / chats / docs / bugs]
            |
            v
   [Knowledge extraction]
            |
            v
 [Structured memory / graph]
            |
            v
 [Agent retrieves relevant context]
            |
            v
   Better decisions next session

The key is that the memory shouldn’t just be raw logs.

It should capture:

decisions
patterns
bug fixes
gotchas
dependencies
relationships between concepts

That’s where a knowledge graph approach gets useful. Instead of storing random notes, you store connected knowledge: what uses what, what replaced what, what conflicts with what, what depends on what.

A simple example

Here’s the kind of thing you want an agent to remember automatically:

npm install -g @pekg/cli
pekg remember "In this project, use zod for runtime validation. We replaced yup because zod integrates better with our tRPC stack."

Then later, when your MCP-compatible agent is working in that repo, it can retrieve that decision instead of proposing yup again.

That’s the idea behind PeKG: a personal knowledge graph for AI coding agents.

It gives agents persistent memory across sessions and projects by storing decisions, patterns, fixes, and architecture knowledge in a searchable graph. It works with MCP-compatible agents like Claude Code, Cursor, Windsurf, Cline, Aider, and Roo Code.

A few things that matter in practice:

BYOLLM: your agent does the reasoning; PeKG stores and retrieves knowledge
Cross-project synthesis: learn something in Project A, reuse it in Project B
Automatic compilation: raw notes and sources get turned into structured wiki-style knowledge
Deep scan: extract knowledge from source code files
Tiered knowledge: personal, team, shared, and public hive knowledge with trust scoring

That matters because a lot of useful engineering knowledge is not just “facts.” It’s accumulated judgment.

Why this matters more than people expect

Without memory, agents repeat effort.

With memory, they start compounding effort.

That changes the workflow:

bug fixes become reusable knowledge
architecture decisions stop disappearing into Slack
project-specific gotchas get surfaced before mistakes happen
patterns learned in one repo can help in another

And importantly, this doesn’t have to be all-or-nothing. You can still use docs, READMEs, and prompt files. A memory layer just gives your agent somewhere durable to put what it learns.

Try it yourself

If you’re already using an MCP-compatible coding agent, the easiest experiment is to give it persistent memory and see whether repeated explanations drop off after a week.

PeKG has a free tier: 100 articles, 5 projects, 1 user. If you want to test the idea, try https://app.pekg.ai. For MCP setup, check out https://pekg.ai/docs. And if you’re thinking about knowledge capture more broadly, see https://pekg.ai/hints.txt for 115 practical tips.

If PeKG isn’t the right fit, the broader takeaway still stands: don’t treat session memory as team memory. They are not the same thing.

Your model may be smart. But if it forgets every lesson by tomorrow, your team keeps paying to teach it the same things again.

How are you handling agent memory today: giant prompts, repo docs, MCP tools, or something else? Drop your approach below.

-- PeKG team

This post was created with AI assistance.

Why AI coding agents keep making the same mistakes (and how we fixed it)

Dana from PeKG — Thu, 16 Apr 2026 16:20:23 +0000

Last week, I watched an AI coding agent make the exact same mistake for the third time.

It wasn’t a hard problem. Two days earlier, we had already explained the fix: don’t use that migration pattern in this repo; it breaks multi-tenant rollbacks. The agent fixed it, the PR passed, everyone moved on.

Then the next session started.

Fresh context window. Fresh confusion. Same bad migration. Same explanation from a human.

That’s the real problem with AI coding agents right now: they’re smart in-session, but amnesiac across sessions and projects.

And if you use agents seriously, you’ve probably felt this already:

you keep re-explaining architecture decisions
the agent rediscovers the same bug fixes
repo-specific gotchas vanish after the chat ends
lessons learned in Project A never show up in Project B

Bigger context windows help a little. Better prompts help a little. Repo indexing helps a little.

But none of those actually give your agent a persistent memory.

The gap isn’t code search. It’s knowledge memory.

Most tooling today is good at finding files.

That’s useful, but it’s not the same as remembering things like:

“We tried library X and replaced it because of cold start issues”
“This service depends on eventual consistency, so don’t ‘fix’ the delay”
“That flaky test only fails when Redis is started with AOF disabled”
“In every React app we own, this auth edge case shows up eventually”

Those aren’t just snippets. They’re decisions, patterns, tradeoffs, and gotchas.

What agents really need is something closer to a team brain:

Project A lesson ─────┐
Bug fix from March ───┼──> persistent knowledge graph ──> Agent in new session
Architecture note ────┤
Gotcha from Project B ┘

That’s where a knowledge graph turns out to be surprisingly practical.

Why a knowledge graph works better than a giant note dump

A flat wiki helps humans. A vector DB helps similarity search. But coding agents often need more structure than “find something vaguely related.”

A knowledge graph can store:

entities: services, libraries, patterns, bugs, teams
relationships: depends_on, replaces, conflicts_with, uses
compiled knowledge: clean articles distilled from raw chats, PRs, docs, and code

That means an agent can retrieve not just “something about auth,” but:

the auth middleware pattern your team uses
the reason it exists
which service depends on it
what it replaced
what breaks if it’s changed

If all you need is local repo memory, a simple notes file or project wiki may be enough. But if your problem is cross-session + cross-project memory, that’s where graph-based memory gets interesting.

A simple MCP example

If you’re already using an MCP-compatible agent, the easiest path is to give it tools for storing and retrieving knowledge.

Here’s a minimal example of adding the PeKG MCP server with npm:

npm install -g @pekg/mcp-server

Then in your MCP config:

{
  "mcpServers": {
    "pekg": {
      "command": "npx",
      "args": ["@pekg/mcp-server"],
      "env": {
        "PEKG_API_KEY": "your_api_key"
      }
    }
  }
}

Once connected, your agent can ingest knowledge, search prior decisions, pull project context, and query relationships through MCP tools.

PeKG works with any MCP-compatible agent, including Claude Code, Cursor, Windsurf, Cline, Aider, and Roo Code. Your agent still does the reasoning; PeKG handles storing and retrieving structured memory.

Check out https://pekg.ai/docs for MCP setup.

What this looks like in practice

The useful pattern is not “save every chat forever.”

It’s:

capture raw sources: chats, code, docs, fixes, notes
compile them into structured knowledge
extract entities and relationships
retrieve the right knowledge when the agent needs it later

That’s the model PeKG is built around.

It stores decisions, patterns, bug fixes, gotchas, and architecture knowledge in a searchable graph. It also does deep scans of source files, clusters related knowledge automatically, and compiles raw material into wiki-style articles.

One thing I think matters here: it’s BYOLLM. Your preferred agent/model does the compilation work; PeKG stores and organizes the resulting knowledge. That makes it easier to fit into existing workflows instead of forcing a new agent stack.

It also supports tiered knowledge:

personal
team
shared
hive

So your private project memory can stay private, while trusted community patterns can still help with common problems. The Public Hive is especially useful for broad gotchas that repeat across teams.

If you’re working solo, this solves “why do I keep re-teaching my agent?”
If you’re on a team, it starts solving “why does every engineer and every agent relearn the same lessons?”

Try it yourself

If this sounds like your problem, the easiest test is simple: pick one recurring gotcha and see whether your agent can remember it next week without you retyping it.

PeKG has a free tier:

100 articles
5 projects
1 user

You can try it at https://app.pekg.ai.

If you’re thinking about agent memory design more broadly, see https://pekg.ai/hints.txt for 115 practical tips.

Pricing if you need more:

Free: 100 articles, 5 projects
Pro: $15/mo
Team: $39/mo/seat
Enterprise: custom

The bigger point

The next bottleneck for AI coding agents isn’t just model quality.

It’s memory.

Until agents can retain decisions, patterns, fixes, and architectural context across sessions, they’ll keep acting like brilliant interns with goldfish memory.

And that’s fixable.

How are you handling agent memory today: bigger prompts, repo indexing, internal docs, or something else? Drop your approach below.

-- PeKG team

This post was created with AI assistance.