Switching AI models feels like easy, freedom, but... every decision has their own trade-offs.
If one provider becomes too expensive, runs out of quota, or stops producing good results, I can move from GPT to Claude, Gemini, or a local model.
At least that is the theory, in practice, the model is only one part of the system.
I can replace the engine and still lose the workflow.
My decisions may still be trapped in Codex.
My project history may still be trapped in ChatGPT.
My agents, skills, MCP configuration, corrections, and working
conventions may still belong to the interface where I created them.
That is not portability. It is starting over.
The problem became visible when I changed agents
I regularly move between Codex and OpenCode. Each can work on the same repository and read the same files, but, a useful decision made in one session does not automatically become durable context for the next one.
I found myself repeating architecture constraints, rediscovering why a previous approach failed, and copying context between conversations. For a while, I treated part of this as a prompting problem.
I wrote longer instructions.
I maintained project files.
I copied the important parts of one conversation into the next.
It helped, but the context still belonged to the session.
I was not starting from a blank page
The first project that made persistent agent memory feel concrete to me was Engram by Gentleman Programming.
Engram demonstrated a useful pattern: important decisions could live outside the conversation, be indexed in SQLite, and return through MCP when a future coding session needed them.
It changed the question from:
Why do AI agents always forget?
to:
What should own the memory when the agent does not?
When I first evaluated Engram, the path I encountered was centered on a local SQLite database and coding-agent workflows. It was useful for an individual developer, but it raised questions for the system I wanted to build.
How would a team share memory without passing database files around?
How would personal, work, and client memories remain isolated?
How would a user know which command to call, where a memory lived, or why search did not find it?
How would uninstalling the integration remove generated configuration and local artifacts instead of leaving them behind?
Engram did not give me the final architecture for it. It gave me the first useful set of constraints.
Then I found the GBrain
Shortly after build my memory MVP, I started studying GBrain by Garry Tan.
The workflow I first learned from centered the brain around human-readable Markdown.
I liked that.
The knowledge was inspectable. A person could open the files, understand what the agent knew, and keep the content outside a proprietary chat product. But I did not want a directory of Markdown files to become an operational shared-memory store. For a personal knowledge base, files are a powerful interface, but for many agents, users, tenants, concurrent writes, access policies, migrations, and audited history, I wanted a database to enforce stronger boundaries.
The lesson was not that Markdown was wrong; It was that human-readable knowledge and operational agent memory do not always need the same storage model.
These projects have changed since then
Both projects are evolving quickly.
Engram now documents cloud replication, Git-based synchronization, and setup for a wider range of MCP agents.
GBrain now combines its Markdown-facing brain with PGlite or Postgres and supports broader personal-agent and coding-agent workflows.
That evolution reinforces the larger point, Agent memory is becoming infrastructure and infrastructure needs more than retrieval quality.
Key takeaways
The projects helped me separate several problems that are often grouped under the word “memory.”
Persistence = Can useful context survive the end of a session?
Portability = Can another agent or interface retrieve it without importing a transcript?
Ownership = Does the user control the storage, or does the memory belong to the chat provider?
Boundaries = Can personal, work, client, and team context remain separate?Provenance = Can I tell which connected agent created a memory and why it was saved?
Lifecycle = Can I preview a connection, approve it, verify it, revoke it, and remove it cleanly?
A system can solve persistence while failing the other five.
The missing layer in model portability
Most model-portability conversations focus on routing.
GPT unavailable
→ use Claude
→ use Gemini
→ use a local model
That is valuable, but, the model is not the durable asset.
The durable asset is everything the system learned while helping you work:
Architecture decisions.
Corrections.
Preferences.
Reusable workflows.
Failed approaches.
Project constraints.
The reason each decision mattered.
If those stay behind when the model changes, the workflow is still locked in.
Real portability needs at least three independent layers:
Replaceable interface
Replaceable model
User-owned context
The third layer is the one I had been missing.
Portable does not mean globally shared
There is also a dangerous version of portability.
If every agent can read every memory, context can cross boundaries where it does not belong.
A work agent should not automatically read personal information.
A client project should not inherit the decisions of another client.
A cloud chat surface should not receive local context merely because it uses the same model.
Memory must be portable without becoming one undifferentiated pool.
The user decides which workspaces and connected agents belong inside that boundary.
Where this led
The goal became more specific:
Give different agents access to the same durable context without giving up ownership, isolation, or trust.
That requires more than storing text.
It requires a common contract across MCP and OpenAPI clients.
It requires local storage for an individual and a credible path to shared team storage.
It requires one identity per connected agent, not one generic key pretending to be everyone.
It requires a human-readable explanation of why something was persisted.
It requires installation and removal to be treated as part of the product rather than documentation left for the user to decipher.
But if my decisions, corrections, and working history cannot move with me, I still do not own the workflow.
I only rent a choice of engines.
That is why I started Alfred Memory: to make your context portable, your workflow yours, and switching agents feel like freedom instead of starting over.
See you next week—or maybe sooner.
— Gilberto O.