Up to 14× faster than Vercel on live data

REFERENCE IMPLEMENTATION

Shared Memory Layer for AI Agents

This reference implementation combines local embeddings, vector search, structured memory, real-time propagation, and distributed persistence in one runtime, giving agents a shared source of context without assembling a separate memory stack.

View Source

THE PATTERN

Agents need memory that outlives the conversation.

Context Continuity

Store decisions, conversations, preferences, and other useful context outside the model session so they can be recalled later.

Shared State

Give multiple agents access to the same underlying memory while controlling what is private, shared, or scoped to a specific agent.

Durable Memory

Store memory in persistent Harper tables rather than tying it to a local process or temporary agent session.

WHAT THIS IMPLEMENTATION SHOWS

The components of a shared agent memory system.

Local Embeddings

Text can be embedded server-side using ONNX without sending every memory or query to an external embedding API.

EMBEDDING GENERATION INSIDE THE RUNTIME

Vector Retrieval

HNSW vector indexes make stored memories searchable by semantic similarity rather than exact keyword matches alone.

SEMANTIC RECALL WITH HNSW

Scoped Memory

Memories can be associated with agents, users, teams, sources, or other attributes so the same underlying system can support private and shared context.

SHARED STORAGE + SCOPED READS

Real-Time Propagation

Harper's built-in MQTT messaging can propagate new state to subscribed agents or applications as memories change.

MEMORY UPDATES WITHOUT A SEPARATE BROKER

Hybrid Retrieval

Vector similarity can be combined with structured attributes such as source, channel, author, classification, or agent ID.

SEMANTIC + STRUCTURED SEARCH

Distributed Persistence

The same application can run locally or be deployed through Harper Fabric for replicated memory across locations.

ONE MEMORY MODEL FROM LOCAL TO DISTRIBUTED

ARCHITECTURE

One runtime, full memory path.

The reference implementation keeps the data, indexing, embedding logic, APIs, and real-time messaging involved in memory inside Harper.

Application logic + data + vector search + messaging

Input

AI Agent / Application / Source

Ingest

API / Event

Receive memory through an API, integration, agent interaction, or event.

Classify

Metadata

Optionally attach metadata or classification to the incoming memory.

Embed

Local ONNX

Generate a vector representation locally through ONNX.

Store

Table + HNSW

Write the content, metadata, and vector to a Harper table with an HNSW index.

Propagate

MQTT

Publish relevant changes to other agents or applications through MQTT.

Input

Natural-Language Query

Embed Query

Local ONNX

Generate the query vector inside the runtime.

Retrieve

HNSW

Search the HNSW index for semantically related memories.

Filter

Attributes

Apply structured criteria such as agent, source, channel, author, or classification.

Return Context

HTTP / SDK / MCP

Send ranked memories through HTTP, an SDK, MCP, or another application interface.

Agent Context

Ready to Use

Relevant persistent memory is available for the agent's next action or response.

Built into Harper

Tables HNSW ONNX REST MQTT Fabric

WHY THIS ARCHITECTURE

Memory does not have to become another stack.

A shared agent memory system can easily turn into another collection of services: an application server, vector database, embedding API, message broker, cache, and synchronization layer.

This reference implementation explores what changes when those capabilities live in the same runtime.

Client AI Agent

Service 01 Application Logic

Service 02 Embedding API

Service 03 Vector Database

Service 04 Metadata Store

Service 05 Message Broker

Service 06 Replication / Synchronization

HTTP API QUERY READ / WRITE EVENTS SYNC REPLICATION

6 Services

Many Network Boundaries

Many Failure Points

Each component can be excellent independently. The application still has to coordinate data movement, credentials, network calls, deployment, and failure boundaries between them.

Agent

Application Logic

Local Embeddings

Harper Tables

HNSW Vector Index

Attribute Filtering

REST APIs

MQTT Messaging

Distributed Layer

Harper Fabric

Distributed Persistence
+ Replication

The memory path runs alongside the data it operates on, reducing the number of separate services that have to communicate, synchronize, and fail independently.

The goal is not to prescribe one universal memory architecture. It is to provide a working example of how much of the memory path can be collapsed into a single runtime.

INTERFACES

Connect the pattern to the tools you already use.

The memory implementation is exposed through multiple interfaces so the same underlying pattern can support different agent architectures.

LIVE

BUILD FROM THE PATTERN

See how shared agent memory can be built on Harper.

Explore the complete open-source implementation, understand the architecture, and adapt the pieces that make sense for your own agents and applications.

View Source

Deploy Free on Fabric

Join Discord

Shared Memory Layer for AI Agents

Agents need memory that outlives the conversation.

Context Continuity

Shared State

Durable Memory

The components of a shared agent memory system.

Local Embeddings

Vector Retrieval

Scoped Memory

Real-Time Propagation

Hybrid Retrieval

Distributed Persistence

One runtime, full memory path.

Write Path

Ingest

Classify

Embed

Store

Propagate

Read Path

Embed Query

Retrieve

Filter

Return Context

Agent Context

Memory does not have to become another stack.

A Typical Assembled Approach

The Harper Reference Pattern

Connect the pattern to the tools you already use.

MCP Server

TypeScript / HTTP

Agent Frameworks

Event Sources

See how shared agent memory can be built on Harper.