📖 Lecture — Three Clouds, Three Auth Models, One Agent

By now you can call a single LLM API from your own code and wire an MCP server around it. This week widens the lens: production agent systems rarely lean on one provider. They span hyperscaler-native services like Amazon Bedrock and Google Vertex AI, plus multi-provider gateways like OpenRouter — and each speaks a different "dialect" of authentication, model access, and routing. Understanding those dialects is what separates an agent that works in your notebook from one that survives a rate limit at 2 a.m. Amazon Bedrock and AgentCore. Bedrock is AWS's managed gateway to foundation models from Anthropic, Meta, Cohere, Mistral, Amazon, and others, all behind a single InvokeModel API. In 2025, AWS layered Bedrock AgentCore on top — a managed runtime for agents, not just model calls. AgentCore went preview in July 2025, reached general availability in October 2025, and expanded in December 2025 with VPC/PrivateLink networking and CloudFormation support for infrastructure-as-code deployments. Practically, this means you can scaffold an agent locally with the AgentCore CLI and it will happily run whatever "reasoning loop" framework you prefer underneath — Strands, LangGraph, Google's ADK, or the OpenAI Agents SDK. AgentCore manages the runtime (sessions, memory, identity, observability); your framework of choice manages the agent logic. The detail that trips people up: Bedrock models are not globally available by default. Each model must be explicitly enabled per AWS account and region, through the Bedrock console's Model Access page. us-west-2 (Oregon) currently has the broadest default model catalog, but availability still varies model-by-model. Because access is region-bound, a model that works perfectly in us-west-2 may not even show up as invocable in us-east-1 until you request access there too. Google Vertex AI and the Agent Development Kit (ADK). Google's ADK has crossed 7 million downloads and is framework-agnostic in a different sense: it runs Gemini models natively, but also anything in the Vertex AI Model Garden, and — via a built-in LiteLLM integration — models from Anthropic, Meta, Mistral, and AI21 as well. ADK understands MCP tools natively and supports the "agents-as-tools" pattern, where one agent calls another agent the way it would call any other tool. Deployment is flexible: ADK agents run in any container runtime you like, or you can hand them to the fully managed Vertex AI Agent Engine for scaling, monitoring, and session state out of the box. OpenRouter. OpenRouter takes a different philosophy entirely: one API key, one credit balance, one OpenAI-compatible request schema, in front of 315+ models from dozens of upstream providers. You don't manage separate credentials per provider — OpenRouter does that behind the scenes. Its most distinctive feature is routing suffixes appended to a model slug:

A critical nuance: specifying a base provider slug (e.g., google-vertex) does not pin your request to one specific endpoint — OpenRouter load-balances across all of that provider's matching endpoints and regions by default. If you need a specific region for latency, data residency, or reproducibility, you must say so explicitly in your provider preferences. Why gateways like LiteLLM or Bifrost still matter. Even with OpenRouter's built-in multi-model routing, teams often add a second layer — a self-hosted gateway such as LiteLLM or Bifrost — in front of Bedrock, Vertex AI, and OpenRouter together. This layer adds automatic retry/fallback across providers (not just models within one provider), quota management, audit logging, and load balancing. It's the resilience layer that keeps your agent running when an entire provider has a bad day, not just when one model does. The authentication trap. The single most common mistake at this stage is treating credentials as interchangeable. They are not:

There is no universal key. Each backend needs its own credential scheme wired into your code or gateway config. Correcting this week's misconceptions directly:

1. "One API key and endpoint works across all providers." False. Bedrock requires AWS SigV4/IAM signing; Vertex AI requires a Google service-account credential. Injecting an OPENAI_API_KEY-style bearer token into a Bedrock request will fail outright — there is no silent compatibility mode.
2. "If a model exists on Bedrock, I can call it from any region." False. Model availability varies by AWS region, and every model must be explicitly enabled per account and region through Model Access. API keys and permissions are region-bound too. A 403 Forbidden almost always means a missing IAM permission or an unenabled model in that region — not that the model doesn't exist at all.
3. "Routing to a provider slug targets one specific endpoint." False. A base provider slug like google-vertex on OpenRouter load-balances across all matching regions and endpoints for that provider by default. If you need one specific region — for latency, residency, or reproducible benchmarking — you must set that explicitly in provider preferences rather than assume the base slug pins it.

Keep these three tables in your notes; you'll draw on all of them directly in this week's lab and quiz.