# Practical and Useful Patterns with ADK ## 🏢 Isolate State per Application with ADK Apps When managing multiple agent workflows, state and artifacts can bleed across boundaries. ADK **Apps** use `app_name` namespacing to completely isolate State, Artifacts, and Memory! 🏗️ ## 📌 Title Apps (Application-Level Configuration) ## 🔗 URL ## 🧩 Overview The App class is the top-level container for ADK agent workflows. It manages lifecycle, centralized configuration, and state scoping around a root agent. Key responsibilities: - **Centralized configuration**: Manage shared resources (API keys, DB clients) in one place - **Lifecycle management**: Startup/shutdown hooks for persistent resources - **State scope**: Explicit data boundaries with `app:*` prefix - **Deployment unit**: Formal unit for versioning and testing App-level settings also include Context Caching, Context Compaction, Resumability, and Plugins. ## 🛠 How to Use Import `Agent` from `google.adk.agents.llm_agent`, `App` from `google.adk.apps`, and `InMemoryRunner` from `google.adk.runners`. Create an `Agent` with `model='gemini-flash-latest'`, `name='assistant'`, and `description='General purpose assistant'`. Then create an `App` with `name="my_app"` and pass the `root_agent`. Optionally, you can also provide `plugins`, `context_cache_config`, `events_compaction_config`, and `resumability_config`. Finally, create an `InMemoryRunner(app=app)` and run with `await "Hello!")`. ## 🏗 Practical Usage **Multi-tenant SaaS data isolation:** Use different `app_name` values per tenant to achieve complete State/Artifact/Memory isolation. Define `create_tenant_app(tenant_id: str, root_agent: Agent) -> App` that creates an isolated `App` per tenant with `name=f"saas_{tenant_id}"` as the tenant-specific namespace. It includes `SecurityGuardPlugin()` for shared security and `TenantLoggingPlugin(tenant_id)` for tenant-specific logging in the `plugins` list. For Tenant A, call `create_tenant_app("tenant_a", support_agent)` and create an `InMemoryRunner` -- state is saved under `"app:saas_tenant_a:*"` and is invisible to Tenant B. For Tenant B, the same pattern applies with `"app:saas_tenant_b:*"`, keeping data completely isolated from Tenant A. **Environment-specific configuration:** For development, create an `App` with `name="myservice_dev"`, `plugins=[DebugLoggingPlugin()]`, and `events_compaction_config=EventsCompactionConfig(compaction_interval=10, overlap_size=3)`. For production, create an `App` with `name="myservice_prod"`, `plugins` containing `SecurityGuardPlugin()`, `BigQueryAnalyticsPlugin()`, and `RateLimitPlugin()`, and a tighter `EventsCompactionConfig(compaction_interval=5, overlap_size=2)` for more frequent compaction. ## 💡 Use Cases - 🏢 **Multi-tenant SaaS**: Isolate Apps per tenant to prevent data leakage entirely - 🔧 **Environment separation**: Apply different plugins and configs for dev/staging/prod - 📦 **Microservices**: Deploy and version each service as an independent App - 🧪 **A/B testing**: Run the same agent with different App configurations to compare results - 🔄 **Lifecycle management**: Centralize DB connection pool and cache init/cleanup ## ⚠️ Caveats - `app_name` is used as the namespace for State/Artifact/Memory — keep it unique and stable - Changing the App name will make past State and Artifacts inaccessible - If multiple Apps share the same root agent, ensure the agent is stateless - Separate tenant-common and tenant-specific plugins appropriately at the App level ## ✨ Closing The App class draws clear boundaries for deploying and operating ADK agents. Multi-tenant isolation, environment-specific configs, lifecycle management — designing Apps thoughtfully is the key to building scalable, secure agent applications! #ADK# #AIAgent#