DEV Community: Pash10g

Building Persistent Memory for Voice AI Agents with MongoDB

Pash10g — Thu, 08 Jan 2026 08:31:28 +0000

Voice agents have a dirty secret: they’re goldfish. End a conversation, come back tomorrow, and they have no idea who you are. For chat apps, you can scroll up and see history. For voice? It’s gone.

We spent the last few weeks fixing this problem for our voice agent platform, and I want to share what we learned by building it with MongoDB Atlas and Gemini Live.

Demo code: Check out the complete working demo at GitHub: voice-memory-demo.

The problem with voice agent memory

When you’re building a voice agent, there are three hard problems:

Session isolation: Each browser/device needs its own memory space.
Multi-user deployments: An agent deployed on a company website has thousands of users.
Semantic retrieval: Users don’t say “What’s my name?” the same way twice.

The naïve approach is stuffing everything into conversation history. But voice sessions are expensive (OpenAI charges per audio minute), and you can’t keep 50 previous conversations in context.

You need actual persistent memory.

Memory as a tool

Here’s the thing that took us a while to figure out: don’t inject memory into the prompt. Expose it as a callable tool and let the AI decide when to use it.

We defined an agentMemory tool with four operations:

get
set
delete
query

const agentMemorySchema = {
  name: 'agentMemory',
  description: 'Store and retrieve memories about the user and conversation',
  parameters: {
    type: 'object',
    properties: {
      operation: {
        type: 'string',
        enum: ['get', 'set', 'delete', 'query'],
        description: 'The operation to perform',
      },
      key: {
        type: 'string',
        description: 'Memory key (for get/set/delete)',
      },
      value: {
        type: 'string',
        description: 'Value to store (for set)',
      },
      query: {
        type: 'string',
        description: 'Natural language query (for query operation)',
      },
    },
    required: ['operation'],
  },
};

Now, when a user says:

“I’m Pavel, I live in Tel Aviv”

the AI decides to call:

agentMemory.set({ key: 'user_name', value: 'Pavel' });
agentMemory.set({ key: 'user_location', value: 'Tel Aviv' });

Next session, the AI can call:

agentMemory.query({ query: 'user location' });

to retrieve relevant context.

The AI is making the decisions about what’s worth remembering — rather than us hardcoding rules.

User isolation: the cookie problem

When you deploy an agent on a company’s website, hundreds of users interact with it. User A shouldn’t see User B’s memories. We needed isolation.

Our approach: generate a UUID per browser/device, and store it in localStorage scoped by deployment:

export const useUserCookie = (deploymentId: string) => {
  const [userCookie] = useState<string>(() => {
    if (typeof window !== 'undefined') {
      const existing = localStorage.getItem(`userCookie_${deploymentId}`);
      if (existing) return existing;

      const newCookie = crypto.randomUUID();
      localStorage.setItem(`userCookie_${deploymentId}`, newCookie);
      return newCookie;
    }

    return crypto.randomUUID();
  });

  return { userCookie };
};

Every API call includes this cookie. Memory operations filter by it.

Simple, but there’s a catch — we’ll get to that.

Global vs private memory

Not all memories should be user-scoped.

If someone asks “What are your business hours?” and the agent looks it up, that answer should be available to everyone.
If they share their email, that’s private.

We use Gemini to classify on write operations:

async function classifyMemory(
  key: string,
  value: string,
): Promise<{
  isGlobal: boolean;
  processedValue: string;
  reasoning: string;
}> {
  const prompt = `Analyze this memory and classify it:
Key: ${key}
Value: ${value}

Categories that should be GLOBAL (shared across all users):
- Product information, pricing, features
- Company info, business hours, policies
- Factual data about services

Categories that should be PRIVATE (user-specific):
- User names, contact info, preferences
- Personal details, account info
- Session-specific data

If GLOBAL and contains emails/phones, obfuscate them.

Return: { isGlobal: boolean, processedValue: string, reasoning: string }`;

  // ... Gemini call

  // return { isGlobal, processedValue, reasoning };
}

The obfuscation part matters. If a user mentions a support email and we store it globally, we replace it with [EMAIL]. Phone numbers become [PHONE].

Global memories are useful context, but we don’t want to leak PII across users.

Voyage AI embeddings

For semantic search, we went with Voyage AI’s voyage-3.5-lite model.

Why not OpenAI embeddings? Cost. We’re generating embeddings on every write operation, and Voyage AI is significantly cheaper at scale.

const VOYAGE_API_URL = 'https://api.voyageai.com/v1/embeddings';
const VOYAGE_MODEL = 'voyage-3.5-lite'; // 1024 dimensions

