nemo-relay-plugin-adaptive-tuning

# Tune Adaptive Plugin Behavior ## Use This When Use this skill when a user has baseline NeMo Relay instrumentation and wants to improve latency, parallelism, prompt-cache behavior, or model-request behavior from runtime signals. Keep adaptive behavior measured against a known baseline. ## Do Not Use This When Do not use this skill when the application is not instrumented yet. Start with `nemo-relay-instrument-calls` or `nemo-relay-get-started` first. ## Default Guidance - Observe first, compare against a baseline, then enable one behavior change at a time. - Use the adaptive plugin component rather than inventing separate tuning logic or hand-registering adaptive behavior at every call site. - Start with in-memory state and telemetry-only behavior for local development. - Move to persistent state only when learned signals must survive restarts or be shared across workers. - Add active behavior only after representative runtime events show what should change. ## Embedded Adaptive Model - Adaptive behavior is configured through the first-party plugin component with kind `adaptive`. - Adaptive requires existing NeMo Relay scopes and at least one relevant managed tool or LLM lifecycle event stream because it learns from runtime signals. - Main configuration areas are state, telemetry, adaptive hints, tool parallelism, Adaptive Cache Governor (ACG), and rollout policy. - State backends are `in_memory` and `redis`. - Tool-parallelism modes are `observe_only...