Convex Agent centralizes memory, threads, and RAG for AI agents in the same serverless backend

The official @convex-dev/agent component bundles threads, persistent history, and hybrid context search within the same serverless database that Convex already offers, eliminating the need for a separate vector DB to give AI agents memory.

Anyone building AI agents the conventional way usually ends up with conversation history, relevant context, and business logic scattered across a relational database, a separate vector DB, and some queue service for long-running workflows. @convex-dev/agent is Convex's answer to that: a component that lives inside the serverless database itself and treats threads, messages, and context search as part of the same system that already stores the application's data.

For those who already use Convex as a BaaS (the same niche as Supabase in the vibe coding workflow), this means not having to spin up a Pinecone, a Redis instance for rate limiting, or a parallel table just to audit what the agent said. The idea is that all of this is ordinary Convex code, running in actions, with client-side reactivity inherited for free.

How the component organizes threads and messages

At the center of the Agent Component is the Agent class, instantiated with a language model and system instructions. The documentation's example uses convexGateway from the @convex-dev/ai-sdk-provider package, which routes calls to providers like OpenAI through the Convex AI Gateway:

import { Agent } from "@convex-dev/agent";
import { convexGateway } from "@convex-dev/ai-sdk-provider";
import { v } from "convex/values";
import { components } from "./_generated/api";
import { action } from "./_generated/server";

const supportAgent = new Agent(components.agent, {
 name: "Support Agent",
 languageModel: convexGateway("openai/gpt-5-mini"),
 instructions: "You are a helpful assistant.",
});

export const createThread = action({
 args: { prompt: v.string() },
 handler: async (ctx, { prompt }) => {
 const { threadId, thread } = await supportAgent.createThread(ctx);
 const result = await thread.generateText({ prompt });
 return { threadId, text: result.text };
 },
});

The central point is createThread: it returns a threadId that the client stores and resends later. On a subsequent call, continueThread(ctx, { threadId }) retrieves the same conversation, with the history of previous messages automatically injected into the prompt, without the developer having to assemble that array manually.

According to the documentation, threads persist messages and can be shared across multiple users and agents, including human agents, which reinforces that the central persistence object is the thread itself, not a parallel table built by hand.

This is what the documentation calls automatic context: every call to the model already includes hybrid search (vector and text) across the thread's messages, deciding what is relevant to bring back without the application code having to implement that retrieval logic.

RAG, files, and multi-step workflows

Threads solve short-term memory within a conversation, but the documentation also covers cases where the agent needs to fetch information from outside it. For that there is integration with Convex's own RAG Component, used both to augment the prompt beforehand and as a tool the agent decides to call during generation.

Files fit into the same persistence mechanics: when an agent receives a PDF or an image as part of the conversation, the component saves the file in Convex's file storage and references it in the history, so it remains available if the thread is resumed days later.

For flows that don't fit in a single call, Convex's Workflows lets you orchestrate steps that can involve multiple agents and multiple users, in a durable and reliable way, according to the documentation. In practice, this suggests that if the process is interrupted, it doesn't need to start over from scratch, although the documentation doesn't explicitly detail that behavior.

Debugging, cost, and usage limits

Three features in the documentation are aimed directly at operating the agent in production, not just prototyping:

• Agent Playground: an interface to inspect metadata from each call and iterate on prompts and context settings without rewriting code.
• Usage tracking: tracks usage per user or per team, enabling billing based on actual token consumption.
• Rate limiting: controls how many interactions a user can make within a period, both to protect the application and to avoid exceeding the LLM provider's limit.

This set of features is what distinguishes a memory component from a simple API wrapper: it assumes the agent will run with real users, spending real money on tokens, and provides tools for that from the start instead of leaving it for later.

What this replaces, and when it's not worth it

The most direct comparison is with what is normally assembled by hand to give an agent memory: a separate vector DB, conversation history tables, a queue for long-running workflows, and some custom rate-limiting system.

The trade-off is lock-in: all of this only exists inside Convex. If the application already runs on a stack with Postgres and its own orchestrator, switching databases just to gain agent memory is a migration cost that the documentation doesn't discuss and that each team needs to weigh.

It's also worth noting that the official example uses the Convex AI Gateway as a model intermediary, which couples the choice of LLM provider to yet another layer of Convex. For those who already have a direct integration with OpenAI, Anthropic, or a local provider working, swapping out that layer is another point of friction to consider before adopting the component just for the persistent memory gain.