export async function generateEmbedding(text: string): Promise<number[]> {
  const response = await fetch(VOYAGE_API_URL, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${process.env.VOYAGE_AI_API_KEY}`,
    },
    body: JSON.stringify({
      input: text,
      model: VOYAGE_MODEL,
    }),
  });

  const data = await response.json();
  return data.data[0].embedding; // 1024-dim vector
}

Embeddings get stored alongside the memory document in MongoDB.

MongoDB schema

Here’s what a memory document looks like:

{
  deploymentId: 'deployment_abc123',
  key: 'user_preference_communication',
  value: 'Prefers email over phone calls',
  userCookie: 'uuid-xxx-yyy-zzz', // or "global" for shared memories
  isGlobal: false,
  embedding: [0.123, -0.456, /* ... 1024 floats ... */],
  createdAt: ISODate('2024-12-01T10:00:00Z'),
  updatedAt: ISODate('2024-12-01T10:00:00Z'),
}

You need two indexes:

Vector search index on the embedding field (for semantic queries).
Text search index on key and value fields (for keyword matching).

Hybrid search with `$rankFusion`

Pure vector search misses obvious keyword matches. Pure text search misses semantic similarity.

MongoDB 8.0 introduced $rankFusion, which combines both.

const searchPipeline = [
  {
    $rankFusion: {
      input: {
        pipelines: {
          vectorSearch: [
            {
              $vectorSearch: {
                index: 'memory_vector_index',
                path: 'embedding',
                queryVector: queryEmbedding,
                numCandidates: 100,
                limit: 30,
                filter: {
                  deploymentId,
                  $or: [
                    { userCookie: effectiveUserCookie },
                    { isGlobal: true },
                  ],
                },
              },
            },
          ],
          textSearch: [
            {
              $search: {
                index: 'memory_text_index',
                compound: {
                  should: [
                    {
                      text: {
                        query: searchQuery,
                        path: 'key',
                        fuzzy: {},
                      },
                    },
                    {
                      text: {
                        query: searchQuery,
                        path: 'value',
                        fuzzy: {},
                      },
                    },
                  ],
                },
              },
            },
            {
              $match: {
                $or: [
                  { userCookie: effectiveUserCookie },
                  { isGlobal: true },
                ],
              },
            },
            { $limit: 30 },
          ],
        },
      },
      combination: {
        weights: { vectorSearch: 0.7, textSearch: 0.3 },
      },
    },
  },
];

We settled on 70/30 weighting after testing:

Vector search (0.7) handles “tell me about my communication preferences” matching user_preference_communication.
Text search (0.3) handles “What’s my name?” matching a key literally called user_name.

Voice implementation: 2 different beasts

We support both OpenAI and Gemini for voice. They’re completely different architectures. The demo uses Gemini Live, but here’s how both work.

OpenAI Realtime (WebRTC)

OpenAI’s approach uses WebRTC. Audio goes directly to their servers, and they handle speech-to-text and text-to-speech internally.

import { OpenAIRealtimeWebRTC } from '@openai/agents/realtime';

const transport = new OpenAIRealtimeWebRTC({
  mediaStream,  // from getUserMedia()
  audioElement, // for playback
});

await transport.connect({
  apiKey: clientSecret, // from /api/session
  initialSessionConfig: {
    modalities: ['audio'],
    audio: {
      input: {
        transcription: { model: 'gpt-4o-mini-transcribe' },
        turnDetection: { type: 'server_vad' },
      },
    },
  },
});

// Tool calls arrive as events
transport.on('response.function_call_arguments.done', async (msg) => {
  const { name, arguments: args, call_id } = msg;

  // Execute tool, then:
  const result = await handleToolCall(name, args);
  transport.sendFunctionCallOutput({
    call_id,
    output: JSON.stringify(result),
  });
});

The nice part: audio codec handling is invisible.

The annoying part: tool calls come as events you need to catch and route yourself.

Gemini Live (WebSocket)

Gemini uses raw WebSockets. You’re responsible for audio format conversion. Here’s how we set it up in the demo:

import { GoogleGenAI, Modality } from '@google/genai';

const ai = new GoogleGenAI({ apiKey });

const session = await ai.live.connect({
  model: 'models/gemini-2.5-flash-native-audio-preview-12-2025',
  config: {
    responseModalities: [Modality.AUDIO],
    speechConfig: {
      voiceConfig: {
        prebuiltVoiceConfig: { voiceName: 'Puck' },
      },
    },
    systemInstruction: { parts: [{ text: systemPrompt }] },
    tools: [{ functionDeclarations: tools }],
  },
  callbacks: {
    onmessage: async (message) => {
      // Handle audio data
      if (message.data) {
        const buffer =
          typeof message.data === 'string'
            ? Buffer.from(message.data, 'base64')
            : message.data;

        const int16Array = new Int16Array(
          buffer.buffer,
          buffer.byteOffset,
          buffer.byteLength / 2,
        );

        // Queue for playback at 24kHz
        audioQueue.push(int16Array);
        processAudioQueue();
      }

      // Handle tool calls
      if (message.toolCall?.functionCalls) {
        for (const call of message.toolCall.functionCalls) {
          const result = await onToolCall(call.name, call.args || {});
          await session.sendToolResponse({
            functionResponses: [
              {
                id: call.id,
                name: call.name,
                response: { result: JSON.stringify(result) },
              },
            ],
          });
        }
      }
    },
  },
});

Gemini expects 16 kHz PCM input and outputs 24 kHz PCM. You need an AudioWorklet for capture:

// audio-processor.js (AudioWorklet)
class AudioCaptureProcessor extends AudioWorkletProcessor {
  process(inputs, outputs, parameters) {
    const input = inputs[0];

    if (input && input[0]) {
      // Convert Float32 to Int16 for sending
      const int16Array = new Int16Array(input[0].length);

      for (let i = 0; i < input[0].length; i++) {
        int16Array[i] = Math.max(
          -32768,
          Math.min(32767, input[0][i] * 32768),
        );
      }

      this.port.postMessage({ type: 'audio', data: int16Array.buffer });
    }

    return true;
  }
}

registerProcessor('audio-capture-processor', AudioCaptureProcessor);

More work than WebRTC, but more control over the audio pipeline.

Routing tool calls

When the AI calls a tool during voice, you need to route it to your backend:

const handleToolCall = useCallback(
  async (name: string, args: Record<string, unknown>) => {
    if (name === 'agentMemory') {
      const response = await fetch('/api/memory', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          ...args,
          deploymentId: DEPLOYMENT_ID,
          userCookie,
        }),
      });

      const data = await response.json();
      return data.result;
    }

    return { error: 'Unknown tool' };
  },
  [userCookie],
);

The memory API handles all four operations (get, set, delete, query) and routes them to the appropriate service functions.

Hybrid search with `$rankFusion`: the technical deep dive

Pure vector search, while excellent for capturing semantic similarity (finding memories conceptually related to the query), often fails at lexical matching (finding exact keywords). Conversely, a pure text index search excels at keyword matching but struggles when a user’s query uses different phrasing to refer to the same concept (for example, “my address” vs. “where I live”).

MongoDB 8.0’s $rankFusion aggregation stage is the technical solution that combines the best of both worlds. It operates by performing the two distinct search pipelines — vectorSearch and textSearch — and then applying the Reciprocal Rank Fusion (RRF) algorithm to merge the results.

How `$rankFusion` works

Independent search pipelines

The vectorSearch pipeline uses the memory_vector_index to find the top numCandidates (100) results based on the cosine similarity between the user’s query embedding (queryVector) and the stored memory embeddings. It then limits this to 30 and applies a filter for deploymentId and user isolation (userCookie or isGlobal: true).
The textSearch pipeline uses the memory_text_index to find the top 30 lexical matches across the key and value fields, leveraging fuzzy matching for robustness. It applies the same user isolation $match filter.

Reciprocal Rank Fusion (RRF)

This is the core of the hybrid search. For each document found in both pipelines, RRF assigns a score based on its rank in each result list:

[
Score(d) = \sum_{r \in R} \frac{1}{k + rank_r(d)}
]

where:

R is the set of search results (vector and text),
k is a constant (typically 60),
rank_r(d) is the document’s rank in the result set r.

This process effectively rewards documents that appear high in either list, or moderately high in both.

Weighted combination

The combination object allows for fine‑tuning the influence of each search type before the final score is calculated. The 70/30 weighting:

vectorSearch: 0.7 — prioritizes semantic relevance, which is crucial for a natural language voice agent. A higher weight here ensures the agent’s intent (for example, “tell me about my communication preferences”) strongly biases the results toward conceptually similar memories.
textSearch: 0.3 — keeps a smaller but significant weight for keyword accuracy. This handles unambiguous, direct queries like “What’s my name?” where a literal match to a key like user_name is paramount, preventing a purely semantic search from hallucinating or prioritizing a less relevant but semantically rich document.

This hybrid approach ensures the voice agent is robust: it handles the nuances of natural language via vector search while retaining the precision required for direct, fact‑based queries via text search.

Performance notes

A few things we learned:

Embedding on write is fine. Voyage AI calls take ~100 ms. Users expect a slight delay when the AI is “remembering” something.
Query embedding latency matters more. We cache query embeddings for repeated searches in the same session.
MongoDB Atlas handles the vector math. Don’t try to do similarity calculations client‑side. The $vectorSearch aggregation stage is optimized for this.

What’s next?

We’re still tuning the 70/30 hybrid search weights based on production data. We’re also looking at cross-deployment memory sharing for agents that need to access a global knowledge base while maintaining user isolation within that deployment.

The memory-as-tool pattern has been the biggest win. Instead of complex prompt engineering to inject context, we let the AI decide what’s relevant. It forgets less and hallucinates less because it’s pulling from actual stored data rather than trying to infer from truncated conversation history.

Todos That Ship Themselves: MongoDB Atlas + Vercel + ChatGPT Apps SDK

Pash10g — Tue, 09 Dec 2025 08:09:55 +0000

MongoDB Atlas turns everyday data into a launchpad for generative AI workflows. Pair it with Vercel’s serverless edge and OpenAI’s new ChatGPT Apps SDK and even a humble to-do list can become a collaborative assistant that lives wherever your users are. We built chatgpt-todo-mcp during MongoDB.local NYC to show how little friction it takes: Spin up MongoDB Atlas, drop the connection string into a Next.js app, and distribute a shareable list manager straight through ChatGPT. It feels less like “writing yet another CRUD app” and more like shipping a co-worker that never misses a checkbox.

Important! at the moment ChatGPT needs to be in "Developer Mode", which means paid plan like Plus.

Why MongoDB Atlas anchors ChatGPT apps

Flexible documents for human-shaped data: Tasks come with free-form text, completion state, ordering, and sharing metadata. MongoDB Atlas stores it all in a single document without forcing you into rigid schemas.
Scales with serverless traffic: Atlas connection pooling keeps Vercel function cold starts low while auto-scaling handles usage spikes from popular GPTs.
Productivity-friendly safety net: Need to demo offline? lib/mongodb.ts slips into an in-memory store when MONGODB_URI is missing, so you can prototype locally and swap to Atlas when you’re ready.
Secrets that stay server-side: Environment variables on Vercel map cleanly to MongoDB Atlas credentials, ensuring ChatGPT widgets never leak database access to the browser.
Observability baked in: Atlas’ metrics, query profiler, and triggers let you watch your GPT’s behavior evolve without bolting on extra tooling.

The app in a nutshell

chatgpt-todo-mcp is a Next.js 15 project that exposes a single, relatable capability: managing shared task lists. Lists live in two MongoDB Atlas collections-todo_lists for metadata and todo_items for the work itself—while a polished React widget keeps everyone in sync, whether they open the Vercel page or summon the tool inside ChatGPT. The same backend routes serve both experiences, so once you deploy to Vercel, the ChatGPT App SDK can reuse the exact infrastructure. It is the classic “single source of truth” story, except your truth now answers spoken prompts.

ChatGPT MCP App Demo

Tutorial: Launch the todo assistant yourself

You’ll need a MongoDB Atlas cluster (M0 is plenty), Node.js 20+, a Vercel project, and access to ChatGPT’s “Develop your own” experience. Expect to bounce between the Atlas UI, your favorite terminal, and the ChatGPT builder tab—it’s a tight loop that keeps momentum high.

1. Create the dataset in MongoDB Atlas

Spin up an Atlas project and cluster, then open the Collections tab.
Add a database named chatgpt_todos with two collections: todo_lists and todo_items.
Seed your first list with mongosh or the Atlas Data Importer:

use chatgpt_todos
db.todo_lists.insertOne({
  title: "Launch checklist",
  shareToken: crypto.randomUUID(),
  createdAt: new Date()
})

Keep the connection string handy—you’ll paste it into the app shortly.

2. Wire Next.js to Atlas (and keep local dev easy)

The project’s lib/mongodb.ts centralizes the connection logic and quietly falls back to a memory store if you haven’t provided MONGODB_URI. That means local demos stay fast while production reads straight from MongoDB Atlas:

// lib/mongodb.ts
const uri = process.env.MONGODB_URI || "mongodb://localhost:27017"
const options = { maxPoolSize: 10, minPoolSize: 1, maxIdleTimeMS: 30000 }

if (!useMemoryStore) {
  client = new MongoClient(uri, options)
  clientPromise = client.connect()
}

export async function getDatabase(): Promise<Db | MemoryDb> {
  try {
    const client = await clientPromise
    return client.db("chatgpt_todos")
  } catch (error) {
    console.error("Failed to connect to MongoDB, falling back to in-memory store", error)
    return getMemoryDb()
  }
}

Drop your Atlas URI into .env as MONGODB_URI (placed in the root directory of the project), restart the dev server, and the same API calls now persist to the cloud.

3. Build CRUD APIs that ChatGPT and the UI share

All list interactions flow through app/api/todos/[listId]/route.ts. The GET handler fetches the list and its items, while POST branches on an action field to add, toggle, or delete tasks:

// app/api/todos/[listId]/route.ts
const items = await db
  .collection("todo_items")
  .find({ listId: new ObjectId(listId) })
  .sort({ order: 1 })
  .toArray()

switch (action) {
  case "add":
    await db.collection("todo_items").insertOne({
      listId: new ObjectId(listId),
      text,
      completed: false,
      order: itemsCount,
      createdAt: new Date(),
    })
    break
  case "toggle":
    await db.collection("todo_items").updateOne(
      { _id: new ObjectId(itemId), listId: new ObjectId(listId) },
      { $set: { completed } },
    )
    break
  case "delete":
    await db.collection("todo_items").deleteOne({ _id: new ObjectId(itemId), listId: new ObjectId(listId) })
    break
}

Because Atlas handles concurrent writes and ordering, ChatGPT can queue new tasks and see the updated list in one round trip.

4. Craft the shared UI and ChatGPT widget

components/todo-list-widget.tsx is the heart of the user experience. It renders the list, performs optimistic updates, and keeps the browser and MongoDB Atlas in sync:

// components/todo-list-widget.tsx
const optimisticItem = {
  id: "temp-" + Date.now(),
  text: newItemText,
  completed: false,
  order: items.length,
}
mutate({ ...data, items: [...items, optimisticItem] }, false)
await fetch(`/api/todos/${listId}`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ action: "add", text: newItemText }),
})

When the same widget runs inside ChatGPT (see app/todos/widget/page.tsx), it listens for tool invocations and routes user actions back through the app SDK:

// app/todos/widget/page.tsx
if (window?.openai?.callTool) {
  window.openai.callTool("add_todo_item", {
    listId: data.listId,
    text: newItemText,
  })
}

That bridge is what lets a user say “Add ‘order swag’ to the launch checklist” in ChatGPT and watch the Vercel-hosted UI update in real time.

5. Hand the controls to ChatGPT via the MCP route

app/mcp/route.ts is where the ChatGPT Apps SDK plugs in. The handler renders the widget HTML once, registers it as a resource, and then lists every tool ChatGPT can call—create, add, complete, delete, fetch, list, and even bulk upsert items—all backed by Atlas:

// app/mcp/route.ts
const handler = createMcpHandler(async (server) => {
  const html = await getAppsSdkCompatibleHtml(baseURL, "/todos/widget")

  server.registerTool(
    "create_todo_list",
    { title: "Create Todo List", inputSchema: { title: z.string().min(1) }, _meta: widgetMeta(todoWidget) },
    async ({ title }) => {
      const { db } = await connectToDatabase()
      const listId = nanoid()
      await db.collection("todo_lists").insertOne({ _id: listId, title, shareToken: nanoid(16), createdAt: new Date() })
      return { structuredContent: { listId, title, items: [] }, _meta: widgetMeta(todoWidget) }
    },
  )
})

Every other tool follows the same pattern: validate input with zod, hit MongoDB Atlas through connectToDatabase, and return both human-readable text and structured content so the ChatGPT UI knows how to render the latest list. Because the widget HTML is cached and served from /todos/widget, the ChatGPT experience looks indistinguishable from the Vercel site.

6. Deploy to Vercel and register the tool

Push the repo to GitHub, then import it into Vercel.
Add MONGODB_URI (and any sharing tokens you want to pre-seed) under Environment Variables.
Deploy—the app auto-detects its public URL through baseUrl.ts, so the Model Context Protocol endpoints advertise the proper origin.
In ChatGPT, open Settings → Apps & Connectors → Create → Inside the workflow, fill the fields and point it at https://<your-app>.vercel.app/mcp. Make sure that you choose no authentication for the simplicity of the demo. Populate the tool list with the Todo operations, reload ChatGPT, and you’re ready to collaborate with your new assistant.

Field notes before you ship

Use MongoDB Atlas Performance Advisor to spot hot queries as your GPT gains users; it will recommend indexes for large task boards.
Consider a capped “activity” collection to log completions—Atlas Triggers can fan those events out to Slack or Vercel in real time.
Keep environment variables organized per environment in Vercel. Atlas makes it easy to create separate users for preview, staging, and production so you never test with live data.

What’s next

With the plumbing finished, swap in your own collections—daily standups, customer onboarding tasks, or any workflow that benefits from a conversational front door. MongoDB Atlas gives you a forever-on source of truth, Vercel ships the experience worldwide, and the ChatGPT Apps SDK turns it into a tool teams can summon on demand. That combination makes “let’s just build it” a realistic answer, even on conference wifi.

Building Intelligent AI Agents with MongoDB Atlas: A Bidirectional Data Flow Architecture

Pash10g — Tue, 02 Dec 2025 12:55:48 +0000

As AI agents become increasingly sophisticated, the way applications interact with databases is fundamentally changing. Gone are the days of simple CRUD operations and static queries. Modern AI-powered applications require a bidirectional data flow where:

Agents feed from the database - Using semantic search and retrieval-augmented generation (RAG) to access relevant data
Agents feed back to the database - Storing conversation context, user interactions, and learned preferences
Agents transform the UI - Dynamically updating search filters, results, and interface elements based on natural language understanding

In this article, I'll walk you through a fully featured rental property search application that demonstrates how MongoDB Atlas's document model and vector search capabilities make this bidirectional agent-database architecture not just possible, but elegant and performant.

Looking for realistic sample data? All of the screenshots and demos below use the 6k-listing Airbnb dataset that MongoDB published on Hugging Face. The repo ships with seed-hf-airbnb-data.js, which downloads that dataset, loads it into MongoDB Atlas (including the vector field), and makes the entire experience turnkey.

Why MongoDB Atlas is perfect for AI agent applications

Before diving into the code, let's understand why MongoDB Atlas stands out for agent-based architectures:

1. Flexible document model

AI agents work with diverse, semi-structured data—user conversations, property details, embeddings, and metadata. MongoDB's document model handles this naturally without rigid schemas:

{
  "_id": ObjectId("..."),
  "sessionId": "user-session-123",
  "userId": ObjectId("..."),
  "messages": [
    {
      "role": "user",
      "content": "Find me a 2BR in Manhattan under $200",
      "timestamp": ISODate("2024-01-15T10:30:00Z"),
      "metadata": {
        "context": { "filters": { "bedrooms": 2, "location": "New York" } }
      }
    },
    {
      "role": "assistant",
      "content": "I found 15 properties matching your criteria...",
      "timestamp": ISODate("2024-01-15T10:30:05Z"),
      "metadata": {
        "tool_calls_made": 1,
        "search_performed": true,
        "rental_ids": [123, 456, 789]
      }
    }
  ],
  "metadata": {
    "totalMessages": 2,
    "lastActivity": ISODate("2024-01-15T10:30:05Z")
  }
}

2. Native vector search

MongoDB Atlas Vector Search enables semantic understanding at the database layer. No need for external vector databases or complex integrations:

{
  $vectorSearch: {
    index: "rental_vector_search",
    path: "text_embeddings",
    queryVector: [0.1234, -0.5678, ...], // 1536-dimensional embedding
    numCandidates: 100,
    limit: 10,
    filter: {
      "address.market": { $eq: "New York" },
      "price": { $lte: 200 },
      "bedrooms": { $gte: 2 }
    }
  }
}

3. Rich querying and aggregations

MongoDB's aggregation pipeline lets you combine vector search with traditional filters, scoring, and transformations in a single operation.

4. Unified platform

Store embeddings, conversation history, user profiles, and application data in one database. No data synchronization headaches.

Architecture overview: The bidirectional data flow

Our rental search application demonstrates three key data flows:

┌─────────────────────────────────────────────────────────────┐
│                         User Interface                       │
│              (Natural Language + Dynamic Filters)            │
└───────────────────────┬─────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│                    OpenAI Agents SDK                         │
│              (GPT-4o-mini with Custom Tools)                 │
└───────┬───────────────────────────┬─────────────────────────┘
        │                           │
        │ ① Agents Feed FROM DB     │ ② Agents Feed TO DB
        ▼                           ▼
┌─────────────────────┐     ┌──────────────────────────────┐
│  Vector Search      │     │  Conversation Storage        │
│  • Embeddings       │     │  • Chat History             │
│  • Semantic Query   │     │  • User Context             │
│  • Filters          │     │  • Search Metadata          │
└─────────────────────┘     └──────────────────────────────┘
        │                           │
        └───────────┬───────────────┘
                    ▼
        ③ Agents Transform UI
    ┌──────────────────────────┐
    │  • Update Search Filters │
    │  • Display Results       │
    │  • Modify Interface      │
    └──────────────────────────┘

Let's explore each flow in detail.

Flow 1: Agents feed FROM the database (RAG pattern)

The first and most critical flow is how agents access relevant data to answer user queries. This is the classic retrieval-augmented generation (RAG) pattern.

Step 1: Vector embeddings as data foundation

Every rental property in our database includes a 1536-dimensional embedding generated from its description, amenities, and location:

{
  "_id": 12345,
  "name": "Luxury Manhattan Loft",
  "description": "Stunning 2-bedroom loft in heart of SoHo...",
  "property_type": "Loft",
  "price": 175,
  "bedrooms": 2,
  "address": {
    "market": "New York",
    "neighbourhood": "SoHo",
    "country": "United States"
  },
  "amenities": ["WiFi", "Kitchen", "Elevator", "Gym"],
  "text_embeddings": [0.023, -0.145, 0.891, ...], // ← Generated from OpenAI
  "review_scores": {
    "review_scores_rating": 95
  }
}

Key insight: Embeddings are stored alongside the data they represent, eliminating the need for separate vector stores and JOIN operations.

Step 2: Agent tool definition

Using the OpenAI Agents SDK, we define a searchRentals tool that the agent can invoke:

import { Agent, tool } from '@openai/agents';
import { z } from 'zod';

this.searchRentalsTool = tool({
  name: 'searchRentals',
  description: "'Search for rental properties using semantic search based on user preferences.',"
  parameters: z.object({
    query: z.string().describe('Natural language search query'),
    filters: z.object({
      min_price: z.number().nullable().optional(),
      max_price: z.number().nullable().optional(),
      min_bedrooms: z.number().nullable().optional(),
      location: z.string().nullable().optional(),
      superhost_only: z.boolean().nullable().optional()
    }).nullable().optional(),
    limit: z.number().default(5)
  }),
  execute: this.handleSearchRentals.bind(this)
});

What makes this powerful: The agent understands the tool's capabilities through the description and parameter schema, deciding when and how to invoke it based on user intent.

Step 3: Hybrid search implementation

When the agent invokes the tool, we perform a hybrid search combining vector similarity with traditional filters:

async hybridSearch(queryText, filters = {}, limit = 10) {
  // Generate query embedding
  const queryEmbedding = await this.generateEmbedding(queryText);

  // Build vector search pipeline
  const pipeline = [
    {
      $vectorSearch: {
        index: "rental_vector_search",
        path: "text_embeddings",
        queryVector: queryEmbedding,
        numCandidates: 100,
        limit: limit,
        filter: {
          // Combine semantic + structured filters
          "address.market": filters.location ? { $eq: filters.location } : undefined,
          "price": {
            $gte: filters.min_price || 0,
            $lte: filters.max_price || 999999
          },
          "bedrooms": { $gte: filters.min_bedrooms || 0 },
          "host.host_is_superhost": filters.superhost_only ? { $eq: true } : undefined
        }
      }
    },
    {
      $project: {
        name: 1,
        description: "1,"
        property_type: 1,
        price: 1,
        bedrooms: 1,
        "address.market": 1,
        "address.country": 1,
        score: { $meta: "vectorSearchScore" } // ← Similarity score
      }
    }
  ];

  return await collection.aggregate(pipeline).toArray();
}

MongoDB's superpower here:

Vector search and traditional filters execute in a single database query
No post-processing, no multiple round-trips
Results are sorted by semantic relevance (cosine similarity)

Step 4: Agent processes and responds

The agent receives structured results and generates a natural language response:

async handleSearchRentals({ query, filters, limit }) {
  const results = await vectorSearchService.hybridSearch(query, filters, limit);

  // Format for agent consumption
  const formattedResults = results.map((rental, index) => ({
    rank: index + 1,
    id: rental._id,
    name: rental.name,
    price: rental.price,
    bedrooms: rental.bedrooms,
    location: `${rental.address.neighbourhood}, ${rental.address.country}`,
    rating: (rental.review_scores.review_scores_rating / 20).toFixed(1),
    similarity_score: rental.score.toFixed(3)
  }));

  return JSON.stringify({
    total_found: results.length,
    query_used: query,
    results: formattedResults
  });
}

The result: User asks "Find me a cozy apartment in Barcelona for under €150" → Agent extracts intent → Searches MongoDB with semantic understanding → Returns relevant properties.

Flow 2: Agents feed TO the database (context persistence)

What makes AI agents truly intelligent is memory. Every interaction teaches the system about user preferences and context. MongoDB's document model makes this persistence natural.

Conversation storage pattern

export class ConversationModel {
  static async addMessage(sessionId, role, content, metadata = {}, userId = null) {
    const message = {
      id: new ObjectId().toString(),
      role, // 'user' or 'assistant'
      content,
      timestamp: new Date(),
      metadata: {
        ...metadata,
        userId: userId || null,
        isAuthenticated: userId !== null
      }
    };

    // Upsert pattern: Create conversation if not exists
    await collection.updateOne(
      { sessionId },
      {
        $push: { messages: message },
        $inc: { 'metadata.totalMessages': 1 },
        $set: {
          updatedAt: new Date(),
          'metadata.lastActivity': new Date()
        },
        $setOnInsert: {
          userId: userId,
          createdAt: new Date()
        }
      },
      { upsert: true }
    );
  }
}

Why this matters:

Upsert pattern: Create conversation on first message, append to existing ones
Nested documents: Messages are embedded in conversation, no JOINs needed
Atomic updates: $push, $inc, $set operations are atomic and efficient
Rich metadata: Store context about tool calls, search results, user state

Storing agent metadata

After the agent responds, we capture what it did:

// Store assistant response with rich metadata
await ConversationModel.addMessage(sessionId, 'assistant', response.message, {
  tool_calls_made: response.toolCalls?.length || 0,
  has_rental_results: response.metadata?.search_performed || false,
  search_metadata: {
    query: response.metadata.search_query,
    filters_applied: response.metadata.search_filters,
    rental_ids: response.metadata.rental_ids // ← IDs of returned properties
  },
  timestamp: new Date().toISOString()
}, userId);

The power: Later queries can reference previous searches, compare properties, and recall user preferences—all because we stored structured metadata alongside conversational content.

User activity tracking

MongoDB's flexible schema lets us track diverse user actions:

await UserModel.updateActivity(userId, {
  $push: {
    activity_log: {
      action: 'search_performed',
      timestamp: new Date(),
      details: {
        query: userMessage,
        results_count: results.length,
        filters_used: filters
      }
    }
  },
  $inc: { 'stats.total_searches': 1 },
  $set: { 'stats.last_search_date': new Date() }
});

Real-world use case: Build personalized recommendations, identify power users, analyze search patterns—all from this rich behavioral data.

Flow 3: Agents transform the UI (dynamic interface updates)

The most magical aspect of agent-database integration is when the agent's understanding directly manipulates the user interface.

The metadata bridge

When an agent performs a search, it returns not just conversational text, but structured metadata:

{
  success: true,
  message: "I found 15 great properties in Barcelona under €150...",
  metadata: {
    search_performed: true,
    search_query: "cozy apartment in Barcelona under €150",
    search_filters: {
      location: "Barcelona",
      max_price: 150,
      property_type: "Apartment"
    },
    rental_ids: [12345, 12346, 12347, ...]
  }
}

Frontend integration

The UI watches for this metadata and reacts:

async function sendMessage() {
  const response = await fetch('/chat', {
    method: 'POST',
    body: JSON.stringify({
      message: userInput,
      context: {
        current_search: searchBar.value,
        filters: getCurrentFilters()
      }
    })
  });

  const data = await response.json();

  // Display conversational response
  displayMessage(data.message);

  // Check if agent performed a search
  if (data.metadata.search_performed) {
    // ① Update UI filters based on agent's understanding
    updateFiltersUI(data.metadata.search_filters);

    // ② Fetch and display the rental results
    const rentals = await fetchRentalsByIds(data.metadata.rental_ids);
    displayRentals(rentals);

    // ③ Update URL and browser history
    updateURLParams(data.metadata.search_filters);
  }
}

User experience:

User: "Show me 2 bedroom apartments in Manhattan under $200"
         ↓
Agent: [Understands intent, extracts filters, searches MongoDB]
         ↓
UI: ✨ Location dropdown changes to "New York"
    ✨ Bedrooms filter updates to "2+"
    ✨ Price slider moves to "$0-$200"
    ✨ Results grid displays matching properties
    ✨ Chat shows: "I found 15 properties matching your criteria..."

Bidirectional filter sync

The genius is that filters work both ways:

Manual filter → Agent context: User adjusts UI filters → Passed to agent in next message
Agent understanding → UI filters: Agent extracts intent from natural language → Updates UI filters

// Sending filter context to agent
const chatPayload = {
  message: userInput,
  context: {
    filters: {
      location: locationDropdown.value,
      min_price: priceSlider.min,
      max_price: priceSlider.max,
      bedrooms: bedroomFilter.value
    }
  }
};

// Agent enhances message with current filter state
if (context.filters && Object.keys(context.filters).length > 0) {
  enhancedMessage += ` Current filters: ${formatFilters(context.filters)}`;
}

Why this works: MongoDB stores both the agent's understanding (in conversation metadata) and the current UI state (in user preferences), creating a single source of truth.

Advanced patterns: Going beyond basic RAG

Pattern 1: Saved rentals with agent integration

Users can save favorite properties, and the agent accesses this data:

this.getSavedRentalsTool = tool({
  name: 'getSavedRentals',
  description: 'Get the user\'s saved rental properties for comparison and recommendations.',
  parameters: z.object({
    includeDetails: z.boolean().default(false)
  }),
  execute: async ({ includeDetails }) => {
    const savedRentals = await UserModel.getSavedRentals(userId);

    if (includeDetails) {
      // Fetch full property data using rental IDs
      const detailedRentals = await Promise.all(
        savedRentals.map(saved => RentalModel.findById(saved.rental_id))
      );
      return JSON.stringify(detailedRentals);
    }

    return JSON.stringify(savedRentals);
  }
});

User experience:

User: "Compare my saved properties in terms of price and location"
         ↓
Agent: [Calls getSavedRentals with includeDetails=true]
         ↓
MongoDB: Returns full property documents
         ↓
Agent: "Here's a comparison of your 3 saved properties:
        1. Manhattan Loft ($175/night) - SoHo, great for nightlife
        2. Barcelona Apartment (€120/night) - Gothic Quarter, historic charm
        3. Sydney Studio ($140/night) - Bondi, beach vibes

        The Barcelona option offers the best value, while Manhattan is ideal
        if you prioritize being in the center of the action."

Pattern 2: Context-aware property details

When a user views a property, that context is passed to the agent:

const chatPayload = {
  message: "Tell me about the neighborhood",
  context: {
    current_property: {
      id: 12345,
      name: "Luxury Manhattan Loft",
      location: { market: "New York", neighbourhood: "SoHo" },
      features: { bedrooms: 2, price: 175 }
    }
  }
};

The agent receives this context and provides targeted advice:

if (context.current_property) {
  const property = context.current_property;
  enhancedMessage += ` User is currently viewing: "${property.name}" in ${property.location.neighbourhood}`;
}

Agent response: "SoHo is one of Manhattan's most vibrant neighborhoods, known for its cast-iron architecture, upscale boutiques, and art galleries. You'll be walking distance from great restaurants and nightlife. At $175/night for a 2-bedroom, this is competitive for the area."

Pattern 3: Hybrid search with scoring

Combine vector similarity with business logic:

const pipeline = [
  {
    $vectorSearch: {
      index: "rental_vector_search",
      path: "text_embeddings",
      queryVector: queryEmbedding,
      numCandidates: 100,
      limit: 50 // Get more candidates for scoring
    }
  },
  {
    $addFields: {
      vector_score: { $meta: "vectorSearchScore" },
      rating_score: {
        $divide: ["$review_scores.review_scores_rating", 100]
      },
      superhost_bonus: {
        $cond: ["$host.host_is_superhost", 0.1, 0]
      }
    }
  },
  {
    $addFields: {
      final_score: {
        $add: [
          { $multiply: ["$vector_score", 0.6] },      // 60% semantic relevance
          { $multiply: ["$rating_score", 0.3] },      // 30% ratings
          { $multiply: ["$superhost_bonus", 0.1] }    // 10% superhost boost
        ]
      }
    }
  },
  {
    $sort: { final_score: -1 }
  },
  {
    $limit: 10
  }
];

Result: Properties ranked by a combination of semantic relevance, user ratings, and business rules—all computed in MongoDB.

MongoDB Atlas setup for production

1. Vector search index configuration

{
  "fields": [
    {
      "numDimensions": 1536,
      "path": "text_embeddings",
      "similarity": "cosine",
      "type": "vector"
    },
    {
      "path": "property_type",
      "type": "filter"
    },
    {
      "path": "address.market",
      "type": "filter"
    },
    {
      "path": "price",
      "type": "filter"
    },
    {
      "path": "bedrooms",
      "type": "filter"
    },
    {
      "path": "host.host_is_superhost",
      "type": "filter"
    }
  ]
}

Key points:

vector field for semantic search
filter fields for structured filtering
Cosine similarity for 1536-dim OpenAI embeddings

2. Supporting indexes

// Conversation history lookup
db.conversations.createIndex({ "sessionId": 1 });
db.conversations.createIndex({ "userId": 1, "metadata.lastActivity": -1 });

// User activity queries
db.users.createIndex({ "username": 1 }, { unique: true });
db.users.createIndex({ "saved_rentals.rental_id": 1 });

// Rental property queries
db.rentals.createIndex({ "address.market": 1, "price": 1 });
db.rentals.createIndex({ "bedrooms": 1, "accommodates": 1 });

3. Aggregation pipeline optimization

Use $project early to reduce data transfer:

{
  $vectorSearch: { /* ... */ }
},
{
  $project: {
    name: 1,
    price: 1,
    bedrooms: 1,
    "address.market": 1,
    score: { $meta: "vectorSearchScore" }
    // Only fetch what you need
  }
}

Performance considerations

Embedding generation strategy

// Cache embeddings at data ingestion
async function seedRental(rental) {
  const embeddingText = `${rental.name}. ${rental.description}.
    Located in ${rental.address.market}, ${rental.address.country}.
    ${rental.property_type} with ${rental.bedrooms} bedrooms.
    Amenities: ${rental.amenities.join(', ')}.`;

  rental.text_embeddings = await generateEmbedding(embeddingText);

  await db.rentals.insertOne(rental);
}

Never generate embeddings at query time—pre-compute and store them.

Conversation history management

// Limit conversation history to last 20 messages
const conversation = await collection.findOne(
  { sessionId },
  {
    projection: {
      messages: { $slice: -20 }, // Only get last 20
      metadata: 1
    }
  }
);

Why: Sending an entire conversation history to LLMs is expensive. Recent context is usually sufficient.

Connection pooling

const client = new MongoClient(uri, {
  maxPoolSize: 50,
  minPoolSize: 10,
  maxIdleTimeMS: 30000
});

Production tip: Pool size should match expected concurrent users/requests.

Security best practices

1. User-scoped data access

// NEVER trust client-provided userId
const userId = await verifyJWT(authToken);

// All queries scoped to authenticated user
const savedRentals = await db.users.findOne(
  { _id: ObjectId(userId) },
  { projection: { saved_rentals: 1 } }
);

2. Input sanitization

// Validate and sanitize before DB operations
const filters = {
  min_price: Math.max(0, parseInt(filters.min_price) || 0),
  max_price: Math.min(10000, parseInt(filters.max_price) || 10000),
  location: sanitizeString(filters.location)
};

3. Rate limiting

// Track API usage per user
await db.users.updateOne(
  { _id: userId },
  {
    $inc: { 'rate_limits.api_calls_today': 1 },
    $set: { 'rate_limits.last_call': new Date() }
  }
);

Real-world results: What we achieved

Performance metrics

Average search latency: 150-300ms (embedding generation + vector search + formatting)
Vector search alone: 50-80ms for 5,000+ properties
Conversation storage: <10ms per message (upsert with indexing)
Concurrent users: Tested up to 100 simultaneous chat sessions

User experience wins

Natural language accuracy: 90%+ intent extraction on first try
Filter synchronization: Seamless bidirectional updates
Context retention: Agent remembers previous searches and user preferences
Multi-turn conversations: Supports complex, multi-step property searches

Developer experience

Single database: No data synchronization between vector DB and app DB
Unified query language: MongoDB aggregation for everything
Flexible schema: Add new metadata fields without migrations
Rich ecosystem: Works with Mongoose, native driver, Prisma, etc.

Lessons learned & best practices

1. Design your document schema for agent access

// ❌ Bad: Deeply nested, agent can't navigate
{
  "data": {
    "property_info": {
      "details": {
        "location": { ... }
      }
    }
  }
}

// ✅ Good: Flat, predictable structure
{
  "name": "...",
  "address": { "market": "...", "country": "..." },
  "price": 150,
  "bedrooms": 2
}

2. Include both structured and unstructured data

{
  "name": "Cozy Manhattan Loft",
  "description": "Full natural language description...", // ← For embeddings
  "property_type": "Loft",                              // ← For filtering
  "bedrooms": 2,                                        // ← For filtering
  "amenities": ["WiFi", "Kitchen"],                     // ← For filtering
  "text_embeddings": [...]                              // ← For vector search
}

3. Store agent metadata richly

// Don't just store the conversation
{
  "role": "assistant",
  "content": "I found 5 properties..."
}

// Store what the agent DID
{
  "role": "assistant",
  "content": "I found 5 properties...",
  "metadata": {
    "tool_calls": ["searchRentals"],
    "filters_applied": { "location": "New York", "max_price": 200 },
    "rental_ids": [123, 456],
    "user_satisfied": true // Track based on follow-up
  }
}

4. Optimize for agent token limits

// Return concise summaries to the agent
const formattedResults = results.map(r => ({
  id: r._id,
  name: r.name,
  price: r.price,
  location: `${r.address.market}, ${r.address.country}`,
  bedrooms: r.bedrooms
  // Skip description, images, etc. - retrieve on-demand
}));

5. Enable agent self-discovery

// Provide tools for agents to explore data
this.exploreDataTool = tool({
  name: 'exploreAvailableMarkets',
  description: 'Get list of available cities/markets in the database',
  execute: async () => {
    const markets = await db.rentals.distinct('address.market');
    return JSON.stringify(markets);
  }
});

The future: What's next for agent-database integration

1. Agent-driven schema evolution

Imagine agents that suggest new fields based on user queries:

Agent: "I notice users frequently ask about 'pet-friendly' properties,
        but this field doesn't exist. Should I add it to the schema?"

2. Semantic caching

MongoDB could cache embedding+filter combinations:

{
  "query_hash": "sha256(...)",
  "embedding": [...],
  "filters": { "location": "New York" },
  "cached_results": [...],
  "valid_until": ISODate("2024-01-15T12:00:00Z")
}

3. Multi-agent coordination

Different specialized agents sharing the same MongoDB instance:

Search agent: Finds properties
Booking agent: Handles reservations
Recommendation agent: Suggests based on history
All coordinating through shared conversation and user state

4. Continuous learning from feedback

// User indicates result quality
{
  "search_query": "cozy apartment in Barcelona",
  "results_shown": [123, 456, 789],
  "user_clicked": 456,        // Implicit feedback
  "user_saved": [456],        // Strong signal
  "user_booked": 456          // Conversion
}

Use this data to fine-tune embeddings or ranking algorithms.

Conclusion: MongoDB Atlas as the foundation for intelligent applications

Building AI agents that truly understand and serve users requires more than just a language model. You need a database that:

✅ Stores semantic understanding (vectors) alongside structured data (filters).

✅ Handles dynamic, evolving schemas (conversations, metadata, user context).

✅ Enables bidirectional data flow (agents read, write, and transform).

✅ Performs at scale (millisecond searches across thousands of documents).

✅ Provides a unified platform (no juggling multiple databases).

MongoDB Atlas delivers all of this with its document model and vector search capabilities. As we've seen in this rental search application:

Agents feed FROM the database using semantic vector search combined with traditional filters.
Agents feed TO the database by storing rich conversation context and metadata.
Agents transform the UI through structured metadata that synchronizes with interface elements.

This bidirectional architecture represents the future of AI-powered applications. And MongoDB Atlas makes it not just possible, but elegant, performant, and production-ready.

Try it yourself

The complete code for this project is available on GitHub.

Quick start:

git clone https://github.com/mongodb-developer/mongodb-openai-agentic-rentals.git

cd mongodb-openai-agentic-rentals
bun install
# Configure .env with your MongoDB Atlas URI and OpenAI API key
node seed-hf-airbnb-data.js
bun start
# Visit http://localhost:3001

What to explore:

Try natural language queries: "Find me a beachfront property in Sydney".
Watch the UI filters update automatically.
Check the MongoDB conversation collection to see stored context.
Examine the aggregation pipelines in src/services/vector-search.service.js.
Extend the agent with new tools in src/agents/rental-rag-agent.js.

Additional resources

About the Author: Pavel Duchovny is a Developer Advocate at MongoDB, passionate about helping developers build intelligent, scalable applications. Connect on Twitter or LinkedIn.

Have questions or feedback? Open an issue on the GitHub repo or reach out to the MongoDB Developer Community.

LangGraph With MongoDB: Building Conversational Long-Term Memory for Intelligent AI Agents

Pash10g — Mon, 18 Aug 2025 20:47:23 +0000

Introduction: The memory problem in AI agents

LangGraph has proven to be one of the most adoptable AI frameworks for building AI agents, but there's been a critical missing piece: persistent, intelligent memory. Most AI agents today suffer from amnesia—they forget everything between conversations, can't learn from past interactions, and fail to build meaningful relationships with users.

MongoDB Atlas is a scalable and extremely stable database solution perfect for the AI era. The flexibility of the document model, combined with the ability to have your operational data right next to your vectorized data for semantic and hybrid searches, makes MongoDB Atlas a robust solution for AI memory management.

LangMem is a powerful new addition to the LangChain suite that allows you to add sophisticated, long-term memory management to your AI agents. Combined with MongoDB's built-in checkpointer and the new MongoDB Store for LangGraph, we now have a complete solution— Reasoning AI → Tools → Storage → Memory —to form a new level of intelligent, context-aware, and personalized experiences.

Technical deep dive: how it works

The architecture

Our solution combines three critical components that work together seamlessly:

MongoDBStore : Vector-based semantic memory storage with intelligent retrieval, as well as a key value store

MongoDBSaver : Conversation state persistence and resumption

Memory Management Tools : Agent-controlled memory operations

Let's explore each component and how they integrate.

Component 1: MongoDBStore—semantic memory storage

The MongoDBStore handles long-term memory storage using vector embeddings, via Voyage AI state-of-the-art models for semantic search:

from langgraph.store.mongodb.base import MongoDBStore, VectorIndexConfig
from langchain_voyageai import VoyageAIEmbeddings

# Initialize MongoDB connection
client = MongoClient(MONGODB_URI)
db = client["memories"]
collection = db["memory_store"]

# Create the store with vector search capabilities
store = MongoDBStore(
    collection=collection,
    index_config=VectorIndexConfig(
        fields=None,          # Auto-detect fields for indexing
        filters=None,         # No additional filters
        dims=1536,           # OpenAI embedding dimensions
        embed=VoyageAIEmbeddings(model="voyage-3.5")   # Embedding model for vector search
    )
auto_index_timeout=70
)

Key features:

Semantic search : Finds memories based on meaning, not just keywords
Namespace organization : Memories can be organized by category ("memories", "preferences", etc.)
Vector indexing : Automatic creation of MongoDB Atlas Vector Search indexes
Scalable storage : Handles thousands of memories without performance degradation

Component 2: MongoDBSaver—conversation checkpointing

The MongoDBSaver manages conversation state and enables thread resumption:

from langgraph.checkpoint.mongodb import MongoDBSaver

# Initialize the checkpointer
checkpointer = MongoDBSaver(
    client,                            # MongoDB client
    db_name="memories",               # Database name
    collection_name="thread_checkpoints"   # Collection for conversation state
)

What it saves:

Complete message history for each conversation thread
Agent state between interactions
Tool call results and intermediate steps
Configuration and metadata

Thread management:

# Each conversation gets a unique thread ID
config = {"configurable": {"thread_id": "thread-a"}}

# The checkpointer automatically:
# 1. Saves state after each interaction
# 2. Loads previous state when thread resumes
# 3. Maintains conversation context

Integration—how they work together

Here's how the components integrate in a complete agent:

from langgraph.prebuilt import create_react_agent
from langmem import create_manage_memory_tool

def prompt(state, store):
    """Dynamic prompt that injects relevant memories"""
    # Semantic search for relevant memories
    memories = store.search(
        ("memories",),   # Namespace
        query=state["messages"][-1].content,   # Current user message
    )
    system_msg = f"""You are a shopping assistant with persistent memory.
## Relevant Memories
<memories>
{memories}
</memories>
Use these memories to provide personalized responses."""
    return [{"role": "system", "content": system_msg}, *state["messages"]]

# Create the complete agent
agent = create_react_agent(
    "openai:gpt-4o",
    prompt=lambda state: prompt(state, store),   # Inject memories into prompt
    tools=[
        create_manage_memory_tool(namespace=("memories",)),   # Memory management
        search_products   # Domain-specific tools
    ],
    store=store,            # Long-term memory storage
    checkpointer=checkpointer,   # Conversation persistence
)

Memory lifecycle in action

Here's what happens during a complete interaction:

# 1. User starts conversation
config = {"configurable": {"thread_id": "user-123"}}
response = agent.invoke({
    "messages": [{"role": "user", "content": "I am vegan"}]
}, config=config)

# Behind the scenes:
# a) MongoDBSaver loads any existing conversation state
# b) MongoDBStore searches for relevant memories (initially empty)
# c) Agent processes the message and decides to save preference
# d) create_manage_memory_tool saves "User is vegan" to MongoDBStore
# e) MongoDBSaver saves the complete interaction state

# 2. Later conversation (same or different thread)
new_config = {"configurable": {"thread_id": "user-123-session-2"}}
response = agent.invoke({
    "messages": [{"role": "user", "content": "Help me find pasta"}]
}, config=new_config)

# Behind the scenes:
# a) MongoDBSaver loads thread state (may be empty for new thread)
# b) MongoDBStore searches memories for "pasta" context
# c) Vector search finds "User is vegan" as relevant
# d) Agent provides vegan pasta recommendations
# e) State saved for future resumption

Real-world implementation example

Let's see a complete shopping assistant:

import logging

logger = logging.getLogger(__name__)
logger.setLevel(logging.ERROR)

db = client["ai_shop"]
collection = db["products"]

@tool
def search_products(query: str) -> str:
    """Searches for products in the database using vector search."""

    vectorstore = MongoDBAtlasVectorSearch(collection, OpenAIEmbeddings(), text_key="title", embedding_key="embedding", index_name="vector_index")
    docs = vectorstore.similarity_search(query, k=5)

    return "\n".join([str(doc.metadata) for doc in docs])



def create_shopping_agent():
    """Complete shopping assistant with memory"""

    # Memory storage setup
    store = MongoDBStore(
        collection=client.memories.user_preferences,
        index_config=VectorIndexConfig(
            dims=1536,
            embed=VoyageAIEmbeddings(model="voyage-3.5"),
            fields=["content"],
            filters=["active"]
        )
    )

    # Conversation persistence
    checkpointer = MongoDBSaver(
        client,
        db_name="shopping_assistant",
        collection_name="conversations"
    )

    # Dynamic prompt with memory injection
    def enhanced_prompt(state, store):
        user_query = state["messages"][-1].content

        # Search for relevant user preferences
        memories = store.search(
            ("preferences",),
            query=user_query,
            limit=3,
            filter={"active": True}
        )

        # Search for relevant past purchases
        purchase_history = store.search(
            ("purchases",),
            query=user_query,
            limit=2
        )

        system_msg = f"""You are an expert shopping assistant with access to:
        - Product search capabilities
        - User preference memory
        - Purchase history

## User Preferences
{memories}

## Recent Purchase Context
{purchase_history}

Provide personalized, helpful shopping advice."""

        return [{"role": "system", "content": system_msg}, *state["messages"]]

    # Create agent with all capabilities
    return create_react_agent(
        "openai:gpt-4o",
        prompt=lambda state: enhanced_prompt(state, store),
        tools=[
            create_manage_memory_tool(namespace=("preferences",)),
            create_manage_memory_tool(namespace=("purchases",)),
            search_products
        ],
        store=store,
        checkpointer=checkpointer
    )

# Usage example
agent = create_shopping_agent()


def get_user_config(user_id, thread_id="default_thread"):
    return {"configurable": {"user_id": user_id, "thread_id": thread_id}}


# Conversation 1: Learning preferences
config = get_user_config("user123")
response = agent.invoke({
    "messages": [{"role": "user", "content": "I'm vegan and prefer organic products"}]
}, config=config)

print(response["messages"][-1].content)

# Conversation 2: Using learned preferences (different session)
config = get_user_config("user123", "mobile-app")
response = agent.invoke({
    "messages": [{"role": "user", "content": "Find me some pasta options"}]
}, config=config)
# Agent automatically applies vegan + organic filters

print(response["messages"][-1].content)

Problems this solution solves

1. Memory persistence across sessions

Traditional agents lose all context when a conversation ends. With MongoDB persistence, memories survive server restarts, deployments, and extended periods between interactions.

2. Intelligent memory retrieval

Instead of dumping all past information into the context, vector search ensures only relevant memories are retrieved, keeping conversations focused and efficient while maintaining important context.

3. Scalable memory management

MongoDB's document model and Atlas's vector search capabilities mean your agent's memory can grow without performance degradation. The system gracefully handles thousands of memories per user.

4. Cross-conversation learning

Memories aren't tied to specific conversation threads. An agent can learn a user's preferences in one conversation and apply that knowledge in completely separate interactions days or weeks later.

5. Self-managing memory

Agents can autonomously decide what information is worth remembering, updating outdated preferences, and even forgetting irrelevant details—just like human memory.

MongoDB Atlas: production-grade AI memory infrastructure

Multi-tenant memory architecture

For applications serving multiple users:

def create_user_scoped_agent(user_id: str):
    """Create agent with user-isolated memory"""
    # User-specific memory namespace
    user_namespace = ("users", user_id, "memories")
    store = MongoDBStore(
        collection=collection,
        index_config=VectorIndexConfig(
            dims=1536,
            embed=OpenAIEmbeddings(),
            # Filter ensures user isolation
            filters={"metadata.user_id": user_id}
        )
    )
    # Memory tools scoped to user
    memory_tool = create_manage_memory_tool(
        namespace=user_namespace,
        # Add user_id to all memories
        metadata_filter={"user_id": user_id}
    )
    return create_react_agent(
        "openai:gpt-4o",
        tools=[memory_tool],
        store=store,
        checkpointer=MongoDBSaver(
            client,
            db_name="multi_tenant_memories",
            collection_name=f"user_{user_id}_checkpoints"
        )
    )

Key benefits for developers

🎯 Production-ready architecture

Automatic scaling : MongoDB Atlas handles traffic spikes and data growth
High availability : Built-in replication and failover
Global distribution : Deploy memory close to your users
Enterprise security : Encryption, authentication, and compliance-ready

🔧 Flexible integration

Zero breaking changes : Add to existing LangGraph agents without modification
Multiple namespaces : Organize memories by type, user, or domain
Custom embeddings : Use any embedding model (VoyageAI [recommended], OpenAI, Cohere, local models)
Metadata filtering : Precise memory retrieval with custom filters

💡 Intelligent memory management

Semantic search : Vector-based retrieval finds contextually relevant memories
Automatic indexing : MongoDB Atlas creates optimized vector search indexes
Memory lifecycle : Agents can create, update, and delete their own memories
Cross-thread persistence : Memories survive conversation boundaries

Use cases that transform user experience

Personal AI assistants

Remember user preferences, habits, and goals.
Provide increasingly personalized recommendations.
Build genuine rapport through consistent context.

Customer support agents

Recall past support interactions and resolutions.
Understand customer context and history.
Provide continuity across different support channels.

Educational AI tutors

Track learning progress and identify knowledge gaps.
Adapt teaching strategies based on student responses.
Remember what explanations worked best for each student.

Healthcare AI companions

Monitor long-term health trends and symptoms.
Remember medication schedules and reactions.
Provide consistent care coordination.

Getting started

Please see our notebook for code implementation details.

The future of AI conversations

This integration represents a fundamental shift in how we build AI agents. Instead of stateless, forgetful bots, we can now create AI companions that truly learn, remember, and grow with their users.

The combination of LangGraph's agent orchestration, LangMem's memory management, and MongoDB's robust data platform creates a foundation for the next generation of AI applications—ones that feel less like tools and more like digital partners.

Conclusion

Memory transforms everything. It's the difference between a helpful tool and a trusted companion, between answering questions and understanding needs, between artificial intelligence and artificial empathy.

With LangMem and MongoDB, that transformation is now within reach for every developer building AI agents. The future of conversational AI isn't just smarter responses—it's relationships that persist, grow, and deepen over time.

Ready to give your AI agents a memory? Start building with the complete code example in our interactive notebook and see how persistent memory can transform your user experiences today.

Want to learn more? Check out the MongoDB Atlas Vector Search documentation and explore the LangGraph integration tutorial for advanced memory management patterns.

Building an HR Team-Matching Agent With MongoDB Vector Search, Voyage AI, & Vercel AI SDK

Pash10g — Tue, 22 Apr 2025 09:00:00 +0000

Picture this: You're an HR manager at a growing tech company. It's Monday morning, and the VP of Product has just dropped a request in your inbox: "We need a team for a new strategic project. Must have experience with React, MongoDB, authentication systems, and cloud deployment. They need to work well together, and we need them to start by Friday."

Sound familiar? If you've worked in HR or talent management, you know this scenario all too well.

Building the right team is often more art than science. The traditional approach involves scanning resumes for keywords, checking availability spreadsheets, and relying heavily on your memory of who works well with whom. It's manual, time-consuming, and prone to overlooking the perfect candidate whose resume doesn't explicitly list "React" but has extensive "frontend JavaScript framework" experience.

This is precisely the kind of problem where traditional workflow-based AI falls short. If you tried to map out every possible decision tree for team building, you'd need to account for:

Thousands of possible skill combinations.
Varying levels of experience and proficiency.
Complex interpersonal dynamics.
Project-specific requirements.
Changing availability.
Career development goals.

No wonder traditional HR systems struggle with this complexity!

Enter agentic AI with Vercel and MongoDB

What if you could simply describe your project needs in plain language and have an AI assistant that:

Understands the semantic meaning behind your requirements?
Searches your talent database using intelligent matching?
Reasons through complex team compositions?
Provides recommendations with clear justifications?
Saves teams to a database for tracking and management?

This is where the combination of Vercel AI SDK's agentic capabilities and MongoDB's Vector Search becomes transformative.

Unlike traditional AI approaches that follow rigid, predefined paths, agentic AI can break down complex problems into manageable steps and solve them iteratively—much like an experienced HR professional would. The Vercel AI SDK makes this easy with its maxSteps parameter, allowing the AI to make a series of intelligent decisions as it builds the perfect team.

Meanwhile, MongoDB's vector search capabilities solve the keyword matching problem by understanding the semantic relationships between skills. "React developer," "JSX experience," and "frontend JavaScript framework specialist" are no longer separate search terms—they're related concepts in a semantic space.

In this article, we'll build an HR team-matching agent that combines these powerful technologies to transform how organizations assemble project teams. You'll learn how to:

Represent employee skills as vector embeddings using Voyage AI.
Create powerful search tools with MongoDB Atlas Vector Search.
Implement agentic patterns with Vercel AI SDK.
Build a complete database-backed system for team recommendations.
Create a management interface for tracking and approving teams.

Let's dive in!

Understanding vector embeddings for skills

Before we dive into the implementation, let's discuss why vector embeddings are so powerful for representing employee skills.

Traditional keyword matching has significant limitations in HR contexts:

Synonym problems: Does your database recognize that "ML" and "Machine Learning" are the same skill?
Contextual understanding: Is "Python" being used for data science, web development, or automation?
Skill relatedness: How do you capture that someone with React experience might ramp up quickly on Vue?
Expertise levels: How do you differentiate between "familiar with Python" and "Python expert"?

Vector embeddings solve these challenges by representing skills in a high-dimensional space where semantic similarity corresponds to vector proximity. This allows us to capture nuanced relationships between skills that keyword matching simply cannot.

Generating skill embeddings with Voyage AI

For our implementation, we'll use Voyage AI to generate high-quality embeddings. Voyage offers state-of-the-art embedding models that capture the semantic relationships between different skills and technical concepts. Recently, Voyage AI joined MongoDB. With Voyage AI, MongoDB's roadmap is to have AI-powered search and retrieval native to the database. Instead of implementing workarounds or managing separate systems, developers can generate high-quality embeddings from real-time operational data, store vectors, perform semantic search, and refine results—all within MongoDB.

First, let's create a utility function to generate embeddings (GitHub):

import { voyage } from 'voyage-ai-provider';
import { embedMany } from 'ai';

const embeddingModel = voyage.textEmbeddingModel('voyage-3');

export const generateEmbeddings = async (
  value: string,
): Promise<Array<{ embedding: number[]; content: string }>> => {
  // Generate chunks from the input value
  const chunks = value.split('\n');
  const { embeddings } = await embedMany({
    model: embeddingModel,
    values: chunks,
  });

  return embeddings.map((e, i) => ({ content: chunks[i], embedding: e }));
};

When creating or updating employee profiles, we'll generate embeddings for their skills that capture not just the skill name but also proficiency, experience, and contexts:

async function generateSkillEmbeddings(employees: Array<Omit<Employee, '_id'>>) {
  for (const employee of employees) {
    try {
      // Create combined skill description using | as separator
      const skillDescriptions = employee.skills.map(skill =>
        `${skill.name}: ${skill.proficiency}/5 proficiency with ${skill.yearsExperience} years experience in contexts like ${skill.contexts.join(', ')}`
      );

      const combinedSkillDescription = skillDescriptions.join(' | ');

      // Generate embedding for all skills combined
      const embeddingResults = await generateEmbeddings(combinedSkillDescription);

      // Add the embedding to the employee document at the top level
      if (embeddingResults.length > 0) {
        (employee as any).embedding = embeddingResults[0].embedding;
        console.log(`✅ Generated top-level embedding for ${employee.name}'s combined skills`);
      } else {
        console.warn(`⚠️ No embeddings generated for ${employee.name}'s combined skills`);
        (employee as any).embedding = [];
      }
    } catch (error) {
      console.error(`❌ Error generating embedding for ${employee.name}'s skills:`, error);
      // Set an empty embedding as fallback
      (employee as any).embedding = [];
    }
  }

  return employees;
}

