DEV Community: Alfredo Izquierdo

How to Give Claude & Cursor Persistent Memory 2026

Alfredo Izquierdo — Wed, 26 Aug 2026 15:42:48 +0000

Install the free official MCP memory server, then upgrade to project-aware ContextForge. 2026 guide.

Here's a small tragedy that plays out in my terminal every single morning: I open
Claude Code, and it has no idea who I am, what I'm building, or what we decided
yesterday. Same with Cursor. Brilliant assistants, zero memory. It's like working
with a genius who has amnesia.

The fix is an MCP memory server — a little service that plugs into Claude or
Cursor over the Model Context Protocol and gives your assistant memory that
survives when the session ends. In this guide I'll show you exactly how to set one
up, starting with the free official server and then the project-aware option I
ended up building because the official one wasn't enough for real work.

New to this whole space? I ranked
the 8 best AI memory tools for Claude
and did a deep ContextForge vs Mem0 vs Zep
comparison in separate posts. This one is the hands-on how to actually install
one guide.

What is an MCP memory server?

MCP — the Model Context Protocol — is the open standard that lets tools like
Claude Code and Cursor talk to external services. An MCP memory server is just
one of those services, with one job: store what your assistant learns (facts,
decisions, project context) and hand the right pieces back at the start of the
next conversation.

Without one, everything your assistant knows lives inside a single session's
context window — and vanishes the moment that session closes. With one, memory
lives outside the model, so tomorrow's you doesn't start from zero.

Two ways to get there, from simplest to most capable. Let's do both.

Option 1: The official MCP memory server (free, 2 minutes)

The Model Context Protocol team ships a reference memory server. It's a
knowledge-graph memory that stores entities, relations, and observations in a
local JSON file. It's the fastest way to feel what MCP memory does, and it costs
nothing.

Install it in Claude Code / Claude Desktop. Open your MCP config
(claude_desktop_config.json, or .mcp.json in your project) and add:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Install it in Cursor. Same idea — add the block to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Restart the app, and your assistant can now save and recall entities across
sessions. That's genuinely useful — and for a lot of people it's enough.

Where it stops being enough. I ran the official server for weeks, and three
things wore me down:

It's one flat graph in a local file — no notion of which project a memory belongs to. My side project's facts and my client work bled into the same blob.
No sync. The memory lives on one machine; switch laptops or tools and it doesn't follow you.
You have to babysit recall. Nothing loads automatically at session start — you're nudging it to remember, every time.

For quick experiments, perfect. For the actual work I do every day, I wanted
something that understood projects. So I built it.

Option 2: ContextForge — a project-aware MCP memory server

ContextForge is an MCP memory server too — same standard, plugs into Claude
and Cursor the same way — but instead of one flat graph, it organizes memory
around your projects: spaces, items, tasks, and decisions that load
automatically the second a new session starts. No vector database to run, no local
file to babysit.

Connect it the same way you connected the official one — add it to your MCP
config, drop in your ContextForge API key, and restart. From that point on, when
you open Claude Code or Cursor, your assistant already knows what project you're
in and what you were doing. You can even import the ChatGPT and Claude history you
already have, so you're not starting your memory from scratch.

Here's the honest side-by-side:

	Official memory server	ContextForge
Cost	Free	Free tier, then paid
Setup	`npx`, 2 min	Connect MCP + API key
Storage	Local JSON file	Managed, no infra
Structure	One flat knowledge graph	Projects, spaces, tasks, decisions
Loads at session start	Manual	Automatic
Syncs across machines/tools	No	Yes
Import existing history	No	Yes (ChatGPT / Claude)
Best for	Quick experiments, local use	Real project work across sessions

Neither is "the winner" in the abstract. If you want a free, local, kick-the-tires
memory, the official server is a great first stop. If you live in Claude Code or
Cursor and want memory that actually understands your projects and follows you
around, that's the gap ContextForge was built to fill.

Which should you pick?

Just curious how MCP memory feels? → the official @modelcontextprotocol/server-memory. Free, two minutes, done.
Working on real projects across sessions, machines, or tools? → ContextForge.
Not sure which memory tool at all yet? → start with my top-8 ranking.

FAQ

What is an MCP memory server?
It's a service that connects to Claude, Cursor, or any MCP client over the Model
Context Protocol and stores your assistant's memory outside the session, so facts,
decisions, and project context persist across conversations instead of resetting
each time.

How do I install the official MCP memory server?
Add @modelcontextprotocol/server-memory to your MCP config
(claude_desktop_config.json, .mcp.json, or ~/.cursor/mcp.json) with the
command npx -y @modelcontextprotocol/server-memory, then restart the app.

Does this work with both Claude Code and Cursor?
Yes. Both speak MCP, so the same memory server plugs into either one — you just add
the server to each tool's MCP config file.

What's the difference between the official server and ContextForge?
The official server stores one flat knowledge graph in a local file. ContextForge
organizes memory by project (spaces, tasks, decisions), loads it automatically at
session start, needs no local infrastructure, and syncs across your tools and
machines.

Do I need a vector database?
No. Neither the official server nor ContextForge asks you to run a vector database
— that's part of the appeal of an MCP memory server over building recall yourself.

Tired of re-introducing your project to Claude and Cursor every morning? I built
ContextForge to be the MCP memory server I wanted —
project-aware, zero infrastructure, connected in minutes.

ContextForge vs Mem0 vs Zep: Best AI Memory Layer (2026)

Alfredo Izquierdo — Tue, 25 Aug 2026 14:18:05 +0000

I'll be honest with you: I build one of the three tools in this post, so you'd
be right to raise an eyebrow. But I've spent the last year staring at this exact
decision — which memory layer do I actually trust with my agents? — and I got
tired of comparisons that were really just sales pages in disguise.

So here's the version I wish someone had written me. Three tools, head to head,
including the parts where mine loses. If you use Claude and MCP, ContextForge
is in the mix. If you don't, Mem0 or Zep is probably your answer — and
I'll tell you exactly when.

Already narrowed it down to these three? Good — that's what this post is for. If
you're still scanning the whole field, I ranked
the 8 best AI memory tools for Claude
in a separate guide. Come back here once you've got your finalists.

TL;DR: Pick ContextForge if you live in Claude / Claude Code and want
project-aware memory that plugs in over MCP with zero infrastructure. Pick
Mem0 if you want a general, framework-agnostic memory API with the biggest
community behind it. Pick Zep if you need temporal, entity-aware memory
with the best published accuracy benchmarks.

The 30-second verdict

If you only have a minute, this table is the whole post:

	ContextForge	Mem0	Zep
Best for	Claude + MCP workflows	General memory API	Temporal / entity memory
Architecture	Project/space memory over MCP	Vector-first, layered scopes	Temporal knowledge graph (Graphiti)
Setup	Connect as MCP server, no infra	SDK or managed cloud	Managed or self-host graph
Standout	Loads project context at session start	~48K GitHub stars, wide adoption	63.8% LongMemEval (accuracy leader)
Free tier	Yes	~10k memory adds/mo	~1k credits/mo
Open source	—	Yes	Engine (Graphiti, Apache 2.0)

The rest of this post is about the why — because the three don't just differ on
features, they disagree on what "memory" even means.

The real difference: three philosophies, not three feature lists

Here's the thing that took me embarrassingly long to see. These tools aren't
competing on who has more features — they start from three different beliefs
about what your agent should remember:

Mem0 believes memory is a pile of facts you retrieve by similarity.
Zep believes memory is a web of entities and events that change over time.
ContextForge believes memory is your project — the tasks, decisions, and context of the work in front of you.

Once you see it that way, the "which is best" question dissolves into a much
better one: which shape matches how you actually work? Let's take them one at a
time.

Mem0: memory as a pile of facts

Mem0 is the one you've probably already heard of — with roughly 48K GitHub stars,
it's the popular kid. Its whole bet is generality: drop it onto almost any stack,
and it quietly files away facts and pulls back the ones that look relevant when
you ask. It even reaches into Claude Desktop and Cursor through an MCP server, so
your facts can follow you between tools.

The trade-off is baked into that same bet. Retrieving by similarity is fast and
flexible, but it's a little forgetful about relationships — how two facts
connect, or which one is still true today. Ask it "what did we decide about auth,
and did that change?" and it'll hand you every auth-flavored memory it has, newest
and stalest alike, and let you sort it out. For a lot of apps that's plenty. For a
messy, evolving project, you feel the gap.

Reach for Mem0 when: you're building on any framework and want one simple,
well-supported memory API that just works everywhere.

Zep: memory as a timeline of entities

If Mem0 is the popular kid, Zep is the honor student. It doesn't store loose facts
— it builds a graph where the people, projects, and things in your data are
connected, and every connection is stamped with when it was true. That's why it
can answer the question Mem0 fumbles: what was true last Tuesday, and what
changed since?

