Your Memories, Your Terms: How He Left IBM for Half the Pay to Build the AI Memory Layer That Keeps Users in Control

Build to Launch Friday: Meet Jing, the VP who open-sourced what most startups would guard fiercely

Welcome to Build to Launch Fridays, where we meet the builders turning domain expertise into AI-powered products.

Every Friday, I’m spotlighting someone from the vibe coding builders collection who’s doing exactly what I believe is the future: using AI not as just another tool, but as a true collaborator to transform curiosity, passion, and years of professional knowledge into something scalable and ownable. No VC funding, no technical co-founders, no permission required, just domain experts who decided to build.

But today’s different.

Today, meet Jing Xie — VP at MemVerge, leading a team of 10 to build MemMachine, the open-source AI memory layer I’ve been using for months. This isn’t a solo indie builder story. This is me getting curious about the next level: What does it look like when you go from lean indie to 50-person startup? How do they think about open source when I’ve always been wary of it? What can I learn about scaling beyond the one-person show?

---

Have you ever wondered what happens after the solo builder phase?

I’ve known Jing for months now. Started with curiosity about their intermediate memory layer.

What? Memory layer? Intermediate? I know those words, but that phrase… mysterious. And suspiciously like something I might need to understand.

Because I’ve built a series of AI projects, with some turned into profitable products. And several needed serious context handling. RAG pipelines, MCP connections, even my workplace systems all run into the same wall: how do you manage context when everything changes in real time?

So when Jing explained the core concept, it instantly clicked. It solved problems I’d been brute-forcing for months. We hopped on calls, dug through diagrams, and later met their engineers to understand how this thing actually worked.

Then it went open source, and that changed everything.

I started asking questions. A lot of them. (Probably too many.) Their team patiently answered as I kept poking at how it all fit together.

See, the “memory layer” space is tricky, even a little dangerous. It’s polarized, hard to get right, and usually dominated by big AI companies. You need real technical depth and the courage to compete on infrastructure. Yet Jing’s team is topping benchmarks and closing enterprise deals. That says something.

When I invited Jing to this series, I had to be honest: this is new territory. Build to Launch Friday has always lived in the indie creator space. Solo builders, side projects, domain experts shipping alone. Jing leads a team of 10 at a 50-person company with enterprise customers and a CEO making strategic bets. That’s a different world.

And I’m curious. Not just about MemMachine, but about what building looks like at this level.
How do decisions shift when you scale?
What changes when you have investors, customers, and a team depending on you?
And the big one I’ve been wrestling with lately: open source.

I’ve always stayed lean, cautious, protective of what feels fragile. Yet here’s Jing, open-sourcing their core product while landing enterprise contracts. That’s not just brave; it’s a bet on a whole philosophy of building.

So this conversation isn’t just about featuring Jing’s work.
It’s me learning, exploring what the path from solo to startup actually looks like.

Jing’s story starts far from Silicon Valley. No Ivy League degree. First job at Chick-fil-A. Eight years ago, he left IBM, cutting his pay in half, doubling his hours. He ran his own startup, learned about failure and the lonely founder road. At MemVerge, he’s betting on what he calls a generational “fat pitch” — solving AI’s fundamental memory problem.

The thesis?
While AI can write complex code and analyze thousand-page contracts in minutes, it still can’t truly remember. Users paste the same context repeatedly. Bots forget yesterday’s conversations. Memory is becoming the new storage layer for AI - not just vector databases, but building understanding over time, enabling genuine personalization.

And here’s where Jing’s conviction gets sharp:
While big AI companies make it easy to hand over our memories, that’s wrong. Our memories define who we are. They should belong to us.

Let’s dig in.

---

Technical Architecture: Inside the Machine

I don’t normally go straight into the technical part... but trust me, you’ll enjoy the rest much better when you have a feel of this part.

How exactly does MemMachine work? What’s the layout like, architecturally?

MemMachine is an open-source memory layer that works in three main parts:

Interface Layer Users interact with AI agents through multiple API options:

• RESTful API

• Python SDK

• MCP Server

Memory Processing Core Handles two key memory types:

• Episodic Memory: Stores conversation context

• Profile Memory: Maintains long-term user information

Supports three memory categories:

• Working (Short-term)

• Persistent (Long-term)

• Personalized (Profile)

Storage Layer Uses specialized databases for different memory types:

• Graph database for Episodic Memory

• SQL database for Profile Memory