async function updateEmployeeSkillEmbeddings(employee) {
  const employeesWithEmbeddings = await generateSkillEmbeddings(employee);

  // Update employee record in MongoDB
  await db.employees.updateOne(
    { _id: employee._id },
    { $set: { embedding: employeesWithEmbeddings.embedding } }
  );
}

MongoDB data models and vector search setup

Before we dive into the implementation details, let's define our MongoDB schema and set up vector search. (GitHub)

Database schemas

// types.ts - Database schema definitions
export interface Employee {
  _id?: ObjectId;
  name: string;
  title: string;
  department: string;
  email: string;
  hireDate: Date;
  availability: number; // percentage available for new projects
  skills: Skill[];
  performance: {
    rating: number; // 1-5 scale
    teamworkScore: number; // 1-5 scale
    lastReviewDate: Date;
  };
  pastProjects: {
    projectId: ObjectId;
    role: string;
    contribution: string;
  }[];
  teamHistory: ObjectId[]; // IDs of employees they've worked with
  embedding: number[]; // Combined skills embedding at the top level
}

export interface Team {
  _id?: ObjectId;
  projectTitle: string;
  projectDescription: string;
  createdAt: Date;
  members: {
    name: string;
    role: string;
    keySkills: string[];
    justification: string;
  }[];
  skillCoverage: number;
  overallRationale: string;
  risks: string[];
  mitigationStrategies: string[];
  status: 'proposed' | 'approved' | 'active' | 'completed';
}

