The Missing Layer in AI Coding: Persistent Memory Across Cursor, Zed and VS Code

AI-assisted software development has changed dramatically.

Developers can now ask an AI coding agent to analyze an architecture, modify multiple files, investigate a production issue, write tests, review a pull request, or implement an entire feature.

But there is still a fundamental problem:

Your AI coding agent often remembers the code, but not the engineering history behind the code.

You may spend three hours debugging a FreeSWITCH issue with Cursor, switch to Zed the next morning, and discover that the new agent has no idea what you tried yesterday.

You explain the architecture again.

You explain the failed approaches again.

You search old conversations again.

You paste logs again.

You reconstruct decisions again.

And the same problem appears when moving between Cursor, Zed, VS Code, Claude Code, Codex, Aider, or another AI coding environment.

The next evolution of AI-assisted development is therefore not simply better models.

It is persistent engineering memory.

The AI Coding Context Problem

Modern coding agents operate inside a context window.

That context may contain:

• your current conversation
• source files
• terminal output
• Git history
• project instructions
• tool results
• documentation
• previous messages

But context is not the same thing as memory.

VS Code, for example, now provides user, repository, and session memory, with repository memory persisting across conversations within a workspace.

That is useful, but it still raises a larger architectural question:

What happens when the developer changes the tool, machine, repository, or AI agent?

A project may contain years of engineering knowledge that isn't represented directly in the source code.

Code Is Not the Complete Project Memory

Consider a production telecom platform.

The repository may contain:

UnifiedPBX
│
├── NestJS
├── PostgreSQL
├── FreeSWITCH
├── Asterisk
├── SIP
├── WebRTC
├── Redis
├── React
└── Docker

The code tells the agent what exists.

It does not necessarily tell the agent:

• Why a particular SIP profile was created
• Why a specific NAT configuration is required
• Which carrier rejected a particular SIP header
• Which approach to RTP failed
• Why a database field is intentionally not nullable
• Why a seemingly redundant service exists
• Which workaround is required for a specific carrier
• Which migration was attempted and rolled back
• Why one architecture was rejected
• Which production incident led to a particular design decision

That information usually exists somewhere else.

It may be hidden inside:

• ChatGPT conversations
• Cursor conversations
• Slack
• Git commits
• Jira
• Notion
• Google Docs
• personal notes
• terminal history
• email
• developer memory

This creates a fragmented knowledge architecture.

The "AI Amnesia" Problem

Imagine this development cycle.

Monday

You ask Cursor:

"Investigate why inbound DID calls are reaching the carrier but not the PBX."

The agent investigates.

You discover:

Carrier
   ↓
INVITE
   ↓
SIP authentication
   ↓
FreeSWITCH external profile
   ↓
DID routing

You discover that an earlier authentication configuration caused the failure.

You fix it.

The conversation ends.

Tuesday

You open Zed.

You ask:

"Investigate the inbound DID problem."

The new agent may understand the current code.

But it may not know:

"We already tried changing the Sofia profile authentication mode and that caused another problem."

So it may repeat the same experiment.

Wednesday

You switch to VS Code.

Same project.

Another conversation.

Another context window.

Another reconstruction.

This is not a model intelligence problem.

It is a memory architecture problem.

What If the AI Had Engineering Memory?

Instead of starting from zero, the agent could retrieve:

Project:
UnifiedPBX

Issue:
Inbound DID not reaching PBX

Previous attempts:
1. Changed external Sofia profile
   Result: failed

2. Disabled authentication
   Result: carrier rejected request

3. Modified DID regex
   Result: partial improvement

4. Updated inbound route
   Result: successful

Decision:
Keep carrier authentication enabled.

Related components:
FreeSWITCH
Sofia
DID routing
Inbound dialplan

Now the agent has something much more valuable than raw conversation history.

It has engineering experience.

Persistent AI Coding Memory

A persistent AI coding memory layer sits between your development tools and your long-term engineering knowledge.

Conceptually:

                     Engineering Memory
                             │
             ┌───────────────┼───────────────┐
             │               │               │
          Projects        Decisions       Skills
             │               │               │
             └───────────────┼───────────────┘
                             │
                       Memory API / MCP
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
        Cursor              Zed             VS Code
          │                  │                  │
        Agent              Agent             Agent

The important principle is:

The IDE should be replaceable. The engineering memory should not be.

MCP Makes This Architecture Practical

The Model Context Protocol (MCP) provides a practical integration point between AI applications and external tools or context systems.

Instead of building a separate memory integration for every AI coding tool, a developer can expose a memory system through an MCP server.

For example:

                    Memory Database
                          │
                     MCP Server
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
      Cursor             Zed             VS Code
        │                 │                 │
        └─────────────────┼─────────────────┘
                          │
                       AI Agent

This makes the memory layer significantly more portable.

