[FEATURE] Support explicit knowledgebaseid parameter instead of mandatory environment variable

[jamesyangoc]

Problem Statement

Problem Statement:
The current Strands SDK implementation for knowledge base interactions mandates using the STRANDSKNOWLEDGEBASEID environment variable (as shown in docs/docs/examples/python/knowledgebase_agent.py). This creates several challenges in production environments:

Multiple knowledge bases: When working with multiple agents or knowledge bases, relying on a single environment variable creates conflicts. Each agent needs its own knowledge base configuration, but the shared env var makes this impossible without fragile workarounds.

Hidden dependencies: Environment variables as implicit requirements reduce code clarity and make debugging harder. It's not immediately obvious from the code what external configuration is required, forcing developers to add special validation logic.

Maintainability: The hidden parameter pattern increases deployment complexity and makes testing workflows more difficult. Developers need extra logic to ensure the env var exists and is set correctly for each context.

This is a significant anti-pattern compared to well-designed SDKs like boto3, which always provide explicit parameters with optional env var fallbacks.

Proposed Solution

Proposed Solution: Make knowledge_base_id an explicit function parameter with optional environment variable fallback:

python

agent = KnowledgeBaseAgent(
knowledge_base_id="kb-123", # explicit parameter
# or falls back to STRANDS_KNOWLEDGE_BASE_ID if not provided
)

This follows the standard pattern used by boto3 and other AWS SDKs:

python

boto3 example - explicit parameters with env var fallback

client = boto3.client(
'bedrock-agent-runtime',
aws_access_key_id='YOUR_KEY', # explicit
region_name='us-east-1' # explicit
)

Falls back to AWS_ACCESS_KEY_ID, AWS_DEFAULT_REGION if not provided

Benefits:
• Multiple knowledge bases work independently without conflicts
• Code is self-documenting with explicit parameters
• Backward compatible - existing code using env vars continues to work
• Follows AWS SDK design patterns and best practices
• Reduces deployment complexity and improves testability

This change would significantly improve the SDK's usability for production deployments while maintaining backward compatibility for existing implementations.

Use Case

Use Case: We're building an AI infrastructure for advanced applications that requires multiple specialized agents, each connected to different knowledge bases:

Sales agent connected to product documentation knowledge base (kb-sales-docs)
Support agent connected to troubleshooting knowledge base (kb-support-kb)
Compliance agent connected to regulatory documents knowledge base (kb-compliance)
These agents run concurrently in the same application. With the current env var requirement, we'd need to:

Set STRANDS_KNOWLEDGE_BASE_ID before each agent instantiation
Risk race conditions in concurrent scenarios
Add complex state management to track which env var is set
Create wrapper classes to isolate env var changes
This workaround is fragile, error-prone, and adds unnecessary complexity to production deployments.

Alternatives Solutions

No response

Additional Context

No response