Gateways and Models

Understand how connection Resources, logical Models, Credentials, scoped bindings, and pricing work together.

explanationFor platform operators, agent developers, integration developersOwner Constal platform teamVerified 2026-08-21

A Gateway is not a separate execution system. It is an ordinary invokable Resource marked as a connection. That Resource owns the external endpoint, Credential bindings, network rules, lifecycle, and the capabilities it implements. It continues to use the normal Resource deployment, Policy, pinning, invocation, and journal machinery.

A Model is the stable, logical capability that an Agent uses. It selects a provider model ID, default parameters, technical limits, accounting references, and either a fixed or scoped Gateway. Keeping these concerns separate lets an Agent use support-model without embedding Anthropic, OpenAI, a proxy hostname, or a customer Credential in its code.

diagram

Agent binding → Model Resource → Gateway (Connection Resource) → provider
                       │                    │
                       │                    └─ endpoint, Credential, egress, payer
                       └─ model ID, defaults, limits, accounting references

Why the split exists

One Gateway can expose several Models, and one logical Model can resolve to different Gateways for different customers. Changing a route, rotating a Credential, or onboarding a customer therefore does not require an Agent redeployment. The Model remains the identity used in Agent bindings, journals, budgets, and analytics; the Gateway is the exact transport selected for an invocation.

Gateways retain their concrete Resource kind because the kind describes how they operate. The connection role describes how people use them. This avoids a parallel Gateway registry or a second invocation path. A normal service Resource is not a Gateway unless it explicitly has the connection role.

The platform-provided Constal Gateway

Every tenant namespace includes Constal Gateway as a platform-managed, platform-paid connection. Tenants do not provide a Credential for this Gateway. Create logical Models on top of it when Constal should operate the upstream inference connection and apply platform pricing and limits through Policy.

The Gateway still has a tenant-local CRN and immutable Resource version. That keeps Policy, lifecycle controls, Run snapshots, usage, and audit evidence isolated to the tenant even though Constal manages the implementation. It is not a global object shared across tenant security boundaries.

Tenant-managed Gateways remain the bring-your-own alternative. They use the same Resource abstraction, but the tenant supplies the endpoint and Credential and is normally responsible for upstream charges.

Fixed and scoped Gateways

Gateway binding	Use it when	Resolution
Fixed	Every invocation of the Model uses the same managed or tenant-owned connection	The Model pins one exact Gateway CRN, document hash, and capability contract
Tenant scoped	Each tenant needs a different connection, with a tenant default	Admission resolves the authenticated tenant before a Run starts
Customer scoped	A shared Agent serves downstream customers that bring their own provider account	Admission resolves the verified customer identity supplied by the Channel
Principal scoped	Individual users authorize their own provider account	Admission resolves the verified subject identity supplied by the Channel

A scoped binding is a lookup rule, not a late-bound secret. Admission resolves it to one exact Gateway and Credential set, records the assignment revision and owner, and pins that evidence into the Run snapshot. A missing required assignment fails before provider dispatch. An existing Run keeps its accepted snapshot if an assignment changes later.

The Model requires a stable capability contract such as “model completion v1.” Any Gateway used by the binding must declare that it implements the contract. Provider-specific operation catalogs may differ internally, but they cannot change what the Model promises to the Agent.

Credentials and ownership

The Gateway references Credentials; the Model does not contain provider secrets. At invocation time the Resource Broker authorizes both the Model and resolved Gateway, and the protected runtime injects only the Gateway’s accepted Credential versions into its invocation. Agent code receives the result, never reusable secret material.

A platform-managed Gateway normally uses a platform-paid provider account. A tenant-managed Gateway is the bring-your-own path and normally uses tenant-paid Credentials. The Gateway records who manages the connection and who pays the upstream provider so the runtime can reject contradictory pricing configuration.

Use a Credential Provider to import, mint, renew, or authorize the secret material. Use a scoped binding when the correct Gateway or Credential depends on tenant, customer, or principal identity.

Pricing and rate limits

Model accounting keeps three values separate:

Accounting lane	Meaning	Authority
Tracked cost	The estimated or reported upstream cost used for cost and margin analysis	Provider or other trusted cost source
Platform charge	What Constal charges the tenant and what consumes the Run budget	Platform Policy
Customer charge	What the tenant may charge its downstream customer	Tenant Policy

The rates themselves are accepted through runtime Policy, not trusted merely because a Model document mentions them. A Model pins immutable table identities so the runtime can prove it applied the intended rates. The same logical model may therefore have a different platform charge or limit policy for each tenant without changing Agent code or dispatch behavior.

For a platform-paid Gateway, Policy must provide a platform charge. For a tenant-paid Gateway, the platform charge may be absent, so the invocation consumes no Constal model budget while tracked cost or a tenant-owned customer charge can still be recorded. Policy can independently cap requests, input tokens, output tokens, and concurrent requests for the Model.

Invocation sequence

Admission resolves the Agent’s logical Model binding.
It resolves the Model’s fixed or scoped Gateway and its Credential bindings.
It verifies the Gateway implements the Model’s required capability contract.
It pins the Model, Gateway, assignment evidence, Credentials, and Policy into the Run snapshot.
On each call, the runtime authorizes both the logical Model and exact Gateway.
The Model identity remains visible to the Agent and journal, while the Gateway’s configured integration performs the external request.
Usage settles into tracked cost, platform charge, and customer charge independently.

This preserves one Resource abstraction end to end. There is no separate Gateway database, execution coordinator, Credential store, or billing engine.

What to verify

In Resources → Gateways, confirm the connection type, Credential relationship, upstream billing owner, status, and exact CRN. In Resources → Models, confirm the provider model ID, fixed Gateway or scoped owner, billing mode, and consumers. Then start a controlled Run and inspect its Resource bindings and invocation journal. The Run should show the logical Model as the called Resource and the exact resolved Gateway in its pinned dispatch evidence.