The system works by capturing interactions, processing them through the memory core, and persisting them in appropriate databases. This creates a continuous learning system that maintains context across multiple sessions and different AI models.

Honest take: When I first tried the UI layer, nothing felt special. ChatGPT, Claude, Gemini - they’ve all advanced their memory features pretty well. On the surface, it just felt like more of the same. But then I went straight into their codebase. That’s when things got fascinating. Seeing these three distinct memory layers - how they deliberately separated episodic (graph) from profile (SQL) from working memory - that’s when I understood what they’re actually building.

I saw that you use PostgreSQL underneath to build dynamic user profiles and memory structures — how do the different memory types (episodic, profile, short session) connect to each other?

MemMachine actually uses a hybrid database architecture to manage different memory types:

Episodic Memory is stored in a graph database, which is ideal for capturing conversational context and temporal relationships between interactions.

Profile Memory is stored in an SQL database (not specifically PostgreSQL in the information provided), which handles long-term user facts and preferences.

The memory types connect through MemMachine’s core processing layer, which:

• Manages the relationships between short-term working memory, long-term persistent memory, and personalized profile memory

• Ensures consistent data flow between the different storage systems

• Maintains coherence across multiple sessions and agents

It is possible to use just Episodic or Profile memory independently based on the use case you are designing for. Storage to and retrieval from MemMachine is fully automated through the use of our own “memory agent service” that works within MemMachine.

Profile memory is my favorite part. I’ve been storing and retrieving many of my articles through MemMachine, and the way it handles personalization is beautiful. Instead of creating another slash command or digging through every file I’ve saved, the profile memory just knows. It’s there when I need it. What I really love is that they’ve abstracted all the complexity away while leaving the flexibility to use pieces independently. That’s the sweet spot - powerful but not overwhelming.

What kind of data pipelines and interchange structures does MemMachine use to store, update, and surface “memories” in real time? Can it handle context across models — say, syncing episodic memory for both Claude and GPT agents in parallel? Or is it isolated per tenant?

Yes, MemMachine is specifically designed to handle context across different models and agents in parallel.

The architecture supports this cross-model functionality through:

• A universal memory layer that works across different AI agents

• Centralized storage where:

  • Episodic memory lives in a graph database

  • Profile memory is stored in an SQL database

This means you can indeed sync episodic memory between Claude and GPT agents in parallel - it’s not isolated per tenant. The system is built to maintain consistency across different AI models while enriching future interactions regardless of which model is being used.

This is the dream right here. I jump between Claude and GPT all the time depending on the task, and losing context between them drives me nuts.

---

Privacy, Security & Data Control

Memory can become a privacy time bomb. How do you store, secure, and expire sensitive user memories without losing model continuity?

Currently, MemMachine handles privacy and security in two ways:

Managed Service Option

• MemVerge hosts MemMachine as a memory endpoint (API or MCP), providing a secure single-tenant managed service on AWS

• Ideal for organizations without in-house IT and DevOps teams

• Policy based memory retention based on customer requirements

Self-Managed Deployment

• Deploy MemMachine as part of your agent tech stack and inferencing environment, security responsibility lies with your IT/DevOps team

• Administrators manage networking, access controls, memory retention policy

Coming Soon:

• Fine-grained memory access controls

• Enhanced memory visibility tools

• BYOK data encryption

• Zero trust access

This is where it gets really interesting for enterprises. I know so many companies that won’t touch commercial AI services because of privacy concerns. The irony? Those companies often have the most valuable data that could benefit from AI. MemMachine’s self-managed deployment option is the workaround they need - host your own LLM, manage your own memories, completely offline if you want. The roadmap features (BYOK encryption, zero trust, fine-grained access controls) aren’t just nice-to-haves. They’re what turns “we can’t use AI” into “we can build with AI on our terms.”

---

Open Source Strategy & Business Model

You open-sourced the product completely — while still trying to win enterprise customers. Doesn’t that mean you just gave away your core value?

Not at all. Open sourcing MemMachine actually strengthens our enterprise value proposition. While the code is open source, enterprises need much more than just code. Many Fortune 500 companies have standard policies requiring enterprise support, even for open source software. They need a trusted partner who can provide security, reliability, and dedicated support for their production environments.

For enterprises deploying MemMachine in their inferencing stack, we ensure they maintain full control over their AI memories while backing them up with support, priority bug fixes, and custom features when and if they need it. This aligns perfectly with our mission - keeping memories in the hands of those who create them while also being their enterprise-grade technology partner.

