Architecture AI Updates: July 28, 2026

1. Evolutionary Architecture Pattern Positions the AI Gateway as a Change-Isolating Seam

Joe Price, Branimir Đurek, Pavlos Migkiros, and Trevor Dearham, writing for InfoQ, argue that AI capabilities evolve far faster than the enterprise systems that consume them, and that the gap is permanent rather than transitional. Their proposed pattern treats the AI gateway as a deliberate architectural seam where fast-moving components concentrate while downstream systems stay stable, applying evolutionary architecture principles to isolate change instead of absorbing it everywhere. The gateway centralizes five evolving responsibilities in a single control plane: model routing to allow provider swaps and cost optimization without application changes, agent identity and authorization to manage delegated authority through still-unstable standards, per-operation action policy for zero-trust checks that catch hijacked actions, content guarding for injection and leakage inspection, and semantic audit that records request-decision-action chains for compliance. The authors contend traditional API gateways fall short because agentic systems are non-deterministic, fail at the semantic rather than schema level, and make indirect decisions beyond client intent. They flag trade-offs including latency overhead, centralization complexity, and probabilistic protection that offset the benefits for single-team, single-model deployments. Source

2. Netflix Splits LLM Serving Across CPU and GPU Paths on an Existing JVM Platform

Matt Foster, reporting for InfoQ, details how Netflix layered LLM inference onto its existing JVM-based serving platform rather than building a separate stack. The design separates concerns by request size: smaller models run in-process on a local CPU path to preserve existing production workflows, while larger requests delegate to a dedicated GPU serving system where Triton handles model loading, batching, GPU scheduling, and multi-framework serving. Netflix selected vLLM for inference while keeping Triton responsible for model management, a split intended to let models and frontends evolve more independently than the Triton Python backend would allow. The team reports version compatibility as a recurring hazard, since mismatched Triton and vLLM releases can block deployments from loading, which pushed them toward tested and pinned version pairs, and custom models required vLLM extension points because built-in Hugging Face compatibility proved insufficient. A common OpenAI-compatible API sits across the backends, and the platform uses red-black and versioned deployment strategies to manage model-level changes and migrate consumers safely after schema updates. Source