Zed supports MCP for extending its agent capabilities, while modern coding agents increasingly support external context and tools.

What Should an AI Memory System Store?

A useful system should not simply save every conversation.

That creates another problem:

too much context.

Instead, it should transform development activity into structured engineering knowledge.

1. Project Knowledge

Architecture
Technology stack
Database schema
Services
APIs
Infrastructure
Deployment
Security
Coding conventions

2. Architectural Decisions

For example:

Decision:
Use PostgreSQL for tenant and billing data.

Reason:
Relational consistency is important for
billing, CDR and reporting.

Status:
Active

Related:
Multi-tenancy
Billing
CDR
Reporting

3. Problems

Problem:
SIP REGISTER returns
"No matching endpoint found"

Component:
FreeSWITCH

Environment:
Production

Date:
2026-09

4. Attempts

Attempt:
Changed Sofia profile configuration

Result:
Failed

Reason:
Authentication behaviour changed.

Do not repeat:
Yes

5. Solutions

Solution:
Updated directory synchronization
and regenerated Sofia directory XML.

Result:
REGISTER succeeded.

6. Developer Skills

A global engineering memory could also contain reusable knowledge:

FreeSWITCH
Asterisk
SIP
PJSIP
NestJS
PostgreSQL
Redis
WebRTC
Docker
Kubernetes
Terraform
AWS
AI Agents
RAG
MCP

This creates an important distinction.

Project Memory vs Developer Memory

A sophisticated system should have at least two scopes.

Project memory

Specific to:

UnifiedPBX
CRM
ERP
IVR
CCaaS

Developer memory

Reusable across projects:

FreeSWITCH patterns
NestJS conventions
PostgreSQL optimization
Docker patterns
AWS deployment
AI agent patterns
MCP integrations

For example:

Developer Memory
       │
       ├── FreeSWITCH
       ├── NestJS
       ├── PostgreSQL
       ├── AI Agents
       └── MCP
              │
              ↓
       Project Memory
              │
       ┌──────┼──────┐
       ↓      ↓      ↓
     PBX     CRM    ERP

A lesson learned while building one project can therefore become useful in the next project.

Don't Store Everything in the Prompt

This is one of the most important architectural considerations.

A naïve implementation might do:

Previous conversations
        ↓
ALL conversation history
        ↓
LLM prompt

That quickly becomes expensive and ineffective.

Instead:

                 Memory Database
                       │
              Search / Retrieval
                       │
             Relevant memories
                       │
               Context ranking
                       │
                Token budget
                       │
                       ↓
                     Agent

The AI should retrieve only the memories relevant to the current task.

This is where semantic search, full-text search, metadata filtering and potentially vector databases become useful.

Database-Backed AI Memory

A production-oriented implementation could look like:

                 PostgreSQL
                     │
       ┌─────────────┼─────────────┐
       │             │             │
   Projects       Memories      Decisions
       │             │             │
       │         Embeddings       │
       │             │             │
       └─────────────┼─────────────┘
                     │
                  pgvector
                     │
               Retrieval API
                     │
                  MCP Server
                     │
        ┌────────────┼────────────┐
        │            │            │
      Cursor        Zed         VS Code

For a developer who wants full ownership, PostgreSQL + pgvector is an attractive foundation because it can combine relational metadata, full-text search and vector similarity in one system.

Local-First vs Cloud Memory

There are two major approaches.

Local-first

Developer machine
       │
   Local database
       │
     MCP
       │
     Agents

Advantages:

• privacy
• no external dependency
• works offline
• easy Git backup
• full ownership

Projects such as projectmem take this direction. It describes itself as local-first, open source and MIT licensed, storing development history such as issues, attempts, fixes and decisions locally and exposing it through MCP.

Cloud-backed

Developer
    │
    ↓
Cloud Memory API
    │
    ↓
Central Database
    │
    ├── Cursor
    ├── Zed
    ├── VS Code
    └── Other agents

Advantages:

• multiple machines
• centralized backup
• team sharing
• cross-device memory
• easier collaboration

The tradeoff is security, privacy and vendor dependency.

What About Delta?

Delta is an interesting example because it approaches the problem from another direction.

Rather than simply being a memory database, Delta connects AI conversations with development work and versioned changes.

That makes the conversation itself part of the development history.

This is powerful because:

Conversation
      ↓
AI decision
      ↓
Code modification
      ↓
Git / version history
      ↓
Future context

But Delta should be thought of as a development history and AI-native workflow system, rather than automatically assuming it is the universal memory layer for every editor.

The broader architectural idea is more important:

AI conversations should become durable engineering artifacts instead of disposable chat sessions.

Existing Options Worth Exploring

Developers interested in this space can already experiment with several approaches.

The important point is that there is not yet one universally accepted standard product that becomes the permanent engineering memory for every AI coding environment.

