Model routing
How agent model calls are routed — the platform's LLM endpoint, the provider and model set offered at agent creation, and what the Gateway screen manages.
Agents never talk to a model provider with their own credentials. Every model call — from the conversational skill builder and from deployed agents alike — goes through one LLM endpoint configured for the platform.
The Gateway → Model Routing screen is disabled by default and may not be enabled in your deployment. Until it is enabled, routing is configured by your platform operator at deployment time (see Deployment); this page describes the behavior that configuration produces.
One endpoint for all model traffic
The platform's LLM endpoint is OpenAI-compatible and can be:
- The platform's managed model gateway, which fronts one or more providers.
- A gateway or proxy you already run (for example, an enterprise LLM gateway).
- A provider's API directly.
The endpoint's credentials live with the platform, not with individual agents — creating an agent never involves pasting a model API key.
Providers and models agents can choose
When someone creates an agent, the create screen offers a provider picker and, per provider, a model picker. That offered set comes from the deployment's routing configuration:
- Behind a gateway, multiple providers can be enabled and every enabled provider's models appear in the picker.
- Pointed directly at a single provider's API, the picker is locked to that provider regardless of what else is configured.
The choice is fixed at creation: editing an agent's skill later does not change its provider or model. The agent's detail page shows the model as "managed by the platform" — endpoint, auth, and routing are not editable per agent.
Where routing shows up elsewhere
- Usage reports consumption broken down by model, so routing decisions are visible in spend.
- Security policies and quotas can cap model usage per org, workspace, or agent — a routed call that exceeds a quota is denied and audited (see Security).