Skip to main content

Trade-offs and limitations

DIAL consolidates AI access and can also provide a workspace and application runtimes. The trade-offs depend on the deployment profile you adopt.

Architectural trade-offs​

Central governance adds a shared runtime dependency​

Routing calls through Core consolidates access checks, limits, provider connectivity, and usage attribution. It also adds network hops and makes Core and its required dependencies part of each routed request's availability and latency budget. Replicas reduce instance failures; shared stores and processing services still need protection.

This commitment is easier to justify when several teams or clients need common controls. For one application and one model, compare the operating cost with a direct integration or a smaller gateway. Measure overhead on the intended request path.

Modularity increases operating and compatibility work​

Separate services let you adopt, replace, and scale capabilities independently. Each added adapter, interceptor, builder, or runtime brings configuration, monitoring, security, and upgrade work. Custom extensions also need a team to maintain their contracts and dependencies.

Start with the smallest profile that meets the requirements. Use a published component assembly; changing components independently requires compatibility validation. Adding application hosting also adds runtime, networking, and permission responsibilities described in Application hosting and lifecycle.

A common API still requires model-specific validation​

The Unified API lets clients reuse a common interface across supported providers. Model features, tool behavior, streaming, and state semantics still depend on the target and adapter. Translation cannot supply capabilities a model lacks; passthrough preserves the selected API but leaves the client dependent on that API's semantics.

Use the common interface when its supported features cover the workload. Where a provider-specific feature is mandatory, verify the exact client, model, adapter, and processing chain before committing. See AI API overview.

DIAL extensions increase migration effort​

Attachments, stages, application state, resource storage, and delegated calls support richer application workflows. Applications using them depend on DIAL contracts beyond standard model calls.

The more of these features you use, the more migration requires changes to client rendering, application integration, and resource handling. If portability is a requirement, demonstrate how representative applications, resources, identities, and secrets move to the intended destination. A compatible model endpoint covers only part of that migration.

Cached writes reduce synchronous storage work but complicate recovery​

Keeping resources outside Core allows service instances to scale independently. Write-behind caching defers blob-store writes, allowing cached updates to be acknowledged before synchronization. Valkey can therefore contain the latest accepted resource version.

warning

Losing unsynchronized cache state can lose acknowledged changes; restoring blob storage alone can recover an older version. Recovery must protect pending writes, configuration, keys, and optional component databases. A requirement to preserve every acknowledged write needs a validated durability design. See State and data lifecycle.

Self-hosting gives deployment control and operational ownership​

Self-hosting lets you choose infrastructure, stores, and approved connections. Your organization owns deployment security, capacity, availability, backups, incident response, and upgrades. Application teams still own business logic, external side effects, and output quality.

Adopt this model when control over deployment and data handling warrants that responsibility and a team can operate the selected services. External models, tools, telemetry, and backups must also satisfy the required processing and storage locations; hosting Core locally does not keep every data copy local.

Limitations that can rule out a deployment​

RequirementBoundary and decision consequence
Specific client APIResponses currently requires the Azure OpenAI Adapter. Messages supports compatible-model passthrough or translation to Chat Completions through the Bedrock Adapter. Do not assume every provider supports every client API. See API support.
Uniform content inspectionInterceptors run on Chat Completions, Embeddings, and Responses requests. Anthropic Messages passthrough does not run interceptors, and MCP and HTTP routes are separate paths. If inspection is mandatory, establish coverage for every permitted path. See security boundaries.
Isolation between mutually untrusted tenantsResource permissions and execution containers alone do not establish this boundary. Validate identity, runtime, network, and storage isolation for the chosen topology. See Data protection and isolation.
Transparent failover and disaster recoveryFailover destinations must meet residency, capability, and quality requirements, which can reduce fallback options. Failover cannot be assumed to resume an interrupted stream; model redundancy alone does not recover the platform's state. Recovery point and recovery time targets need deployment-specific evidence. See Run DIAL with high availability and Back up and restore DIAL.

Cost boundary​

Evaluate cost per completed workflow: one answer can involve embeddings, multiple model and tool calls, retries, and logging. Include platform compute, stores, telemetry, backups, network transfer, evaluations, and operating effort. Core's configured pricing and usage attribution support allocation; they do not replace provider, tool, and infrastructure bills.

Further reading​