I’d admit, this answer shifted something for me. I’ve always been wary of open source because it felt like giving away your best value. But hearing Jing explain it - the code is just one piece, enterprises need the support ecosystem - it makes sense. I’ve been thinking in a small pond, but what if the market is actually an ocean?

How’s that playing out? Are enterprise clients still paying for support, scalability, or something entirely different? Are there open-source peers you look up to or benchmark against — like n8n, LangChain, or LlamaIndex?

We benchmark ourselves against other memory solutions. MemMachine currently leads the field with a LoCoMo score of 0.85, significantly outperforming alternatives like Mem0 (0.67), LangMem (0.52), ChatGPT Zep (0.74), and Memobase (0.75). For more, read our blog: https://memmachine.ai/blog/2025/09/memmachine-reaches-new-heights-on-locomo/

Love that they’re putting numbers out there. 0.85 vs 0.67 is a big gap. The fact they’re benchmarking openly and sharing the methodology on their blog shows confidence. That transparency matters when you’re asking companies to trust you with their AI capabilities.

Do you see your open nature as a moat or a vulnerability? How do you respond to companies that build proprietary memory layers using your foundation?

We absolutely see our open nature as a moat, not a vulnerability. The AI memory market is poised to become the next major data layer, with decades of growth ahead - similar to how databases evolved in previous technology waves. Just as open source databases like PostgreSQL thrived alongside proprietary solutions, we believe the memory layer market is large enough to support multiple approaches.

When companies build proprietary solutions on our foundation, that actually validates our core thesis: that memory infrastructure is a critical component of the AI stack. We’re focused on building the best possible open memory foundation while offering enterprise-grade features and support for companies that need them. Our approach of keeping memories portable and user-controlled resonates strongly with both developers and enterprises who don’t want to be locked into proprietary AI systems.

The market opportunity here is massive - every AI application needs a memory layer, and we’re just at the beginning of this transformation. We’re building for the long term, focusing on innovation, community growth, and enterprise-grade capabilities rather than trying to lock customers into a proprietary solution.

This resonates. Some of my own AI apps and workflows need memory, and I didn’t have a good solution until MemMachine. The market being big enough for multiple approaches makes sense; look at databases: PostgreSQL, MongoDB, Redis all serve different needs. Jing’s betting memory becomes the next fundamental layer. I think he’s right.

Suppose OpenAI or Anthropic forks your open-source MemMachine repo. How do you protect your intellectual edge while being transparent?

We actually see this scenario as validation of our open source strategy. Remember, companies like Red Hat and MongoDB have shown that being open source doesn’t diminish your competitive advantage - it enhances it. We’re focused on building the best possible memory system while ensuring users maintain control of their most valuable asset: their memories. Our memory is also multi-model and works across models from all the leading AI labs. These players today haven’t shown interest or willingness to enable their respective memory layers to interoperate.

I really appreciate this mentality. Seeing forking as validation instead of threat is something I’ve been re-learning from fellow builders and communities. It enriches you instead of depletes you. That mindset shift matters. And the multi-model point is huge. As I jump between models constantly, this interoperability is truly important for me.

---

AI Memory Landscape: Competition & Market Position

Models like ChatGPT and Claude have built rich, persistent memories. Are they already encroaching on your territory? What’s left for MemMachine to do better?

While ChatGPT and Claude have built impressive memory capabilities, they operate in a fundamentally different way from MemMachine. These platforms maintain centralized control over user memories - especially for free tier users, where the AI companies often retain rights to your data and conversations. This is precisely the challenge we’re addressing.

Enterprise adoption of these tools has been slower precisely because companies view their AI conversations and memories as precious intellectual property that must remain under their control. They need their memories to be:

• Fully owned and controlled by them

• Secured within their infrastructure

• Portable across different AI models

• Protected from vendor lock-in

Rather than competing with ChatGPT or Claude, we’re empowering organizations to build their own AI applications with complete control over their memory layer. Our open-source approach ensures transparency and trust, while our enterprise offerings provide the security and support that businesses require.

I see this tension firsthand. I use ChatGPT and Claude constantly, and I’m always aware that my conversations are sitting on their servers. For personal use, fine. But when I’m working on client projects or thinking through business strategy? That memory lock-in gets uncomfortable. MemMachine’s positioning makes sense, they’re not replacing the models, they’re giving you control over what those models remember.

With Anthropic rolling out “Claude Projects” and OpenAI building native long-term memory, do you see these giants directly threatening what you’ve built — or validating it?