That leaves considerable room for experimentation.

A Better Architecture for Serious Engineering Teams

For a professional engineering organization, I would go beyond simple chat memory.

A useful architecture could be:

                         AI MEMORY PLATFORM
                                │
          ┌─────────────────────┼─────────────────────┐
          │                     │                     │
      Project Memory       Developer Memory      Organization
          │                     │                     │
          ├── Decisions         ├── Skills          ├── Standards
          ├── Issues            ├── Patterns         ├── Architecture
          ├── Fixes             ├── Gotchas          ├── Security
          ├── Architecture      └── Preferences      └── Policies
          │
          └──────────────┬───────────────────────────┘
                         │
                    Retrieval Layer
                         │
                    MCP / API Layer
                         │
       ┌─────────────────┼──────────────────┐
       │                 │                  │
    Cursor              Zed             VS Code
       │                 │                  │
       └─────────────────┼──────────────────┘
                         │
                   AI Coding Agents

Now the memory layer becomes infrastructure.

The editor becomes a client.

The model becomes replaceable.

The knowledge remains.

Why This Matters for AI-First Development

The current generation of AI coding tools is largely competing on:

• model quality
• context windows
• agent capabilities
• tool use
• code generation
• autonomous execution
• pricing
• token consumption

The next competitive layer may increasingly become:

experience.

Two agents can use the same model.

One starts with:

"Here is the repository."

The other starts with:

"Here is the repository.

Here are the architectural decisions.

Here are the failed approaches.

Here are the production incidents.

Here are the relevant skills.

Here are the conventions.

Here is what changed last week.

Here is what you should not repeat."

Those are fundamentally different development experiences.

The Future: AI That Gains Engineering Experience

The long-term goal should not be:

"Make the AI remember every conversation."

The better goal is:

"Make the AI accumulate useful engineering experience."

That means converting raw activity into durable knowledge.

Conversation
     ↓
Observation
     ↓
Problem
     ↓
Attempt
     ↓
Result
     ↓
Decision
     ↓
Knowledge
     ↓
Reusable experience

And then:

New task
    ↓
Retrieve relevant experience
    ↓
AI reasoning
    ↓
Implementation
    ↓
New experience
    ↓
Memory updated

This creates a feedback loop.

From AI Assistant to Engineering Partner

This is ultimately a shift in how we think about AI coding tools.

The traditional model is:

Developer → Prompt → AI → Code

The emerging model is:

Developer
    ↓
AI Agent
    ↓
Tools
    ↓
Code
    ↓
Engineering Memory
    ↓
Experience
    ↓
Better Future Sessions

The AI isn't merely generating code anymore.

It is participating in the engineering lifecycle.

What Developers Should Look for in an AI Memory Platform

Before adopting a persistent AI memory solution, evaluate these capabilities:

Interoperability

Does it work with:

• Cursor?
• Zed?
• VS Code?
• Claude Code?
• Codex?
• other MCP clients?

Ownership

Can you export your data?

Can you self-host it?

Can you back it up?

Memory quality

Does it store:

• decisions?
• failed attempts?
• solutions?
• architecture?
• skills?

Or does it simply dump conversations?

Retrieval

Can it find the right memory without loading everything?

Security

Where does the data live?

Is code sent to a third party?

Is telemetry collected?

Versioning

Can you see how a decision changed over time?

Portability

Can you change your AI model without losing your engineering knowledge?

These questions may ultimately matter more than which AI editor has the most impressive demo.

Conclusion

AI coding assistants have solved much of the problem of access to intelligence.

The next problem is access to experience.

Your codebase contains your current implementation.

Git contains your changes.

Documentation contains your formal knowledge.

But your engineering conversations contain something else:

the reasoning behind the system.

That reasoning should not disappear when a chat ends.

A persistent AI memory layer can connect:

Projects
+
Code
+
Git
+
Conversations
+
Decisions
+
Debugging history
+
Skills
+
AI agents

into one durable engineering knowledge system.

The future of AI-assisted development may therefore look less like:

"Which coding assistant should I use?"

and more like:

"Where does my engineering knowledge live, and which AI agent can access it?"

That is the architectural question worth solving.

How UnifiedPBX Approaches AI Engineering

At UnifiedPBX, we look at AI not simply as a code-generation tool, but as part of a larger engineering architecture involving AI agents, automation, APIs, SaaS platforms, communications systems, VoIP, CPaaS, CCaaS and enterprise applications.

The same principle applies beyond coding:

AI systems become substantially more useful when they have access to the right context, tools, data and long-term knowledge.

That is where persistent context, agentic workflows, MCP, RAG and AI automation increasingly intersect.

If you are designing an AI-enabled engineering or business platform, the question is no longer simply which model should we use?

It is:

What should the AI know, where should that knowledge live, and how should it safely access it?