Setting up MongoDB Atlas Vector Search

First, we need to create a vector search index in MongoDB Atlas on the "employees" collection:

// Vector search index configuration via atlas UI called `skill_vector_index`
{
  "fields": [
    {
      "type": "vector",
      "path": "embedding",
      "numDimensions": 1024,
      "similarity": "cosine"
    }
  ]
}

Once our index is set up, we can perform vector searches to find employees with specific skills:

const embedding = await generateEmbeddings(query)

// Perform vector search with additional filters
const matchingEmployees = await employeesCollection.aggregate([
  {
    $vectorSearch: {
      index: "skills_vector_index",
      path: "embedding",
      queryVector: embedding,
      numCandidates: 100,
      limit: 20
    }
  },
  // Filter by proficiency and availability
  {
    $match: {
      "skills.proficiency": { $gte: minProficiency },
      "availability": { $gte: minAvailability }
    }
  },
  // Project relevant fields
  {
    $project: {
      _id: 1,
      name: 1,
      title: 1,
      department: 1,
      availability: 1,
      hireDate: 1,
      performance: 1,
      relevantSkills: {
        $filter: {
          input: "$skills",
          as: "skill",
          cond: { $gte: ["$$skill.proficiency", minProficiency] }
        }
      },
      pastProjects: 1,
      teamHistory: 1,
      similarity: { $meta: "vectorSearchScore" }
    }
  },
  // Sort by similarity score
  {
    $sort: {
      similarity: -1
    }
  }
]).toArray();

