The Qdrant agent deploys and manages a Qdrant vector database cluster: sizing for your vector count and dimension, HNSW index configuration, scalar quantization, shard layout, snapshot backups to S3, and a recall harness for regression detection.

What it deploys

• Qdrant Helm release — replicaCount = 3, gRPC (port 6334) + HTTP (port 6333), clustered mode enabled
• EKS node group — r6i.xlarge (4 vCPU, 32 GB RAM) × 3, spread across AZs
• EBS gp3 PVCs — 200 GB per node for persistent collection storage
• S3 snapshot bucket — snapshot CronJob every 6 hours; snapshots retained for 30 days
• Collection bootstrap Job — creates the first collection with your chosen vector size, HNSW parameters, and quantization config
• Prometheus ServiceMonitor — scrapes /metrics (request rate, P95 latency, index size, peer health)
• Recall harness — daily synthetic eval (1k known queries) posting recall@10 to Grafana

Quickstart

1. Start the agent: “Deploy a Qdrant cluster for our RAG pipeline.”
2. Gate 1 — sizing inputs: Agent asks for expected vector count, dimension, peak QPS, and whether you need hybrid search. Reply (e.g. 10M vectors, 1536 dim for OpenAI ada-002, 50 QPS).
3. Gate 2 — topology: Agent proposes a 3-node cluster with replication factor 2, 6 shards, HNSW m=16 ef_construct=128, scalar int8 quantization. Approve or ask for alternatives.
4. Gate 3 — sizing confirmation: Agent shows per-node memory math (raw vectors + HNSW graph overhead) and confirms r6i.xlarge fits the workload.
5. Gate 4 — storage: Agent proposes 200 GB gp3 per node + S3 snapshots every 6 hours. Approve.
6. Gate 5 — observability: Agent wires Prometheus + Grafana + alerts (peer down, P95 > 100 ms, index build queue > 60s). Approve.
7. Gate 6 — review and deploy: Terraform plan shows EKS cluster, Helm release, PVCs, S3 bucket, bootstrap Job. ~12 minutes.

After deploy the agent outputs:

• Qdrant HTTP endpoint: http://qdrant.qdrant:6333 (internal)
• gRPC endpoint: qdrant.qdrant:6334
• S3 snapshot bucket name

Configuration options

Vector dimension → memory sizing

HNSW graph adds ~50% overhead. Plan (raw_size × 1.5) + 30% headroom per replica.

Common patterns

Creating a collection manually

After deploy you can create additional collections via the Qdrant REST API:

curl -X PUT http://qdrant.qdrant:6333/collections/my-collection \
  -H 'Content-Type: application/json' \
  -d '{
    "vectors": { "size": 1536, "distance": "Cosine", "on_disk": true },
    "shard_number": 6,
    "replication_factor": 2,
    "quantization_config": { "scalar": { "type": "int8", "always_ram": true } },
    "hnsw_config": { "m": 16, "ef_construct": 128 }
  }'

Tell the agent to create the collection and it will run this for you.

Hybrid search (dense + sparse)

Qdrant 1.10+ supports built-in sparse vectors for hybrid search — no separate Elasticsearch or BM25 engine needed. Tell the agent: “Enable hybrid search on the documents collection.” The agent adds a named sparse vector alongside the dense vector in the collection schema.

Scaling up nodes

Tell the agent: “Add a 4th node to the Qdrant cluster.”

The agent updates replicaCount in the Helm release, waits for the new peer to join, then proposes a shard rebalance.

Troubleshooting

See also

• Concepts: Agents
• Concepts: Gates
• Reference: Agents list