Model pool architecture patterns

Select a pattern from the hard boundary and failure outcome, not from a preferred provider name. These examples show how to structure model pools. They do not confirm product availability, provider suitability, or data residency.

Separate customers or regions

Create a separate tenant when a customer needs a tenant-scoped provider configuration, cost view, Task history, Library, or logical access boundary. Provision distinct provider accounts and credentials when the customer boundary requires them. Use a separate regional deployment when the full processing path must remain in that region.

The following map is an illustrative enterprise design:

The application can keep one source integration only when Duale AI has qualified the SDK and platform version pair for every function it uses. Each deployment still needs its own endpoint, token, identifiers, Grants, activity cache, and telemetry configuration. The token provides identity inside its deployment; it is not locality evidence. Confirm the supported SDK and platform pair for each deployment with Duale AI.

Separate model pools prevent a model response from a route outside the pool. They do not control the other processing paths: documents and search data, images, Tools and their destinations, telemetry, backups, billing, support, and human access. Data protection maps those paths. Review every path before a local-processing or no-cross-border claim.

Isolate a strict workload

Use a dedicated tenant that contains only standalone routes for the approved provider model and version when a contract, evaluation, or policy requires it. Pin the provider identity under the exact-version conditions in the routing contract. The application still uses the normal SDK contract.

You can include several approved endpoints for the same pinned identity when the account, region, and credential boundaries permit them. This pattern removes fallback to another model and can also remove endpoint fallback. Define a manual path, delayed processing, or safe failure when no approved route is available. Do not add a general fallback that violates the strict requirement.

Use independent multi-provider fallback

Place two or more functionally compatible routes in one approved pool when the workload can use several providers and resilience is more important than fixed route identity. Verify that the routes do not share critical failure domains.

Test output compatibility and the complete failure path. Extra provider requests can add quota use, cost, and delay. Routing contract and limits defines the limits on request order and traffic split.

Within one Task, Duale AI also retries through a provider outage.

Separate cloud and customer-hosted work

Treat cloud and customer-hosted deployments as separate application environments unless the installation agreement states what they share. Hosting location alone does not prove the full processing boundary.

Use separate deployments when cloud and customer-hosted workloads have different data, network, provider, or change-control boundaries. Give each deployment its own application configuration and SDK client. A private endpoint does not create connectivity, and a customer-hosted Platform can still send requests to external model or Tool services.

Treat a move as new provisioning. A source task_id cannot continue in the target; submit a new Task with only the context you are authorized to carry, and verify the target before you stop the source environment. Run the Platform in your infrastructure explains the installation agreement that sets eligibility, responsibilities, connectivity, qualification, and migration.

Protect stable and experimental work

Use a separate tenant for experimental routes so production tasks cannot select them. Use separate credentials or a separate deployment when the evaluation also needs a provider-account or physical boundary. Control model changes gives the complete evaluation, enablement, observation, and rollback sequence.