KeepTheLLMOn
Reference Architecture

Architecture that assumes failure

Resilient AI is not a bigger contract with one vendor. It is a routing layer, diversified paths, synchronized knowledge, and tested procedures — sized to each service's criticality.

BusinessWorkflowsSupport · Sales · DevAIR LayerModel routingMonitoringFailover controlPrimary Cloud AIActiveSecondary CloudStandbyLocal InferenceLast resortACTIVEFAILOVERFAILOVER

Failover topologies

Three reference topologies

Selected per service during the Design phase, based on the criticality scores and recovery objectives set in the Assessment.

AIR Routingpolicy + health checksProvider Aprimary — activeProvider Bsecondary — standbyACTIVEFAILOVER

Cloud-to-cloud failover

Best fit: Most operational AI services (ACI 2–3)

A routing layer with health checks directs traffic to your primary provider, failing over to a secondary provider when availability or latency degrades. Prompts are validated against both model families in advance, so failover doesn't mean quality collapse.

Trade-offs: Fast to implement and inexpensive to run, but both paths still depend on internet connectivity and external vendors.

AIR Routingpolicy + health checksCloud AIprimary — activeLocal Inferenceon-prem GPU — standbyknowledge syncACTIVEFAILOVER

Cloud-to-local failover

Best fit: Mission-critical services (ACI 4–5), connectivity-sensitive sites

Cloud AI remains primary for capability and cost, with on-premises GPU inference as the failover target. Knowledge bases and embeddings synchronize continuously so the local path meets your AI-RPO, not just your AI-RTO.

Trade-offs: Survives vendor and connectivity failures entirely, at the cost of GPU infrastructure and a capability gap between frontier and local models — which degraded-mode design must account for.

AIR Routingweighted load balanceProvider AactiveProvider BactiveACTIVEACTIVE

Active-active routing

Best fit: High-volume services where failover latency is unacceptable

Traffic is load-balanced across two or more providers continuously. There is no 'failover event' — losing a provider simply shifts weights. Both paths are proven healthy at all times because both serve production traffic.

Trade-offs: The strongest availability posture and continuous validation, but requires prompt portability discipline and doubles integration surface.

Design principles

How we make architecture decisions

Criticality drives topology

A service with an AI Criticality Index of 2 gets a documented degraded mode. A 5 gets tested multi-path failover. Spending is proportional to business impact — never uniform.

Knowledge sync is the hard part

Failing over the model is easy; failing over what the model knows is not. Vector indexes, prompt libraries, and agent state need replication strategies that meet your AI-RPO.

Prompts must be portable

Prompts tuned to one model family degrade on another. We maintain evaluation suites across primary and failover models so quality is measured, not assumed.

Untested failover is fiction

Every topology we design ships with drill procedures. If a path hasn't been exercised this quarter, we treat it as unavailable.

Architecture starts with the Assessment

Topology selection without criticality scores is guesswork. The AIR Assessment produces the scores — then the architecture designs itself.