Production Vector Memory Integration with AutoGPT: HNSW Index Bottlenecks and Hybrid Search Trade-offs

When evaluating AutoGPT for production agent workflows, the memory subsystem quickly becomes the operational bottleneck. This post documents the architectural trade-offs and hardened configurations from integrating AutoGPT's long-term memory into a multi-tenant agent orchestration platform.

AutoGPT's memory backend relies on pgvector with HNSW indexing. Under sustained write load (20+ concurrent agents generating embeddings), we observed:

Root cause: HNSW indices acquire exclusive locks during graph construction. AutoGPT's default schema didn't partition by tenant or agent session, creating a single hot index.

Here's the PostgreSQL schema that resolved the lock contention:

CREATE EXTENSION IF NOT EXISTS vector;

-- Partition by agent_session_id for lock isolation
CREATE TABLE agent_memory (
    id BIGSERIAL,
    agent_session_id UUID NOT NULL,
    memory_type TEXT NOT NULL, -- episodic | semantic | procedural
    content TEXT NOT NULL,
    embedding vector(1536) NOT NULL,
    metadata JSONB DEFAULT '{}',
    created_at TIMESTAMPTZ DEFAULT NOW(),
    PRIMARY KEY (agent_session_id, id)
) PARTITION BY HASH (agent_session_id);

-- Create 8 partitions (tune based on concurrent agent count)
DO $$
BEGIN
    FOR i IN 0..7 LOOP
        EXECUTE format(
            'CREATE TABLE agent_memory_p%s PARTITION OF agent_memory FOR VALUES WITH (MODULUS 8, REMAINDER %s)',
            i, i
        );
        -- HNSW index per partition with tuned ef_construction
        EXECUTE format(
            'CREATE INDEX agent_memory_p%s_embedding_idx ON agent_memory_p%s USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64)',
            i, i
        );
    END LOOP;
END $$;

-- Filtered search index on metadata
CREATE INDEX agent_memory_metadata_idx ON agent_memory USING gin (metadata jsonb_path_ops);

Critical parameters:

m = 16: Controls graph connectivity (higher = better recall, slower inserts)ef_construction = 64: Build-time search depth (AutoGPT's default 200 was overkill for our embedding distribution) AutoGPT's memory retrieval often needs filtering by time windows or memory type before vector ranking:

-- Hybrid filter: metadata pre-filter + vector search
WITH filtered_candidates AS (
    SELECT id, content, embedding, 
           1 - (embedding <=> $1::vector) AS similarity
    FROM agent_memory
    WHERE agent_session_id = $2
      AND memory_type = ANY($3) -- ['episodic', 'semantic']
      AND created_at >= NOW() - INTERVAL '7 days'
      AND metadata @> $4::jsonb -- e.g., {"task_id": "abc123"}
)
SELECT id, content, similarity
FROM filtered_candidates
WHERE similarity > 0.7
ORDER BY similarity DESC
LIMIT 10;

This two-phase approach (GIN index metadata filter → HNSW vector scan) cut P95 query latency from 340ms to 45ms when filtering reduced the candidate set below 10K rows.

Pure vector search fails on exact keyword matches (model names, error codes). We layered BM25 full-text search with RRF scoring:

import asyncpg
import numpy as np
from typing import List, Tuple

async def hybrid_search_rrf(
    pool: asyncpg.Pool,
    agent_session_id: str,
    query_embedding: List[float],
    query_text: str,
    k: int = 10,
    rrf_k: int = 60  # RRF constant, standard default
) -> List[Tuple[int, str, float]]:
    """
    Reciprocal Rank Fusion of pgvector cosine similarity and PostgreSQL full-text search.

    Returns: [(memory_id, content, fused_score), ...]
    """

    vector_results = await pool.fetch(
        """
        SELECT id, content, 
               ROW_NUMBER() OVER (ORDER BY embedding <=> $1::vector) AS rank
        FROM agent_memory
        WHERE agent_session_id = $2
        ORDER BY embedding <=> $1::vector
        LIMIT $3
        """,
        query_embedding, agent_session_id, k * 2
    )

    fts_results = await pool.fetch(
        """
        SELECT id, content,
               ROW_NUMBER() OVER (ORDER BY ts_rank_cd(content_tsv, query) DESC) AS rank
        FROM agent_memory, plainto_tsquery('english', $1) query
        WHERE agent_session_id = $2
          AND content_tsv @@ query
        ORDER BY ts_rank_cd(content_tsv, query) DESC
        LIMIT $3
        """,
        query_text, agent_session_id, k * 2
    )

    scores = {}
    for row in vector_results:
        scores[row['id']] = scores.get(row['id'], 0) + 1.0 / (rrf_k + row['rank'])

    for row in fts_results:
        scores[row['id']] = scores.get(row['id'], 0) + 1.0 / (rrf_k + row['rank'])

    top_ids = sorted(scores.keys(), key=lambda x: scores[x], reverse=True)[:k]

    final_results = await pool.fetch(
        "SELECT id, content FROM agent_memory WHERE id = ANY($1)",
        top_ids
    )

    return [
        (row['id'], row['content'], scores[row['id']])
        for row in sorted(final_results, key=lambda r: scores[r['id']], reverse=True)
    ]

RRF advantages over weighted linear combination:

We traced the 0.73 recall rate to unnormalized embeddings upstream. AutoGPT's memory layer expects unit-normalized vectors for cosine similarity, but the default OpenAI SDK client doesn't enforce this.

Validation snippet:

import numpy as np

def validate_and_normalize(embedding: List[float]) -> List[float]:
    vec = np.array(embedding, dtype=np.float32)
    norm = np.linalg.norm(vec)

    if not (0.99 <= norm <= 1.01):
        print(f"[WARN] Unnormalized embedding detected: norm={norm:.4f}")
        vec = vec / norm

    return vec.tolist()

After enforcing normalization in the embedding generation pipeline, recall recovered to 0.89 @ k=5.

When testing embedding provider failover through B-Lost's relay gateway (baseURL: "https://b-lost.com/v1"), we measured:

The relay added 23ms P50 overhead but enabled zero-downtime provider switching when OpenAI's embedding endpoint returned 529 errors during a December incident.

What breaks at scale:

What holds up:

HNSW indices are append-optimized, but AutoGPT's memory consolidation phase periodically deletes outdated memories. PostgreSQL's VACUUM doesn't reclaim HNSW graph nodes efficiently, leading to index bloat (50% dead tuples after 10M insert/delete cycles).

Current mitigation: weekly REINDEX CONCURRENTLY during low-traffic windows. Ideal solution would be a log-structured HNSW variant that supports efficient tombstoning—does anyone have production experience with DiskANN or SPANN for this use case?