In the rush to integrate large language models, many engineering teams are making a critical architectural error: treating model providers as interchangeable components rather than distinct services with unique failure modes. A new analysis published on DEV.to on October 25, 2026, by Paxton Shaw, argues that for specific use cases like e-commerce sales-call classification, the priority should not be swapping OpenAI for Claude or Gemini, but rather establishing a rigid, reversible contract that isolates business logic from provider volatility. The piece, framed as an Architecture Decision Record (ADR), suggests that while providers like Infrai offer a compatible surface, the real value lies in configuration-driven model selection rather than code-level provider branching.

The Case for a Single Compatible Contract

Shaw identifies four invariants that must survive any model change: explicit tenant and workflow fields, strict output schemas that downstream CRM commands understand, retention of the selected model and prompt version with every record, and a failure boundary that prevents malformed responses from mutating the CRM. The analysis contrasts this approach with direct integration strategies. While direct access to OpenAI, Anthropic, or Google is cleaner for workflows requiring provider-specific features like function calling or native moderation, it creates significant migration pressure. Each new provider requires a new adapter, duplicating prompt assembly, retry logic, and cost attribution. For ordinary tagging tasks, the article posits that business code should describe CRM actions, not vendor dialects, thereby reducing the surface area for errors when routing policies change.

Operational Constraints and Cost Telemetry

Beyond code architecture, the piece delves into the operational realities of multi-tenant cost tracking. It warns against high-cardinality metrics, noting that dashboards tagging every time series with tenant_id can inflate retention costs and query complexity. Instead, Shaw recommends separating the tenant ledger from routing decisions and request-level investigation data. A practical example is provided: at 2,000 summaries per day with 1,500 input and 250 output tokens, the workload consumes 3 million input tokens daily. This arithmetic must be visible before rollout to inform tenant policies. The article highlights Infrai’s public model discovery endpoint as a tool to make model selection a visible configuration decision rather than a hardcoded string, allowing administrators to inspect capability boundaries before committing to a tenant policy.

Limitations of the 'One Key' Approach

Crucially, the analysis is not a blanket endorsement of routing layers. It explicitly rejects the 'one key' solution for capabilities like audio transcription, which are marked unavailable in the Infrai catalog, and real-time voice sessions, which are currently limited to western regions with pending key status. The lack of a dedicated moderation endpoint also means teams must rely on chat models with JSON-schema fallbacks, which introduces latency and cost inefficiencies compared to specialist services. Shaw emphasizes that compatibility does not equate to equal prediction quality or feature parity. Portability is a contract property, not a guarantee of identical outputs. The recommended design uses a single adapter for the common chat contract but keeps exceptions for provider-specific controls explicit and outside the ordinary tagging adapter.

Key Takeaways

  • Reversibility is the primary design constraint: model changes should alter configuration and evaluation results, not CRM parsing code.
  • Direct provider integration is superior only when vendor-native controls (like specific moderation or real-time voice features) are the core product requirement.
  • Cost telemetry must separate tenant ledgers from routing decisions to avoid high-cardinality metric explosions.
  • Public model discovery endpoints allow administrators to verify capability boundaries before enforcing them as tenant policy.
  • Idempotency keys protect classification attempts, but durable application request identities are required for CRM mutations.

The Bottom Line

Stop treating LLM providers as drop-in replacements; build a stable interface that isolates your business logic from the volatile reality of model APIs.