Persistence of Memory: AI Can’t Learn without It
(End of) June 2, 2025
There’s a moment in every AI project when you realize the difference between intelligence and memory. Intelligence can solve problems. Memory can learn from solutions. Today’s story is about trying to give Piper Morgan the ability to remember — and discovering that persistence is more complicated than “just add a database.”
The persistence problem
As of June 2, every conversation with Piper Morgan started from scratch. The intent classifier could achieve 0.95 confidence on PM requests, and the orchestration engine could execute multi-step workflows with context passing. But ask about a similar request the next day? Complete amnesia.
This was like having a brilliant consultant who gets a concussion between every meeting. Helpful in the moment, useless for building on previous insights.
The obvious solution was persistence. The less obvious challenge was figuring out what to persist.
The first attempt: store everything
My initial instinct was to save workflow results. User asks for feature analysis, AI generates recommendations, database stores the output. Simple enough.
But this approach treats AI interactions like static documents instead of dynamic learning opportunities. You get a historical record, not accumulated wisdom.
My LLM advisor suggested we shifted focus from storing outputs to storing the reasoning process itself.
Database design: domain models drive schema
The earlier June 2 session had laid important groundwork here. Instead of generic “AI_interactions” tables, we modeled PM concepts as first-class database entities:
Products with features and stakeholders
WorkItems that can map to any external system
Workflows that capture the complete analysis process
Events that track every decision and outcome
This isn’t just better data modeling — it’s teaching the database to think in PM concepts.
The repository pattern revelation
Rather than scattering database queries throughout the codebase, we implemented a repository pattern. Every domain concept gets its own repository with clean CRUD (Create, Read, Update, and Delete) operations.
This sounds like developer inside baseball, but it matters for AI memory. When the system needs to find “similar feature requests,” it’s querying ProductRepository.find_similar(), not writing raw SQL scattered across different services.
The abstraction means we can later add sophisticated similarity search without changing how the rest of the system requests data.
What we’re actually persisting
The current system captures:
- Complete workflow executions with timing and context
- AI decision points including confidence levels and alternatives considered
- User interactions mapped to PM domain concepts
- Cross-workflow relationships between related requests
But here’s what we’re not capturing yet:
- Outcome data (did the feature actually get built? how did it perform?)
- User feedback on AI recommendations (were they helpful? accurate?)
- Pattern improvements (learning from what works vs what doesn’t)
The foundation supports these capabilities, but we haven’t built the feedback loops yet.
The testing reality
By the end of June 2, database persistence was working mechanically. Workflows got saved, domain entities had proper relationships, the repository pattern kept data access clean.
But we discovered something important: persistence without validation is just organized data hoarding. We’d successfully saved workflow results but hadn’t verified that saving them actually enabled better future recommendations.
SQLAlchemy insights (the technical bits)
Some discoveries from the June 2 database implementation:
back_populates creates bidirectional relationships automatically. Set feature.product = X and SQLAlchemy adds the feature to X.features without explicit code.
JSON columns enable schema evolution. Instead of adding new database columns every time we expand PM concepts, we use JSON fields for flexible data that can evolve over time.
Async all the way. Using asyncpg with SQLAlchemy’s async support enables non-blocking database operations. Critical when the AI is processing multiple workflows concurrently.
Note: I came to loath the string “asyncio” as I tended to see it when tests were failing and it started to feel like we kept fixing async issues all the time. “Ay-sink-ee-oh!” I would groan again, like some sort of demented bizarro bingo player.
The compound learning vision (not yet reality)
The goal is compound learning: each interaction teaches the system something about how product work actually happens in your context. After analyzing dozens of feature requests, the AI should recognize patterns like “requests from the enterprise team typically have hidden compliance requirements.”
That’s the vision. The current reality is more humble: we can store workflow results and query them later. The pattern recognition and insight generation? Still on the roadmap.
Current capabilities vs future promises
What actually worked as of June 2:
- Structured persistence of workflow executions
- Database queries for historical workflow data
- Proper PM domain modeling in the database
- Repository pattern for clean data access
What we were building toward:
- Learning from workflow outcomes
- Pattern recognition across similar requests
- Feedback incorporation to improve recommendations
- Cross-project insight generation
The architecture supports the vision, but we’re maybe 20% of the way to genuine learning.
The late-night architecture insight
Some of the best discoveries happen during those late coding sessions when your critical brain is tired. Around 11 PM during the June 2 session, I made a decision that turned out to be crucial: store the uncertainty too.
When the AI classifies an intent with 0.95 confidence, save that confidence level. When it considers multiple workflow options, save the alternatives it didn’t choose. When it makes assumptions, capture what those assumptions were.
This creates a research dataset about AI decision-making that could be incredibly valuable for improving the system over time.
The debugging reality
The June 2 session ended with working persistence but some unresolved circular import issues in the orchestration layer. Classic software development: you solve one problem and discover two more.
But the foundation was solid. The domain models felt right, the repository pattern kept data access clean, and the database schema could evolve as our understanding of PM concepts deepened.
What persistence actually enables
With working database persistence, future versions of Piper Morgan could:
Resume interrupted workflows: “We were analyzing that payment feature before the weekend. Here’s where we left off.”
Reference historical decisions: “The last time we worked on mobile performance, these three approaches worked best.”
Track pattern evolution: “Enterprise feature requests have gotten 40% more complex over the last quarter.”
But that’s conditional on building the learning loops that turn stored data into accumulated wisdom.
The honest assessment
Giving AI memory is like giving someone a library card. The potential is enormous, but the value depends on what they do with access to all that information.
We’ve built the library. The AI can check out books. Whether it becomes genuinely smarter over time… that depends on capabilities we haven’t built yet.
But the foundation is in place. Every workflow execution is captured. Every decision point is logged. When we’re ready to build learning algorithms, we’ll have the data to train them on.