🔥 Top Story
Meta’s Iris push signals the next phase of AI infrastructure
Meta is set to begin production of its first proprietary AI inference chip, Iris, this September, according to an internal memo reported by Reuters, after roughly six weeks of bug testing. Iris extends Meta's Meta Training and Inference Accelerators (MTIA) program and is designed to take over inference workloads currently running on third-party GPUs, powering content ranking, recommendations, and generative AI across Facebook, Instagram, and WhatsApp. Meta is working with Broadcom on chip design and TSMC on manufacturing, and plans to ship a new iteration roughly every six months through 2027 — an aggressive cadence versus typical industry timelines. Alongside the chip, Meta has locked in long-term supply deals for high-bandwidth memory from Samsung, flash storage from SanDisk, and fiber-optic networking gear from Sumitomo Electric. The company plans to bring about 7 gigawatts of compute capacity online this year, doubling to 14 gigawatts by 2027 — enough to rival the power consumption of a small country. The move mirrors similar in-house silicon pushes by Google (TPU) and Amazon (Trainium/Inferentia) as hyperscalers race to control their own AI infrastructure stack.
💡 Why it matters: In-house inference silicon is becoming table stakes for hyperscalers looking to escape GPU supply bottlenecks and cost pressure, so infra teams should plan for growing hardware heterogeneity and keep workloads portable across accelerator vendors.
🔗 Read more · The New Stack
AI & ML
How Deutsche Telekom is rewiring telecommunications with AI
OpenAI
This OpenAI blog post profiles Deutsche Telekom, one of the world's largest telecoms with over 300 million customers across Europe and the US and more than 200,000 employees, as it pursues a goal of becoming an 'AI-native telco.' Based on an interview with Chief Product & Digital Officer Jonathan Abrahamson, the piece reports over 50,000 monthly active users of ChatGPT Enterprise and API tooling, and a 546% increase in AI tool usage since the start of 2026. The transformation started by rolling out ChatGPT Enterprise to employees and encouraging experimentation, while simultaneously redesigning customer-facing workflows, with customer care as an early priority area. Abrahamson describes AI-powered customer service as still early-stage but with real potential to eventually outperform traditional support models as systems accumulate context and reduce friction like handoffs and wait times. Working with OpenAI and other partners, Deutsche Telekom is embedding AI directly into core telecom experiences — live translation, in-call assistants, and post-call summaries — without requiring customers to install new apps, and is also applying AI to network operations to dynamically reallocate resources as demand shifts (e.g., commuter traffic, major sporting events).
💡 This is a case study in scaling AI beyond chatbots into enterprise-wide workflow redesign, and it signals that infra teams should start planning for latency-sensitive AI features (live translation, in-call assistants) running alongside AI-driven network operations at telecom scale.
Profiling in PyTorch (Part 3): Attention is all you profile
Hugging Face
This is Part 3 of Hugging Face's 'Profiling in PyTorch' series, which builds the skill of reading profiler traces to drive optimization. Part 1 covered basic operations like addition and multiplication, and Part 2 wrapped those into a linear layer and multilayer perceptron, including fused and hand-tuned kernels; Part 3 moves on to attention, the core operation in Transformer architectures. Attention is broken down into its constituent steps — a QK^T matmul, scaling, causal masking, softmax normalization, and a final matmul with V — and while it's notorious for quadratic-time complexity, the post's goal isn't to cover every optimization trick in depth but to show how each looks distinctly different under the profiler. The accompanying code spans four scripts, from naive attention through in-place operations, scaled dot-product attention (SDPA), and custom kernels, run on an NVIDIA A100-SXM4-80GB GPU, with Hugging Face's Dev Mode with Spaces or the Jobs pipeline offered as an easy way to get GPU access. The post starts by implementing a naive causal attention module and walking through what the profiler trace is expected to show — a matmul, a scaling multiply, a masking op, a softmax, and a second matmul — before comparing it against faster variants in later sections.
💡 Before reaching for attention optimizations like SDPA or custom kernels, profiling the trace to confirm whether the actual bottleneck is the matmuls or the masking/softmax step avoids wasting time optimizing the wrong part of the pipeline.
Cloud Updates
Contributing to U.K. financial sector resilience as a critical third party
Google Cloud
On July 10, 2026, the UK Treasury designated Google Cloud EMEA as a Critical Third Party (CTP) to the UK financial sector, a decision based on the scale and materiality of UK financial firms' reliance on Google Cloud services. As a CTP, Google Cloud EMEA will now be directly overseen by the Bank of England, the Prudential Regulation Authority (PRA), and the Financial Conduct Authority (FCA), collectively the UK financial regulators. The CTP regime is designed to strengthen sector-wide operational resilience by bringing critical infrastructure providers — not just individual financial firms — under direct regulatory oversight. Google Cloud already offers customers a whitepaper addressing PRA Supervisory Statement SS1/21 (operational resilience) and a contract mapping for SS2/21 (outsourcing and third-party risk management), and states the CTP regime complements rather than replaces these existing requirements. The designation formalizes deeper, ongoing engagement and transparency between Google Cloud and UK financial regulators going forward.
💡 Teams running UK financial workloads on Google Cloud should review the new CTP oversight requirements alongside the SS1/21 and SS2/21 mappings, since this direct regulatory relationship changes the operational resilience and reporting obligations they need to account for.
Frontier and Center: Who evaluates the evaluations?
Google Cloud
This is the second post in Google Data Cloud's 'Frontier and Center' series, following an earlier piece on the Open Knowledge Format, and it critiques how AI agents are typically evaluated. The authors argue that today's pass/fail benchmark scores tell you an agent cleared a bar but not where or how narrowly it fails, which is especially problematic for the 'discovery' step where data agents must find the right tables or files in a large warehouse or data lake based on a vague human question. They note that manually labeling evaluation cases by difficulty (easy vs. hard) is an industry-standard but unscalable practice, and instead introduce Discovery Bench, an information-theory-based meta-benchmark that systematically modulates question ambiguity to map exactly where an agent's retrieval capability breaks down. In building this finer-grained fidelity into evaluations, the team also surfaced deeper quality issues in existing evaluation cases themselves. The post is aimed at teams building and evaluating data-retrieval agents, with more entries in the series promised.
💡 Teams relying on a single pass/fail benchmark score risk missing exactly where their retrieval agent breaks down, so adopting difficulty-modulated evaluation approaches like Discovery Bench is a practical way to pinpoint and fix weak spots in the discovery/retrieval stage.
What’s new with Google Cloud
Google Cloud
This is Google Cloud's weekly 'What's new' rollup, aggregating announcements, events, and resources from July 6–10. Highlights include an upcoming preview of Cloud NGFW Enterprise's advanced malware protection powered by Palo Alto Networks Advanced Wildfire (with a July 16 webinar), the public preview of Cloud Run sandboxes — lightweight, isolated execution environments for running LLM-generated or dynamically generated code safely within an existing Cloud Run service — an Australia-based API Horizon event series focused on governing agentic AI at scale via Apigee as an AI gateway, and the general availability of Cloud Run's Service Health feature for building highly available, multi-region services. Service Health automates cross-region failover using readiness-probe-based instance health checks with a two-click setup, and can be paired with global external Application Load Balancers for public-facing applications. Rather than a single announcement, this page functions as a weekly digest and index into Google Cloud's broader blog content.
💡 Teams running Cloud Run in production can now set up multi-region failover easily with the newly GA Service Health feature, and teams that need to execute LLM-generated code should evaluate the new Cloud Run sandboxes preview as an isolated execution option.
Improving Smart Tiered Cache for Public Cloud Regions
Cloudflare
Cloudflare's Smart Tiered Cache, launched in 2021, automatically picks the single fastest upper-tier data center to route through for each origin based on real-time latency probing, and it's now the most popular tiered-cache topology among Cloudflare customers, available free on all plans. The gap this update addresses is public cloud origins hosted behind anycast or regional unicast front ends (common on AWS, GCP, Azure, and Oracle Cloud), where the origin IP appears equally 'close' to many Cloudflare data centers at once, so latency probing can't identify a clear winner and the system falls back to multiple upper tiers — sacrificing the cache efficiency gains a single tier provides. With Smart Tiered Cache for Public Cloud Regions, customers can now supply a cloud region hint, letting Cloudflare map the origin to its actual region and select better primary and fallback upper tiers even when the IP itself looks ambiguous. This builds on earlier extensions — automatic upper-tier selection for R2 buckets (November 2024) and shared caching across an entire Load Balancing pool (January 2025) — continuing Cloudflare's pattern of automatically understanding customer origin architecture to optimize caching.
💡 Teams running origins on public cloud behind anycast or regional unicast front ends can improve cache hit ratio and cut origin load simply by supplying a cloud region hint — worth checking if your Cloudflare-fronted origin architecture falls into this category.
Pluggable by design: An agent mesh for software modernization that adopts the next model release
Red Hat
Red Hat's 'agent mesh for software modernization' is an architecture built on Red Hat AI for modernizing legacy systems in regulated, often disconnected environments (e.g., defense, financial services), where coding agents run on Devstral and non-coding agents on Ministral without relying on outside API calls. Following an earlier post on the harness pattern, workflows, and KPI framework, this post focuses on 'pluggability': models, agents, and static tools are each treated as independent, swappable components behind clear interfaces, so a connected commercial coding agent (like Claude Code or Codex) can run when policy allows, or be swapped for an on-premises alternative like OpenCode without rewriting the orchestration layer above it. The harness's iteration cycle, automated workflow tracking, merge policy, and audit trail stay stable across these component swaps. The post walks through a concrete case where the team upgraded to Gemma 4 and the latest CrewAI simultaneously, detailing which parts of the swap were clean and which required scoped engineering work. The harness itself organizes work into five capabilities, starting with 'code archaeology' — which uses SDGHub for metadata generation and GraphRAG for structural indexing to produce a migration plan, SBOM, and a list of risky modules.
💡 Teams planning AI-agent-driven modernization in disconnected or regulated environments benefit from designing models, agents, and tools as swappable components from day one, so future model upgrades or vendor changes can be absorbed as upgrades rather than orchestration rewrites.
New observability features in Red Hat OpenShift 4.22
Red Hat
The latest Red Hat OpenShift release adds native monitoring, logging, tracing, and dashboarding capabilities that merge metrics, logs, traces, and network telemetry into a single workflow, aiming to reduce the common problem of Kubernetes tool sprawl. The centerpiece is Cluster Observability Operator (COO) 1.5, a 'meta-operator' that deploys and manages autonomous monitoring stacks; this release brings advanced analytics like incident detection and Korrel8r-powered signal correlation, along with observability UI plug-ins, to general availability. Notably, the Red Hat build of Perses dashboarding tool is now fully supported as a core COO 1.5 component, offering multi-cluster dashboard visibility via integration with Red Hat Advanced Cluster Management, RBAC aligned with OpenShift, GitOps-friendly dashboard definitions, and compatibility with existing Prometheus and Thanos data sources. Perses is built as a Kubernetes-native, declaratively configured dashboarding platform designed for high-performance rendering at scale and a flexible plugin model for custom panels and data sources, positioning it as a modern alternative to traditional dashboarding approaches that struggle in dynamic, multi-cluster environments. With Perses inside Red Hat Advanced Cluster Management, teams can build reusable dashboards across clusters, normalize observability views, and cut down on duplicated configuration.
💡 Platform teams running multiple OpenShift clusters should use the GA of COO 1.5 and Perses as a prompt to evaluate consolidating fragmented, per-cluster dashboard stacks into a centralized, GitOps-friendly setup.
Friday Five — July 10, 2026
Red Hat
Red Hat's weekly 'Friday Five' roundup for this week covers three main items. First, IBM and Red Hat announced an expansion of the Lightwell product line — developed with leading global financial institutions — to build 'trust infrastructure' for the open source supply chain in the AI era, calling it the largest single commitment to open source security since IBM's landmark $1 billion investment in Linux in 1999. Per a Silicon Angle report, IBM is partnering with Deloitte to help enterprise customers map the open source components used across their applications and continuously update that inventory as software changes, aiming to prevent situations where a company is unaware that an application contains a vulnerable open source module. A Techzine EU report notes that Red Hat OpenShift has made significant strides in virtualization, addressing the growing operational burden of managing VMs, containers, and heavier AI workloads as virtualization costs increasingly become a concern beyond the traditional IT department. The post also promotes sign-ups for a new Lightwell newsletter.
💡 Organizations focused on open source supply chain security should compare the continuous component-inventory and vulnerability-mapping approach behind the Lightwell/Deloitte partnership against their own SBOM management practices.
DevOps & Infrastructure
Why retrieval quality is becoming the defining challenge in AI agent architecture
The New Stack
This The New Stack piece argues that many failures blamed on LLMs actually originate earlier, in the context-building (retrieval) step of agentic systems. In a case study with Specstory, an agent trying to answer why a team chose Authlib for authentication surfaced implementation code snippets instead of the actual trade-off discussion, producing a confident but misleading answer. A similar pattern shows up with AnkiHub, where a lecture on a broad topic can match hundreds of flashcards, and ranking — not the LLM — decides whether the right cards make it into context. The article maps three common symptoms — hallucination, 'context rot' (noisy context from an inflated top_k), and latency — back to retrieval failures rather than generation failures. It cites the Mixedbread OfficeQA-Pro benchmark, built on 89,000 pages of financial documents, dense tables, and scanned PDFs, where giving Codex better search tools reduced tool calls and improved answer quality. The core takeaway: a better generation model can't compensate for bad context, and once data lives in PDFs, tables, chat histories, or permissioned sources, plain-text tools like grep no longer suffice — teams need dedicated retrieval infrastructure.
💡 Before swapping in a bigger model to fix agent quality issues, teams should check whether hallucinations, latency, and context bloat are actually symptoms of a weak retrieval/ranking layer — investing in retrieval infrastructure is often the higher-leverage fix.
Better tools made Copilot code review worse. Here’s how we actually improved it.
GitHub
GitHub's engineering team migrated Copilot code review from its own bespoke code-exploration tools (list_dir, search_file/dir, read_code) to the shared, Unix-inspired tools (glob, grep, view) used by the Copilot CLI harness, aiming to consolidate infrastructure across Copilot products. The migration initially backfired in offline benchmarks: average review cost went up and fewer useful issues were caught. Tracing the regression revealed the tools weren't the problem — the old tools automatically returned surrounding context around a match, which earlier, less context-efficient models relied on, while the new shared tools returned only the exact requested range, sending the review agent into a repetitive 'browsing loop.' After rewriting the tool-use instructions to match how a human reviewer actually reads a pull request, the team turned the regression into a win: roughly 20% lower average review cost while maintaining the same review quality. Because the harness is shared across Copilot products, including GitHub Copilot cloud agent, the fix benefits multiple products at once.
💡 Swapping in better-maintained shared agent tools isn't enough on its own — the instructions guiding how the model uses those tools need to be redesigned alongside them, or you risk a costly regression like GitHub saw here.
What running Kubernetes across millions of clusters taught AWS about zonal failures
The New Stack
This post distills years of engineering lessons AWS learned building zonal resiliency into Amazon EKS across millions of production clusters. The core problem isn't a cleanly dead zone but a 'gray' one — slow, dropping some traffic, yet still passing health checks — where the default automated response of detecting-unhealthy-and-replacing turns a single-zone problem into a regional outage. Early on, a brief network partition would cause API servers in the affected zone to fail health checks (even though the servers themselves were fine), triggering the Auto Scaling group to terminate them, attempt replacements in the same impaired zone, fail again, and back off for up to thirty minutes — cascading a 30-second network blip into fleet-wide terminations. AWS's fix centers on the principle of 'static stability': during a zonal impairment, the most valuable action a system can take is to stop reacting, preserve existing capacity, route around the bad zone, and wait rather than aggressively self-heal. The post covers what was built into the EKS control plane (API server and etcd resilience across AZs) as well as what was exposed in the data plane for workloads, framing these as the connecting principles behind zonal resiliency in EKS today.
💡 When designing auto-recovery or autoscaling logic, a naive 'health check fails → replace immediately' policy can amplify gray zonal failures into region-wide outages — building in static-stability behavior that pauses reactive scaling during ambiguous impairments is essential.
초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기
LINE
LY Corporation (LINE) describes how it designed and rolled out end-to-end encryption (E2EE) for Kafka clients to protect sensitive user data flowing through a shared topic handling up to 1 million messages per second, with zero downtime. Standard Kafka already provides in-transit encryption (TLS), authentication (SASL), and authorization (ACLs), but payloads stored on brokers remain plaintext — so LINE's goal was to keep payloads encrypted all the way from producer to consumer. They chose record-level (rather than batch-level) encryption so they could implement it entirely through Kafka's standard interceptor and serializer extension points, and adopted a DEK-KEK dual-key structure: a fast symmetric key (DEK, AES-GCM) encrypts the actual payload, while that DEK is itself encrypted with an asymmetric key (KEK, ECIES over the secp521r1 curve) registered in a KMS. To prevent message size from growing with each additional consumer, LINE introduced a shared-KEK model where multiple consumers share one KEK, offsetting the resulting risk with KMS-based authorization and mandatory periodic key rotation. For the production rollout, consumers' deserializers were built to detect whether encryption metadata is present in the message header and fall back to plaintext handling when it's not, allowing encrypted and unencrypted messages to coexist safely during a gradual, zero-downtime migration.
💡 For teams adding message-level encryption to high-throughput Kafka topics, LINE's DEK-KEK design with a shared KEK to keep header overhead flat, plus a plaintext-fallback deserializer for zero-downtime migration, is a concrete pattern worth studying.
This digest was collected from RSS feeds and summarized by AI (Claude). See the original links for full details.