And it's not just theory — Zep posts the best public accuracy numbers in this
space, 63.8% on LongMemEval against Mem0's 49.0%. When I say it earns my respect,
that benchmark is a big part of why.

The catch is the same thing that makes it powerful: a graph is something you
design and maintain, not something you drop in and forget. If your goal is
"help my assistant remember this project," Zep can feel like hiring a librarian to
organize a single shelf — genuinely excellent, just more machine than the moment
calls for.

Reach for Zep when: you're building conversational agents that track real
entities over time and accuracy is the hill you'll die on.

ContextForge: memory as your project

This is mine, so read it with your skepticism turned up. I didn't build
ContextForge to win a benchmark — I built it because I was tired of re-explaining
my own codebase to Claude every single morning. So instead of storing facts or
entities, it stores the thing I actually care about: the project. You connect
it as an MCP server, and your assistant gets spaces, items, tasks, and decisions
that survive across sessions and load automatically the second a new conversation
opens. No cold start.

What makes it click for Claude users: there's no vector database for you to run,
memory is organized by project and space instead of one giant blob, and it'll
pull in the ChatGPT and Claude history you already have.

And now the honest part. ContextForge is built around Claude and MCP. That's its
superpower and its ceiling. If you're not in that ecosystem, it's the wrong tool —
Mem0 is more general and I won't pretend otherwise. Zep will out-benchmark me on
raw recall accuracy. I'm not the best at everything; I'm the best at one specific
job.

Reach for ContextForge when: you live in Claude / Claude Code and you want
memory that understands your projects without you standing up any infrastructure.

Head-to-head by what actually matters

Enough philosophy — here's how they feel day to day:

Setup cost: ContextForge (connect MCP, no infra) < Mem0 (SDK/cloud) < Zep (graph, managed or self-host). If you hate infrastructure, that order is your whole decision.
Retrieval quality: Zep leads on benchmarks; Mem0 is solid on similarity; ContextForge keeps context scoped to your project instead of going global on you.
Claude / Claude Code fit: ContextForge is MCP-native and loads at session start; Mem0 offers an MCP server too; Zep integrates but isn't Claude-first.
Openness & price: Mem0 and Zep's engine are open source and self-hostable — Mem0's free tier runs ~10k adds/month, Zep's ~1k credits/month. ContextForge is a managed service with a free tier and nothing to self-host. If self-hosting is a hard requirement, that line just picked your tool.
Structure: ContextForge models projects, spaces, and tasks; Mem0 and Zep model facts and entities. If your memory is your project, structure wins.

A concrete way to choose

Still torn? Answer one question — what does your agent forget that hurts the
most?

It forgets my project, my decisions, my stack → ContextForge.
It forgets facts across a big general app → Mem0.
It forgets who's who and what changed when → Zep.

And here's the plot twist nobody tells you: these aren't mutually exclusive.
Plenty of teams run Zep or Mem0 for general app-level memory and ContextForge for
their Claude/MCP dev workflow. They're solving different halves of the problem, so
using two isn't hedging — it's just matching the tool to the job.

FAQ

Is Mem0 or Zep better?
Depends on what you're optimizing for. Mem0 leads on adoption and simplicity with
a vector-first layer; Zep leads on accuracy (63.8% vs 49.0% on LongMemEval) with
a temporal knowledge graph. Choose Mem0 for a general memory API, Zep for time-
and entity-aware recall.

What's the best memory tool for Claude specifically?
For Claude and Claude Code, ContextForge is purpose-built: it connects over MCP
and gives project-aware memory that loads automatically at session start —
without you running your own vector database.

Can I use more than one of these together?
Yes, and many teams do — for example Zep or Mem0 for broad app memory plus
ContextForge for the Claude/MCP developer workflow. They target different layers,
so combining them is common rather than redundant.

Are these open source?
Mem0 is open source; Zep's engine Graphiti is Apache 2.0 and self-hostable.
ContextForge is a managed service with a free tier.

Using Claude and tired of re-explaining your project every single session? I
built ContextForge precisely because I was — it's
persistent, project-aware memory over MCP, and you can be set up in minutes.

Best AI Memory Tools for Claude in 2026 (Top 8 Ranked)

Alfredo Izquierdo — Mon, 24 Aug 2026 16:39:43 +0000

If your AI assistant forgets your project every time you open a new session,
you don't have a model problem — you have a memory problem. In 2026, memory
stopped being a nice-to-have and became core AI infrastructure. This guide ranks
the 8 best AI memory tools you can use with Claude, Claude Code, and other agents,
with honest picks for each use case.

TL;DR: For Claude and MCP-native workflows, ContextForge is the fastest
way to give your assistant persistent, project-aware memory. For a general
vector memory layer, Mem0 leads on adoption. For temporal, entity-aware
memory, Zep leads on accuracy. For fully self-hosted graph memory, pick
Cognee or Letta.

What "AI memory" actually means

An AI memory tool stores facts, preferences, decisions, and project context
outside the model's context window, then retrieves the right pieces on demand —
so your agent remembers across sessions, tools, and days instead of starting cold
every time. The approaches differ: some are vector-first, some build knowledge
graphs, some manage the context window like an operating system manages RAM.

How we ranked these

Persistence across sessions — does it actually survive a new conversation?
Retrieval quality — does it pull the relevant memory, not everything?
Setup cost — managed vs. self-hosted infrastructure.
Claude / MCP fit — how cleanly it plugs into Claude Code and MCP clients.
Pricing & openness — free tier, open source, self-hostable.

1. ContextForge — Best for Claude + MCP persistent memory

ContextForge is a persistent memory system built for Claude and MCP clients.
Instead of running a vector database yourself, you connect it as an MCP server and
your assistant gains project-scoped, git-aware memory: spaces and items,
tasks, and project context that persist across every session and sync across tools
(Claude Code, Cursor, and imported ChatGPT history).

Best for: Claude / Claude Code users who want project-aware memory without standing up infrastructure.
Why it wins its niche: MCP-native, so memory loads at session start automatically; organized by project and space, not one flat blob; captures tasks and decisions, not just chat facts.
Trade-off: purpose-built around the Claude/MCP workflow rather than a general-purpose SDK for any stack.

2. Mem0 — Best overall adoption / general memory layer

Mem0 is a vector-first memory layer you bolt onto almost any agent stack. It
organizes memory by scope (conversation, session, user, organization) and promotes
facts between layers over time. With ~48K GitHub stars it's the most widely adopted
option, and its OpenMemory MCP server carries memory across clients.

Best for: teams wanting a general, framework-agnostic memory API.
Pricing: open source + managed cloud; free tier ~10,000 memory adds/month.
Trade-off: vector-first recall can miss how facts relate or change over time.

3. Zep — Best for temporal, entity-aware memory