return matchingEmployees;

This query will return employees whose skills are semantically similar to the requested skill, not just those who have an exact keyword match.

Building agentic HR tools with Vercel AI SDK

What makes Vercel AI SDK so powerful for HR applications is its agentic capabilities. Unlike traditional AI implementations that follow a fixed workflow, an agentic approach allows the AI to break down complex problems, make decisions, and iteratively work toward a solution.

This is particularly valuable for HR challenges like team building, where the solution path isn't always clear at the outset.

Understanding Vercel's agentic pattern

At the heart of Vercel's agentic implementation is the maxSteps parameter. Here's how it works:

The HR manager submits a project description.
The AI analyzes the request and determines what information it needs.
The AI calls a tool (like searching for employees with a particular skill).
The AI receives the result and decides what to do next.
Steps 3-4 repeat until the AI has gathered enough information to make a recommendation.
The AI delivers a final, structured recommendation.

This iterative process mirrors how an experienced HR professional might approach team building—gathering information, testing hypotheses, and refining recommendations based on what they learn.

Implementing team analysis logic

Before we create our tools, let's implement the core logic for analyzing team compositions (GitHub):

calculateSkillCoverage
calculateTeamDiversity
analyzeCollaborationHistory
calculateTeamScore

Defining our HR agent tools

