Every AI agent starts from zero. Squish makes them remember.

We built Squish because we kept running into the same problem across every AI system we shipped at 4M Labs: agents that performed brilliantly within a single session, then forgot everything the moment the conversation ended. User preferences, project context, past decisions, learned patterns -- all gone. The agent would spend the first five minutes of every new session re-discovering what it already knew.

This is not a niche problem. It is the default state of every production AI agent. And it is expensive. Every re-explanation is lost productivity. Every re-discovered preference is wasted inference. Every repeated mistake is a failure the system should have learned from.

Squish is our answer. It is an open-source memory layer purpose-built for AI agents, providing persistent, searchable, structured memory that survives across sessions, improves with use, and integrates with any agent framework through the Model Context Protocol.

The Problem: Context Loss Is the Silent Killer of AI Products

When we talk about "context loss" in AI systems, we mean the complete absence of state between interactions. An LLM processes a prompt, generates a response, and then discards everything. There is no native mechanism for an agent to remember that a user prefers TypeScript over Python, that a project uses a specific database schema, or that a previous approach to a problem failed.

This manifests in concrete ways:

The re-explanation tax. Users spend the first minutes of every interaction repeating information the agent should already know. In customer support, this adds 2-4 minutes per ticket. In developer tools, it means re-describing project architecture every session.

The re-discovery tax. The agent rediscovers facts it previously learned. It re-analyzes codebases it has already seen. It re-reads documentation it has already processed. Each re-discovery costs tokens and time.

The repetition of mistakes. Without memory of past failures, agents repeat the same errors. A coding agent that introduced a race condition last week may introduce the same one today because it has no record of the previous failure.

The loss of institutional knowledge. When team members change, their context about projects, decisions, and conventions vanishes. The AI agent starts fresh, just like a new hire -- but without the benefit of human judgment.

Traditional approaches to this problem are inadequate. Storing everything in a vector database gives you semantic search but no structured memory management. Conversation histories grow unbounded and become noisy. Long context windows are expensive, limited by model constraints, and degrade retrieval quality. Simple key-value stores lack the intelligence to determine what is worth remembering.

What is needed is a purpose-built memory system that understands what to remember, how to organize it, how to retrieve it efficiently, and how to maintain itself over time.

Architecture Overview

Squish is designed around a single principle: memory should be a first-class primitive in AI systems, not an afterthought bolted onto an existing stack.

The architecture has four layers:

Agent Application
    |
Squish API (7 tools via MCP Protocol)
    |
Memory Router (type detection, routing, importance scoring)
    |
Storage Layer (SQLite with FTS5 full-text search)
    |
Consolidation Engine (dedup, staleness, summarization)

Each layer has a specific responsibility, and the boundaries between them are intentional. Let us walk through each one.

SQLite Backend: Why Not Postgres

We chose SQLite as the storage engine for Squish. This was not a default decision -- we evaluated PostgreSQL, Turso, libSQL, and several managed solutions. SQLite won for reasons that matter in production:

Zero operational overhead. SQLite requires no server, no connection pool, no configuration file, no credentials. The entire memory store is a single file. This matters because AI agents often run in ephemeral environments -- containers, serverless functions, local development setups. A memory system that requires a running database server creates a deployment dependency that slows down iteration.

Portability. A Squish memory store is a file. You can back it up with cp. You can version it with git. You can move it between environments. You can inspect it with any SQLite client. This transparency is valuable when debugging agent behavior -- you can literally query the memory store to understand what the agent knows.

Performance characteristics match the workload. Agent memory workloads are read-heavy with occasional writes, benefit from full-text search, and rarely exceed thousands of queries per second. SQLite handles this workload comfortably. Benchmarks on our systems show sub-millisecond query times for memory retrieval with full-text search across 50,000+ memories.

ACID guarantees. Memory operations need to be reliable. If an agent stores a critical decision and the process crashes mid-write, that decision should not be lost or corrupted. SQLite provides ACID compliance without configuration.

Embedded deployment. Squish runs in-process with the application. There is no network hop, no connection timeout, no connection pool exhaustion. Memory operations are as fast as a local function call.

The tradeoff is clear: we sacrifice horizontal scaling for deployment simplicity. For the vast majority of AI agent use cases -- individual developer tools, team collaboration agents, customer support bots -- this is the right tradeoff. If you need distributed memory across hundreds of nodes, you can layer Squish on top of a shared SQLite backend via LiteFS or use the memory export APIs to sync to a centralized store.

The 7-Tool API Surface

Squish exposes its functionality through seven tools, each designed for a specific memory operation. This is not arbitrary -- each tool maps to a distinct phase in the memory lifecycle.

