Stores and Tools
Overview
This page covers the shared storage and tool blocks inside global:.
These settings back route-local plugins and router-wide tool behavior.
Key Advantages
- Centralizes shared backing stores instead of repeating them per route.
- Keeps semantic cache, memory, retrieval, and tool catalogs consistent.
- Lets route-local plugins stay small and focused.
- Makes shared infrastructure dependencies explicit.
What Problem Does It Solve?
Route-local plugins often depend on shared storage or tool state. If those dependencies are configured ad hoc inside each route, the system becomes inconsistent and harder to operate.
These global: blocks solve that by defining shared backing services once.
When to Use
Use these blocks when:
- multiple routes depend on the same semantic cache or memory backend
- retrieval features need one shared vector store
- the router should expose one shared tool catalog
- backing-store configuration belongs to the whole router rather than one route
Configuration
Semantic Cache
global:
stores:
semantic_cache:
similarity_threshold: 0.8
Memory
The memory store supports two backends: milvus (default) and valkey.
Milvus backend (default):
global:
stores:
memory:
enabled: true
milvus:
address: milvus:19530
collection: agentic_memory
dimension: 384
Valkey backend (requires Valkey with Search module):
global:
stores:
memory:
enabled: true
backend: valkey
valkey:
host: valkey
port: 6379
dimension: 384
collection_prefix: "mem:"
index_name: mem_idx
metric_type: COSINE
For full deployment instructions, see:
- Valkey Agentic Memory — Docker, Kubernetes, config reference, tuning, and troubleshooting
deploy/examples/runtime/memory/for backend-specific configuration references
Vector Store
global:
stores:
vector_store:
provider: milvus
Supported backends: memory, milvus, llama_stack, valkey.
Tools
global:
integrations:
tools:
enabled: true
top_k: 3
tools_db_path: deploy/examples/runtime/tools/tools_db.json