We see these developments as strong validation of our vision. When industry leaders like Anthropic and OpenAI invest heavily in memory capabilities, it confirms what we’ve been saying: memory is becoming a first-class citizen in the AI stack, just as critical as the core LLM technology.

Rather than threatening MemMachine, these moves create more opportunities. Here’s why:

Through our MCP interface, MemMachine can actually serve as a secure memory layer for Claude and OpenAI’s services. This means organizations can use these powerful models while maintaining complete control over their memories and data.

While these companies are building walled-garden memory solutions, we’re taking an open, interoperable approach. Companies increasingly want the flexibility to use multiple AI models while keeping their memory layer independent and under their control.

The memory capabilities being built by OpenAI and Anthropic are tied to their specific services. MemMachine, in contrast, provides a universal memory layer that works across different AI models and services.

Their investment in memory capabilities validates the market opportunity while highlighting the need for an independent, open-source memory solution that puts users in control of their AI memories.

This “validation, not threat” framing keeps coming up, and I find it fascinating. On one hand, when giants like OpenAI and Anthropic move into memory, it proves the market exists. On the other hand, I’ve seen people teasing that ChatGPT’s new “learning” feature is just another opportunity for someone else to do it much better. Both perspectives are optimistic, just from different angles. One says “the market is real,” the other says “there’s room for better solutions.” And both are true. That’s the opening MemMachine is positioned for.

It seems every AI company is claiming “memory.” What is your definition of AI memory — and what’s just marketing noise?

There’s a lot of buzz around ‘AI memory’ right now, but it’s important to distinguish between two fundamentally different approaches:

Data Integration Memory (RAG)

• Focuses on connecting AI agents to existing enterprise data (emails, documents, etc.)

• Essentially makes existing data accessible to AI through RAG (Retrieval Augmented Generation)

• Think of this as ‘looking backward’ at historical data

True AI Memory Management (where MemMachine operates)

• Manages the new data layer being generated by AI interactions

• Stores and retrieves data created during AI conversations and agent operations

• Handles real-time context and long-term memory persistence

• Think of this as ‘looking forward’ at the exponentially growing AI data layer

MemMachine specifically focuses on the second category - we’re building the infrastructure to manage this new, rapidly growing AI data layer. While RAG solutions help AI access existing data, we help organizations maintain control and ownership of the valuable new data being generated through AI interactions.

These approaches are complementary - organizations need both to build comprehensive AI solutions. But it’s crucial to understand the distinction when evaluating memory solutions for your specific needs.

This distinction is interesting, though my experience with MemMachine actually blurs this line. I fed my past articles into it and built on top of that - so it can handle the “looking backward” RAG use case too. The theoretical distinction makes sense (RAG = existing data, MemMachine = AI-generated data), but in my world, there’s overlap. They support similar functionality, just in different formats. Which means MemMachine can serve both needs. That’s actually more powerful than I initially thought.

From what you’ve seen, how far are today’s foundation models from achieving what MemMachine already delivers in persistent AI reasoning and episodic recall?

Foundation models are powerful reasoning engines, but they’re not designed to be memory systems. Here’s why:

Foundation models have impressive in-context reasoning capabilities, but they lack true persistent memory. Their ‘memory’ is limited to their training data and whatever fits in their context window.

MemMachine, on the other hand, is purpose-built as a dedicated memory layer that:

• Persists across multiple sessions and conversations

• Works with multiple LLMs and AI agents

• Stores both episodic memories (conversation context) and profile memories (long-term user facts)

• Gives users and enterprises full control over their memory data

Think of it this way: LLMs are like powerful processors, while MemMachine is like a specialized database for AI-generated data. Just as applications need both processors and databases, AI systems need both strong reasoning capabilities (LLMs) and persistent memory management (MemMachine).

The future of AI will likely see these layers becoming even more distinct and specialized, with foundation models focusing on reasoning and inference while dedicated memory systems handle the critical task of persistent knowledge management.

The LLM-as-processor, memory-as-database analogy is perfect. We don’t expect CPUs to also be hard drives. Why would we expect LLMs to also be perfect memory systems? This separation of concerns makes so much sense.

---

Community Building, Scale & Marketing

You hosted that large “MemMachine Memory Marathon” — how’d it go? How many people showed up, and what did the winners get?

