Support multiple knowledge bases for a single watsonx Orchestrate agent
Current behavior
IBM watsonx Orchestrate currently allows only one knowledge base to be associated with an agent.
When a knowledge source is already connected, another source cannot be added. The existing source must be replaced. The same limitation applies to agents created through the Agent Development Kit, where an agent can reference only one knowledge base.
This forces customers to:
- merge unrelated content into a single knowledge base or vector collection;
- implement a custom search service that aggregates several repositories;
- or create multiple collaborator agents solely to separate knowledge domains.
These workarounds increase implementation complexity and make knowledge lifecycle management, governance, testing, and troubleshooting more difficult.
Requested capability
Allow a single watsonx Orchestrate agent to reference and query multiple knowledge bases.
For example, an enterprise agent should be able to use separate knowledge bases for:
- internal HR policies;
- IT procedures;
- project documentation;
- regulatory or public information;
- customer-specific content;
- frequently updated external repositories.
The capability should be available in both Agent Builder and the ADK, and should be supported across SaaS and on-premises deployments.
Expected behavior
Builders should be able to:
- Associate multiple existing knowledge bases with an agent.
- Add knowledge bases backed by different supported technologies, such as built-in Milvus, external Milvus, Elasticsearch, OpenSearch, Astra DB, or custom search services.
- Define a description or purpose for each knowledge base so the agent can select the most relevant source.
- Configure whether the agent searches:
- all associated knowledge bases;
- only the most relevant knowledge base;
- or a defined subset based on instructions or routing rules.
- Configure source-specific retrieval parameters, filters, result limits, and confidence thresholds.
- Preserve the source knowledge base identity in citations and trace information.
- Manage knowledge base associations independently without deleting or replacing existing connections.
- Define an optional priority or fallback order between knowledge bases.
The agent should be able to merge and rerank results returned by several knowledge bases before generating its response.
Business value
Supporting multiple knowledge bases per agent would:
- preserve clear separation between business domains and content owners;
- avoid mixing unrelated documents in a single vector collection;
- simplify knowledge governance and lifecycle management;
- allow different ingestion, update, retention, and access strategies per corpus;
- improve source traceability and auditability;
- reduce the need for custom aggregation services;
- avoid unnecessary multi-agent architectures;
- simplify reuse of enterprise knowledge across agents;
- improve retrieval quality by allowing source-specific configuration;
- support more realistic enterprise RAG architectures.
This is particularly important for enterprise and on-premises deployments, where knowledge sources are frequently separated for security, regulatory, organizational, or data-sovereignty reasons.
Example use case
An internal enterprise assistant must answer questions using:
- a private knowledge base containing internal company policies;
- a project knowledge base containing customer and technical documentation;
- and a public knowledge base populated from trusted government websites.
These repositories have different owners, update cycles, access policies, and retrieval settings. Combining them into a single knowledge base is operationally undesirable, while creating three separate agents adds unnecessary orchestration complexity.
The same agent should be able to select or query the appropriate knowledge bases and produce a unified answer with citations identifying the originating source.
