A vector database for AI agents, from one line of YAML.
An agent's long-term, semantic memory shouldn't be a vector store you self-host in dev, provision separately in prod, and hope stays in sync. On a2a cloud you declare `resources.memory.tiers: [vector]` once in a2a.yaml — and get a real local Qdrant while you build and a managed Qdrant when you ship. Same engine, both sides, no per-environment wiring.
one declaration · real Qdrant in dev · managed Qdrant in prod
Self-hosting a vector store twice is where parity dies.
The usual path to agent memory is to stand up a vector database, pick a host, wire a client, and do it again — differently — for production. Dev ends up on a mock or a hand-run container; prod ends up on a separately provisioned service. The two drift, an `if PROD` branch quietly selects a different store than you tested against, and the semantic recall you validated on your laptop isn't the one that runs. Memory becomes infrastructure you babysit per environment instead of a property of the agent.
Declare vector memory once; get Qdrant on both sides.
`resources.memory.tiers: [vector]` in a2a.yaml is the whole request. Locally, `a2a chat` provisions a real Qdrant via Docker Compose with a persistent volume at http://qdrant:6333. In production the same declaration provisions a managed Qdrant. And pgvector rides along on the managed Postgres if you'd rather keep embeddings in SQL.
Declare it once in a2a.yaml
Add `resources.memory.tiers: [vector]` to a2a.yaml. That single line is the whole request for the agent's long-term, semantic memory. You don't stand up a vector store, pick a host, or wire a client — you declare the resource and the platform provisions it.
Real Qdrant in dev
Locally, `a2a chat` provisions Qdrant via Docker Compose — qdrant/qdrant:latest with a persistent volume — at http://qdrant:6333. Not a mock, not an in-memory stub: the same Qdrant your agent will hit in production, running on your machine.
Managed Qdrant in prod
The same declaration provisions a managed Qdrant when the agent deploys. Collections, embeddings, and semantic recall behave the way they did on your laptop — because it's the same engine, not a different vector store you swapped in for production.
Dev↔prod parity, by construction
One line describes the memory in both environments. There's no `if PROD` branch selecting a real vector DB and a fake one for dev, no drift between what you tested and what runs. Parity isn't a discipline you maintain — it's what the declaration gives you.
pgvector too, if you prefer SQL
The managed Postgres you declare under resources.databases ships with pgvector, so embeddings can live alongside relational data and be queried in SQL. Reach for it when memory is a column on your rows; reach for Qdrant when semantic search is the primary store.
Memory is a platform resource
The vector store is a declared resource with the same provisioning, scoped grants, and receipts as the rest of the agent — not infrastructure you self-host and babysit per environment. LangGraph, OpenAI Agents SDK, CrewAI, or custom: the memory is there when the agent runs.
Self-hosted, wired-per-env vector store vs. one declaration.
Frequently asked.
How do I add a vector database to an AI agent on a2a cloud?
Declare it. Add `resources.memory.tiers: [vector]` to your a2a.yaml and the platform provisions the agent's vector memory for you. Locally, `a2a chat` brings up a real Qdrant via Docker Compose; in production the same declaration provisions a managed Qdrant. You don't stand up a vector store or wire a client — the memory is a declared resource, not infrastructure you assemble.
What runs locally when I use `a2a chat`?
A real Qdrant. `a2a chat` provisions qdrant/qdrant:latest via Docker Compose with a persistent volume, reachable at http://qdrant:6333. It is not a mock or an in-memory shim — it's the same Qdrant engine your agent will hit in production, so semantic recall you build against dev behaves the same once deployed.
Is the production vector store the same as the one in dev?
Yes — that's the point. The single `resources.memory.tiers: [vector]` declaration provisions Qdrant locally through Docker Compose and a managed Qdrant in production. Collections, embeddings, and semantic queries behave the same on both sides because it's the same engine, not a different vector store swapped in for production. Dev↔prod parity comes from the declaration, not from you keeping two setups in sync.
Can I use pgvector instead of Qdrant?
You can, and both are available. The managed Postgres you declare under resources.databases ships with pgvector, so you can store and query embeddings in SQL alongside your relational rows. Use pgvector when memory is naturally a column on your data; use Qdrant when semantic search is the agent's primary long-term memory store. The primary store on this path is Qdrant — pgvector is there when SQL fits better.
Do I have to manage or self-host the vector database?
No. Vector memory is a declared platform resource with the same provisioning, scoped grants, and receipts as the rest of the agent — you don't self-host it or re-wire it per environment. LangGraph, OpenAI Agents SDK, CrewAI, or custom Python/TypeScript agents all get the same memory from the same one-line declaration; the platform stands it up in dev and prod.
Related guides.
All guides live in the guides index.
Give the agent memory it keeps — same in dev and prod.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — and gives it vector memory from one line of a2a.yaml: a real Qdrant locally via `a2a chat` and a managed Qdrant in production, same engine both sides. pgvector is available through the managed Postgres for SQL-side embeddings. Plus an MCP server, an API, a frontend, scoped grants, and an Ed25519-signed receipt per run. You declare the memory; the platform provisions it.