squish_search performs semantic search across the memory store. It accepts a query string and optional filters (by memory type, user, project, date range) and returns ranked results. Under the hood, it combines SQLite FTS5 full-text search with a lightweight relevance scoring algorithm. This is the primary tool for retrieving memories during an interaction.

squish_remember stores a new memory. The system automatically detects the memory type (observation, fact, decision, context, preference, note) based on the content, assigns an importance score, and routes it to the appropriate storage location. The caller can override the type and add metadata like user ID, project path, or tags.

squish_recall retrieves memories filtered by type and context. Unlike squish_search, which is query-driven, squish_recall is context-driven -- it retrieves all memories relevant to a given situation, user, or project. This is useful for loading an agent's context at the start of a session.

squish_learn captures learning events -- successes, failures, fixes, and insights. Each learning event is linked to the memory it relates to and creates a feedback loop that improves agent behavior over time. When a coding agent tries an approach that fails, it records a learning event. Next time it encounters a similar situation, it retrieves that learning and avoids the same mistake.

squish_context loads the relevant context for a new session. It considers the current project, user, and situation to pull the most relevant memories and return them as a structured context block. This is the tool an agent calls before every interaction to eliminate the cold-start problem.

squish_stats returns statistics about the memory store -- total memories, type distribution, storage size, consolidation status, and health metrics. This is essential for monitoring and debugging memory systems in production.

squish_consolidate runs the consolidation engine, which deduplicates similar memories, summarizes related entries, prunes stale content, and adjusts importance scores based on access patterns. This is the self-maintenance tool that keeps the memory store efficient over time.

MCP Protocol Integration

Squish integrates with AI agent frameworks through the Model Context Protocol (MCP). MCP is a standardized protocol for connecting AI models to tools and data sources. It defines a JSON-RPC based interface that agents use to discover and invoke tools.

The integration works as follows:

Squish registers its 7 tools with the MCP server
The agent framework (Claude, OpenCode, Cursor, or any MCP-compatible client) discovers the tools
The agent calls tools using standard MCP tool invocation
Squish processes the request and returns results through the MCP response channel

This means Squish works with any MCP-compatible agent out of the box. There are no framework-specific adapters to write, no SDK dependencies to manage, and no vendor-specific APIs to learn. If your agent speaks MCP, it can use Squish.

For agents that do not use MCP, Squish also provides a direct JavaScript/TypeScript API. The same 7 tools are available as async functions that you can call from any application.

Memory Types

Squish categorizes memories into six types, each serving a distinct purpose in agent cognition:

Observation captures things the agent noticed during interactions. These are sensory inputs -- what the user said, what the code looked like, what the error message was. Observations are the raw material from which other memory types are derived.

Fact stores verified information that has been confirmed through interaction or evidence. Facts are the agent's knowledge base -- user preferences, project configurations, API endpoints, team structures. They are high-confidence and long-lived.

Decision records choices made and their rationale. This is critical for debugging agent behavior and maintaining consistency. When an agent chooses approach A over approach B, it should remember why so it can apply the same reasoning in future situations.

Context holds situational information relevant to interactions. This includes temporal context (what time it is, what phase of a project the team is in), environmental context (what tools are available, what constraints exist), and social context (who the user is, what their role is).

Preference captures user or system preferences. These are the "how" behind interactions -- preferred languages, coding styles, communication patterns, output formats. Preferences make agents feel personalized rather than generic.

Note is a catch-all for information that does not fit other categories. Notes are low-priority and tend to be pruned more aggressively during consolidation.

This categorization enables intelligent retrieval. When an agent needs to understand a user's coding preferences, it queries for preference-type memories specifically. When it needs to remember a past failure, it queries for learning events. This structured approach is more efficient than dumping everything into a single vector store and hoping semantic search finds the right information.

Consolidation: The Self-Maintaining Memory

Memory without maintenance becomes noise. Squish includes a consolidation engine that runs periodically (or on-demand via squish_consolidate) to keep the memory store healthy.

Deduplication. The engine identifies memories with high semantic similarity and merges them. If an agent stores "User prefers TypeScript" three different ways across three sessions, consolidation merges these into a single, authoritative memory with the combined confidence of all three observations.

Staleness detection. Memories are scored based on recency, access frequency, and importance. Memories that have not been accessed and have low importance scores are flagged as stale. Stale memories are not immediately deleted -- they are moved to a lower-priority tier and eventually pruned if they remain unused.

Summarization. Related memories are grouped and summarized. If an agent has accumulated 15 observations about a user's coding patterns, consolidation summarizes these into a concise preference memory. This reduces storage and improves retrieval quality.

Importance scoring. Each memory has an importance score that is adjusted based on access patterns. Memories that are frequently retrieved are scored higher. Memories that are never accessed are scored lower. This ensures that the most relevant memories rise to the top during retrieval.