We hosted our first ever MemMachine hackathon on DevPost back in October. We had 80+ participants and 13 MemMachine powered AI application submissions. We were able to host 4 of the 13 teams in person at our Bay Area and NYC offices. The 1st place winner got $2,500 followed by $1,000 and $500 for 2nd and 3rd places.

80+ participants for a first hackathon is impressive. And $2,500 prizes show they’re serious about building community. I’m curious what those 13 applications looked like, that’s the kind of real-world validation that matters more than marketing.

Are you planning to make it a yearly thing?

We will be hosting many more hackathons to come. Next week we are working with students at Pace University to accelerate MemMachine integration with other AI tools and frameworks. In December, we will be hosting a hackathon in partnership with Neo4J and AWS. Stay tuned!

Partnerships with Neo4J and AWS are smart - Neo4J for graph database expertise, AWS for enterprise distribution. Working with university students builds the next generation of developers who grow up using your tool. But I’m also curious about the operational side - where does hackathon budget like this come from? Who makes those decisions? That’s not a small investment.

You’re also seen at major AI conferences. Do you sponsor or showcase directly, or let your technology speak for itself?

We will continue to be at AI conferences to help get the word out about MemMachine. In addition, we have a close partnership with AWS and they invite us all around the world to present to customers and conduct educational workshops. For example, today (October 28th) part of our team is in Singapore leading an agent builders workshop for NUS students and researchers in partnership with AWS.

AWS inviting them to present globally is a big deal. That’s not just sponsorship, that’s AWS validating them as a serious enterprise solution. Singapore, NUS researchers... this is operating at a scale I’ve never touched, and now I see what the next level looks like.

The open-source community can be fragmented. Do you plan to join any accelerators, like YC, to amplify reach — or do you prefer staying independent?

Great question…while we do not need funding from VC at the moment we do partner with founders and engineering teams at the major incubators and VCs who need an AI memory system. In fact, some of our earliest users are founders and early stage startups who let us handle the AI memory part of their tech stack while they build all the other important pieces of their solution.

That settled my curiosity. Instead of joining an accelerator, they’re partnering with the startups IN the accelerators. That’s smart distribution, because early stage startups need memory solutions, and if they grow, MemMachine grows with them.

For marketing: how do you explain something this technical to non-technical decision makers? What’s your go-to analogy when pitching MemMachine?

Here’s a simple analogy: Imagine if every time you talked to an important client, you had to start from scratch because you couldn’t remember any previous conversations. That would be frustrating and inefficient, right? That’s exactly what happens with AI without proper memory management. Just as your company needs a database to store customer information and business data, you need a dedicated system to store and manage AI-generated data.

MemMachine solves this by:

• Securely storing all AI conversations and interactions

• Keeping your company’s AI memories under your control (not in the hands of big AI companies)

• Making these memories instantly accessible when needed

• Working across different AI platforms while maintaining your data sovereignty

In today’s world, your AI conversations and interactions are becoming valuable intellectual property. MemMachine ensures you maintain complete control over this critical business asset while making it easy to use across your organization.

This analogy works. I’ve used similar framing when explaining RAG systems and MCP servers in building your own second brain. If you want to 10x your AI productivity, memory management is the foundation. Simple, effective, gets the point across.

---

Vision, Team & Personal Journey

How big is your team now, and how do you maintain that blend of research depth and product agility?

We have about 50 people at MemVerge. Our CEO is deeply involved in key decisions we are making around MemMachine and to ensure we move with speed he has organized our engineering team into 5 teams each with 3-5 people focused on different parts of the MemMachine stack (core memory, interfaces, reporting/observability, QA & benchmarking, solutions).

My team of 10 focuses on evangelizing MemMachine to developers and working with commercial customers. We are spreading the word about MemMachine via social media: LinkedIn, Substack, X, and Reddit and we are growing our user community via Discord (digital) and in-person training and events.

Compare that to me: solo, doing everything, constantly context-switching. But who knows. This organizational clarity is exactly what I need to understand if I ever want to scale.

What made you personally join MemVerge? You wrote about it in your newsletter — was it curiosity, challenge, or conviction that this was the future?

I would say a combination of all three. MemVerge was founded in 2017 before the GenAI craze captured all of our imaginations. It is a company that has had to transform itself over the years, but one thing has remained constant: working on cutting edge memory technologies. It attracted me initially and it has kept me here.

The essence of the MemMachine project is the belief that memories - especially AI memories - belong to their creators. While big AI companies make it easy to hand over our memories, I’m convinced that’s wrong. The real magic happens when we combine our memories with LLMs in a way that keeps users in control. Keeping us in control of our own AI memories is important at both the individual and corporate level and technologies like MemMachine are a critical enabler.

