Is it possible to create a dynamic configurable agent?

[Morriaty-The-Murderer]

** Please make sure you read the contribution guide and file the issues in the right place. **
Contribution guide.

Is your feature request related to a problem? Please describe.
In production environments we often need to change agent settings (model, instructions/system prompts, tool configurations, temperature/top‑p, etc.) without redeploying or restarting services. Today, these values are typically hard-coded or loaded at startup, which makes it difficult to:

• Roll out targeted changes (e.g., switch models for only one agent or environment).
• Hotfix instruction updates in response to user behavior or compliance incidents.
• Run controlled experiments (A/B tests) on prompts or model parameters.
• Centralize configuration across multiple agents and services.

This results in operational friction and downtime when we need to iterate quickly.

Use cases:
▫ Switch a subset of agents from “gemini‑1.5‑pro” to “gemini‑2.0” with a canary rollout.
▫ Update instruction prompts to comply with new policy without restarting.
▫ Rapidly tune temperature/top‑p for a specific workflow.
▫ Enable/disable tools per tenant or environment.

Describe the solution you'd like
Provide first-class support for dynamic, externalized configuration of agent properties via common configuration backends (e.g., Consul, Redis, etcd). Ideally:

• A pluggable “Config Provider” interface that supports:
  ▫ Read-through configuration for agent metadata (model name/provider, inference parameters), instructions/system prompts, toolset settings, and policy flags.
  ▫ Watch/subscribe semantics to apply updates at runtime (with debouncing and validation).
  ▫ Namespacing and environment scoping (e.g., dev/staging/prod, per-agent IDs).
• Safe live reload:
  ▫ Validate config schemas (Pydantic or equivalent) before applying.
  ▫ Apply changes atomically with rollback on failure.
  ▫ Optional grace periods or feature flags to stage/gradually roll out updates.
• Caching and fallback:
  ▫ Local cache to survive backend outages.
  ▫ Default static config if the backend is unreachable.
• Observability and audit:
  ▫ Emit events/metrics on config loads, diffs, and apply/rollback.
  ▫ Expose current effective config via API for debugging.
• Security:
  ▫ Support secrets/credentials via vault or KMS references rather than plain text.
  ▫ Per-namespace ACLs and read-only modes for non-privileged runtimes.

A minimal demo

# -*- coding:utf-8 -*-
from google.adk.agents import LlmAgent
from google.adk.cli.fast_api import get_fast_api_app
from google.adk.config import ConfigBackend, ConfigManager

conf_backend = ConfigBackend("consul", host="127.0.0.1", port=8500)
conf_manager = ConfigManager(namespace="agents", backend=conf_backend)

root_agent = LlmAgent(
    name="root",
    model=conf_manager.watch("root.model", default="gemini-2.5-pro"),
    instruction=conf_manager.watch("root.instruction", default="xxxxxxx")
)

app = get_fast_api_app(
    agents_dir="/path",
    web=True,
    watch_config=True
)

Describe alternatives you've considered
None

Additional context
None

[surajksharma07]

@Morriaty-The-Murderer This is an excellent feature request for production/enterprise users.

While ADK doesn't currently have built-in support for dynamic configuration from external backends (Consul, Redis, etcd), you can use workarounds like environment variables with restart, config files with custom file watching, or a proxy/wrapper pattern that recreates agents when config changes.

However, these don't provide the full feature set you're requesting (validation, rollback, caching, security, observability).

This would be a significant architectural addition requiring careful design - suggest the team consider a phased approach starting with basic config provider interfaces and environment/file-based configs, then expanding to distributed backends and enterprise features in later phases.

Thanks!