Now, let's create the specialized tools our HR agent will need. These are the available endpoints for the large language model to produce the needed context or results (GitHub):

analyzeProjectRequirements
searchEmployeesBySkill
analyzeTeamComposition
saveTeamToDatabase
generateTeamRecommendation

import { tool } from 'ai';
import { z } from 'zod';
import { MongoClient, ObjectId } from 'mongodb';
import { voyage } from 'voyage-ai-provider';
import { embedMany } from 'ai';
import {
  calculateSkillCoverage,
  calculateTeamDiversity,
  analyzeCollaborationHistory,
  calculateTeamScore,
  generateTeamAnalysis
} from './teamAnalysis';
import { Employee, Team } from './types';
import { generateEmbeddings } from './embeddings';

// Initialize MongoDB connection
const mongoClient = new MongoClient(process.env.MONGODB_URI!);
const db = mongoClient.db('hr_database');
const employeesCollection = db.collection<Employee>('employees');
const teamsCollection = db.collection<Team>('teams');

// Tool 1: Project Requirements Analysis

// Tool 2: Skill Search with MongoDB Vector Search
export const searchEmployeesBySkill = tool({
  description: 'Searches for employees with specific skills using semantic matching.',
  parameters: z.object({
    skillDescription: z.string().describe('Description of the required skill'),
    minProficiency: z.number().describe('Minimum proficiency level (1-5)'),
    minAvailability: z.number().describe('Minimum availability percentage')
  }),
  execute: async ({ skillDescription, minProficiency = 3, minAvailability = 20 }) => {
    try {
      // Generate embedding for the skill description using Voyage AI
      const embeddingResults = await generateEmbeddings(skillDescription);
      if (embeddingResults.length === 0) {
        return { error: "Failed to generate embedding for skill description" };
      }
      const embedding = embeddingResults[0].embedding;

      // Perform vector search with additional filters
      const matchingEmployees = await employeesCollection.aggregate([
        {
          $vectorSearch: {
            index: "skills_vector_index",
            path: "embedding",
            queryVector: embedding,
            numCandidates: 100,
            limit: 20
          }
        },
        // Filter by proficiency and availability
        {
          $match: {
            "skills.proficiency": { $gte: minProficiency },
            "availability": { $gte: minAvailability }
          }
        },
        // Project relevant fields
        {
          $project: {
            _id: 1,
            name: 1,
            title: 1,
            department: 1,
            availability: 1,
            hireDate: 1,
            performance: 1,
            relevantSkills: {
              $filter: {
                input: "$skills",
                as: "skill",
                cond: { $gte: ["$$skill.proficiency", minProficiency] }
              }
            },
            pastProjects: 1,
            teamHistory: 1,
            similarity: { $meta: "vectorSearchScore" }
          }
        }
      ]).toArray();

      return matchingEmployees;
    } catch (error) {
      console.error("Error searching for employees:", error);
      return { error: "Failed to search for employees" };
    }
  },
});