This conviction hits different. It’s not just a product philosophy, it’s a stance about who owns the AI-generated future we’re building. Memories define who we are - that line resonates. And Jing’s right that it’s easy to hand them over. Too easy. This is the kind of foundational belief that sustains you through the hard building years.

What strengths have you personally brought to the company, and how has the experience compared to what you expected?

When I joined MemVerge three years ago, I started with no team. I fought for my ideas and earned my CEO’s trust. Together with the great team we built, we transformed from a proprietary, engineering-focused company into one that’s open source and customer-obsessed. I’m recognized by others for my passion, hard-work ethic, and extreme competitiveness. Where I am now and what I get to do here surpassed my wildest imagination. What is more exciting than building the world’s best memory system for AI?

Starting with no team, fighting for ideas, earning trust, building a team of 10, transforming an entire company’s approach from proprietary to open source - that’s a journey. That transformation is harder than starting from scratch. And “surpassed my wildest imagination”, I relate to that feeling when something you’re building starts working at scale.

In your view, when does an AI system have “enough” memory? Do we risk going too far into perfect recall?

There is a tradeoff and it is different for each developer/use case. Too much memory can increase latency and inference costs. Too little can hurt the accuracy and contextual richness of the response back from the LLM. The good thing is these are all customizable components in the MemMachine system. There is no one size fits all and how much memory is needed differs for each use case and application.

This is the practical engineering answer I appreciate. Not “perfect recall is always better” but honest trade-offs. I’ve hit this exact balance in my AI building systems, too much context and responses get slow and expensive, too little and they lose relevance. Having it customizable per use case makes sense.

If you could solve one bottleneck in AI infrastructure overnight so you could focus purely on creativity, what would it be?

I daydream of a world where the exact hardware and middleware is completely abstracted away from us. All of our thoughts, feelings, ideas, knowledge, and the quirks that make us all unique in the world are digitized into a single source memory vault owned and controlled by us alone. All we need to decide is what AI systems and applications get to have access to which parts of our AI memory so that they can help us do things that we would normally have to do ourselves…with the ultimate goal being more time for the things that matter in life: living out our purpose, being with our loved ones, with our family, enjoying good health, eating good food, and being in good company.

This is my dream too! A single memory vault that YOU control, that AI systems request permission to access. That’s the future Jing’s building toward. And that final line - more time for purpose, family, health, good food, good company - that’s why any of us build anything that matters. Technology as a means to human flourishing, not an end in itself.

---

What This Taught Me

The technical architecture made me understand the product, but three things from Jing’s journey stayed with me.

First, the “validation not threat” mindset. When I see competition or someone copying an idea, my instinct is still protective. Jing sees it as market validation and moves forward building better. That shift from scarcity to abundance thinking - where the market is an ocean, not a pond - changes everything about strategy. Open source makes sense at that scale.

Second, conviction as infrastructure. Memory ownership isn’t marketing, it’s the foundation everything else is built on. (This is the same clarity I see in builders like Elena who orchestrated 37 contributors or Benjamin who built the free visa tool — conviction first, then everything follows.) The technical architecture, the business model, the open-source strategy all flow from that core belief: our memories define us and should belong to us. That’s the kind of clarity that sustains you through the hard years of building.

Third, scale doesn’t require compromise. You can open-source your core, organize 50 people with clarity, win enterprise deals, and stay true to founding conviction. That’s not a trade-off, it’s a different game entirely - one I’m just starting to understand.

If Jing’s approach to building with conviction at scale resonates, connect with him. Whether you’re solo or thinking about what comes next, there’s insight here worth learning from.

Check out MemMachine on GitHub: github.com/MemMachine/MemMachine

Learn more at: MemMachine

If you’re turning your expertise into products, building with AI, or helping others do the same, you belong here. Join the vibe coding builders community and get featured on Build to Launch Friday. Curious why it all started? Here’s the full story behind Vibe Coding Builders.

Your turn:

How do you think about AI memory ownership in your own work — do you trust the big platforms with your context?

What would you build differently if you had complete control over your AI memories across every tool you use?

Jing went from Chick-fil-A to IBM to cutting his pay in half to bet on AI’s memory problem. Now he’s leading a team building the open-source layer that enterprises trust.

What will your builder story be, and what level are you building toward?

— Jenny