🔥 Top Story
SymptomAI: Towards a conversational AI agent for everyday symptom assessment
Google Research published a paper titled 'SymptomAI: Towards a Conversational AI Agent for Everyday Symptom Assessment', describing a large-scale, national study of a conversational AI system for symptom checking. The team built five randomized variants of a SymptomAI agent on top of Gemini Flash 2.0, each using a different history-taking strategy, and had 13,917 consenting research participants describe their symptoms to one of the agents, receiving a differential diagnosis (DDx) list and next-step recommendations. Two weeks later, participants self-reported the diagnosis they received from an actual healthcare provider visit, and a panel of three board-certified clinicians blindly reviewed the transcripts to rank SymptomAI's DDx against DDx produced by fellow clinicians. Clinicians preferred SymptomAI's differential diagnosis over other clinicians' in more than half of cases, and SymptomAI's top-5 accuracy was also higher than that of human clinicians. Prompting strategies where the agent actively asked follow-up questions significantly outperformed a bare, unprompted baseline model. The team also correlated SymptomAI's diagnoses with participants' Fitbit biosignal data and found that, for those diagnosed with respiratory infections, cardiovascular, respiration, skin-temperature, and sleep metrics shifted noticeably around the time symptoms were reported. Google stresses this is exploratory research only, and that all diagnoses generated in the study are for research purposes and do not constitute confirmed clinical assessments.
💡 Why it matters: The key practical takeaway isn't that the AI beat clinicians outright, but that actively prompting follow-up questions, rather than passively answering, was what drove the accuracy gains, a concrete design signal for anyone building conversational intake or triage flows.
🔗 Read more · Google Research
Kubernetes & Cloud Native
Confidential Containers becomes a CNCF incubating project
CNCF
The CNCF Technical Oversight Committee (TOC) has voted to promote Confidential Containers from the Sandbox to an incubating project. The project protects data in use (data actively being processed in memory) using hardware-based Trusted Execution Environments (TEEs), complementing existing encryption for data at rest and in transit. Started in 2021 as a collaboration among Red Hat, Intel, IBM, and other partners, it integrates TEEs into the Kubernetes ecosystem via the Kata Containers runtime, letting teams deploy confidential workloads through familiar Kubernetes workflows. The project has grown with backing from Microsoft Azure, Intel, AMD, IBM, NVIDIA, Alibaba, and Red Hat, and now counts over 1,000 combined GitHub stars, 1,200+ merged pull requests, and 150+ active contributors. Its core components include Confidential Containers Pods, the Trustee attestation service, Helm charts and controllers for lifecycle management, and a hardware abstraction layer supporting Intel TDX and AMD SEV-SNP. It is also integrating with Kyverno for automation and KServe for confidential AI inference use cases. The roadmap targets a stable, easy-to-deploy end-to-end solution in the short term (2-6 months) and use-case-driven development in the mid-to-long term (6-18 months).
💡 Confidential Containers reaching CNCF incubation signals that TEE-based workload isolation is maturing from niche research into a standard Kubernetes pattern, worth watching for teams that need to run sensitive data or AI inference workloads on shared, multi-tenant infrastructure.
Runtime Enforcement, Not Runtime Advice
Docker
Docker published Part 2 of its AI governance blog series, titled Runtime Enforcement, Not Runtime Advice, following Part 1 on the laptop becoming the new production environment. Author Karan Verma argues that written policies alone cannot govern autonomous agents, summarizing the idea as a prompt can influence behavior while a runtime can restrict it. The post frames developer trust in agents around three boundaries: an execution boundary covering file access, code changes, command execution, and dependency installation; a tool boundary covering MCP-connected access to source control, issue trackers, cloud services, and internal APIs; and a credential boundary covering access to things like GitHub repositories and cloud environments. It identifies isolation, the same principle behind containers, VMs, and sandboxes, as the foundation for actually enforcing these boundaries, citing Docker Sandboxes as an example of isolation adapted for agent execution. The piece closes by arguing governance is not a constraint on autonomy but a trust-building mechanism, since clear boundaries create predictability and predictability lets teams delegate more work to agents, teasing Part 3 on the developer-experience angle.
💡 As agents gain more MCP-connected tool access, the real enforcement point is the runtime isolation layer, not policy documents, a distinction worth internalizing before delegating more autonomy to agents.
Agentic AI Needs Guardrails, Not Guesswork
Docker
Docker's Mark Lechner recapped a panel featuring Warp founder and CEO Zach Lloyd, NanoCo co-founder and CEO and NanoClaw creator Gavriel Cohen, and moderator Moriah Hara, who leads a community of more than 3,000 CISOs. The panel discussed how to secure agentic AI without slowing developers down and converged on the idea that agents must run inside isolated environments with trusted control boundaries, summed up as isolate, control, observe. Warp addresses this with its Oz cloud agent infrastructure for centralized visibility and access control, while Docker, after integrating NanoClaw with Docker Sandboxes in March, runs agents in disposable, MicroVM-isolated sandboxes. Panelists flagged supply chain risk from agents autonomously choosing base images and dependencies, citing attackers such as TeamPCP and ShinyHunters, and recommended mitigations including a minimum seven-day image release age, minimizing dependencies, and using immutable tags, digests, and SBOMs, while also calling MCP a potential new shadow IT that requires centralized governance and a vetted tool catalog. Docker pointed to its year-old open source MCP Gateway, which authenticates, authorizes, and logs every tool call between agents and external systems as a chokepoint. Hara closed with a warning that six months from now enterprises will all be running agents at scale, and the key success factor will be whether governance was present from day one or bolted on after the first major incident.
💡 What these CISOs converged on were concrete operational controls such as MicroVM isolation, minimum image-age rules, and MCP gateways rather than policy documents, making it a practical checklist for teams rolling out coding agents.
Multi-Cluster databases on Kubernetes: Architecture and deployment
CNCF
This CNCF blog post, written by CNCF Ambassador Edith Puclla and Percona for MongoDB tech lead Ivan Groenewold, walks through building a multi-cluster MongoDB deployment on Kubernetes using the open-source (Apache 2.0) Percona Operator for MongoDB that can survive a full regional outage, a corrupted control plane, or a network partition. Standard Kubernetes self-heals within one cluster but has no built-in recovery path when an entire cluster fails, so the post splits clusters into a Main Site (fully Operator-managed, holding the Primary) and one or more Replica Sites (Operator running in unmanaged mode, joining the existing replica set using TLS certificates and credentials copied from the Main Site). Cross-cluster connectivity relies on the Kubernetes Multi-Cluster Services API (MCS API): setting multiCluster.enabled: true makes the Operator create ServiceExport/ServiceImport resources so nodes discover each other through a shared svc.clusterset.local DNS zone, which requires a separate implementation such as Submariner, Cilium ClusterMesh, or a cloud provider's managed MCS. The key availability insight is that splitting voting members evenly, 2 and 2, across two sites leaves neither side with a majority during a network partition, so the post recommends a 2+2+1 pattern with a fifth voting member in a third location to guarantee a 3-vote majority on one side. Under default settings, the median time to elect a new Primary after a failure is typically under 12 seconds, though cross-region latency can extend that window, so the authors recommend retryable writes and tuning electionTimeoutMillis. The post also notes that similar multi-cluster patterns exist for relational workloads via Vitess and CloudNativePG. A follow-up post promises chaos-engineering experiments to stress-test this architecture under real failure conditions.
💡 Teams building multi-region database HA should treat quorum design, an odd number of voting members split across three sites, as the core decision rather than just adding nodes, and remember that the MCS API is not part of stock Kubernetes, so a mesh implementation like Submariner or Cilium ClusterMesh must be stood up first.
I made a policy engine think it was in production
CNCF
This CNCF blog post is a retrospective by a final-year undergraduate who worked as a Spring 2026 LFX Mentee, mentored by Shuting Zhao and Frank Jogeleit, on Kyverno's Unified CLI project (GitHub issue #15264). Kyverno is a Kubernetes-native policy engine that validates, mutates, and generates resources before they reach the cluster, but when policies use GlobalContextEntry lookups against live Kubernetes resources, the kyverno CLI has no API server to resolve them in CI/CD, causing test panics and silently skipped rules, a gap that was still open at the start of 2026. Over the first four weeks the author fixed foundational bugs, including a panic in wildcard mutateExisting rules and silent test-result swallowing for CEL-based policy types such as ValidatingPolicy, MutatingPolicy, and GeneratingPolicy. The key fix left the policy engine itself untouched: after realizing the Kubernetes informer cache always returns a slice of unstructured objects ([]interface{}), the author built resolveResourcesMockData, a CLI-only translation layer that reshapes mock resources from kyverno-test.yaml into that same structure, so the engine evaluates offline test data exactly as it would live cluster data (shipped in PRs #15948 and #16123). The fix turned out to have real production stakes: a community member commented on a related PR, #15846, that the gap had been blocking their team's offline CI/CD tests since Kyverno v1.17 and asked for a backport to v1.18. Over the 12-week mentorship the author also shipped multiple additional bug fixes and new CLI flags such as --http-payload and --envoy-payload for offline testing of HTTP and Envoy authorization policies.
💡 The core lesson, disguising mock data as the exact shape the engine already expects rather than modifying the engine to accept test data, is a reusable design principle for anyone building offline or CI test harnesses for policy and rules engines that must match production behavior exactly.
AI & ML
Towards a quantum computer that learns from its errors
Google Research
Google Research's Quantum AI team, in a paper by research scientists Volodymyr Sivak and Paul Klimov published in Nature titled 'Reinforcement learning control of quantum error correction', unveiled a reinforcement-learning (RL) framework that lets a quantum computer keep learning from its own errors and stabilize itself without halting computation. Because quantum computers are analog and prone to drift, calibrating their control parameters has always required fully stopping the computation, a bottleneck for future algorithms that need to run continuously for days or months. The team's approach repurposes the stream of error-detection events generated during quantum error correction (QEC): instead of using it only to recover lost information, an RL agent also uses it as a live learning signal to continuously steer thousands of control parameters. Tested on Google's Willow superconducting processor by deliberately injecting artificial drift, RL-based steering improved the logical stability of the error-correcting code 3.5-fold, and even after exhaustive expert human calibration, RL fine-tuning suppressed the logical error rate by a further 20%. Combined, these techniques pushed logical error rates in quantum memory to a record low, fewer than one error per thousand correction cycles in the surface code and one per hundred in the color code. Numerical simulations with hundreds of qubits and tens of thousands of control parameters showed that the number of RL training iterations needed is independent of system size, suggesting the method can scale to much larger future quantum computers.
💡 Removing the need to halt computation for recalibration is a prerequisite for any quantum algorithm that must run continuously for days, and the finding that RL training cost doesn't scale with qubit count is the key signal for whether this generalizes to larger, more useful machines.
Building AI infrastructure with the Effingham County community
OpenAI
OpenAI detailed community commitments for Project Camellia, a long-term data center it is developing in Effingham County, Georgia. The project is backed by a contract with Georgia Power for 3.2 gigawatts of power to be delivered in phases between 2028 and 2032. OpenAI says residents' electricity rates will not rise because of the project, since it will cover the full cost of the infrastructure and electric-service upgrades required, and the facility is designed to proactively cut its own power draw during periods of high regional demand. Water use will be minimized through a closed-loop cooling system, with ongoing consumption expected to be comparable to an office building with a similar number of employees. OpenAI pledged $80 million in community benefits over the project's lifetime for schools, public safety, health care, housing, and veterans' services, separate from projected tax revenue and up to $71 million in Codex credits worth $100 each for eligible Georgia college, community college, and technical school students. The company expects to become the county's largest taxpayer and says an independent firm will conduct a publicly released annual audit to verify compliance. It is holding a public open house on Thursday, July 23, with resident feedback expected to inform a forthcoming Georgia Community Compact.
💡 Spelling out rate protection, water limits, and independent audits upfront shows how community pushback over data-center power and water use has become a real business risk that hyperscalers now negotiate before breaking ground, not after.
How news organizations are using AI to advance their vital missions
OpenAI
OpenAI published a roundup of how news organizations have used its technology over the past year, organized around reporting, audience experience, and business operations. It noted that the American Journalism Project recently announced renewed OpenAI support for its portfolio of dozens of publications across 38 states, alongside continued backing for the Lenfest Institute for Journalism and WAN-IFRA. On the reporting side, the Associated Press uses the tools for image and video verification and for making Supreme Court filings searchable, the Philadelphia Inquirer built Scribe to summarize and rank public-meeting transcripts by newsworthiness, the Daily Beast runs Data Scouts agents inside Slack, and Axios built custom GPTs including a FOIA Refiner for drafting open-records requests. On reader experience, Conde Nast's Bon Appetit launched a recipe Q&A Test Kitchen Assistant, the Atlantic built an interactive murder-mystery game with author Lemony Snicket using the ChatGPT API for character dialogue, and Germany's BILD said its Hey_ assistant has answered more than 250 million reader questions. On the business side, News Corp is building Knowledge Agents that use Model Context Protocol to query its global data lake, and the Seattle Times built a prospecting agent that cut ad-sales lead research time from hours to minutes. OpenAI also runs an OpenAI Academy for News Organizations to share these use cases and says its three-plus years of partnership with the news industry are just getting started.
💡 The examples are tied to specific workflows such as verification at AP, lead generation at the Seattle Times, and archive search at WBEZ, showing newsroom AI adoption has moved past generic chatbots into purpose-built, task-specific agents.
3 Google updates from Galaxy Unpacked 2026
Google AI
At the Galaxy Unpacked event in London, Google outlined the first Gemini Intelligence capabilities coming to Samsung's newly launched Galaxy Z Fold8 Ultra, Fold8, and Flip8. First, task automation, which entered beta in February, is expanding from a handful of apps to more than 40, letting Gemini handle everyday life admin like shopping, dinner reservations, travel bookings, and event tickets. On the Flip8 this automation can be triggered directly from the Flex Window by long-pressing the power button, and Gemini's reasoning has been upgraded to read on-screen content and interpret complex images as prompts. Second, Gemini Notebook, the renamed NotebookLM, now comes preinstalled on the new foldables, letting users on the Fold8 series' large display drag photos, documents, whiteboard images, and voice recordings into a side-by-side workspace and generate slide decks, videos, flashcards, quizzes, or podcasts, with every Galaxy Z Fold8 Ultra, Fold8, and Flip8 also shipping a six-month trial of Google AI Pro. Third, the Galaxy Watch 9 can now summon Gemini just by raising your wrist, with no wake word required. Google also revealed two new frames for the Gemini-enabled smart glasses it announced with Samsung at I/O 2026, from Gentle Monster and Warby Parker, which launch this fall and can be controlled via hand gestures using a compatible Wear OS watch.
💡 Rolling Gemini Intelligence out feature by feature tied to specific Samsung hardware launches, rather than as a blanket software update, shows Google using partner devices to pilot agentic AI UX before a wider rollout.
Advancing the next era of national science
OpenAI
OpenAI published a commitment to advancing American science in partnership with the U.S. government, National Laboratories, and universities, framing the effort as part of the Department of Energy's Genesis Mission. It will provide $4 million in Codex access to roughly 2,000 Genesis researchers at National Laboratories and universities, commit $3 million in API support to two large-scale campaigns testing frontier models against major scientific challenges, and offer participating researchers up to $10 million in API usage for every $2.5 million they spend. It will also give selected national-lab researchers on eligible biology projects access to GPT-Rosalind's specialized bioscience capabilities, grant trusted lab leaders early access to upcoming models and features, and expand trusted access to advanced cyber capabilities for national-lab cybersecurity researchers. OpenAI points to prior work as context, including an AI Jam Session where more than 1,000 scientists across nine National Laboratories tested frontier models, deployment of advanced reasoning models on the Venado supercomputer at Los Alamos National Laboratory as a shared resource for NNSA labs, and joint work with Los Alamos evaluating safe use of multimodal AI in lab settings. The post newly names two flagship campaigns, one pursuing breakthroughs in high-temperature superconductors and another building an Atlas of the Machine-Accessible Frontier mapping where AI can already meaningfully assist scientific work. It closes by describing the Genesis Mission, launched last year with DOE, its 17 National Laboratories, universities, and industry, as aiming to double the productivity and impact of American research within a decade.
💡 Published the same day as Google Cloud's $40 million pledge, this shows OpenAI and Google both courting the same DOE National Laboratories via the Genesis Mission summit, and it's worth watching how tools like Codex and GPT-Rosalind actually get embedded into public research workflows.
Cloud Updates
Building a serverless AI assistant at Pelago: concept to care in two weeks
AWS Architecture
AWS's Architecture blog details how Pelago, a digital clinic for substance use disorder treatment, built and deployed a serverless AI assistant in just two weeks. Pelago's care coaches each hold conversations with dozens of members at once, and every reply needs to reflect weeks of prior context, making manual drafting too slow to keep up. The requirements were strict: the AI could only generate suggestions for a human coach to review and adapt, not send automated replies; protected health information (PHI) could never leave Pelago's AWS VPC; and suggestions had to appear instantly when a coach opened a conversation, without a long wait for LLM processing. The solution is an event-driven serverless architecture: messages arriving through AWS AppSync are stored in DynamoDB by a Lambda function and published to an SNS topic, which fans the event out in parallel to several Lambda subscribers handling metadata storage, Amplitude analytics, push notifications, and AI suggestion generation. The Chat Assistant Lambda runs asynchronously, pulling the full conversation history from DynamoDB, calling Amazon Bedrock's Claude models to generate a contextual suggestion, and storing it in MySQL on Amazon RDS; the whole pipeline finishes in under 4 seconds, and when a coach later opens the conversation, the pre-generated suggestion loads in under 100 milliseconds. To maintain HIPAA eligibility, Bedrock calls route through VPC endpoints to avoid the public internet, data is encrypted at rest, and CloudWatch audit logs capture only message IDs, never content. After launch, average response preparation time dropped 40%, coaches rated 79.6% of AI suggestions as helpful, and the system absorbed an 8x message-volume spike during a seasonal campaign with no configuration changes.
💡 Decoupling AI generation from the message path via SNS fanout and pre-computing suggestions asynchronously so retrieval stays under 100ms is a clean pattern for hiding LLM latency from end users entirely, and routing Bedrock calls through VPC endpoints is a directly reusable blueprint for anyone building in HIPAA-regulated environments.
Building multi-Region resiliency for AWS CloudFormation custom resource deployment
AWS Architecture
AWS's Architecture Blog presented a reference architecture for making CloudFormation custom resource processing resilient across multiple AWS Regions. Custom resources let CloudFormation invoke external logic, typically a Lambda function via an SNS topic, during stack Create, Update, or Delete operations, but CloudFormation has no native multi-Region support: no fan-out mechanism, no protection against duplicate execution, no distributed locking, and no automated failover, leaving idempotency entirely up to the developer. The proposed solution is an active-active architecture with a primary Region (us-east-1) and secondary Region (us-west-2) that are both always live, where an SNS topic in each customer Region fans out events via cross-Region subscriptions to SQS queues in both infrastructure Regions simultaneously. The primary Lambda handler processes the event immediately, acquiring a lock in a DynamoDB Global Table via a conditional write, while the secondary Lambda handler, triggered after a delay, checks the same lock and either skips the event if the primary already handled it or takes over and processes it itself in a failover scenario. DynamoDB Global Tables provide strongly consistent, bidirectionally replicated lock state, idempotency records, and request state across both Regions, while CloudWatch alarms monitor SQS queue depth and Lambda health so that Amazon Application Recovery Controller (ARC) can automatically trigger failover to the secondary Region without manual intervention if the primary fails. AWS positions this pattern as suited for mission-critical, compliance-driven, or globally available workloads that cannot tolerate a single-Region point of failure for custom resource processing.
💡 Custom resource handlers are commonly built as single-Region Lambdas in practice, which becomes a hard blocker for stack operations during a Regional outage; this DynamoDB Global Table conditional-write locking pattern is a reusable reference not just for custom resources but for multi-Region failover design in other event-driven systems.
From maintenance to innovation: Checking in on Checkout.com’s Cloud Composer 3 migration
Google Cloud
Google Cloud's blog detailed how payments company Checkout.com's Data Platform team migrated a self-managed Apache Airflow deployment running on another hyperscaler to Google Cloud's fully managed Managed Service for Apache Airflow (Gen 3, also known as Cloud Composer 3). Under the old self-hosted setup, the team dealt with stability issues during high-load periods, manual and constant dependency management when upgrading packages, roughly six-minute DAG sync times after deployment to S3, and manual creation of secrets and variables every time a new team was onboarded for dbt. After migrating, moving from fixed peak-capacity worker provisioning to built-in dynamic scaling cut monthly costs by an estimated 30 percent, and DAG isolation, with each DAG running in its own execution environment, meant a single failing DAG no longer affects the whole environment. The team also gained near-instant DAG syncing via Cloud Storage, eliminated the dependency bottleneck of manually managing per-version virtual environments by containerizing dbt runs, and no longer needs to redeploy the entire environment to add roles or update Python packages. For troubleshooting, engineers can now launch a Gemini Cloud Assist investigation directly from the Airflow DAG UI, which produces a scorecard weighing supporting and contradicting evidence for different failure hypotheses to help reduce mean time to recovery. Checkout.com Data Platform Engineer Keisi Mancellari said the move to managed infrastructure, automated scaling, faster deployments, and isolated execution environments transformed how the team operates.
💡 This reconfirms that the Day 2 burden of self-hosted Airflow, patching, incident response, and manual scaling, is the main driver behind managed-orchestrator migrations, and DAG isolation plus containerized dbt runs specifically address the common multi-tenant Airflow pain point where one bad DAG destabilizes the whole shared environment.
Architecting offline-first generative AI applications for edge deployments using AWS services
AWS Architecture
AWS's Architecture Blog, citing Siemens' 2024 report The True Cost of Downtime, notes that Fortune 500 companies lose an estimated $1.4 trillion annually to unplanned downtime, and presents a reference architecture for offline-first generative AI aimed at manufacturing sites, offshore platforms, and remote agricultural facilities with unreliable cloud connectivity. The design customizes models in the cloud with Amazon Bedrock and SageMaker AI, deploys them to the edge via AWS IoT Greengrass, and orchestrates local inference with Strands Agents. Of four possible customization strategies, fine-tuning, continued pre-training, a fine-tuning-plus-RAG hybrid, and a CPT-plus-RAG-plus-fine-tuning hybrid, the reference build uses the fine-tuning-plus-RAG hybrid, fine-tuning a 21-billion-parameter gpt-oss-20b model (3.6B active parameters per token, 32 experts, 128k context) via SageMaker AI Pipelines while keeping retrieval on a CPU-only ChromaDB and sentence-transformer stack with sub-50ms latency. For edge hardware it cites an example g4dn.12xlarge instance with four NVIDIA T4 GPUs (64 GiB total) and compares two serving strategies, full model replication per GPU versus four-way tensor parallelism that frees up memory for a 128K-token KV cache, with Ollama as the on-device inference runtime. In an evaluation using 30 domain-specific question-answer pairs judged by three LLMs, Claude 4.5 Haiku, Claude 4.5 Sonnet, and Amazon Nova Pro, on a 12-point rubric, the fine-tuned model consistently outperformed the base model, for example scoring 10.20 out of 12 (85 percent) versus 8.20 (68.3 percent) under the Claude 4.5 Haiku judge. AWS notes this is a reference architecture only and recommends a full security review before any production deployment.
💡 What makes this useful in practice is the concrete hardware sizing, per-GPU memory, context length, and latency, paired with an LLM-judge evaluation of the actual quality gain from fine-tuning, giving engineers real numbers to use when budgeting edge GPU capacity and justifying a fine-tuning-plus-RAG investment.
Accelerating the frontiers of scientific discovery: Google’s $40M commitment to the Genesis Mission
Google Cloud
Google announced an expanded $40 million commitment in AI tokens and cloud credits at the 2026 U.S. Department of Energy Genesis Mission Summit to support researchers under the Genesis Mission. Genesis Mission is a White House initiative launched last November aimed at doubling the pace of American scientific discovery within a decade. Google had already pledged support last December, and Google DeepMind has been running an early-access program giving all 17 DOE National Laboratories access to its AI-for-science tools. Under the expanded commitment, Genesis Mission awardees get in-kind access to Google DeepMind's frontier science AI portfolio, including AlphaEvolve for algorithm design, AlphaFold 3 for protein structure prediction, AlphaGenome for interpreting DNA variation, WeatherNext for weather forecasting, and AlphaEarth Foundations for planetary mapping, plus one year of Gemini for Government seats and tokens for tens of thousands of users across the DOE National Laboratories. The post cites concrete examples, including PNNL scientist Dr. Henry Kvinge using AlphaEvolve to explore complex combinatorics structures, and NLR materials scientist Dr. Steven R. Spurgeon using Gemini to cut microscope calibration time from over 90 minutes to about 13 minutes while reducing manual focusing steps from as many as 50 down to two. Google says it will share further details at the Google Public Sector Summit in October.
💡 Donating in-kind access to frontier science models alongside concrete results like an 8x cut in microscope calibration time is a clear way for a cloud vendor to prove ROI and stake a claim in public-sector AI procurement.
Avoid operational drift with Red Hat Lightspeed content templates for RHEL extended environments
Red Hat
This Red Hat blog post announces that Red Hat Lightspeed's content management capabilities now extend to legacy and extended-lifecycle RHEL environments. According to author Anthony Johnson, a Product Manager for Lightspeed Content Management and Proxy, manually managing repositories or locking package versions across older, fragmented systems is time-consuming and causes operational drift, which reduces predictability, breaks compliance, and multiplies security vulnerabilities. With this update, IT teams can build custom content templates specifically for the RHEL Extended Update Support (EUS) Add-On, Update Services for SAP Solutions (E4S), and the Enhanced Extended Update Support (EEUS) Add-On. The approach centers on a unified, time-locked collection of repositories hosted on the Red Hat Hybrid Cloud Console, combining standard Red Hat repositories, including EUS, E4S, and EEUS, with an organization's own custom repositories and freezing them to a specific calendar date so that any RHEL machine bound to that template is restricted to that exact snapshot. Operationally this is framed as a three-step model: Define, selecting the exact repositories and versions allowed; Instruct, assigning RHEL systems to the template so they pull only from that validated set; and Patch, applying updates on your own schedule with confidence that a system patched today gets the same packages as one patched weeks later. The post also describes a promotion workflow where teams keep separate templates for test and production, advancing the test template's date first to validate updates before matching the production template to that same verified date. Beyond content management, Lightspeed also surfaces configuration analytics, vulnerability data, and compliance scanning across an organization's full deployment history.
💡 For teams still hand-managing repositories on older RHEL EUS, E4S, and EEUS environments, date-locked templates with a Define, Instruct, Patch model give a concrete way to promote a validated snapshot from test to production, structurally reducing the compliance risk that comes from operational drift.
Why AI apps fail in production (And how Google solved it)
Google Cloud
This Google Cloud blog post, by Stephanie Wong (Global Lead, Developer Programs), argues that while agentic engineering and LLMs have cut the time from a blank IDE to a working local app from quarters to hours, only about 5% of AI prototypes actually reach production in an enterprise setting, with the rest falling into what the post calls a validation abyss. To understand this speed-versus-risk paradox, Wong looked at how YouTube's engineering team handles it, material that also appears in the premiere episode of a new show called Emergent. AI engineering leader Addy Osmani describes running ten parallel coding agents on a personal project and breaking two apps because the changes weren't properly isolated, illustrating why an operation like YouTube, a 20-year-old codebase serving billions of users that is effectively public infrastructure, historically needed slow, extensive guardrails that couldn't tolerate that kind of risk; the catch was that by the time an idea cleared those guardrails, the underlying AI models had already moved on. Former YouTube engineer and current DeepMind's Benji Bear addressed this not by speeding up reviews but by restructuring the infrastructure: developers prototype using Google AI Studio templates that connect through a Google Cloud proxy server to read-only, pre-authenticated access to real metadata such as playlists, videos, and channels, with no ability to write back to or crash core databases, and separately can inject experimental features into YouTube's actual live web surface via client-side YouTube Extension wrappers that stay isolated from production binaries through code-split chunks, deployable to safe staging in minutes. As a result, YouTube says it cut prototype validation from multiple quarters to weeks, shipping prototypes such as YouTube Recap and Ask YouTube into user research studies. The post closes with a philosophy of deliberately embracing throw-away code, treating a 95% failure rate as the strategy rather than a bug, and argues engineers' roles are shifting from syntax gatekeepers to system architects who design the sandboxes and guardrails that make fast, frequent failure safe.
💡 The number worth remembering is not the 5 percent statistic itself but the design principle behind it, giving prototypes read-only access to real production data and isolating experimental code via code-splitting so failure is safe by construction, which applies to any team bolting AI prototypes onto a legacy production system, not just YouTube-scale services.
DevOps & Infrastructure
Copilot vs. raw API access: What are you actually paying for?
GitHub
GitHub's engineering blog published a piece titled 'Copilot vs. raw API access: What are you actually paying for?' explaining the difference between paying for a Copilot subscription and calling model APIs directly. Its central argument is that Copilot isn't charging for the model call itself but for the development workflow wrapped around it, the connections between an issue, the repository, a terminal, a pull request, and an organization's policies. Under a recent billing change, Copilot now meters usage through GitHub AI Credits at the same rates as listed API pricing, while code completions and Next Edit Suggestions remain included in paid plans and credits are consumed only by heavier chat and agentic work. Organization plans can pool AI Credits, letting admins set budgets and track usage centrally in a billing dashboard instead of scattering spend across individual API keys. The post cites GitHub's own evaluation showing that, with model, context window, tool selection, and MCP servers held constant, Copilot CLI matched task-resolution rates of vendor-specific harnesses on SWE-bench Verified, SWE-bench Pro, SkillsBench, TerminalBench, and Win-Hill while using fewer tokens in most configurations. It also describes Bring Your Own Key (BYOK), currently in public preview, which lets developers use 20-plus supported models, including Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, and OpenAI, inside Copilot Chat, CLI, and VS Code while billing flows through their own provider contract instead of GitHub. The overall guidance is to choose raw API access when building and owning a custom system, and to choose Copilot when the work is software development inside the tools and repositories a team already uses.
💡 The real decision isn't Copilot versus API price but whether to build and maintain your own harness for context retrieval, retries, and policy enforcement or adopt a pre-benchmarked one, and BYOK means teams with existing model contracts can keep that billing relationship while still using Copilot's workflow tooling.
Kimi K3: White House alleges Fable 5 siphoning
The New Stack
Michael Kratsios, the White House's top technology official, posted on X on Wednesday accusing Chinese AI startup Moonshot of using deceptive methods to extract data from Anthropic's frontier Fable 5 model and using it to train Moonshot's newly released Kimi K3. Kratsios said Moonshot built a purpose-built platform that cycled through multiple access methods to avoid detection while conducting large-scale distillation of Fable 5, calling it unacceptable covert industrial distillation aimed at stealing U.S. technology, and separately alleged Moonshot had acquired and deployed servers with Nvidia GB300 chips in Thailand, likely to train its models. The allegations have not yet been backed by publicly verifiable evidence, and Moonshot, Anthropic, and the White House's Office of Science and Technology Policy did not immediately respond to requests for comment. For context, model distillation, training a smaller, cheaper model on a larger frontier model's outputs, is itself a common and accepted technique; the dispute here is over the alleged deceptive method of access, not the practice itself. This follows Anthropic's own public accusation in February that Moonshot, DeepSeek, and MiniMax ran coordinated distillation campaigns against Claude, attributing more than 16 million exchanges across roughly 24,000 fraudulent accounts to the three, with 3.4 million of those tied to Moonshot alone. Kimi K3, released July 16 as a 2.8-trillion-parameter model billed as the largest open-weight AI system with performance Moonshot claims approaches Fable 5, launched about five weeks after a U.S. export-control directive forced Anthropic to temporarily suspend access to Fable 5 and Mythos 5 over national security concerns. The episode signals the administration could pursue tougher measures, including tighter API access restrictions and expanded export controls targeting remote cloud compute rented in third countries like Thailand.
💡 The framing matters: this is being cast as covert, ToS-evading distillation at industrial scale rather than distillation itself, which raises the odds of tighter API rate limits and export controls on remote GPU rentals in third countries, a trend worth watching for any team building on frontier-model APIs.
Agents keep changing their answers. Harness just built delivery pipelines that don’t care.
The New Stack
Software delivery lifecycle company Harness this week launched an AI Agent DLC (Development Lifecycle) service that puts AI agents through the same pipelines, governance, testing, and security controls already used for application code. Citing the 2026 Gartner CIO and Technology Executive Survey finding that only 17% of organizations have deployed AI agents so far, Harness SVP and GM Trevor Stuart says getting an agent to work in a demo is easy, but knowing it will behave correctly in production is a different problem, since the larger and more dynamic attack surface leaves companies keeping agents stuck in pre-production sandboxes, technically a success but practically useless. Unlike deterministic application code, an agent's underlying model can choose a different tool or action for the same input on different runs, so tests aren't reliably reproducible and the standard bug-catching playbook doesn't transfer. Harness's fix is to stop trying to make the agent itself predictable and instead make the pipeline around it predictable, grading responses on correctness, safety, and performance with eval scores wired in as pass or fail quality gates, the same way CI already checks whether tests passed. The launch bundles five new capabilities: Harness AI Evals for measurable agent quality gates; Agent deployments, which extend Harness's existing canary releases, approvals, and OPA guardrails to managed agent runtimes; AI configs for managing prompt and model changes at runtime; an AI asset catalog that auto-discovers every agent, skill, and plugin across an org's repositories and ties each to an owner; and AgentTrace, which records the path an agent took and where it slowed down across a run, with its underlying components, harness-sdk and harness-evals, being open-sourced. Harness also cites its own 2026 State of Engineering Excellence report showing that 31% of a developer's day goes to AI-related work invisible to any metric, and that 94% of engineering leaders admit tech debt, validation time, and burnout go untracked.
💡 Rather than trying to eliminate agent non-determinism, wiring execution traces and eval gates directly into existing CI/CD pipelines is a pragmatic middle ground, and it confirms that what's actually blocking agents from production is governance and reproducibility, not model capability.
OpenAI built support agents for its own customer service line, now it hopes big enterprises will trust them too
The New Stack
OpenAI unveiled Presence on Wednesday, a product that brings the same AI agents it already runs on its own customer support line to enterprise phone and chat channels. In its announcement, the company argues that the bottleneck for enterprise AI agents is no longer whether they can do the job, but whether they stay reliable as products, policies, and user behavior keep changing around them. Presence bundles the agent itself with everything needed to run it in production: OpenAI builds and deploys the agent for each customer, policy changes are tested through simulation against batches of past cases before rollout, and a live dashboard tracks response accuracy, call volume, and how specific tasks like refunds or cancellations are being handled. Each customer assigns the agent a single, specific job, such as an insurance claim, an IT request, or a billing dispute; the agent only gets the systems and data tied to that job, and it is the customer, not OpenAI, who sets the rules for what needs human sign-off and when to hand off to a person. OpenAI says its own agent already resolves 75% of inbound issues on its English-language phone support line without human involvement, a claim it is using as part of its pitch to early design partners including BBVA, SoftBank, and IAG (Insurance Australia Group). The product isn't self-serve yet; it is in a restricted rollout limited to eligible enterprise customers, with deployments handled directly by OpenAI's forward deployed engineers (FDEs) and a small number of global systems integrators. The launch lands a month after OpenAI, Google, and Microsoft founded the Appia Foundation to standardize AI trust and compliance claims, and comes amid a broader industry rush into forward-deployed engineering, with OpenAI having launched a separate $4 billion company built around staffing enterprises with FDEs, while Google and AWS have both announced major investments in similar embedded-engineer teams.
💡 The substance of Presence is the operational layer around the model, policy simulation before rollout, narrow single-task scoping, explicit human-handoff boundaries, and audit dashboards, and the pattern of proving it internally first before selling it, paired with FDEs embedded per deployment, is a template worth watching for anyone evaluating whether to put an agent in front of real customers.
Next chapter: Restructuring GitHub’s bug bounty program
GitHub
GitHub announced a significant restructuring of its bug bounty program, shifting incentives from report volume to verified quality in response to a growing backlog driven by a surge of new researchers and an influx of low-effort, AI-generated submissions. The centerpiece is a new permanent, invite-only VIP program for researchers who meet at least one of the following thresholds: one critical finding, two high findings, four medium findings, or seven low findings; VIP researchers get higher payouts (Low $1,000 / Medium $7,500 / High $20,000 / Critical $30,000+), faster responses, and closer collaboration with GitHub's security team. The public program moves from payout ranges to a static bounty table with generally lower payouts (Low $250 / Medium $2,000 / High $5,000 / Critical $10,000). GitHub is also adding a HackerOne signal requirement to the public program, capping submissions at an initial allowance of up to four for researchers who have not yet built a quality track record, to cut down on low-effort and AI-generated reports. The new structure takes effect for reports submitted on or after July 27, 2026, while reports filed before that date will be honored under the prior payout structure, and GitHub says its commitment to fast payouts and clear communication is unchanged, with plans to deepen researcher engagement through events like DEFCON.
💡 The overhaul is a concrete signal that AI-generated, low-quality vulnerability reports are becoming an operational burden on bug bounty programs, and GitHub's reward-proven-quality-over-volume model (VIP tiering plus signal thresholds) is likely to be watched as a template by other companies running similar programs.
Cost attribution in Grafana Cloud: Manage spend across observability and testing workflows
Grafana
Grafana announced that Grafana Cloud's cost attribution feature, part of its Cost Management and Billing tooling, now extends beyond observability data into testing workflows. Previously available only for metrics, logs, and traces, cost attribution now also covers Grafana Cloud Synthetic Monitoring and the Grafana Cloud k6 performance-testing platform. The mechanism is label-based: users configure up to two labels, such as team or env, and Grafana Cloud calculates usage and cost for every unique combination of those label values, supporting up to 1,000 unique combinations. Attribution is forward-looking only, starting from the moment it is configured rather than applying retroactively, and telemetry lacking the configured labels shows up as unattributed usage. For Synthetic Monitoring, cost is attributed based on check executions using existing custom labels; for k6, it is based on Virtual User Hour (VUH) consumption per test run, with labels managed via the UI, Terraform, or the REST API. Grafana said it is also building usage attribution for Grafana Assistant, its AI agent, to show token consumption broken down by user, and the overall feature, aimed at centralized observability teams, engineering teams, and FinOps practitioners, is available now to Grafana Cloud customers.
💡 Because attribution is not retroactive, teams that want chargeback or showback need to standardize labels and turn this on before costs accrue, not after the fact; extending label-based attribution to k6 load-testing spend, not just observability data, also broadens what FinOps teams now need to track.
Embracing the Code Review Bottleneck
Honeycomb
A Honeycomb engineer who moved from the SRE team to the newly formed Tenant team, which builds the company's Private Cloud offering, wrote about how the team handled a growing code review bottleneck. As AI tools let the team generate code faster than they could review it, most of their work turned into an endless stream of code reviews, and subtler problems emerged too: reviewers in overlapping time zones moved faster together, some people got stuck permanently as reviewers and others as producers, and knowledge became concentrated in ways that caused over-specialization. Rather than following the industry's usual advice to reduce the review bottleneck, the team deliberately chose the counterintuitive option of leaning into it, reviewing not just the generated code but the plan and prompt given to the AI. They built a Claude skill covering four phases, plan, review, implement, and finish, to standardize the feedback process, and the author, self-described as one of Honeycomb's more AI-skeptical engineers, framed the choice around Donella Meadows' idea that in complex systems the counterintuitive direction is often the real leverage point. The outcome was that team velocity held steady rather than dropping, shared awareness of the system and cross-team knowledge grew because everyone had to review and commit to plans, and plans from similar past tasks could be reused for new ones. The team has since relaxed the practice rather than applying it strictly to every task, with simpler tickets getting lighter review, and the author notes other teams at Honeycomb have independently arrived at similar conclusions.
💡 As AI-generated code outpaces reviewer bandwidth, this is a concrete data point that deliberately reviewing the plan and prompt, not just the diff, can preserve shared system knowledge while keeping velocity steady, worth considering for teams tempted to simply automate review away.
One service, many doors: Multi-port services in Consul
HashiCorp
This HashiCorp blog post introduces native multi-port service support, added in Consul 1.22. Previously, one application exposing several ports, such as a user-facing API, an admin endpoint, and a metrics endpoint, had to be registered as multiple separate Consul services (for example order-http, order-admin, order-metrics), which split health checks, policies and intentions, and dashboards across multiple names and made Kubernetes services line up awkwardly with the Consul catalog. Now a single service block can declare a list of named ports, such as http, admin, and metrics, with one marked as default, so the service keeps one identity while still being queryable per port through both DNS (SRV records by port name, returning NXDOMAIN for unknown names) and the HTTP API, which stays backward compatible by keeping ServicePort while adding a full ServicePorts list for port-aware clients. When Consul syncs Kubernetes services, it preserves the existing named ports directly in the catalog, lets operators override the default port via an annotation, and syncs externally reachable nodePort values for NodePort services. On the mesh side, a beta multi-port service mesh feature lets a single sidecar handle multiple destination ports: the calling sidecar carries the destination port name in the TLS handshake via ALPN, and the receiving sidecar routes to the matching local port, supporting both explicit upstreams and transparent-proxy virtual DNS names. Health checks and tagged addresses still operate at the service-instance and default-port level rather than per port, and native multi-port routing across cluster peering connections is still in development, so peered traffic currently falls back to default-port behavior.
💡 Teams that have been registering one Consul service per port now have a concrete reason to consolidate onto Consul 1.22's native multi-port model, but should check two limits before migrating: health checks still apply at the service-instance level, not per port, and cluster-peered traffic still falls back to the default port until native multi-port mesh routing across peers ships.
Modernize Java with Cursor and GitLab
GitLab
This GitLab tutorial, written by Michael Friedrich, starts from the observation that modernizing Java 8 to Java 21 is not one task, since it touches build, runtime, dependencies, APIs, concurrency, tests, containers, and production behavior all at once, and walks through three exercises combining the Cursor AI coding agent with GitLab Duo Agent Platform. The example project is a Java HTTP metrics collector from the Tanuki IoT Platform that checks HTTP endpoints and sends metrics to a Rust backend. The first exercise has Cursor diagnose and fix a failing end-to-end test, a bug where every 2xx response was treated as success and a configured 503 always failed, then open a branch and merge request that goes through GitLab Duo Code Review, CI/CD, and security scanning under the same standard as any other MR. The second exercise connects Cursor to a GitLab MCP server so it can pull in issues, epics, pipeline history, and security findings from a Java modernization epic, while respecting the user's existing GitLab permissions, and uses that context to set up CI quality gates that test Java 8 and Java 21 in parallel. The third exercise replaces the legacy HttpURLConnection API with Java 21's java.net.http.HttpClient in one bounded work item, since redirects, restricted headers, timeouts, and connection reuse behave differently between the two, verifying the change locally and against the Rust backend via Docker Compose. The post also recommends codifying repository conventions in an AGENTS.md file, defining Java-specific review rules in .gitlab/duo/mr-review-instructions.yaml, and packaging proven workflows into reusable agentic skills. Its conclusion is that Cursor handles implementation while GitLab supplies the evidence, CI/CD, review, impact analysis, and traceability, that lets an agent-authored merge request be trusted to the same standard as any other.
💡 The practical takeaway is not Cursor-specific: bounding AI-agent work to one failing test, one quality gate, or one API swap at a time, and gating each step through existing CI/CD, code review, and impact-analysis processes, is a governance pattern any team adopting an AI coding agent can reuse.
This digest was collected from RSS feeds and summarized by AI (Claude). See the original links for full details.