// Tool 3: Team Composition Analysis

// Tool 4: Database Integration - Save Team

// Tool 5: Team Recommendation (structured output)

Integrating tools with Vercel AI SDK

Now, let's implement the main agent function that orchestrates these tools under api/build-team/route.ts(GitHub):

import { NextRequest, NextResponse } from 'next/server';
import { openai } from '@ai-sdk/openai';
import { generateText, tool } from 'ai';
import { z } from 'zod';
import {
  analyzeProjectRequirements,
  searchEmployeesBySkill,
  analyzeTeamComposition,
  saveTeamToDatabase,
  generateTeamRecommendation
} from '../../../utils/tools';

export async function POST(req: NextRequest) {
  try {
    const { projectDescription } = await req.json();
    if (!projectDescription) {
      return NextResponse.json({ error: 'Project description is required' }, { status: 400 });
    }

    const result = await buildTeam(projectDescription);
    return NextResponse.json(result);
  } catch (error) {
    console.error('Error building team:', error);
    return NextResponse.json({ error: 'Failed to build team' }, { status: 500 });
  }
}

async function buildTeam(projectDescription: string) {
  const { steps, toolCalls } = await generateText({
    model: openai('o3-mini', { structuredOutputs: true }),
    tools: {
      analyzeProjectRequirements,
      searchEmployeesBySkill,
      analyzeTeamComposition,
      saveTeamToDatabase,
      generateTeamRecommendation,
    },
    toolChoice: 'auto', // Force structured output using the generateTeamRecommendation tool
    maxSteps: 15, // This is the key to enabling agentic behavior!
    system: `You are an expert HR assistant that builds optimal teams for projects.
    Given a project description follow this set of steps:
    1. Analyze the requirements to identify needed skills (analyzeProjectRequirements)
    2. Search for employees with matching skills (searchEmployeesBySkill)
    3. Evaluate possible team compositions (analyzeTeamComposition)
    4. MUST Save the recommended team to the database (saveTeamToDatabase)
    5. Generate a final recommendation with justification (generateTeamRecommendation)

    Consider skill coverage, team diversity, availability, and past collaboration success.
    Be thorough in your analysis but aim to build the smallest effective team possible. If unable to complete a team, please provide a reason why but do place people with potential.

    After your final recommendation is complete, save the team to the database for record-keeping.`,
    prompt: projectDescription,
  });

  console.log(JSON.stringify(steps.map(step => step.toolCalls), null, 2))

  // Find the last generateTeamRecommendation call for the final recommendation
  const recommendationCall = toolCalls.find(
    call => call.toolName === 'generateTeamRecommendation'
  );

  // Find the database save call to get the team ID
  const databaseCall = toolCalls.find(
    call => call.toolName === 'saveTeamToDatabase'
  );

  // Combine the recommendation with the database result
  if (recommendationCall && databaseCall) {
    return {
      recommendation: recommendationCall.args,
      databaseResult: databaseCall.args
    };
  }

  // Fallback to just the recommendation if database save failed
  if (recommendationCall) {
    return { recommendation: recommendationCall.args };
  }

  return { error: "Failed to generate team recommendation" };
}

The maxSteps parameter is what enables our agent to make multiple tool calls in sequence, iteratively building its solution. It allows the agent to:

Analyze project requirements.
Search for employees with specific skills.
Evaluate different team compositions.
Save the chosen team to the database.
Generate a structured recommendation.

Without maxSteps, we would need to manually code each step of this process, making our implementation much more rigid and less adaptable to different kinds of projects.

The complete HR team-building workflow

Let's visualize the entire workflow to understand how the different components work together:

The workflow starts when the HR manager submits a project description. This kicks off a series of steps:

Project Analysis: The agent analyzes the project description to extract required skills and their importance.
Skill Matching: For each required skill, the agent performs a vector search to find matching employees.
Team Composition: The agent evaluates different combinations of employees to form potential teams.
Team Analysis: Each potential team is analyzed for skill coverage, diversity, and past collaboration.
Team Selection: The agent selects the optimal team based on the analysis.
Database Storage: The selected team is saved to the database for future reference.
Recommendation Generation: A structured recommendation with justification is returned to the HR manager.
Team Approval: The HR manager can review and approve the recommended team.
Status Tracking: The team's status is updated as it moves through the project lifecycle.

This end-to-end process creates a seamless experience for HR managers, from initial request to team tracking.

Bringing it all together: A practical example

Let's see our HR team-building agent in action with a real-world scenario. Imagine you're an HR manager at a fintech company, and you receive the following project request:

"We need to build a new customer portal for our wealth management platform. The portal needs to have a modern React front end with sophisticated data visualization components, connect to our MongoDB database, and implement OAuth 2.0 for secure authentication. We also need someone familiar with financial regulations and compliance. The project timeline is tight—we need to launch in 2 months. This is a high-visibility project for our top clients."

Step 1: Analyze project requirements

First, the agent calls analyzeProjectRequirements to extract structured information:

// Agent's first tool call
{
  "tool": "analyzeProjectRequirements",
  "parameters": {
    "projectDescription": "We need to build a new customer portal for our wealth management platform. The portal needs to have a modern React frontend with sophisticated data visualization components, connect to our MongoDB database, and implement OAuth 2.0 for secure authentication. We also need someone familiar with financial regulations and compliance. The project timeline is tight—we need to launch in 2 months. This is a high-visibility project for our top clients."
  }
}

The tool returns:

{
  "requiredSkills": [
    { "skill": "React", "importance": 5 },
    { "skill": "Data Visualization", "importance": 4 },
    { "skill": "MongoDB", "importance": 4 },
    { "skill": "OAuth 2.0", "importance": 4 },
    { "skill": "Financial Regulations", "importance": 3 },
    { "skill": "UI/UX for Financial Applications", "importance": 3 }
  ],
  "estimatedTeamSize": 4,
  "timeline": "2 months",
  "specialRequirements": [
    "High visibility for top clients",
    "Financial compliance expertise",
    "Tight deadline"
  ]
}

Step 2: Search for key skills

Based on the requirements analysis, the agent starts searching for employees with the necessary skills:

// Agent's second tool call
{
  "tool": "searchEmployeesBySkill",
  "parameters": {
    "skillDescription": "Modern React development with data visualization experience",
    "minProficiency": 4,
    "minAvailability": 40
  }
}

MongoDB Vector Search returns several candidates with relevant frontend skills:

[
  {
    "_id": "60a2c1e04f5bc12345678901",
    "name": "Alex Chen",
    "title": "Senior Frontend Developer",
    "department": "Engineering",
    "availability": 75,
    "relevantSkills": [
      {
        "name": "React",
        "proficiency": 5,
        "yearsExperience": 4
      },
      {
        "name": "D3.js",
        "proficiency": 4,
        "yearsExperience": 3
      }
    ],
    "similarity": 0.92
  },
  // ... more results
]

The agent continues searching for other required skills:

// Searching for MongoDB expertise
{
  "tool": "searchEmployeesBySkill",
  "parameters": {
    "skillDescription": "MongoDB database experience for financial applications",
    "minProficiency": 3,
    "minAvailability": 30
  }
}

// Searching for authentication expertise
{
  "tool": "searchEmployeesBySkill",
  "parameters": {
    "skillDescription": "OAuth 2.0 implementation and security protocols",
    "minProficiency": 4,
    "minAvailability": 30
  }
}

// Searching for financial compliance expertise
{
  "tool": "searchEmployeesBySkill",
  "parameters": {
    "skillDescription": "Financial regulations and compliance for wealth management",
    "minProficiency": 3,
    "minAvailability": 20
  }
}

Step 3: Evaluate team compositions

After gathering potential candidates for each skill area, the agent begins evaluating possible team compositions:

// Agent evaluates a potential team
{
  "tool": "analyzeTeamComposition",
  "parameters": {
    "teamMembers": [
      "60a2c1e04f5bc12345678901", // Alex - React/D3.js
      "60a2c1e04f5bc12345678903", // Sam - MongoDB
      "60a2c1e04f5bc12345678905", // Riley - Security/OAuth
      "60a2c1e04f5bc12345678907"  // Jordan - Financial compliance
    ],
    "requiredSkills": [
      { "skill": "React", "importance": 5 },
      { "skill": "Data Visualization", "importance": 4 },
      { "skill": "MongoDB", "importance": 4 },
      { "skill": "OAuth 2.0", "importance": 4 },
      { "skill": "Financial Regulations", "importance": 3 },
      { "skill": "UI/UX for Financial Applications", "importance": 3 }
    ]
  }
}

The tool returns an analysis:

{
  "skillCoverage": 91,
  "diversityScore": 76,
  "collaborationHistory": {
    "previousCollaborations": 2,
    "averageSuccessScore": 4.0
  },
  "overallScore": 85,
  "analysis": "This team of 4 members has excellent skill coverage. The team includes 3 high-performing members with strong track records. The team spans 3 different departments, which brings diverse perspectives but may require additional coordination. This team composition is highly recommended."
}

The agent might try a few different team compositions, adding or removing team members to balance skill coverage, collaboration history, and team size.

Step 4: Save team to database

After evaluating different options, the agent saves the chosen team to the database:

// Agent's database tool call
{
  "tool": "saveTeamToDatabase",
  "parameters": {
    "projectTitle": "Wealth Management Customer Portal",
    "projectDescription": "We need to build a new customer portal for our wealth management platform...",
    "teamMembers": [
      {
        "id": "60a2c1e04f5bc12345678901",
        "name": "Alex Chen",
        "role": "Frontend Lead",
        "keySkills": ["React", "D3.js", "Frontend Architecture"],
        "justification": "Alex brings 4 years of React experience and strong data visualization skills with D3.js, which are critical for the financial dashboard components."
      },
      // ... other team members
    ],
    "skillCoverage": 91,
    "overallRationale": "This team combines strong technical skills in all required areas with crucial domain expertise in financial regulations. The inclusion of Morgan with both design and compliance knowledge allows us to keep the team size efficient while ensuring the interface meets regulatory requirements.",
    "risks": [
      "Tight 2-month timeline for a complex financial application",
      "High visibility increases pressure for a polished product"
    ],
    "mitigationStrategies": [
      "Start with compliance and security architecture to avoid late-stage rework",
      "Implement phased delivery with core features first",
      "Schedule weekly demos with key stakeholders for early feedback"
    ]
  }
}

The database operation returns:

{
  "success": true,
  "teamId": "60a2c1e04f5bc12345678999",
  "message": "Team \"Wealth Management Customer Portal\" has been saved to the database with 4 members.",
  "status": "proposed"
}

Step 5: Generate final recommendation

Finally, the agent provides a structured recommendation:

// Agent's final tool call
{
  "tool": "generateTeamRecommendation",
  "parameters": {
    "projectTitle": "Wealth Management Customer Portal",
    "projectDescription": "We need to build a new customer portal for our wealth management platform...",
    "teamMembers": [
      {
        "id": "60a2c1e04f5bc12345678901",
        "name": "Alex Chen",
        "role": "Frontend Lead",
        "keySkills": ["React", "D3.js", "Frontend Architecture"],
        "justification": "Alex brings 4 years of React experience and strong data visualization skills with D3.js, which are critical for the financial dashboard components. Previous leadership experience on similar projects."
      },
      {
        "id": "60a2c1e04f5bc12345678903",
        "name": "Sam Patel",
        "role": "Backend Developer",
        "keySkills": ["MongoDB", "Node.js", "API Design"],
        "justification": "Sam has extensive experience with MongoDB in financial contexts and has worked with Alex before, which will streamline the frontend-backend integration."
      },
      {
        "id": "60a2c1e04f5bc12345678905",
        "name": "Riley Johnson",
        "role": "Security Specialist",
        "keySkills": ["OAuth 2.0", "Security Protocols", "Compliance"],
        "justification": "Riley's expertise in OAuth 2.0 and security is essential for protecting sensitive financial data. Has implemented similar authentication systems for other financial products."
      },
      {
        "id": "60a2c1e04f5bc12345678909",
        "name": "Morgan Lee",
        "role": "UI/UX Designer & Financial Compliance",
        "keySkills": ["UI/UX Design", "Financial Regulations", "User Research"],
        "justification": "Morgan brings the dual expertise of UI/UX design specifically for financial applications and knowledge of financial regulations. This combination is rare and valuable for ensuring the portal is both compliant and user-friendly."
      }
    ],
    "overallRationale": "This team combines strong technical skills in all required areas with crucial domain expertise in financial regulations. The inclusion of Morgan with both design and compliance knowledge allows us to keep the team size efficient while ensuring the interface meets regulatory requirements. Alex and Sam's previous successful collaboration will help meet the tight timeline.",
    "skillCoverage": 94,
    "risks": [
      "Tight 2-month timeline for a complex financial application",
      "High visibility increases pressure for a polished product"
    ],
    "mitigationStrategies": [
      "Start with compliance and security architecture to avoid late-stage rework",
      "Implement phased delivery with core features first",
      "Schedule weekly demos with key stakeholders for early feedback",
      "Consider adding a QA specialist for the final testing phase"
    ]
  }
}

The user interface

To make this technology accessible to HR professionals, we've created a simple web interface:

https://github.com/mongodb-developer/GenAI-Showcase/tree/main/apps/vercel_sdk_hr_agent/app

Conclusion

The HR team-building agent we've developed demonstrates the significant advantages of integrating MongoDB Vector Search with Vercel AI SDK's agentic capabilities and Voyage AI embeddings. By representing skills as nuanced vectors within a semantic space, this solution empowers HR professionals to navigate the complex, multi-dimensional challenge of building effective teams.

This approach marks a transformative shift from rigid, keyword-based HR systems toward dynamic, adaptive tools capable of iterative reasoning and context-sensitive decision-making. To maximize the effectiveness of this solution in your organization, consider the following implementation tips:

Start with quality data: The success of vector search hinges on detailed, context-rich skill descriptions. Enrich employee profiles with information on how skills were practically applied in previous projects.
Consider skill contexts: Generate embeddings that encapsulate not just skill names but also proficiency levels, experience, and relevant usage contexts, creating richer and more accurate vector representations.
Optimize MongoDB indexes: For optimal performance in large-scale deployments, fine-tune vector search indexes by experimenting with parameters such as numCandidates and similarity thresholds.
Balance tool complexity: Design agent tools that maintain a balance between specificity and flexibility, enabling AI-driven agents to adapt effectively while preserving utility.
Incorporate feedback loops: Establish mechanisms that allow HR professionals to provide feedback on recommendations. Continuous learning from such feedback ensures progressively improved and refined team-building suggestions.

Ultimately, the true strength of this HR team-building agent lies in its ability to complement and amplify human expertise rather than replace it. The fusion of AI's semantic understanding and computational precision with the emotional intelligence and strategic insights of HR professionals creates an innovative, collaborative environment for more insightful team formation and effective project management.

Try MongoDB Atlas today, Happy team building!

DEV Community: Pash10g

Building Persistent Memory for Voice AI Agents with MongoDB

The problem with voice agent memory

Memory as a tool

User isolation: the cookie problem

Global vs private memory

Voyage AI embeddings

MongoDB schema

Hybrid search with $rankFusion

Voice implementation: 2 different beasts

OpenAI Realtime (WebRTC)

Gemini Live (WebSocket)

Routing tool calls

Hybrid search with $rankFusion: the technical deep dive

How $rankFusion works

Performance notes

What’s next?

Todos That Ship Themselves: MongoDB Atlas + Vercel + ChatGPT Apps SDK

Why MongoDB Atlas anchors ChatGPT apps

The app in a nutshell

Tutorial: Launch the todo assistant yourself

1. Create the dataset in MongoDB Atlas

2. Wire Next.js to Atlas (and keep local dev easy)

3. Build CRUD APIs that ChatGPT and the UI share

4. Craft the shared UI and ChatGPT widget

5. Hand the controls to ChatGPT via the MCP route

6. Deploy to Vercel and register the tool

Field notes before you ship

What’s next

Building Intelligent AI Agents with MongoDB Atlas: A Bidirectional Data Flow Architecture

Why MongoDB Atlas is perfect for AI agent applications

1. Flexible document model

2. Native vector search

3. Rich querying and aggregations

4. Unified platform

Architecture overview: The bidirectional data flow

Flow 1: Agents feed FROM the database (RAG pattern)

Step 1: Vector embeddings as data foundation

Step 2: Agent tool definition

Step 3: Hybrid search implementation

Step 4: Agent processes and responds

Flow 2: Agents feed TO the database (context persistence)

Conversation storage pattern

Storing agent metadata

User activity tracking

Flow 3: Agents transform the UI (dynamic interface updates)

The metadata bridge

Frontend integration

Bidirectional filter sync

Advanced patterns: Going beyond basic RAG

Pattern 1: Saved rentals with agent integration

Pattern 2: Context-aware property details

Pattern 3: Hybrid search with scoring

MongoDB Atlas setup for production

1. Vector search index configuration

2. Supporting indexes

3. Aggregation pipeline optimization

Performance considerations

Embedding generation strategy

Conversation history management

Connection pooling

Security best practices

1. User-scoped data access

2. Input sanitization

3. Rate limiting

Real-world results: What we achieved

Performance metrics

User experience wins

Developer experience

Lessons learned & best practices

1. Design your document schema for agent access

2. Include both structured and unstructured data

3. Store agent metadata richly

4. Optimize for agent token limits

5. Enable agent self-discovery

The future: What's next for agent-database integration

1. Agent-driven schema evolution

2. Semantic caching

3. Multi-agent coordination

4. Continuous learning from feedback

Hybrid search with `$rankFusion`

Hybrid search with `$rankFusion`: the technical deep dive

How `$rankFusion` works