setup
self-hosted
Provision a vector DB, choose a host, and wire a client into the agent.
a2a declared
Add `resources.memory.tiers: [vector]` to a2a.yaml — one line.
declare memory, don't wire it
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
0
line in a2a.yaml
0
vector engine, dev↔prod
self-hosting to manage
the problem
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.
Provisioning a vector DB, choosing a host, and wiring a client — per environment.
Dev on a mock or in-memory stub while prod runs a real, different store.
`if PROD` branches select one vector store for tests and another for production.
Semantic recall validated in dev isn't the recall that actually ships.
the a2a way
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.yamlReal Qdrant in devManaged Qdrant in prodDev↔prod parity, by constructionpgvector too, if you prefer SQLMemory is a platform resource
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.
side-by-side
Self-hosted, wired-per-env vector store vs. one declaration.
dev store
self-hosted
A mock, an in-memory stub, or a hand-run local container you maintain.
a2a declared
Real Qdrant via `a2a chat` — qdrant/qdrant:latest, persistent volume, :6333.
prod store
self-hosted
A separately provisioned, separately configured managed vector service.
a2a declared
The same declaration provisions managed Qdrant — same engine both sides.
parity
self-hosted
Dev and prod drift; `if PROD` picks a different store than you tested.
a2a declared
One line describes memory in both environments — parity by construction.
ownership
self-hosted
You self-host and re-wire the vector store for every environment.
a2a declared
Memory is a declared resource: provisioned, scoped, and recorded for you.
dimension
self-hosted
a2a declared
setup
Provision a vector DB, choose a host, and wire a client into the agent.
Add `resources.memory.tiers: [vector]` to a2a.yaml — one line.
dev store
A mock, an in-memory stub, or a hand-run local container you maintain.
Real Qdrant via `a2a chat` — qdrant/qdrant:latest, persistent volume, :6333.
prod store
A separately provisioned, separately configured managed vector service.
The same declaration provisions managed Qdrant — same engine both sides.
parity
Dev and prod drift; `if PROD` picks a different store than you tested.
One line describes memory in both environments — parity by construction.
ownership
You self-host and re-wire the vector store for every environment.
Memory is a declared resource: provisioned, scoped, and recorded for you.
questions
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.
keep reading
Related guides.
All guides live in the guides index.
memory is a declared resource
Give the agent memory it keeps — same in dev and prod.
a2a cloud gives any agent vector memory from one line of a2a.yaml: Qdrant locally via `a2a chat` and managed Qdrant in production, with pgvector through managed Postgres. MCP and API surfaces, a frontend, scoped grants, and signed receipts on Agent API, public `/invoke`, and standard MCP `tools/call` executions ship with it.