/agent-observability-experiment-bootstrap

Provider: LiteLLM

Triggered by introspection (Workflow step 2.5) when the call-site function imports litellm and calls:

• litellm.completion(...)
• litellm.acompletion(...)

{{PROVIDER_ASSERTS}} substitution

LiteLLM auto-routes to whatever provider the underlying model identifier resolves to (gpt-5.4-mini → OpenAI, claude-sonnet-4-5 → Anthropic, gemini-pro → Vertex, etc.). The skill cannot statically determine which provider's key is needed — the routing decision happens at runtime based on the model arg.

Emit a comment instead of an assert:

# LiteLLM auto-routes to the underlying provider at runtime. Make sure the keys
# for your chosen model's provider are set in .env or shell:
#   - OpenAI models  → OPENAI_API_KEY
#   - Anthropic models → ANTHROPIC_API_KEY
#   - Gemini models → GEMINI_API_KEY or GOOGLE_API_KEY
#   - Bedrock models → AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY (+ AWS_REGION)
#   - Azure OpenAI  → AZURE_OPENAI_API_KEY + AZURE_OPENAI_ENDPOINT

Adapter notes

• litellm.completion(model=..., messages=[...]) returns a response with the same .choices[0].message.content shape as OpenAI, regardless of underlying provider. LiteLLM normalizes for you.
• Async variant: litellm.acompletion(...) — wrap with asyncio.run(...) inside a sync task_fn.
• LiteLLM has its own retry / fallback config (litellm.set_verbose, litellm.api_base, etc.). If the user's function configures these, leave their setup intact in task_fn.

Common gotchas

• Detecting which underlying provider needs which key at runtime is on the user — they know which model they're calling. The TODO comment is the most we can do statically.
• If the user is using LiteLLM's proxy mode (litellm.api_base pointing at their own proxy), they may not need any provider keys at all in this process — surface that possibility in the comment block.