The consolidation engine is what makes Squish a memory system rather than a memory dump. Without it, the memory store would grow linearly with usage and eventually degrade retrieval quality. With it, the store maintains a steady state of relevant, high-quality memories.

Design Decisions

Several design decisions in Squish deserve explanation because they reflect our experience building production AI systems.

Why Open Source

Memory infrastructure is too important to be proprietary. If your agent's memory is locked in a proprietary cloud service, you cannot debug it, you cannot customize it, and you cannot guarantee its availability. When a cloud memory service has an outage, your agents forget everything. When it changes its API, your integration breaks.

Open-source memory gives you control. You own the data, you own the storage format, you own the retrieval logic. Squish stores everything in SQLite, a format you can inspect, back up, and migrate without any dependency on us.

Why This API Shape

The 7-tool API is designed around the memory lifecycle, not around database operations. Most memory systems expose CRUD operations -- create, read, update, delete. These are storage primitives, not memory primitives.

Squish exposes remember, recall, learn, context, search, stats, and consolidate. These map to what an agent actually needs to do with memory. The storage details are abstracted away. This makes the API easier to integrate and harder to misuse.

Why Not a Cloud Service

We considered building Squish as a cloud service. The economics are attractive -- recurring revenue, centralized infrastructure, easier updates. But the use cases we serve require local-first memory. Agents running on developer machines, in CI pipelines, on edge devices, or in air-gapped environments need memory that works without a network connection.

Local-first also means lower latency, no egress costs, and no privacy concerns about sensitive data leaving the environment. For teams working with proprietary code, regulated data, or competitive intelligence, local memory is a requirement, not a preference.

Production Usage at 4M Labs

We use Squish internally across all three arms of 4M Labs -- Studio (client work), Products (reusable infrastructure), and Lab (applied research).

In our engineering workflow, every coding agent maintains a Squish memory store for each project. The agent remembers architecture decisions, coding conventions, test patterns, deployment procedures, and team preferences. When a new engineer joins a project, their coding agent inherits the accumulated context from previous sessions. This reduces onboarding time from days to hours.

In our sales process, our agents remember prospect interactions, objection patterns, pricing discussions, and follow-up commitments. Every touchpoint builds on the last. Prospects experience continuity across conversations, even when different team members or agents are involved.

In our research lab, agents track experiment results, failed approaches, successful patterns, and emerging insights. The learning loop is explicit -- every experiment produces a squish_learn event that the agent can retrieve when designing the next experiment.

The measurable impact across our operations:

40% reduction in context reconstruction time at session start
25% fewer repeated questions to clients and team members
30% improvement in agent accuracy on recurring tasks
15% reduction in token usage by eliminating re-discovery

Getting Started

Setting up Squish takes minutes.

Installation

bun add squish-memory

Basic Integration

import { Squish } from 'squish-memory';

// Initialize for a project
const squish = new Squish('./my-project');

// Store a memory
await squish.remember({
  content: 'Project uses PostgreSQL with pgvector for vector search',
  type: 'fact',
  project: './my-project',
  tags: ['database', 'architecture']
});

// Search memories
const results = await squish.search('database setup', {
  project: './my-project',
  limit: 5
});

// Load context at session start
const context = await squish.context({
  project: './my-project'
});

// Record a learning event
await squish.learn({
  type: 'failure',
  content: 'Race condition in concurrent writes -- use mutex pattern',
  tags: ['bug', 'concurrency']
});

// Run consolidation periodically
await squish.consolidate();

MCP Integration

To use Squish with MCP-compatible agents, add it to your MCP configuration:

{
  "mcpServers": {
    "squish": {
      "command": "squish-mcp",
      "args": ["--project", "./my-project"]
    }
  }
}

The agent will automatically discover all 7 Squish tools and can use them immediately.

Typical Integration Pattern

The standard pattern for integrating Squish with any agent:

Session start: Call squish_context() to load relevant memories
During interaction: Let the agent use context naturally
After important events: Call squish_remember() to capture new information
After outcomes: Call squish_learn() to record successes and failures
On query: Call squish_search() when the agent needs specific information
Periodically: Call squish_consolidate() to optimize the memory store

This pattern works with any agent framework and any language model. The memory layer is orthogonal to the agent's reasoning capabilities -- it provides the persistent state that reasoning requires.

Try Squish

Squish is open source and available now. The repository includes comprehensive documentation, integration examples for major agent frameworks, and a quick-start guide.

If you are building AI agents and need persistent memory, start with Squish. Install it, integrate it with your agent, and see the difference that memory makes.

For teams building production AI systems, we offer consulting on memory architecture, agent design, and deployment. Book a call to discuss how persistent memory fits into your AI strategy.

Squish is open source at squishplugin.dev. Clone it, try it, contribute to it. Memory infrastructure should be accessible to every AI developer.