DEV Community: Suraj Suradkar

Should AI coding agents remember decisions, or just code?

Suraj Suradkar — Wed, 19 Aug 2026 07:53:36 +0000

I've been thinking about this while working with AI coding agents.

Most agent workflows are pretty good at remembering the current state of the codebase.

But that's not necessarily the same thing as remembering the context behind the code.

Imagine an agent encounters a problem and considers three approaches:

Approach A was rejected because it would create a performance problem.
Approach B was rejected because it conflicted with an existing architectural constraint.
Approach C was implemented and passed the tests.

A few weeks later, another agent sees the code and asks:

"Why don't we just use Approach A?"

If the only thing it can see is the final code, it may make the exact same mistake again.

So I'm wondering what an AI coding agent should actually retain after completing a task.

Should it remember:

What changed
Why it changed
What alternatives were rejected
What evidence supported the decision
Which assumptions the decision depended on
Who made the final call

And there's an uncomfortable second question:

If we keep everything, don't we eventually create another context-window problem?

Maybe the hard problem isn't giving agents more memory.

Maybe it's deciding what deserves to become durable knowledge, what should expire, and what should be retrieved when a future decision actually depends on it.

I'm curious how other people are handling this.

What information from an AI-assisted coding session do you actually want the next agent—or the next developer—to remember?

And what would you deliberately not preserve?

Your AI Agent Doesn't Have a Memory Problem. It Has a Trust Problem.

Suraj Suradkar — Sat, 15 Aug 2026 06:38:59 +0000

I've been thinking about AI memory quite a bit lately, and I think we've been asking the wrong question.

Most discussions about AI agents frame the challenge as:

How do we make an AI remember more?

More context. Better embeddings. Improved retrieval. Longer context windows. More sophisticated memory stores.

But I'm increasingly convinced the harder problem isn't remembering. It's knowing when something should no longer be trusted.

The Problem With Stale Decisions

Consider an AI coding agent working on a project. Three months ago, the team made a deliberate decision:

"We won't use library X because it doesn't support our deployment environment."

The agent stores this. It retrieves it when relevant. And technically, it remembers correctly.

But then—six weeks later—someone updates the deployment architecture. Library X releases a new version. The original constraint disappears.

Yet the memory still says: "Don't use library X."

The agent hasn't forgotten. The agent has provided a stale answer with confidence. And that's far more dangerous than simply forgetting.

Memory Can Be Valid Without Being True

There's a crucial distinction I want to establish. Project knowledge exists in at least three states:

Known and Valid

"We use PostgreSQL for this service"

Known But Uncertain

"We believe this service uses PostgreSQL, but the architecture changed recently"

Previously Valid, Now Questionable

"We rejected library X because of constraint Y"

The third category is particularly insidious. It carries the authority of a documented decision. It was made deliberately. Someone wrote it down. The AI retrieves it. The answer sounds confident.

But the conditions that made the decision correct may no longer exist.

What Durable Memory Actually Needs

If we're going to trust AI agents to make decisions, we need to rethink what we store.

Instead of:

Decision: Use architecture A.

We need something more like:

Decision: Use architecture A.

Reason: Architecture B couldn't satisfy constraint X.

Evidence:

Deployment requirement Y
Performance test Z

Made: June 2026

Confidence: High

Depends On:

Constraint X
Deployment environment Y

Revisit If:

Constraint X changes
Deployment architecture changes

Now the system isn't just recording what was decided. It's preserving the reasoning, evidence, and conditions that made the decision sound. It captures the why—not just the what.

The Value of Negative Knowledge

There's another dimension we often miss: understanding why we rejected something matters as much as understanding what we chose.

Suppose an agent suggests: "Why don't we introduce service B?"

A typical memory system retrieves: "Service B was considered previously."

That's insufficient. The useful information is:

"Service B was evaluated in April and rejected because it introduced 300ms latency under the expected workload."

Without this context, the system confidently rediscovers the same rejected idea in six months and presents it as a fresh solution.

The system didn't forget the project. It forgot why the project rejected something. That's a critical failure of institutional memory.

The Real Risk: Dangerous Confidence

There are two very different failure modes in AI systems:

Forgetting: "I don't know." Annoying, but safe.

False Confidence: "I know," when that knowledge is stale. Potentially dangerous—especially for coding agents.

The output isn't always text. It's:

Code changes
Database migrations
Architectural recommendations
Dependency upgrades
Deployment decisions
Destructive operations

The cost of stale context becomes exponentially higher when an agent can act on it.

Toward a "Reconsider" Mechanism

Rather than a simple pipeline:

store → retrieve → use

We need something more like:

observe → preserve → connect → validate → retrieve → question when necessary

The final step is critical. Something changed—a dependency, a requirement, a deployment environment, a user preference, a previous assumption, a piece of evidence.

The memory shouldn't necessarily disappear. It should become questionable.

Deleting old knowledge destroys history. Treating old knowledge as permanently authoritative destroys trust. The better approach is to preserve history while changing its epistemic status—marking it as potentially outdated, pending review, or dependent on conditions that may have shifted.

Why This Matters Now

This is one of the problems I'm actively exploring with Xeyria, a project intelligence layer designed specifically for AI-assisted development.

The part that fascinates me most isn't simply giving an AI more context to work with. It's something far more fundamental: preserving the connections between:

decisions → reasoning → constraints → evidence → outcomes

This creates a web of institutional knowledge that doesn't just survive in an agent's memory—it can be intelligently questioned when conditions shift. Because here's what we're really after: not systems that remember everything, but systems that understand what's changed since they last knew something.

The shallow answer is: "Add a vector database." That solves storage.

The harder, more interesting question is this:

How does an AI know that something it remembers should no longer be treated as truth?

Maybe the next generation of AI agents won't be defined by how much they can remember, but by how well they know what they should still trust.

I'd genuinely love to hear from you: How are you currently handling stale decisions, assumptions, and outdated project knowledge in your AI agents? What's breaking in your systems right now? Drop your thoughts in the comments—this is a problem we're all going to need to solve together.

What should an AI coding agent be allowed to forget?

Suraj Suradkar — Tue, 11 Aug 2026 08:48:45 +0000

What should an AI coding agent be allowed to forget?

We talk a lot about giving AI coding agents more context.

But I’m starting to think the harder problem is deciding what should survive.

A project can contain:

an architectural decision made 6 months ago
a constraint that must never be violated
an approach that was tried and failed
a temporary implementation detail
an old requirement that is no longer relevant
a conversation explaining why something was built a certain way

Should an AI agent treat all of these as “memory”?

I don't think so.

Some information should remain part of the project's long-term knowledge. Some should expire. And some should remain available only as historical context without influencing current decisions.

That makes me wonder:

If you were designing memory for an AI coding agent, what would you make permanent, what would expire, and what would you keep only as history?

I’m curious how other developers think about this.

AI coding tools are fast. But who remembers the project context?

Suraj Suradkar — Sat, 08 Aug 2026 14:49:09 +0000

AI coding tools can write code incredibly fast now.

But there’s a problem I keep running into: project context doesn't seem to persist very well.

Over time, a project accumulates hundreds of decisions:

Why something was designed a certain way
What approaches were already tried
Which parts shouldn't be changed
How different systems depend on each other
What the current priorities and constraints are

The code shows what exists, but not always why it exists.

So I’m curious:

How do you currently keep your AI coding tools aware of this context?

Do you use AGENTS.md, CLAUDE.md, architecture docs, repo-level instructions, or something else?

And after working on a project for months, does this still work well for you?