Memory Query Language

An MQL allows agents to specify what information they need rather than how to retrieve it. The agent submits a query expressing its intent (e.g., "find conversations about project Alpha from last week"), and the memory system's execution engine determines the optimal retrieval strategy. This abstraction separates the agent's reasoning logic from the complexities of underlying storage formats and indexing schemes.

Effective MQLs support queries across diverse memory representations and data types. A single query might need to combine:

• Vector search for semantic similarity.
• Graph traversal for relationship exploration.
• Structured query (SQL) for tabular metadata.
• Full-text search for keyword matching. This polyglot capability is essential for hybrid search, where results from different modalities are fused and re-ranked to provide comprehensive context.

Agent memory is inherently temporal. A robust MQL provides native operators for reasoning about time, enabling queries based on:

• Recency: "Fetch the most recent user feedback."
• Sequencing: "What steps were taken after the system alert?"
• Duration: "Find all sessions longer than 10 minutes."
• Event ordering: "Retrieve events between timestamp T1 and T2." This allows agents to reconstruct narratives and understand cause-and-effect within their stored experiences.

MQL queries are building blocks that can be composed into complex retrieval pipelines. Key features include:

• Subqueries and Joins: Combining results from multiple memory stores (e.g., joining entity details from a graph with related text chunks from a vector store).
• Filtering and Aggregation: Applying conditional logic (WHERE clauses) and functions (COUNT, GROUP BY) on retrieved results.
• Pipeline Definitions: Chaining retrieval, re-ranking, and compression steps declaratively. This programmability is central to implementing sophisticated Memory RAG Pipelines.

Queries are not executed in isolation. An MQL is designed to be aware of the agent's current operational context and state. This includes:

• Session Context: Automatically filtering memories relevant to the current dialog or task session.
• Agent Identity: Scoping queries based on the agent's permissions and role.
• Conversation History: Implicitly referencing prior turns in a dialogue without explicit query rewriting.
• Working Memory: Providing low-latency access to recently activated facts, similar to a CPU cache.

Unlike databases demanding exact matches, MQLs prioritize approximate and semantic retrieval optimized for AI reasoning. This involves:

• Similarity Operators: Native support for NEAREST or SIMILAR TO against vector embeddings.
• Approximate Nearest Neighbor (ANN) Indexes: Queries are structured to leverage ANN indices for sub-second search over billion-scale embedding sets.
• Relevance Scoring: Results are returned with similarity scores (e.g., cosine distance) allowing the agent to threshold or weight retrieved information. This is the foundation for Memory Vector Search.

The core retrieval operation for semantic memory stores. An agent converts a query into a high-dimensional embedding and searches for the most similar stored embeddings using metrics like cosine similarity or Euclidean distance. This is accelerated by Approximate Nearest Neighbor (ANN) indexes (e.g., HNSW, IVF) for scalability. It enables finding conceptually related information even without exact keyword matches.

• Key Metric: Cosine Similarity
• Index Type: Approximate Nearest Neighbor (ANN)
• Use Case: Finding semantically similar past conversations or documents.

A retrieval strategy that combines multiple techniques to improve recall and precision. A typical hybrid search merges:

• Dense Vector Search for semantic meaning.
• Sparse (Keyword) Search (e.g., BM25) for exact term matching.
• Metadata Filtering on structured fields (e.g., timestamp > '2024-01-01').

Results are combined using a weighted scoring or reciprocal rank fusion (RRF). This approach ensures an MQL can retrieve information based on both conceptual relevance and specific factual constraints.

The algorithmic process of navigating a knowledge graph memory structure. An MQL for a graph might use a language like Cypher or SPARQL to declaratively follow relationships (edges) between entities (nodes).

• Operation: MATCH (user)-[:SENT]->(message)-[:CONTAINS]->(topic)
• Purpose: To discover connections, infer new knowledge, or retrieve multi-hop context.
• Advantage: Enables complex, relational queries that are difficult with pure vector search.

The end-to-end sequence where an MQL is a critical component. It defines the flow from query to grounded response:

1. Query Formulation: The agent generates an MQL query (e.g., a search string, an embedding).
2. Retrieval Execution: The MQL is executed against the memory store (vector DB, graph).
3. Context Augmentation: Retrieved snippets are formatted into the LLM's context window.
4. Response Synthesis: The LLM generates a response grounded in the retrieved memory.

The MQL dictates the efficiency and relevance of step 2, directly impacting response quality.

The software abstraction that often exposes the MQL interface. This layer sits between the agent's core logic and disparate memory backends (vector DB, graph DB, SQL DB). Its responsibilities include:

• Query Translation: Converting a high-level agent intent into specific backend queries.
• Query Routing: Sending parts of a query to the most appropriate memory subsystem.
• Result Fusion: Combining results from multiple backends after a hybrid query.
• Caching: Managing in-memory caches to reduce latency for frequent queries. It provides a unified MQL facade over a potentially complex, multi-store memory architecture.

The underlying storage model that enables associative querying. Instead of accessing data by a fixed location (address), it is accessed by its content or a derived key.

• Examples: Hash tables (keyed by hash), vector databases (keyed by embedding similarity), and the brain's associative memory.
• MQL Role: An MQL for such a system is inherently declarative. The agent specifies what it wants (content pattern), not where to find it.
• Contrast: Differs from location-addressable memory (e.g., RAM), which requires knowing the exact memory address.