Zep builds a temporal knowledge graph (via Graphiti, Apache 2.0) where
entities are nodes and facts are edges with validity intervals — so it tracks how
facts change over time. It leads published accuracy benchmarks (63.8% on
LongMemEval vs. Mem0's 49.0%).

Best for: conversational agents that need entity memory and "what was true when" reasoning.
Pricing: open-source engine; managed free tier ~1,000 credits/month.
Trade-off: graph model is more to reason about than a simple vector store.

4. Cognee — Best self-hosted graph memory (open source)

Cognee is the open-source memory platform that natively combines graph,
vector, and relational storage into one self-improving "memory control plane."

Best for: teams that want full data ownership and a graph+vector hybrid.
Pricing: open source, self-hostable.
Trade-off: you run and maintain the infrastructure.

5. Letta (formerly MemGPT) — Best for agent-managed context

Letta treats the context window as a constrained resource — like RAM in an OS —
letting the agent move data between in-context "core" memory and external
recall/archival memory. It's the MemGPT tradition, and its OSS self-host is the
most complete open-source offering.

Best for: long-running autonomous agents that self-manage memory.
Pricing: open source; managed tiers roughly $19–$125/mo for early production.
Trade-off: more framework than drop-in layer.

6. Supermemory — Best lightweight managed option

Supermemory is a managed memory API focused on simplicity and fast setup for
adding recall to assistants and apps without infrastructure overhead.

Best for: shipping memory quickly in a small product.
Trade-off: less control than a self-hosted graph.

7. Basic Memory (Official Memory MCP) — Best minimal MCP server

Basic Memory is a lightweight MCP memory server: create entities, add
observations, search by keyword or semantics, persist across sessions. Runs via
npx, Docker, or local install with minimal dependencies.

Best for: developers who want a tiny, official MCP memory primitive.
Trade-off: minimal by design — no project/task structure or team features.

8. Pinecone — Best managed vector store to build on

Pinecone isn't a memory framework — it's the managed vector database many
memory layers are built on. Choose it when you're building custom memory retrieval
and want a scalable, managed index underneath.

Best for: teams rolling their own memory pipeline.
Trade-off: you build the memory logic; it only stores/retrieves vectors.

Quick comparison

Tool	Best for	Approach	Open source	Free tier
ContextForge	Claude + MCP persistent memory	Project/space + MCP	—	Yes
Mem0	General adoption	Vector-first, layered	Yes	~10k adds/mo
Zep	Temporal / entity memory	Temporal knowledge graph	Yes (Graphiti)	~1k credits/mo
Cognee	Self-hosted graph memory	Graph + vector + relational	Yes	Self-host
Letta	Agent-managed context	Context-as-RAM (MemGPT)	Yes	OSS / $19+
Supermemory	Lightweight managed	Managed API	Partial	Yes
Basic Memory	Minimal MCP server	Entity/observation store	Yes	Self-host
Pinecone	Build-your-own	Managed vector DB	No	Yes

How to choose

You use Claude / Claude Code and want it to remember your projects → ContextForge (MCP-native, project-aware, zero infra).
You want one memory API across any framework → Mem0.
You need entity memory and time-aware facts → Zep.
You want to self-host a graph+vector brain → Cognee or Letta.
You're building custom retrieval → Pinecone underneath.

FAQ

What is the best AI memory tool for Claude in 2026?
For Claude and Claude Code specifically, ContextForge is the fastest path to
persistent, project-aware memory because it connects as an MCP server and loads
context automatically at session start. For a general-purpose memory layer across
any stack, Mem0 leads on adoption and Zep on benchmark accuracy.

Does Claude have built-in memory?
Claude Code has CLAUDE.md files and auto-memory for lightweight persistence. For
richer, searchable, project-scoped memory that syncs across tools, teams add a
dedicated memory tool like ContextForge or an MCP memory server.

What's the difference between vector memory and knowledge-graph memory?
Vector memory (Mem0, Pinecone) retrieves by semantic similarity. Knowledge-graph
memory (Zep, Cognee) stores entities and relationships, so it can reason about how
facts connect and change over time — at the cost of more complexity.

Are these AI memory tools free?
Most ship meaningful free tiers or are fully open source and self-hostable —
Mem0 (~10k adds/mo), Zep (~1k credits/mo), Letta and Cognee (OSS). ContextForge
offers a free tier to start.

Want persistent memory for Claude in about five minutes? Try ContextForge —
connect it as an MCP server and your assistant remembers your projects across
every session.

One Developer, Five Terminals, Zero Awareness

Alfredo Izquierdo — Wed, 08 Jul 2026 13:43:46 +0000

One Developer, Five Terminals, Zero Awareness

It's 11 p.m. and I have four terminals open.

One is running a Claude Code session on the auth refactor. Another is in a git worktree, rebuilding the tests. A third is reviewing a pull request. A fourth is just… there, waiting, because I know I'll need it in ten minutes. Somewhere in the mix there's a small team of sub-agents fanning out on a migration.

I'm not doing this because I enjoy the chaos. I'm doing it because this is what "productive" looks like now.

If you ship software with AI agents, you already know the feeling. One agent working one task, start to finish, is too slow. So you split the work. You open a second window. Then a third. You spin up a worktree so two branches can move at once. You hand a batch of independent tasks to a fleet of sub-agents and let them run. Parallelism is the only lever left when a single session can't keep up with the size of what you're trying to do.

And it works — right up until it doesn't.

The parallel blind spot

Here's the thing nobody tells you when you start running sessions in parallel: every one of those sessions is an island.

Session A is deep in the auth module. It's been there for twenty minutes, halfway through a refactor, files open, changes uncommitted. Three minutes later, Session B — a completely separate process, in a completely separate terminal — also reaches for the auth module. Not because it's reckless. Because it has no idea Session A exists.

Now you have two agents editing the same code with no knowledge of each other. One overwrites the other's assumptions. A merge conflict blooms out of nowhere. Or worse — no conflict, just two half-finished ideas quietly braided into the same file, and you don't notice until the tests go red for reasons that make no sense.

You lose exactly the time parallelism was supposed to save. That's the trap. The faster you go by splitting work, the more surface area you create for the splits to collide — because none of them can see the others.

I started calling this the parallel blind spot. You added more hands to move faster, and the hands can't see each other.

Memory solves "what happened." This is "what's happening."

If you've used ContextForge, you know it already gives your agents a memory that survives every session — the decisions, the corrections, the constraints, carried from one session to the next so your agent stops forgetting Friday by Monday.

But durable memory answers a question about the past: what happened before. The parallel blind spot is a different question entirely — a question about right now:

Who else is working on this, at this moment, while I am?

Memory is history. This is presence. A session's history tells you what it did yesterday; it tells you nothing about the session running in the terminal next to it this second. No amount of "remember what happened" fixes "I can't see what's happening."

That's the gap. And for a while, it was a gap I only half-noticed — because when it's just you and one terminal, it doesn't exist. It only shows up once you're deep enough into parallel work to get bitten by it.

The comment that named it

Then a reader left a comment on one of my posts that named it exactly.

They pointed out that ContextForge covered the single-session story beautifully — memory that persists — but that the multi-session case was wide open. When you run two or more agents against the same project, there's no live shared-state layer. Nothing that lets Session A raise a hand and say "I've got the auth module right now" so Session B doesn't walk into it.

Reading it, I felt that particular sting of good feedback: the obvious thing you somehow hadn't let yourself see. They were right. Memory across sessions was solved. Awareness between sessions wasn't. It had a name now, and once something has a name, you have to go build it.

So I did.

Session Presence: a live "who's here" for your agents

The new feature is called Session Presence, and the whole idea fits in one sentence: your parallel sessions can now see each other in real time.

Here's how it actually works, because the best part is how little you have to do:

It registers itself. Every Claude Code session (or Cursor, or any MCP client) automatically announces itself as live the first time it does anything. You don't run a command. You don't think about it. The moment a session starts working, it's on the board.
It stays honest. Each session sends a quiet heartbeat every couple of minutes. So the list is always live sessions — not a graveyard of things you closed hours ago. A session that dies without saying goodbye simply ages off on its own.
It disappears cleanly. When you close a session, it's removed at once — even in the split second before the process is fully killed. No stale ghosts lingering on the list.

On top of that, three small tools give the agent a voice:

session_update — "I'm working on the auth module." One session declares what it's focused on.
session_list — "Who else is on this project right now, and what are they doing?"
session_end — "I'm done here."

And you don't have to memorize any of that. You just talk. Ask your agent, in plain English, "is anyone else working on this project right now?" — and it checks the board and tells you: yes, another session has been on the auth module for the last few minutes; you might want to steer clear.

One more thing that matters: it's advisory, not a lock. Presence is a "busy" sign on a door, not a key that bolts it shut. It doesn't stop you from doing anything — it just makes sure you're never doing it blind. You stay in control; you just get to make the call with the full picture instead of half of it. And it's scoped to the project you're actually in, so a busy afternoon across five different repos doesn't turn into noise — you see the sessions that can actually collide with yours, and nothing else.

What it feels like in practice

Back to that 11 p.m. scene. Two sessions, both drifting toward the auth module.

With presence, the second one asks the board before it dives in. It sees that Session A is already there, focused on exactly that. So instead of colliding, it picks up the tests — the other thing on the list that nobody's touching. No conflict. No braided half-ideas. No 30 minutes lost untangling a mess that never needed to happen.

That's the whole win. It's not flashy. It's the quiet difference between five sessions working near each other and five sessions working blind next to each other.

Try it this week

If you're already running parallel sessions — worktrees, agent teams, three terminals before lunch — this is for you.

Update to the latest ContextForge MCP. Session Presence ships in the current release and works with Claude Code, Cursor, and Copilot through MCP — so even if you bounce between all three tools in a day, your sessions still see each other.
Ask "who else is here?" at the start of a session. Make it the first thing you do when you sit down, the same way you'd glance around an office before taking a desk.
Say what you're working on when you switch tasks. One sentence — "I'm on the payments flow now" — and every other session can see it.
Already have a CLAUDE.md? Re-running npx contextforge-mcp init is safe, it's idempotent per section. It checks for a hidden marker and only appends what's missing. Your existing content and your own edits stay exactly as they are; it just adds the new "Session Presence, Coordination Rules" block if it isn't there yet.

It's on the free tier. Five minutes to set up. And if you've ever lost an evening to two of your own agents fighting over the same file, you already know exactly what it's worth.

Parallelism without awareness isn't speed. It's a collision waiting to happen.

Give your sessions a way to see each other.

Give Your AI Coding Agent a Memory That Survives Every Session

Alfredo Izquierdo — Fri, 26 Jun 2026 22:02:27 +0000

Open a new session with Claude Code, Cursor, or Copilot and it has no idea what you were doing yesterday. Your stack, your decisions, the bug you spent an hour explaining — gone. So you re-explain. Again.

The root cause is simple: your AI's memory only lasts one conversation. Close the terminal and it's wiped.

ContextForge fixes that. It's an MCP server that gives any AI agent a permanent, searchable memory that carries across every session and every project. Below is the full setup — it takes three commands.

The walkthrough uses Claude Code as the example, but the same setup works for Cursor, ChatGPT, Claude Desktop, Windsurf, and GitHub Copilot.

📺 Watch the full walkthrough

▶️ Watch the setup on YouTube →

The setup, in three commands

1. Install the MCP server

npm install -g contextforge-mcp

2. Connect it to your editor — the wizard asks for your API key (grab a free one at contextforge.dev):

npx contextforge-setup

3. Initialize your project — this is the step people skip:

npx contextforge-mcp init

That last command writes a small rules file (CLAUDE.md for Claude Code, .cursorrules for Cursor) that tells your AI to use ContextForge for memory. Without it, your agent silently falls back to its built-in memory and ignores ContextForge — even though the server is connected.

The payoff

Once it's connected, you just talk to your agent like normal:

"Remember this is a todo app with Next.js and Supabase, deployed on Vercel. Save it to memory."

It stores that as a real, searchable memory — not in the chat, in a permanent store. Plant a couple of tasks the same way, then close the terminal and open a brand-new session:

"Let's start working on this project. What do I have pending?"

And it knows. New session, clean slate, and your agent already has your stack, your context, and your open tasks — no re-explaining. You can browse everything in the dashboard, organized by project.

Try it

ContextForge has a free tier — no credit card. Give your AI a memory that actually sticks:

👉 Get started at contextforge.dev

Works with Claude Code, Cursor, ChatGPT, Claude Desktop, Windsurf, and GitHub Copilot.

Your CLAUDE.md Is Lying to Your Agent — Why a Stale Instructions File Is Worse Than None

Alfredo Izquierdo — Tue, 23 Jun 2026 14:20:31 +0000

Your CLAUDE.md Is Lying to Your Agent

An empty CLAUDE.md is honest.

When the file isn't there, your agent does the sensible thing: it looks around. It reads the code. It asks you a question. It admits, in its quiet way, that it doesn't know yet — and so it goes and finds out.

A stale CLAUDE.md does the opposite. It walks into the room with total confidence and tells your agent something that used to be true. And your agent believes it. Why wouldn't it? You wrote it down. You committed it. It's the context file.

That's the part nobody warns you about. We talk about CLAUDE.md like it's free insurance — write it once, and your agent stops doing dumb things. Nobody mentions that the file has a half-life, and that a decayed instruction doesn't fall silent. It keeps talking. It just starts being wrong.

The Friday I got betrayed by my own notes

Let me tell you how I learned this, because I learned it the embarrassing way.

A few months ago I spent a Friday afternoon cleaning up a project. You know the kind of afternoon — the satisfying one. I pulled authentication out of a fat utils.ts file and gave it its own home. I renamed a module that had been bugging me for weeks. I deleted a helper we'd stopped using and replaced it with something cleaner. I committed all of it, closed the laptop, and felt like a responsible adult.

What I did not do was open CLAUDE.md. It was three weeks old. It still said "auth lives in utils.ts." It still named the module I'd just renamed. It still recommended the helper I'd just deleted.

Monday morning, I asked my agent to add a small feature near the auth flow. And it did exactly what I'd told it to do — back in a version of the project that no longer existed. It went looking for auth in utils.ts. It reached for the dead helper. When it couldn't find them, it didn't stop and ask. It reconstructed them. It rebuilt a little ghost of last month's codebase, confidently, because the one document I'd told it to trust said that's how things were.

The model wasn't broken. The reasoning was fine. It followed its instructions perfectly. The instructions were just lying to it — and I was the one who'd written the lie and signed it.

The half-life of a CLAUDE.md

Here's the uncomfortable truth about that file: it starts dying the moment you save it.

A CLAUDE.md is a static photograph. Your codebase is a moving thing. Every commit, every rename, every "actually, let's not do it that way" pulls the real project a half-step away from the photograph. None of those moves announce themselves to the file. The file has no idea Friday happened.

So the gap opens quietly. Day one, the photo is perfect. Week two, a couple of details are off. Month two, whole paragraphs describe a project that's been refactored out from under them. And the worst part is that it still reads fine. Stale documentation doesn't look stale. It looks authoritative. That's exactly what makes it dangerous.

This is the same disease I wrote about in context rot — more text doesn't mean more truth. A longer CLAUDE.md isn't a more reliable one. It's just a bigger surface for the rot to spread across.

Why "wrong" is worse than "empty"

We treat having some context as strictly better than having none. With static files, that math is backwards.

Anthropic's own data tells you why. The biggest single category of agent failure isn't creativity or hallucination — it's consistent wrong interpretation: the agent making the same incorrect assumption, every single run. A stale CLAUDE.md is a factory for exactly that failure. It hands the agent a wrong assumption and stamps it "official." Now the mistake isn't a one-off. It's load-bearing. Every session starts from the same wrong place and marches confidently in the same wrong direction.

Compare the two failure modes honestly:

No file: the agent is uncertain, so it explores, asks, and checks. Slower, occasionally annoying — but it self-corrects.
Stale file: the agent is certain, so it doesn't check. It just executes. Fast, smooth, and wrong in a way you won't catch until it's three commits deep.

Uncertainty is recoverable. Misplaced confidence is the thing that ships the bug.

The three ways it rots

It's never dramatic. It's always small. In my experience it's almost always one of these three:

The map stops matching the territory. You move a file, rename a module, restructure a folder. The CLAUDE.md still points at the old address, so your agent keeps knocking on a door that isn't there — and then builds a new door rather than admit it's lost.
A reversed decision keeps giving orders. "We use library X." Three weeks later you rip out library X because it didn't support your runtime. Nobody tells the file. It keeps cheerfully recommending the thing you spent a whole afternoon removing.
Yesterday's conventions outlive themselves. The rule that was right when it was just you becomes wrong the moment a teammate joins, or the project grows past the shape it had when you wrote it down.

Each one is tiny. Each one is invisible until an agent acts on it. And the friction of keeping all three in sync, by hand, forever — that's the actual problem.

"Just keep it updated" is not a plan

I know what you're thinking, because I thought it too: fine, I'll just keep the file current.

You won't. Not because you're lazy — because nobody does. Documentation that has to be hand-updated drifts out of date in every team that has ever existed, and a CLAUDE.md is documentation wearing an agent's clothes. The instinct to write down what you learn is exactly right. The mechanism — a flat file you have to remember to edit at the precise moment your hands are busy doing the thing that just made it wrong — is what's broken.

This is the same gap I keep circling back to in why your AI forgets everything: the problem was never that the agent had no memory. It's that the memory lived in a place that couldn't keep up with you. A static file can't keep up. It was never built to.

What living memory actually looks like

The fix isn't a better file. It's a different shape entirely.

Imagine memory that updates from the work instead of from your discipline. You correct the agent once — "auth moved, it's in its own module now" — and that correction sticks, surfacing the next time it's relevant instead of waiting for you to remember to go edit a paragraph. The renamed module updates because you renamed it, not because you also opened a markdown file afterward. The reversed decision stops giving orders the moment you reverse it.

And because it isn't trapped in one tool's config file, it follows you. Claude Code on Monday, Cursor on Tuesday, Copilot for the PR review on Wednesday — same memory, same truth, no three-way drift between three stale files telling three agents three different versions of last month.

That living layer is what I built ContextForge to be: a memory that plugs into Claude Code, Cursor, and Copilot over MCP, holds your corrections and decisions in one place, and surfaces the right one at the right moment instead of handing your agent a month-old photograph and calling it context.

You don't have to use mine. You can roll your own. What you can't do — what I tried to do, on that Friday, and failed — is keep a static file honest by sheer force of will.

What to do this week

Three things, and you can start the first one in the next ten minutes:

Audit your CLAUDE.md for lies. Open it and read it like a stranger. Every path, every "we use," every convention — is it still true today? Count the ones that aren't. That number is how often your agent has been confidently misled this month.
Split the durable from the decaying. Some things in that file are genuinely stable (the project's purpose, hard constraints). Some are just state that caches the current shape of the code — and state belongs somewhere that updates itself, not in a file you have to babysit.
Try a memory layer. ContextForge has a free tier that plugs into Claude Code, Cursor, and Copilot via MCP. Five minutes to set up. Your corrections start sticking instead of rotting.

An empty CLAUDE.md admits it doesn't know. A stale one pretends it does — and your agent can't tell the difference.

Stop asking your agent to trust a photograph. Give it something that can actually keep up with you.

The Week Two Problem: 60% of AI Agent Failures Are Not the Model's Fault

Alfredo Izquierdo — Tue, 26 May 2026 16:16:31 +0000

60% of AI agent failures are not from the model.

Read that again. Not from the model. And almost every dev I talk to is still debugging the model — swapping Sonnet for Opus, retuning prompts, comparing Claude Code vs Cursor vs Codex.

LangChain's 2026 production report found that the majority of agent failures trace to the harness, not the LLM. Anthropic's own data shows 71% of Claude's failures come from "consistent wrong interpretation" — the same incorrect assumption, every run.

If you've ever shipped an AI agent, watched it work for a week, then watched it break in week two on something you already fixed — you've lived this. It's not your prompts. It's not the model. Your agent has no memory of what happened on Friday.

The Week Two Problem

There's a pattern that anyone running real AI agents recognizes:

Demo: flawless. The room claps.
Week one: holds up. You're a believer.
Week two: the agent makes the same mistake you corrected on Friday. Then it makes it again on Wednesday. Then on the following Monday.

I started calling this the Week Two Problem because that's when the gap shows up — between "works in a demo" and "actually survives in production." The first week, you're still tuning. The second week, the tuning starts un-tuning itself.

The strange part: nothing changed. Same model. Same prompts. Same tools. The only thing that drifted was the agent's awareness of what already happened.

The Data Nobody's Talking About

I've spent the last month reading every "my agent broke" thread I could find — Reddit, HN, DEV.to. The same three data points keep showing up:

1. LangChain 2026 production report: Around 60% of agent failures trace to the harness, not the model. Cold boots, lost identity across sessions, poor sub-agent briefing — all the things the LLM is not responsible for.

2. Anthropic's own evals: 71% of Claude's failures in production come from "consistent wrong interpretation" — making the same incorrect assumption across every run. If the agent had memory of "we already tried that, here's why it doesn't work," that whole bucket disappears.

3. The 21,000-token typo fix: A Claude Code agent was logged consuming over 21,000 input tokens to make a one-line spelling correction. Why? Because every run re-loads the same context from scratch, including the things the agent already learned and forgot. Reddit practitioners report 70–120x cost spikes on multi-step agents for exactly this reason.

These are not three problems. They are one problem wearing three costumes. The harness doesn't remember.

Why a Bigger Context Window Won't Save You

The instinct, when an agent forgets, is to give it more room to remember. Bigger context window. More tokens. Stuff the whole project into the prompt.

I wrote about why this fails — it's called context rot, and it makes the problem worse, not better. A bigger haystack doesn't help you find the right needle. It just gives the model more wrong needles to confuse the right one with.

If you've been told "the new model has a 2M token context window, so memory is solved," that's the same vendor selling you the same problem with more pages.

Memory ≠ Context

Here's the distinction that matters, and almost no one names it cleanly:

Context is what your agent sees on this turn. The current prompt, the current tools, the current scrollback. It dies when the session ends.
Memory is what survives the session. What the agent learned on Tuesday and can recall on Friday. What it tried, what failed, what you corrected, what the constraint actually was.

A bigger context window grows the first thing. It does nothing for the second.

This is why Claude's built-in memory feature, Cursor rules, .cursorrules, and CLAUDE.md files are all half-solutions. They store some memory in some place, often tied to a specific tool. The moment your workflow crosses tools — Claude Code Monday morning, Cursor Tuesday afternoon, Copilot for the PR review — the memory doesn't follow. So you end up with three different agents with three different partial views of the same project, all making the same wrong assumption from earlier this week.

This is the same pattern I described in "Why Your AI Coding Assistant Forgets Everything" — every session starts from zero, no matter how many notes you keep on the side.

That's the Week Two Problem in slow motion.

The Missing Harness

What would a real harness look like?

It would store corrections once. When you tell the agent "don't use that library, it doesn't support our Node version," that constraint persists — across sessions, across tools, across the entire team. The next time any agent on any tool reaches for it, the memory layer says no.

It would recognize patterns across sessions. Not "remember everything verbatim" — that's just context rot in a new bottle. But "remember the decisions and the constraints and the things-that-did-not-work." The model handles reasoning. The harness handles continuity.

It would reduce token spend, not increase it. Because the agent stops re-discovering things it already learned. The 21,000-token typo fix becomes 1,200 tokens because the agent already knows the file's conventions, the recent corrections, the patterns that matter.

This is the layer I built ContextForge for. It's a memory layer that plugs into Claude Code, Cursor, Copilot, and any MCP-compatible client. Corrections in one place. Persistence across sessions. Relationship-aware recall so the right memory surfaces at the right moment, not all of them at once.

It's not the only way to solve this. You can hand-roll a memory layer. You can build your own embedding store. You can chain together vector DBs and tool definitions. What you cannot do — and what nine out of ten teams are still trying to do — is keep debugging the model and expecting the failures to stop.

What to Do This Week

If you've been losing time to week-two failures, three things you can do right now:

Audit one agent. List every correction you've made in the last 14 days. How many were persisted? How many will you have to make again next week? That number is your harness debt.
Separate context from memory in your head. Context is the turn. Memory is the relationship. They are not the same thing, and the same tool rarely solves both.
Try a memory layer. ContextForge has a free tier that plugs into Claude Code, Cursor, and Copilot via MCP. Five minutes to set up. Your agent stops forgetting Friday by Monday.

The Week Two Problem isn't a model problem. It never was.

Stop debugging the model. Start asking what your harness remembers.

Skills Were Dead Prompts. Routines Made Them Alive.

Alfredo Izquierdo — Thu, 14 May 2026 16:45:46 +0000

A few weeks ago I shipped Skills — a way to save AI prompts as reusable templates inside ContextForge, so my best prompts wouldn't keep dying in a Notion page nobody opens.

It worked. I stopped losing them.

Then I noticed something worse.

I had a Skill that drafts marketing copy every time we ship a feature. Another that summarizes my weekly progress. Another that generates LinkedIn posts. They were all sitting there, clean and named, in a tab I'd open every Monday morning and slowly click "Run" on like a factory line.

That's when it hit me: I built a library, not an assistant. Skills were just dead prompts with a database row.

So I built Routines.

What a Routine actually is

A Routine is a Skill on a cron expression. That's it.

You pick a Skill (the prompt template). You pick a schedule — daily, weekly, monthly, or any 5-field cron you write yourself. You pass the input variables. You hit Create. From then on, ContextForge fires the Skill on schedule, forever, until you pause or delete the Routine.

Skill:        "Write a LinkedIn post about {{topic}} in my voice"
Routine:      Daily at 9am Chicago, topic = "shipping in public"
Result:       A fresh draft in my execution history every morning,
              ready to copy-paste and post.

It sounds trivial because it is trivial as a user experience. The complexity is hidden, which is the point.

The first design was wrong

My first instinct was Postgres-native: use pg_cron (Supabase has it built-in) plus pg_net to make outbound HTTP calls every minute. Schedule lives in the database, no extra infra, beautiful.

I started writing it. Then I hit a wall I'd already climbed once.

ContextForge has two auth models. Dashboard users authenticate with a Supabase session JWT. MCP clients (Claude, in particular) authenticate with API keys we verify ourselves inside edge functions. Both eventually call the same skill-execute function via a "service-role bridge" — the function probes the database with the service role key, then trusts an x-cf-user-id header for the actual user identity.

This bridge took me two weeks to get right when I shipped Skills. I documented it in CLAUDE.md. I have memories about it. It's load-bearing.

pg_cron would have meant recreating it inside Postgres functions. PL/pgSQL talking HTTP to my own edge functions, replaying the auth dance, debugging it without proper logs. I'd be writing the same nasty integration twice.

So I pivoted. Vercel Cron pings a Next.js API route every minute. The route queries for due Routines, then fires each one against the same skill-execute edge function the dashboard already calls. Same path, same headers, same auth bridge. One source of truth for "running a Skill" — manual, MCP, scheduled, all go through the same door.

Sometimes the right architecture is the one that doesn't make you rewrite a thing you already trust.

The unglamorous parts

Three things bit me harder than the design:

1. Hobby plans don't allow per-minute cron.

I shipped to Vercel. The deploy failed instantly:

Hobby accounts are limited to daily cron jobs. This cron expression (* * * * *) would run more than once per day. Upgrade to Pro.

Pro is $20/month. I had to make a decision: pay it, downgrade the feature to daily-only, or use an external cron service (cron-job.org, free, hits my endpoint with a shared secret). I picked Pro. The math is simple — 5 Premium users at $15/month covers Pro + Supabase Pro, and the feature is worth nothing if I cripple it to daily-only just to dodge $20.

2. CRON_SECRET hates whitespace.

The first deploy after Pro upgrade failed with:

The CRON_SECRET environment variable contains leading or trailing whitespace, which is not allowed in HTTP header values.

I had copy-pasted the secret from a terminal. It had a trailing newline. Five minutes of "why" before I realized.

3. The Premium gate I wired in stripe-webhook was missing the Routines limit.

I added a max_routines column on organizations. Updated the dashboard to gate behind it. Tested local with a flipped plan column — perfect. Deployed.

Then a paying Premium user opened Routines and saw the upgrade banner. Their plan column said premium, but max_routines was still 0.

Reason: the Stripe webhook handler that bumps plans had a PLAN_LIMITS constants object. It set max_projects, max_spaces, max_collaborators, etc., — but I'd added max_routines to the database without adding it to that constants file. Subscribers got upgraded everywhere except the column my new gate checked.

One-line fix in _shared/plan-limits.ts plus a backfill migration:

UPDATE organizations SET max_routines = 999 WHERE plan = 'premium';
UPDATE organizations SET max_routines = 0   WHERE plan IN ('free', 'pro');

Embarrassing. Also the kind of bug that only ships if you have actual paying users hitting it, which is its own kind of milestone.

What it looks like in practice

The dashboard side is dead simple. Open any Skill-enabled project, click Routines, click + New Routine. The form is one screen:

Pick the Skill
Name the Routine
Pick a preset (daily, weekly, etc.) — the cron expression auto-fills, but you can override
Pick a timezone (defaults to your browser's)
Paste your input params JSON

Hit create. You land on the Routine detail page with a ▶ Run now button (fires immediately, ahead of schedule), a Pause/Enable toggle, execution history, and a Danger Zone with delete.

Every fire writes a row to the audit log: status, output, tokens used, cost. Click any row to expand and see the rendered prompt + final output. Same component the manual Skill runs use — Routines didn't get their own special view, they get a trigger_type=scheduled tag and they're one query away from filtering.

Schedule it from Claude

This is the part I'm most proud of.

The MCP exposes seven new tools — routines_list, routines_get, routines_create, routines_update, routines_toggle, routines_run_now, routines_delete. From inside any Claude session connected to ContextForge, you can say:

"Schedule the LinkedIn Post skill to run every weekday at 9am Madrid time."

Claude picks the right skill, infers schedule_preset = "daily", fills the cron expression, sets timezone = "Europe/Madrid", and creates the Routine. You never touch the dashboard.

This matters more than it sounds. The pitch for ContextForge has always been "let agents act on your memory, not just read from it." Routines is the first feature where Claude can schedule its own future work — close a loop the agent owns, end-to-end.

What's next

Skills + Routines is the start of what I'm calling the agentic OS for context. A library of named prompts (Skills), the ability to run them automatically (Routines), and an agent (Claude via MCP) that can create both for you on demand. The next layer is chains — Routines that fire other Routines, conditional triggers, "if this Skill output contains X, fire that Skill with Y."

But that's the next article.

For now: I have 26 users on the free plan. None of them have Routines yet. But the day one of them upgrades to Premium and starts seeing AI-generated marketing copy show up in their notifications at 9am every Monday, this whole thing pays for itself.

If that sounds useful — give ContextForge Memory a try. The Skills tier is free. Routines is the upgrade.

ContextForge Memory is a persistent memory layer for AI coding agents. Built on Supabase + Next.js. BYOK for all LLM operations. Docs · GitHub · Twitter

I Built Skills Because My Notes App Was Full of Dead Prompts

Alfredo Izquierdo — Tue, 12 May 2026 13:49:13 +0000

Open your Notes app right now. Search "prompt."

Count what comes up.

If you're anything like the 200+ developers I've talked to in the last six months, the answer is somewhere between "more than I want to admit" and "oh god I forgot about that one."

You have a folder of prompts that work. The one that writes your release notes the way your team actually wants them. The one that turns a messy PR into a clean changelog entry. The one that drafts customer emails in your tone. The standup summarizer. The weekly recap generator. The "explain this code in plain English" template that takes you 12 tries to get right and then lives forever in a screenshot.

None of them run.

They're just text. Pasted into ChatGPT every time you need them. Copy. Paste. Edit. Paste. Edit again. Wait for output. Copy the output. Paste it where it actually needs to go.

This is the prompt graveyard, and you're not the only one who has one.

The Hidden Cost Of "I'll Just Paste It Again"

Here's the cost nobody talks about.

Every time you re-type or re-paste a prompt, something drifts. You change a word. You forget a constraint. You leave out the example you added last time that made the output good. You think you're using "the prompt that works" — but you're actually using "the prompt that worked the first time, three weeks ago, before I tweaked it twice."

By the time you've used a good prompt ten times, you've used ten slightly different prompts. The output quality wobbles. You start blaming the model. "GPT-5 is getting worse," you say. The model didn't get worse. Your prompt did, and you didn't notice because there was no version of it that was actually fixed in place.

This is the same problem we used to have with shell scripts before we put them in a repo. The same problem we had with email templates before tools like Front and Mixmax. The same problem we had with code snippets before Gist existed.

The work was real. The artifact was real. The home for the artifact was a chat history and a Notes app — neither of which were built to be the home for it.

The Other Cost: Context Lives Where The Work Lives

There's a deeper problem.

The prompts you'd want to save aren't generic. They're project-specific. The release note prompt is good because it knows your product's voice. The PR summarizer is good because it knows your codebase's conventions. The customer reply template is good because it references your refund policy.

When that prompt lives in your Notes app, it lives away from the project. Your teammate can't find it. Your future self can't find it. Six months from now when you need it, you'll search Slack DMs and ChatGPT history for forty minutes and rewrite it from scratch because that's faster than the search.

The prompts that are most valuable are the ones most tied to a specific project. And those are exactly the ones that have nowhere to live.

What A Real Home For Prompts Looks Like

If we built it from scratch, knowing what we know now, what would it look like?

A prompt would live inside the project it belongs to, the same way a README does.
It would have a name and a description so you and your team can find it.
It would be a template, not a paste — with placeholders you fill in at run time.
It would have version history so the prompt that worked last week doesn't quietly become a different prompt this week.
It would run on your own LLM key so the output stays yours and the cost goes through your account, not someone else's.
It would keep a log of every run — input, output, tokens, cost — so you can actually see whether your prompt is getting better or worse over time.
It would be callable from your AI agent so Claude or Cursor or Copilot can run it for you without you having to copy-paste yet again.

This is the shape of the thing. We just shipped it.

Meet Skills

Skills are reusable AI prompts that live inside one of your ContextForge projects.

Each Skill has:

A name and description — visible in your project's Skills tab
A prompt body with {{variables}} you substitute at run time
A provider and model — Anthropic Claude or OpenAI GPT, your pick
An optional save target — auto-save each run's output to a knowledge space
An execution history — every run, with input, output, tokens, cost, and timestamp

You write the prompt once. You name it. You run it from the dashboard with one click, or from Claude via MCP with one sentence. You stop pasting.

Here's what one of my own Skills looks like.

Name: Feature Announcement Pack
Provider: OpenAI / gpt-5-mini
Body:
  You are a developer-marketing assistant for ContextForge Memory.
  A new feature just shipped:
    FEATURE: {{feature}}
    WHAT IT DOES: {{what_it_does}}
    WHO BENEFITS: {{audience}}
  Produce 4 outputs in this exact order:
    ## 1. Tweet — under 280 chars, one emoji, developer voice
    ## 2. LinkedIn post — 3 paragraphs, confident but humble
    ## 3. Changelog entry — Title / Summary / What's new / Why it matters
    ## 4. Docs blurb — 2 paragraphs, plain English, no marketing fluff

When I ship a new feature, I open the Skill, paste this into the input panel:

{
  "feature": "Skills",
  "what_it_does": "Save reusable AI prompts as named, versioned templates inside a project.",
  "audience": "developers tired of re-typing prompts"
}

Click Execute. Five seconds later I have a tweet, a LinkedIn post, a changelog entry, and a docs blurb — all in my voice, all consistent with last week's announcement, all auto-saved to my Content Marketing space for review.

Here's me building and running this exact Skill in under 3 minutes:

[[YOUTUBE]]

Next week, when I ship the next feature, the only thing that changes is the JSON.

BYOK, Audit Log, And Why That Matters

Two things people ask first:

"Does ContextForge see my prompts and outputs?"

Your prompts and outputs live in your project. They're scoped by RLS to your organization. Nobody else can read them. We don't model-train on them. We don't store them off your row.

"Whose LLM key is being used?"

Yours. You add your Anthropic or OpenAI key to your project's settings, and Skills calls your account directly. We don't mark up tokens. We don't have a "ContextForge LLM credits" SKU. The dashboard shows the estimated cost of every run in USD so you can keep an eye on spend, but the bill goes from OpenAI/Anthropic to you, not through us.

The audit log is the third piece. Every run is recorded — successful or failed — with tokens, cost, the exact input params, and the model's output. You can click any row to expand it and see exactly what went in and what came out. If a Skill starts producing worse output, you can compare runs side by side and see where it drifted.

This is the part that's hard to do on your own. Even if you save your prompts in a Notion doc, you don't have a record of every time you ran them and what came out. That record is what turns prompts from craft into engineering.

The MCP Angle

There's one more piece, and it's the part that closes the loop.

Skills are exposed as MCP tools. That means Claude itself can run your Skills. Six tools are shipped: skills_list, skills_get, skills_create, skills_update, skills_run, skills_delete.

In practice, that looks like this:

"Run my Feature Announcement Pack skill for feature 'Routines' with what_it_does='schedule any Skill on a cron expression' and audience='devs who want cron for AI'"

Claude calls skills_run, the LLM does the work against your key, the run is logged in the same audit log as your dashboard runs, and the output comes back to your conversation.

You stop pasting. You stop re-typing. You start composing.

What This Replaces

If you've been using:

A Notes app for prompts → Skills replaces it. Versioned, executable, findable.
ChatGPT custom GPTs for personal prompts → Skills is the project-scoped, BYOK, no-vendor-lock version.
A bookmarked Claude conversation → Skills runs the same prompt without you having to open that conversation and scroll.
A doc full of "useful prompts" that nobody on your team actually opens → Skills lives next to the project, in the tool the team is already in.

Try It

If you've got a prompt you've been pasting into ChatGPT this week — the daily standup one, the customer reply one, the PR summarizer, the one you whisper to Claude every Monday morning — that prompt has a home now.

Open ContextForge → pick a project → Skills
Click New Skill
Paste the prompt. Replace your variable parts with {{placeholders}}.
Run it.

The prompt graveyard ends today.

→ Skills documentation
→ Get ContextForge

Your AI Is Drowning in Its Own Context — Why Longer Conversations Make It Worse

Alfredo Izquierdo — Tue, 05 May 2026 14:58:53 +0000

You know the feeling.

You started the conversation with your AI feeling great. It was helpful. It got you. You were on the same page. An hour in — maybe two — something quietly shifted. It started suggesting things you'd already ruled out. It forgot the tone you agreed on at the start. It told you a story you told it twenty minutes ago, like it was new information.

You didn't change anything. The AI didn't change. The conversation just... went somewhere bad.

If you've ever felt this — and almost everyone using AI has, whether you're writing a book, planning a wedding, building a business, learning something new, or yes, coding a project — you've met context rot. And no, the answer isn't a smarter AI or a longer "memory window." Most of the fixes you'll read about are solving the wrong problem.

What's Actually Happening

Imagine asking a friend to help you with something. The first ten minutes are great — they're focused, they remember what you said, they ask good follow-ups.

Now imagine that same friend, three hours later, after listening to everything you've said all afternoon. They're tired. They're mixing up details. They keep referencing something you mentioned an hour ago that doesn't apply anymore. They're not getting worse at their job — they're just buried under everything you've told them.

That's what's happening to your AI in a long conversation.

The longer it goes, the more it has to keep track of. Old questions. Drafts you abandoned. Decisions you reversed. Files you replaced. Tone you adjusted. By the time you're deep into the session, the AI is sifting through a pile of things you've said — and pulling up the wrong ones.

A 2026 developer survey found that 66% of people using AI tools say their biggest frustration is that the output is "almost right, but not quite." That "almost right" almost always shows up in the second half of a long session. Not in the first.

Why a Bigger "Memory" Doesn't Fix It

Every few months, an AI company announces a bigger context window — now your AI can hold a whole book in its head! A whole project! A whole year of conversation!

It sounds like the answer. It isn't.

Imagine handing that tired friend the entire transcript of your afternoon and asking them, "okay, now please remember what mattered." That's not better. It's the same problem with more pages.

A bigger memory window doesn't help your AI find the right thing. It just gives the AI more wrong things to confuse the right one with. The signal gets buried in the noise. You haven't solved the problem — you've made the haystack bigger.

This is why people keep telling you their AI "got dumber" after a long session. It didn't. It just has too much to look through, and no good way to know what still matters.

Where It Quietly Falls Apart

It contradicts itself. You spent half an hour deciding not to do something — then thirty messages later, the AI suggests it again like the conversation never happened. The decision is in there. It just got buried.

The output looks fine until you look closely. A paragraph that almost says what you meant. A summary that's mostly accurate. A plan that's almost the one you agreed on. Most of it works. The 10% that doesn't is the part that quietly breaks everything downstream.

You start fact-checking more than creating. This is the moment most people don't notice. You're not really collaborating with the AI anymore — you're auditing it. Re-reading. Correcting. Re-explaining. The conversation has become work about the conversation.

By that point, the AI isn't saving you time. It's costing it.

"Just Start a New Conversation" Isn't the Answer Either

So you do the obvious thing. You close the chat. Open a new one. Fresh start.

Except now the AI knows nothing. It doesn't remember the tone you decided on. The story you've been building. The list of things that didn't work. The reason you ruled out the obvious answer two hours ago.

So you re-explain. Again. From the top. Ten minutes in, the new conversation feels great — because it's small. Then it grows. Then it rots. And you're right back where you started.

This is the trap most people are stuck in without naming it. Context rot if you keep going. Amnesia if you don't. Both burn your time.

The Real Fix: Memory That Remembers What Matters

Here's the shift that changes everything.

The problem isn't how much your AI can remember. It's what it remembers, and when.

Think about a really good colleague — the one who's worked with you for years. They don't remember every conversation you've ever had. They don't need to. What they remember is the things that matter: the decisions you've made, the way you like to work, the patterns you fall into, the things that have already been tried.

When something new comes up, they pull the relevant memory — not the whole archive.

That's what your AI is missing. Not a bigger window. A better way to remember.

This is the idea behind tools like ContextForge. Your decisions, your context, the things you've already established — they live outside the conversation. The AI pulls in only what's relevant when it's relevant. The chat stays short. The memory stays long. Context rot doesn't happen, because the conversation never gets bloated with things that don't matter.

It's the difference between an assistant who has read everything you've ever said, and one who actually knows you.

What You Can Do Right Now

You don't need a fancy tool to start fixing this. A few habits help:

Keep conversations short on purpose. When you find yourself scrolling up to remember what was said, that's the rot point. Close it. Start fresh — but bring forward only the decisions, not the full transcript.

Write down what mattered. The valuable part of a long session isn't the back-and-forth. It's the two or three things you actually decided. Capture those somewhere. Even a notes app works.

Don't confuse "long chat" with "real progress." A 60-message conversation isn't more thinking. It's more talking. Most of it is friction.

If you can, give your AI real memory. This is the bigger move. Tools that give your AI persistent memory — across sessions, across days — are how this actually gets solved. Your context becomes something the AI looks up, not something it has to drag through every prompt.

The Takeaway

Context rot isn't a problem with the AI. It's a problem with how we're using it.

We've all been told the answer is "more": more memory, more context, more tokens, more window. But more isn't the answer when the problem is signal getting lost in noise.

The people getting the most out of AI right now aren't the ones with the longest conversations. They're the ones whose AI doesn't have to re-learn them every time — because the important things are already remembered, and only show up when they matter.

A bigger memory just gives you more room to drown. The fix is remembering the right things.

ContextForge gives your AI persistent, curated memory — so what matters surfaces when it should, instead of getting lost in a long conversation. Free tier available at contextforge.dev

Vibe Coding Is a Trap — Why AI-Generated Code You Don't Understand Will Cost You

Alfredo Izquierdo — Tue, 28 Apr 2026 16:55:35 +0000

There's a story going around Reddit that hit me hard.

A guy spent three months building a side project with AI. Everything worked. The app shipped. Life was good. Then he needed to add one small feature — and realized he had no idea how his own code worked.

He ended up deleting 70% of it. Rewrote the whole thing in two weeks. Half the code, zero unnecessary complexity, and for the first time, he actually understood what he built.

The AI hadn't written bad code. It had written code that looked like it came from a big company — layers of abstraction, configuration systems for things that only had one option, wrappers on top of wrappers. All for a project built by one person.

This is what vibe coding looks like when the vibes run out.

What Even Is "Vibe Coding"?

You've probably done it even if you don't know the term. Vibe coding is when you tell AI what you want, it writes the code, you glance at it, it looks fine, and you move on. You're not really reading it. You're going by feel. The vibes are good, so you ship it.

And for a while? It feels amazing. You're building things faster than ever. The AI writes code that looks professional. Everything runs. You feel unstoppable.

Then something breaks.

And you're staring at code that has your name on it but feels like someone else wrote it. Functions you never asked for. Patterns you didn't choose. A project that somehow got huge while you weren't looking.

It's Only Getting Faster

Here's the thing — AI coding tools aren't slowing down. They're getting more autonomous. The latest trend is "agentic coding" — where the AI doesn't just suggest a line, it writes entire features on its own. It creates files, runs tests, fixes errors, all without you touching anything.

That's powerful. But it also means the gap between "what the AI built" and "what you understand" is growing every month.

When AI was just finishing your sentences, you were still driving. Now it's writing whole chapters while you're getting coffee. You come back to 400 new lines of code and think... I guess that's fine?

There's a line from that Reddit thread that stuck with me: "Speed without understanding isn't productivity. It's deferred confusion."

That's it. That's the whole problem.

Where It Falls Apart

When something breaks, you're lost. You didn't write it. You didn't design it. And the AI that did? It doesn't remember either. Every new conversation starts from scratch. So now you're debugging code you don't understand with an AI that doesn't remember building it.

When you need to add something real, you can't. The Reddit guy lived this. His AI built all these clever abstractions for problems he didn't even have. When he needed to add an actual feature, he had to first figure out all the unnecessary complexity the AI created. It was easier to start over.

The understanding disappears overnight. Maybe you spend an afternoon tracing through the code. You finally get it. The next morning? Gone. Not because you're forgetful — but because the AI that helped you understand it yesterday has zero memory of that conversation. You're explaining your own project to it all over again.

So What Do You Actually Do?

Look — nobody's going back to writing everything by hand. AI is too useful. The point isn't to stop using it. The point is to stop blindly trusting it.

Actually read what it writes. I know, obvious. But be honest — how often do you really read the full output before hitting accept? Take 60 seconds. If you can't explain it, don't ship it.

Write down your decisions. Why did you pick this approach? Why not the other one? The AI won't remember tomorrow, and honestly, neither will you. Keep a running log of the important calls.

Give your AI a memory. This is the big one. The core problem with vibe coding is that every AI session starts with amnesia. You explain everything, build something great, close the tab, and tomorrow it's all gone. The AI writes code that contradicts what you decided yesterday because it literally doesn't know yesterday happened.

That's why tools like ContextForge exist. It gives your AI persistent memory — your project context, your architecture decisions, your patterns — all carried across sessions. Instead of your AI writing generic code in a vacuum, it writes code that actually fits what you've already built. Because it remembers what you've already built.

Keep things simple. Small files, clear names, obvious structure. AI works better with less complexity, and so do you when you come back to it later.

The Real Takeaway

That developer didn't have a bad AI. He had a fast AI and no way to keep context between sessions.

Vibe coding isn't evil. The trap is letting AI generate code while you stop paying attention — and while the AI itself forgets everything between conversations.

The people doing well with AI coding right now aren't the fastest shippers. They're the ones who ship fast and can still explain what they built two weeks later.

Speed you can sustain beats speed you can't.

ContextForge gives your AI persistent memory — so it writes code that fits your project, not generic code you'll delete later. Free tier available at contextforge.dev

I Use 3 AI Coding Tools Every Day. Here's How I Keep Them in Sync

Alfredo Izquierdo — Tue, 21 Apr 2026 20:31:09 +0000

Let me tell you about my morning last Tuesday.

I opened Cursor to work on a feature I'd been building all week. I asked it to continue where I left off. It had no idea what I was talking about. So I spent ten minutes re-explaining the architecture, the decisions I'd already made, the files I'd already changed.

Then I switched to ChatGPT to brainstorm a tricky database problem. Same thing. Fresh conversation. No memory of the project. I copied and pasted three messages from yesterday's chat just to get it back up to speed.

By 10 AM, I'd already spent more time explaining my own work to machines than actually doing the work.

Sound familiar?

The Multi-Tool Reality

Here's something most people don't talk about: developers don't just use one AI tool anymore. According to recent surveys, the average developer uses 2.3 AI tools on any given day. Some of us use even more.

And it makes sense. Each tool has its strengths. I use Cursor for writing code inside my editor -- it's fast, it understands the file I'm looking at, and it makes great inline suggestions. I use ChatGPT for thinking out loud -- brainstorming approaches, asking "stupid questions" I'd be embarrassed to ask a coworker, and exploring ideas before I commit to them. And I use Claude Code for the heavy lifting -- multi-file refactors, debugging complex issues, and working across the whole codebase at once.

Three tools. Three different strengths. One massive problem.

None of them know what the others are doing.

The Invisible Tax

Every time you switch between AI tools, you pay a tax. Not in money -- in time, energy, and context.

Think about it. When you move from ChatGPT to Cursor, you're essentially starting a new conversation with someone who has amnesia. You have to re-explain:

What you're building and why
The decisions you've already made
The constraints you're working within
What you tried that didn't work
The conventions your team follows

This isn't a minor annoyance. It's a fundamental workflow problem. And it gets worse the longer your project goes on, because the gap between what you know and what your tools know keeps growing.

I've caught myself keeping a separate document -- a kind of "AI briefing doc" -- just so I can paste it into every new conversation. That's when I realized something was deeply broken.

Why Every Tool Forgets

To understand the problem, it helps to understand why it exists.

Most AI tools are designed around sessions. You start a conversation, you work, and when the conversation ends, it's gone. Some tools save your chat history, sure. But saving a transcript is not the same as remembering.

Remembering means understanding that when you say "the API we discussed yesterday," I should know you mean the Stripe webhook endpoint you were refactoring. It means knowing that your team uses Supabase, that you prefer server components over client components, and that last week you decided to split the monolith into three services.

No single AI tool does this well. And across multiple tools? Forget about it. Literally.

The problem isn't that these tools are bad. They're incredible at what they do. The problem is that they're isolated. Each one lives in its own bubble, with its own memory (or lack thereof), its own context window, and its own understanding of your project.

What "Keeping Them in Sync" Actually Means

When I say I keep my tools in sync, I don't mean I copy-paste between them. That's the duct tape solution, and it doesn't scale.

What I actually mean is that I use a shared memory layer -- a single place where project context lives and that all my tools can access.

Think of it like this. Instead of each tool having its own notebook that gets thrown away at the end of the day, they all share one notebook. When I make a decision in ChatGPT, that decision is available when I open Cursor. When Claude Code refactors a module, Cursor knows about it in the next session.

This changes everything. Instead of spending the first ten minutes of every conversation catching up, I just... start working.

The Pieces That Matter

Not all context is created equal. Over months of working this way, I've found that there are a few categories of information that matter most when syncing between tools:

Project decisions. Why you chose Postgres over MongoDB. Why the auth flow works the way it does. Why you're NOT using GraphQL, even though it seems like you should. These decisions get made once but need to be referenced dozens of times.

Architecture context. The shape of your codebase. Which services talk to which. Where the boundaries are. An AI that knows your architecture can make suggestions that actually fit.

Team conventions. How you name things. How you structure files. Whether you use semicolons. This sounds trivial, but an AI that follows your conventions saves you from constant code review friction.

What you tried that didn't work. This might be the most underrated one. Half the value of experience is knowing what NOT to do. When your tools remember your failed approaches, they stop suggesting them.

How I Actually Do It

I'll be honest with you -- I built a tool to solve this problem. It's called ContextForge, and it started as a personal hack before it became a product.

The idea is simple: ContextForge acts as a persistent memory layer that connects to your AI tools through MCP (Model Context Protocol -- the open standard that Anthropic created and that most AI tools are adopting). You store your project context once, and every tool that supports MCP can access it.

In practice, my workflow looks like this:

I make a decision or learn something important during a coding session
That knowledge gets saved to ContextForge (either automatically or with a quick command)
Next time I open any of my tools -- Cursor, ChatGPT, Claude Code -- the context is there

No copy-pasting. No briefing docs. No "as I mentioned yesterday" followed by five paragraphs of recap.

The first time I opened Cursor after a long ChatGPT brainstorming session and it already knew what I'd decided -- that was the moment I knew this approach was right.

What Changes When Your Tools Remember

The shift is subtle at first, but it compounds.

You stop repeating yourself. This alone saves 15-20 minutes a day. Multiply that across a week, a month, a quarter.

Your tools give better suggestions. An AI that knows your project gives answers that fit your project. Not generic Stack Overflow answers -- specific, contextual ones.

You switch tools without friction. The "warm-up tax" disappears. Cursor, ChatGPT, Claude Code -- they all start from the same shared understanding.

You build momentum. Instead of losing context every time you close a tab, knowledge accumulates. Your tools get smarter about your project over time, not dumber.

And maybe most importantly: you feel less alone. There's something genuinely reassuring about opening a tool and having it say, essentially, "I remember. Let's keep going." It turns AI from a stranger you have to brief into a collaborator that grows with your project.

The Bigger Picture

We're at a weird moment in software development. The tools are more powerful than ever, but the way we use them is still fragmented. We jump between contexts, re-explain ourselves, and lose knowledge at every seam.

I don't think this is permanent. The ecosystem is moving toward shared context. MCP adoption is accelerating -- 70% of major SaaS platforms already support it. The idea that your tools should know you and know your project is becoming obvious.

But you don't have to wait for the future to arrive. The pieces are here now. You just have to connect them.