The recent $75 million funding round for Nous Research’s Hermes agent has highlighted a growing tension in the AI developer ecosystem: while open source code is transparent, the context accumulated by self-improving agents often remains locked within proprietary product boundaries. Hermes, which secured the investment led by Robot Ventures with participation from Union Square Ventures, boasts over 214,000 GitHub stars and ships with built-in capabilities for web searching, coding, and image analysis. However, its core feature—automatically analyzing user patterns to refine skills without manual intervention—creates a valuable dataset that developers may not actually control.

The Lock-in Problem in Self-Improving Agents

Gauzzastrip, a developer building a memory layer called Empirical, argues that open source licensing alone does not guarantee data portability. When an agent like Hermes learns a developer’s preferences over twelve months—such as code structure choices, project history, and rejected approaches—that accumulated context becomes more valuable than the underlying model weights. If a developer decides to switch to a faster competitor or a new model release, the learned context often stays behind in the previous assistant’s product database. This creates a significant switching cost, effectively tying the user to the vendor that processed their history.

Three Models for Context Storage

Developers currently face three primary options for where their AI memory resides. The default scenario places memory inside the assistant product, offering convenience but zero portability; if you leave the tool, you lose the context. A second approach involves keeping notes in local files, which provides ownership but requires manual effort to paste context into new chats, leading to eventual abandonment. The third option, which Empirical advocates, involves using a user-owned memory layer accessible via the Model Context Protocol (MCP). This allows any MCP-capable assistant, including ChatGPT, Claude, or CLI tools, to read and write to a persistent graph of decisions and preferences, ensuring the memory survives model swaps.

Practical Tests for Portability

To assess their current lock-in risk, developers are advised to perform a simple portability test by asking their current AI assistant, "What do you know about how I work?" If the assistant provides an accurate summary of personal preferences that cannot be exported in a format readable by other tools, that limitation defines the extent of vendor lock-in. Gauzzastrip’s Empirical tool attempts to solve this by making memory a standalone graph, allowing agents to query durable facts about projects and decisions independently of the model’s training data. While early versions of proactive features like "Daydream" may occasionally surface loosely related content, the architectural shift toward user-owned context layers represents a necessary evolution for long-term AI usability.

Key Takeaways

  • Open source licensing does not equate to data portability for learned user context.
  • Self-improving agents like Hermes create high switching costs by storing user patterns in product-bound databases.
  • MCP-compatible memory layers offer a potential solution by decoupling user context from specific AI models.
  • Developers should regularly test whether their AI assistant’s knowledge can be exported to gauge lock-in severity.

The Bottom Line

Stop letting your AI assistant become a black box that knows you better than you know yourself. Demand user-owned memory layers via MCP so your context survives the next model swap.