π₯ Top Story
Meta lets Claude and Codex configure WhatsApp Business via MCP
Meta has launched a WhatsApp Business Tools MCP server that lets AI coding agents like Claude, Codex, Cursor, and ChatGPT set up and manage WhatsApp Business messaging for a company. Previously, developers had to jump between Meta's Developer Console, Business Manager, API docs, and their code editor to create an account, verify a phone number, and register for the Cloud API; now an agent can handle that setup from a natural-language description. Agents can also write and edit message templates, and test webhooks and sample messages, catching problems with Terms of Service, payment methods, or Business Verification that previously failed silently. It can be paired with Meta's existing Social Technologies MCP to discover API endpoints, search documentation, and troubleshoot errors. The MCP connection does not remove Meta's underlying requirements, though: account verification, business checks, payment details, and acceptance of terms still require human involvement. The article also notes that agents are not given their own identity for WhatsApp Business operations.
π‘ Why it matters: An MCP server that automates onboarding cuts setup time, but the fact that payment and business verification still require a human, and that agents have no identity of their own, means DevOps teams must design audit trails and accountability around those gaps rather than assume full automation.
π Read more Β· The New Stack
Kubernetes & Cloud Native
What I learned organizing KCD Lima 2026
CNCF
The third edition of Kubernetes Community Days (KCD) Lima was held on July 18, 2026, at the UTEC Barranco campus in Lima, Peru, drawing over 900 attendees out of more than 2,200 registrants. The event featured 60 speakers across 54 sessions in five simultaneous spaces: Auditorio Principal, Aula Magna, UTEC Ventures, Garage Concept Lab, and room 705 dedicated to workshops. Co-organizer Ronald Requena, CTO at Rumbo and a professor at Universidad Ricardo Palma, became a CNCF Ambassador for Peru as of August 2026. The organizers report having already sent the Transparency Report to the CNCF and thanked sponsors, noting that returning sponsors came back this year and new ones joined. International speakers said yes to the invitation because they already knew of KCD Lima from prior editions. The organizers frame the event as strengthening the cloud native, Kubernetes, DevOps, and open source ecosystem in Peru while building a bridge between academia and the tech community.
π‘ A regional KCD scaling to 900+ attendees and 54 sessions for a third consecutive year, with returning sponsors and repeat international speakers, is a useful leading indicator for DevOps engineers gauging how mature a local cloud native ecosystem has become for hiring or community engagement.
Kubernetes Changed Block Tracking API - Beta Differences
Kubernetes
Changed Block Tracking (CBT) support for CSI drivers first shipped as Alpha in September 2025, and this post walks through what changed as it graduated to Beta with the March 2026 v1.0.0 release of the external-snapshot-metadata project. The headline change is that the SnapshotMetadataService custom resource was promoted from v1alpha1 to v1beta1. CBT is built from three core pieces β the CSI SnapshotMetadata gRPC service, the SnapshotMetadataService CRD, and the external-snapshot-metadata sidecar β and the post revisits how to use the API under these updated names and versions. It also states a clear scope limitation: CBT currently applies only to block volumes, while change-list tracking for file volumes and network file shares is not covered. The post was authored by Prasad Ghangal of Veeam Kasten and published on September 14, 2026, as part of the Kubernetes blog's ongoing coverage of storage-related feature graduations.
π‘ Since backup vendors like Veeam build incremental-backup pipelines directly against this CRD, teams upgrading CSI drivers or backup tooling should check CBT API version compatibility (v1alpha1 vs v1beta1) before assuming block-volume incremental snapshots will keep working.
Kubernetes v1.37: Memory QoS Graduates to Beta
Kubernetes
Memory QoS has graduated to Beta in Kubernetes v1.37 and is now enabled by default. On Linux nodes running cgroup v2, it uses the kernel's memory controller to give better guidance on how container memory should be treated, with a history dating back to Alpha in v1.22 and tiered memory reservation added in v1.36. As of v1.37, the MemoryQoS feature gate is Beta, meaning every v1.37 kubelet has it turned on without any configuration change. A key upgrade note: the default for memoryThrottlingFactor changed from 0.9 to null, so memory.high is no longer set automatically unless an operator explicitly configures it β a deliberate move to preserve backward compatibility with existing workloads. Cluster operators can opt into memory throttling, tiered memory reservation via memoryReservationPolicy, both together, or disable the feature entirely, each via specific kubelet configuration. A known limitation is that memoryReservationPolicy applies node-wide rather than per-pod, and hard reservations count page cache usage against the container's cgroup.
π‘ Because the memoryThrottlingFactor default flipped from 0.9 to null, teams relying on the old automatic memory.high throttling behavior need to explicitly re-enable it in kubelet config after upgrading to v1.37, or memory pressure handling will silently change.
Cilium 1.20: Gateway API ExternalAuth, TCPRoute/UDPRoute, ENI IPAM for IPv6, and more
CNCF
Cilium 1.20, the second major open-source Cilium release of 2026, bumps Gateway API support from v1.4 to v1.6 and adds ExternalAuth, CORS filters, and ListenerSets. New TCPRoute and UDPRoute support means non-HTTP L4 services β databases, DNS servers, game servers, and similar β can now be managed through the same Gateway API model previously reserved for HTTP and gRPC traffic. The ExternalAuth capability implements the Gateway API ExternalAuth filter from GEP-1494, letting HTTPRoute requests be authenticated and authorized by an external service before they ever reach the application. IPv6 gets ENI IPAM support on AWS: building on the earlier move to a multi-pool allocator, the operator now attaches an IPv6 /80 prefix to each node's ENI via AWS Prefix Delegation, and the Cilium agent assigns pod addresses out of that range. The release also adds automatic netkit/veth datapath selection for fleets running mixed kernel versions, plus a new datapath plugin system that lets cloud providers extend Cilium's eBPF datapath without forking the project.
π‘ With TCPRoute/UDPRoute and ExternalAuth, platform teams can now consolidate routing and authn/authz policy for non-HTTP services (databases, DNS, game servers) under the same Gateway API resources used for HTTP, so upgrading to Cilium 1.20 is worth evaluating as a chance to de-fragment ingress and mesh policy.
AI & ML
Bypassing inference bottlenecks: Accelerating complex AI search with Retrieve-for-Train
Google Research
Google Research introduced Retrieve-for-Train (R4T), a framework that moves the expensive query fan-out decomposition step in complex AI search from inference time to training time. Standard approaches generate hundreds of intermediate chain-of-thought tokens to plan search terms, which is tolerable for conversational AI but becomes a severe structural bottleneck for set-valued search, the post explains. R4T uses offline reinforcement learning once to discover reward-aligned fan-out patterns, compiles them into supervision data, and distills that optimized exploration behavior into a lightweight diffusion retriever that produces the full fan-out in a single pass at inference time. The approach delivers a 12-20x speedup, cutting fan-out latency from nearly 50 seconds down to sub-second range. A diffusion retriever with just 53.9 million parameters replaces autoregressive LLMs, generating the entire result set in one parallel pass instead of token-by-token generation. The work was presented at ICML 2026 under the title "Efficient, Property-Aligned Fan-Out Retrieval via RL-Compiled Diffusion."
π‘ Shifting inference-time chain-of-thought reasoning into a one-time offline RL training step and distilling the result into a small diffusion model is a concrete infrastructure pattern for cutting both GPU serving cost and p99 latency in latency-sensitive search and retrieval workloads.
Your Agent Aced the Task. Will It Do It Again?
Hugging Face
IBM Research published consistency guidelines under the ALTK-Evolve framework to address the reliability gap where an AI agent succeeds on average but fails inconsistently across repeated runs of the same task. On the AppWorld test_normal benchmark, a GPT-4.1-based ReAct agent succeeds 77.4% of the time on average, but only 53.0% of tasks succeed on all 5 repeated runs (a metric the post calls Pass^5) -- a concrete gap the article uses to frame the problem. To diagnose this, IBM introduces a tool called the Consistency Analyzer, which replays a single recorded trajectory through controlled resampling to measure how much the model's output actually varies at each decision step, identifying flip-prone steps without needing ground truth. Incorporating the resulting consistency guidelines into the ALTK-Evolve long-term episodic memory framework halves the consistency gap on the AppWorld benchmark, raising the GPT-4.1 ReAct agent's Pass^5 score from 53.0% to 69.0%. ALTK-Evolve itself is described as a memory system that lets agents improve over time by learning from guidelines generated out of their own previous executions.
π‘ Deploying an agent based only on average success rate misses the kind of repeat-run reliability gap this post quantifies (77% average vs. 53% Pass^5), which argues for tracking repeated-run consistency, not single-run success rate, as the SLO that actually matters in production.
AI for Societal Impact
Google AI
Google published an "AI for Societal Impact" collection showcasing how experts and local leaders are applying recent AI breakthroughs to make sure the opportunity of AI is shared broadly. Google frames its partnership work around key areas: making disease detectable, treatable, and preventable, predicting natural disasters, expanding access to learning, and unlocking economic opportunities for more people, done in collaboration with communities and researchers. Over the past decade, the post argues, AI has steadily moved from theoretical research toward measurable real-world impact, and is now reshaping how humanity approaches complex challenges. The featured projects are described as collaborative, pairing local leaders and researchers to tailor AI solutions to community-specific needs rather than applying one-size-fits-all models. The collection was published in the innovation and AI section of the Google blog on September 15, 2026.
π‘ Social-impact AI projects co-designed with local leaders imply models must be served across highly varied regional infrastructure and connectivity constraints, which for cloud engineers signals growing demand for low-bandwidth and edge deployment patterns rather than centralized cloud-only serving.
Building AI to accelerate science and improve lives
Google AI
In a post rounding up AI applications aimed at accelerating science and improving lives, Google states its AI technologies now support more than 300 languages spoken by 7 billion people, representing 86% of the global population. It also released new interactive insights via its AI & Economy ATLAS, giving a look at how people around the world are actually using AI. On the science side, Google highlights mapping all 9 billion possible single-letter genetic changes across the human genome with the AlphaGenome Atlas and making it openly available to researchers. The post also says Google has scaled AI research to help cut the climate impact of aviation, work already being applied in the U.K. and parts of Asia. Google reiterates its focus areas as making disease detectable, treatable, and preventable, predicting natural disasters, expanding learning, and unlocking economic opportunities for more people; the post was published September 15, 2026.
π‘ Releasing genome-scale AI datasets like a 9-billion-variant atlas is a leading signal for the storage and compute scale research institutions and biotech workloads will soon demand, so cloud teams should get ahead of designing large public-dataset serving and access-control patterns.
AI for everyone in every language
Google AI
Google described its effort to help people communicate in hundreds of languages using AI, including many languages that have historically been left out of mainstream technology. Gemini 3.5 Live Translate powers real-time spoken translation across 70 languages and more than 2,000 language pairs, naturally capturing code-switching and emotional cues as they occur in conversation. Google frames the work as moving beyond traditional text translation toward models that understand the world's living languages as they are actually spoken, with a stated goal of supporting the 1,000 most-spoken languages globally. To get there, the post says Google is training AI to understand emotion, tone, and everyday slang rather than just literal text, and is working with local communities to ensure the tools function even without reliable internet access. Google also introduced TranslateGemma, a new collection of open translation models built on Gemma 3 that supports communication across 55 languages regardless of a person's location or device.
π‘ Open translation models like TranslateGemma built on Gemma 3 give platform teams a self-hostable, on-device or edge option for low-latency translation pipelines instead of routing every request through an always-on cloud translation API.
How Fyxer built an AI executive assistant people trust
OpenAI
OpenAI's customer story covers how AI assistant startup Fyxer built an executive assistant that users actually trust. Fyxer combines OpenAI models, fine-tuning, memory, and real user feedback to triage inboxes and draft emails in each user's own voice, following work as it moves across different tools. Instead of one large text-generation model, the system splits the work across 30 to 50 specialized models handling classification, intent prediction, memory retrieval, and draft generation, trained on more than 500,000 hours of executive-assistant workflow data. The reported results are specific: 53% of AI-generated drafts are accepted as-written, 90-day user retention sits at 90%, and annual recurring revenue grew from $1 million to $32 million over 2025. Fyxer says it's now working toward a deeper understanding of relationships, preferences, and ongoing work threads so the assistant can eventually manage more of a user's communication and coordination workload beyond just drafting replies.
π‘ Splitting a single assistant into 30-50 task-specialized models (classification, intent, memory retrieval, drafting) instead of one monolithic LLM call is a concrete pattern for cutting latency and cost while letting each component be independently improved from user feedback.
Cloud Updates
Introducing new session management tools with native, granular controls
Google Cloud
Google Cloud has overhauled session management as a deeply integrated part of Context-Aware Access (CAA), moving from broad policies tied to Organizational Units toward granular, automation-first controls. Session controls can now be managed programmatically through Terraform, the gcloud CLI, and REST APIs, folding them into DevSecOps workflows and removing reliance on manual UI configuration (GA). Policies can now target specific Google Groups instead of OUs -- for example, applying 2-hour sessions to privileged users like billing admins and project owners while keeping standard 16-hour sessions for general developers, independent of the org hierarchy (GA). Precision application-level controls let admins scope session policies to the Google Cloud Console, the gcloud CLI, or specific OAuth applications individually (GA), preventing overly strict policies from breaking legitimate integrations such as BI dashboarding tools. A native Google Cloud Console experience inside Access Context Manager (ACM) is now in preview, replacing the old requirement to configure session settings through the Google Workspace admin console. The new default session length is 16 hours, rolled out globally to all customers, aimed at mitigating credential theft and account takeover risk.
π‘ With session policies now Terraform/API-managed and scoped by group or application instead of OU, security teams can bake least-privilege session TTLs -- short sessions for privileged accounts, longer ones for everyday devs -- directly into their IaC pipeline instead of managing them out-of-band.
Best practices for handling cloud reliability incidents
Google Cloud
Google Cloud outlined a five-step framework for handling cloud reliability incidents -- Verify, Investigate, Report, Resolve, and Review -- preceded by a Prepare phase covering pre-incident readiness. The Prepare phase recommends automated response actions such as load balancers shifting traffic away from slow instances, using observability tools like Cloud Logging, Cloud Trace, and Cloud Monitoring, documenting a playbook with clear roles and communication procedures, and running simulated incident drills multiple times a year. For Verify, the post points to Personalized Service Health (which distinguishes Emerging from Confirmed incidents and is scoped to a customer's own projects and regions), Gemini Cloud Assist for natural-language queries, and the public Cloud Service Health Dashboard. The Investigate phase advises checking Cloud Monitoring for spikes in 5xx errors and latency, using Log Explorer to find specific errors like DEADLINE_EXCEEDED or SERVICE_UNAVAILABLE, and rolling back to the last known-good configuration if symptoms appeared right after a change. For Report, the post defines P1 (critical, production unusable with no workaround) and P2 (high, significant degradation with a possible workaround) priorities, and lists what a support case should include: project ID, timestamped details with timezone, error messages, blast radius, and quantified business impact, noting Premium/Enhanced support customers can use an Escalate button for P1 cases. Resolve recommends transparent stakeholder communication, failover to multi-regional architecture, and checking the Service Health Dashboard for posted workarounds, while Review calls for a blameless post-mortem and reviewing Google's own published incident reports to refine disaster recovery plans.
π‘ Pre-configuring Personalized Service Health and Gemini Cloud Assist ahead of an incident materially shortens the early triage time spent determining whether an outage is Google's fault or your own configuration, which directly moves the needle on MTTR.
Agent Substrate brings high-density, scalable, trusted infrastructure to GKE
Google Cloud
Google Cloud announced general availability of Agent Substrate, an open-source, secure-by-default agent execution runtime, on GKE. It runs millions of sandboxes on a single cluster with 10x higher density than standard container runtimes, packing more than 1,000 dormant agents per host. On performance, suspended agents resume in under 500 milliseconds, the system handles 500+ suspend/resume activations per second, and activated agents are dispatched onto pre-warmed workers with millisecond latency. Security is enforced at the kernel and network level by default, using hardware-isolated Cloud Hypervisor microVMs alongside lower-overhead gVisor sandboxes, with an integrated gateway managing egress/ingress under fine-grained network policies and credentials injected outside the agent's reach to prevent host escape and credential theft. GKE-specific integration includes custom ComputeClasses spanning spot and on-demand machine pools, support for Google's Arm-based Axion processors delivering 30% better price-performance for sandbox workloads, and Filestore agent volumes that attach and detach NFS mounts in milliseconds with Read-Write-Many (RWX) access for multi-agent collaboration. Nous Research, an early design partner, built Hermes Agent on top of it -- ranked the #1 AI agent globally by OpenRouter usage -- and other agents including Antigravity, Claude Code, Codex, and OpenClaw also run on Agent Substrate. The runtime is open source and works on any Kubernetes infrastructure; non-production workloads are available to all GKE customers now, while GA production support is available via allowlist.
π‘ The combination of microVM/gVisor isolation, 500+ suspend/resume operations per second, and millions-of-sandboxes-per-cluster density gives platform teams a concrete reference point for safely packing multi-tenant agent workloads without wasting compute on idle sandboxes, making Agent Substrate worth evaluating as a baseline for any team building its own agent execution platform.
Have it both ways: stay discoverable in search while disallowing AI training
Cloudflare
Cloudflare introduced a new Accountable designation for crawlers along with a Disallow AI Training setting that lets any website refuse AI training while remaining fully visible in search. To earn the Accountable designation, an operator must provide a way to opt out of AI training, permit opting out of AI-generated search summaries, offer URL-level visibility into how content is used, and publicly confirm that declining training does not affect a site's traditional search ranking. Apple, Google, and Microsoft are now labeled Accountable, having either met these criteria or given specific timelines to meet them. The hardest part of the problem, per Cloudflare, was mixed-use crawlers -- a single crawler that does both search indexing and AI training; for Accountable mixed-use crawlers, the search function stays allowed while every other training-only crawler is blocked, including the training-only crawlers operated by Amazon, Anthropic, Meta, and OpenAI. The new controls and recommended settings let publishers and businesses independently manage how their content is used across search, AI training, and AI agents.
π‘ Splitting out mixed-use crawlers that previously did search and AI training under one user-agent string means site operators need to audit and rewrite robots.txt and edge/WAF rules to distinguish crawler purpose rather than blocking or allowing by user-agent alone.
Give every teammate and agent the right level of access to your Workers
Cloudflare
Cloudflare shipped granular access controls that let teams grant access to specific Workers with a choice of four roles, effective September 15, 2026. The roles are Metadata Read-Only (view settings, metrics, logs, and traces without access to Worker code or the ability to make changes), Content Read-Only (read Worker code, settings, and observability data without modifying or deploying), Editor (update and deploy a Worker without the ability to delete it), and Admin (everything in Editor plus delete). For human teammates, admins create a permission policy under Manage Account > Members, scope it to individual Workers, and assign a role; for agents or CI/CD workflows, an account-owned API token is created under Account API Tokens, scoped to specified Workers with a chosen role. When several people on the same team need identical access, the permission policy can be assigned to a User Group instead of each member individually, so anyone added to the group automatically inherits it. Worker-level access controls are available today for all customers via the dashboard, the API, and Terraform.
π‘ Being able to scope CI/CD tokens and AI agents to a single Worker with a specific role, instead of handing out account-wide API tokens, lets platform teams enforce least privilege in deploy pipelines and contains the blast radius of a leaked token to one Worker instead of the whole account.
The datacenter myth: Why sovereign AI demands a tenancy model, not just geography
Red Hat
Red Hat argues that much of the "digital sovereignty" conversation stops at geography β put servers in-country, keep data inside the border β and that this checkbox approach is no longer sufficient as regulators shift from a "trust us" posture to a "show us" one, especially for AI workloads. Its position is that sovereign AI requires a tenancy model: logical, cryptographic, and operational isolation between different customers even when they share the same physical infrastructure, not just a location guarantee. To operationalize this, the post describes "landing zones" built on Red Hat Enterprise Linux, OpenShift, and Ansible β pre-configured, automated enclaves meant to provide technical proof of jurisdictional control by enforcing operational guardrails at launch time. It also references Kubernetes-based placement policies as a mechanism to keep sensitive AI workloads pinned to specific geographic or regulatory zones. This is framed within Red Hat's broader sovereign AI push, which includes regionalized operations and preconfigured deployment frameworks intended to simplify compliant AI rollouts for governments and regulated enterprises. The overall message is that sovereignty can't be achieved through superficial geographic mirroring alone β it requires rethinking how data, personnel, and access protocols interact.
π‘ For platform teams, this means sovereignty controls need to be engineered into deployment automation and tenancy boundaries (landing zones, placement policies) up front, not bolted on as a data-residency checkbox after the fact.
Opening the black box: Profiling a secured agentic pipeline on Red Hat OpenShift AI
Red Hat
This Red Hat post examines two questions enterprises face as they move to autonomous agentic pipelines: can security be added to agents without killing performance, and where should optimization effort be focused for the biggest payoff? The core message is that a code-execution sandbox for agents can be provisioned securely and auditably while its latency overhead is still measured and optimized, rather than security and performance being framed as a strict trade-off. The authors argue observability is what turns an agent from a black box into an auditable system β without fine-grained telemetry, you can't answer basic audit questions like which model served a given request or which prompt version was used. To make that possible, the pipeline emits structured security telemetry across four categories β network activity, HTTP activity, process activity, and filesystem activity β kept distinct from standard operational observability like OpenTelemetry traces and Prometheus metrics. The approach runs agent, tool, and model telemetry through the same collection pipeline used for regular services, so security posture and performance can be profiled together on Red Hat OpenShift AI. The practical takeaway is that adding sandboxing and security controls to agentic workloads is an instrumentation and profiling problem as much as an architecture problem.
π‘ Before assuming sandboxing an agent pipeline will tank performance, instrument it with structured, security-specific telemetry alongside normal OTel and Prometheus signals so you can profile exactly where the latency overhead lives and optimize with data instead of guesswork.
Fedora 45 Beta now available
Red Hat
The Fedora Project released the Fedora Linux 45 Beta on September 15, 2026, ahead of a planned October general release. On the desktop side, the traditional in-kernel console is replaced by kmscon, a userspace virtual terminal implementation with smoother rendering, better internationalization and font handling, and security improvements, while Fedora Workstation moves to GNOME 51 on Linux kernel 7.2. The developer toolchain gets a major refresh with early access to Python 3.15, Go 1.27, GCC 16.2, and glibc 2.44, plus new versions of Podman 6, Pandas 3, and MySQL/MariaDB. Security defaults are tightened too: Fedora 45 now requires valid package signatures before installation by default, and DNF5 disables automatic vendor switching across conflicting third-party repositories during dependency resolution or upgrades unless the user explicitly asks for it. Desktop secret management is standardized on oo7, replacing legacy backends like GNOME Keyring and KWallet. For Apple Silicon users, Fedora Asahi Remix 45 Beta adds initial support for Apple M3, M3 Pro, and M3 Max chips, with hardware video decoding for H.264 and VP9 across all Apple Silicon Macs and AV1 decoding specifically on M3 machines.
π‘ The default-on package-signature enforcement and DNF5's blocked auto vendor-switching are meaningful supply-chain hardening, so teams basing container or edge images on Fedora should validate their package and repo pipelines against the beta before it becomes the GA default.
DevOps & Infrastructure
OpenAIβs voice model doesnβt think. Thatβs the point.
The New Stack
Voice agents run into a latency problem the moment they have to do real work, and within five days Google and OpenAI shipped two different fixes to it, the article reports. Google's Gemini 3.8 Live Extended Thinking keeps reasoning inside the voice model itself, letting it keep speaking while it executes asynchronous tool calls in the background. OpenAI instead split the job across two systems: GPT-Live-1 handles the real-time conversation while a separate backend reasoning model takes on complex tasks. OpenAI puts GPT-Live-1's turn-taking latency at around 800 milliseconds, a figure it attributes directly to keeping the real-time voice layer separate from heavier backend reasoning work. In effect, OpenAI's voice model deliberately does not think in real time, trading reasoning depth for responsiveness by offloading the hard problems to another model.
π‘ Choosing between a single model that reasons in real time versus a split architecture like GPT-Live-1's real-time layer plus backend reasoning model is really a decision about where trace boundaries and failure isolation live in the observability stack.
AWS agents will suggest your new flights. Code decides what gets booked.
The New Stack
AWS published a new Step Functions pattern in which AI agents propose new flight itineraries after a disruption, while deterministic code validates those proposals and controls actual reservation changes and payments. In the pattern, specialized Amazon Bedrock AgentCore agents suggest itineraries and draft compensation messages, and deterministic steps in the Step Functions workflow validate those proposals before any reservation is changed or payment is issued. The article warns that an unconstrained agent might ignore a codeshare restriction, rebook a passenger onto a flight that meets minimum connection time only on paper, or miscalculate compensation by misreading the ticket's point of sale and applying the wrong regulatory regime. The core principle, as AWS states it, is that agents propose and deterministic code validates -- orchestrating specialized Bedrock AgentCore agents with Step Functions combines generative AI's reasoning with deterministic guardrails. Step Functions adds native fan-out across thousands of passengers, a callback pattern that pauses a case for human review at zero compute cost, and a durable execution history that serves as an audit trail. AWS notes the pattern generalizes to any workflow where automated decisions carry real financial or regulatory consequences.
π‘ Instead of letting an agent directly execute irreversible actions like booking or payment, enforcing a propose-then-validate split with a deterministic validation layer gives platform teams an auditable, code-level chokepoint for regulatory and financial risk.
Simplifying Terraform for IBM Z with intent-driven workflows
HashiCorp
HashiCorp announced intent-driven workflows for IBM Terraform Self-Managed for Z and LinuxONE (Terraform for Z), a new interaction model where operators define a desired infrastructure outcome and guided agents execute tasks within established governance boundaries. The capability provides three core functions: discovering existing infrastructure resources, simulating environments that mirror infrastructure behavior, and rehearsing operational changes before execution. Operators can describe their intent in natural language or select from predefined workflows without needing deep Terraform expertise, with the system guiding them through required steps, capturing inputs, and presenting evidence for review before any modification happens. Before changes execute, workflows can be rehearsed against simulated environments so teams can validate the process and understand impact, and the system produces a complete record of decisions, approvals, generated artifacts, and execution history for audit and compliance purposes. Initial workflows focus on deployment tasks for Terraform for Z and LinuxONE environments, with additional infrastructure lifecycle management workflows planned. The feature is slated for general availability later in 2026, with HashiCorp directing interested customers to contact sales for early access.
π‘ A workflow that turns natural-language intent into a rehearsed, evidence-backed change with a full decision-and-execution audit trail is a useful pattern for regulated environments like mainframes where a bad IaC change is expensive, and worth borrowing when designing GitOps review gates elsewhere.
The AI Hurricane Is Here
Snyk
A Snyk blog post argues that AI risk has moved from an uncertain fog into an active hurricane: severe vulnerabilities are surfacing weekly, AI-assisted attackers are lowering the skill bar needed to run sophisticated campaigns, and the AI supply chain itself has become a target. The post identifies three core problems: automated attacks moving faster than a human-speed remediation backlog can absorb, agentic development that writes code and reaches for tools nobody vetted, and AI applications running in production with no inventory, no policy, and no audit trail. It ties together Anthropic's Dario Amodei's pace the frontier proposal with CrowdStrike CEO George Kurtz's runtime-security counterpoint, distilling them into a shared principle: the system that generates code or a fix must never be its own sole validator. The post closes with a three-part framework -- secure at inception, enforce controls at runtime, and validate defenses independently -- and promotes an upcoming joint Snyk/Anthropic webinar. As a concrete example, the post cites Anthropic's September 2026 report on a Russian state-nexus espionage actor that used an AI-assisted workflow to identify, modify, rebuild, and redeploy its own implants, with the AI closing that loop faster than defenders could write and ship a new detection.
π‘ The principle that a code-generating AI system must never be its own sole validator translates directly into a CI/CD requirement: any AI-authored code or config change needs an independent policy engine or runtime control gate that re-validates it before it ships.
ν μ€μ¦κΆμ΄ GPU-awareλ₯Ό λμ΄ GPU-native ν΄λ¬μ€ν°λ₯Ό ꡬμΆν λ°©λ²
ν μ€
Toss Securities re-architected how its large, multi-team Kubernetes cluster handles GPUs, moving beyond simply making GPUs visible to the scheduler ("GPU-aware") toward a "GPU-native" design where GPU health and topology inform cluster operations end to end. To stop unverified nodes from silently taking GPU jobs and causing failures, the team added a gating step so only nodes that pass health checks are allowed to receive GPU workloads. They also introduced finer-grained placement and isolation policies so multiple teams sharing the same GPU pool don't interfere with each other's jobs while utilization stays high. The redesign touched GPU device configuration as well as Kubernetes scheduling and monitoring settings, keeping all three layers consistent with each other. This builds on Toss Securities' earlier public writeups about adopting a high-performance GPU cluster and GPU virtualization (MIG), suggesting incremental hardening of the same platform. Because direct access to toss.tech was blocked by network policy in this session, this summary is based on search-indexed descriptions of the article rather than a full read of the source page.
π‘ It's a reminder that safely sharing GPUs across many teams in one Kubernetes cluster requires node health gating and tenant isolation baked into the scheduler and monitoring stack, not just GPU device-plugin visibility.
Monitor TAS and gang scheduling for AI training in Kubernetes
Datadog
Datadog explains how it helps teams monitor Topology-Aware Scheduling (TAS) and gang scheduling for distributed AI training on Kubernetes. TAS groups nodes into topology domains β block, rack, host β based on topology labels and places a job's pods within a single domain to minimize inter-GPU communication latency during training. Gang scheduling addresses "partial gang starts," where some pods run while others wait and allocated GPUs sit idle, by enforcing all-or-nothing binding so every required worker pod starts simultaneously. The stack relies on Kueue, an open-source job queue that sits above the native scheduler to make admission decisions and write topology constraints into pod templates, plus a Coscheduling plugin that coordinates gang assembly via PodGroup custom resources. Datadog collects Kueue metrics like kueue_pending_workloads (queue depth by status), kueue_admission_wait_time_seconds (rising p99 signals bottlenecks), and kueue_evicted_workloads_total (an eviction reason of "NodeFailures" points to TAS-related capacity loss), alongside PodGroup .status.phase values (Pending, Scheduling, Running, Failed), and correlates these with GPU NVLink and PCIe throughput, Ray's ray_placement_groups and ray_tasks metrics, and PyTorch DDP/Horovod throughput (steps or tokens per second) to distinguish placement failures from gang-assembly failures, with preview features like Capacity Planning, GPU Fleet Explorer, Training Optimization, and Continuous Tracing (which surfaces NCCL spans) supporting cross-correlation by topology tags such as rack.
π‘ To quickly tell whether a stalled training job is an idle-GPU problem, a failed gang assembly, or bad topology placement, teams need Kueue admission and eviction metrics, PodGroup phase, and GPU NVLink/PCIe throughput pre-correlated by topology tags β building that dashboard before an incident, not during one, is what actually saves MTTR.
How to operate shared platforms safely at agent scale
Datadog
Datadog describes how to operate shared platforms safely as AI agent workloads scale across teams. The key is mapping the full "agent trajectory" β triggers, model requests, tool calls, queues, CI or workflow jobs, sandbox operations, downstream APIs, and final side effects β rather than just watching model traffic, so every dependency is accounted for. A concrete example: a conversational agent and a background coding agent can share a nearly identical dependency map but have very different capacity profiles, since the former needs low-latency responses and concurrent connections while the latter accumulates queued work over hours. In one internal evaluation of a coding agent, Datadog estimated roughly 2,000 requests per minute and 45 billion tokens per day; RPM was manageable, but token consumption would have approached an upstream token-throughput limit. To handle contention, Datadog recommends tagging every workload with consistent identifiers (workload, owner, environment, service class, task/run) and defining workload-class policies that specify overload behavior per criticality tier β queue, reduce concurrency, fall back, or reject. Datadog itself implemented source-specific rate-limiting buckets to protect customer-facing traffic, moved evaluation workloads to a completely separate provider account, fixed a real incident where a traffic spike left some spans tagged with an unknown calling source (delaying root-cause analysis) by updating rejection telemetry to retain the calling source even on early 429 responses, and extended its AI Gateway's graceful-shutdown window from 5 seconds to 60 seconds so p99 in-flight requests can finish with headroom during rolling deployments.
π‘ Capacity-planning AI agents purely off model-API traffic misses the real bottleneck β tagging and rate-limiting the full trajectory (queues, CI jobs, sandboxes) by workload class, plus generous graceful-shutdown windows on the AI gateway, is what actually keeps one team's eval traffic from starving customer-facing requests during rolling deploys.
Manage Cursor costs with Datadog Cloud Cost Management
Datadog
Datadog integrated the AI coding tool Cursor into its Cloud Cost Management (CCM) platform, addressing the FinOps problem of AI engineering spend being tracked separately from infrastructure costs. Cursor spend can be filtered by individual user, AI model, Max Mode status, headless mode, and billing group, with per-user cost and period-over-period comparisons that make it easy to spot spending shifts or outlier users. The out-of-the-box dashboard covers 30-day usage-change trends, budget-consumption widgets, and model cost comparisons, plus an "Efficiency" section showing metrics like tab-completion acceptance rate and cost per accepted line of code. An anomaly-detection feature automatically surfaces spending spikes that deviate from historical patterns, and integrates with Bits Chat to provide root-cause analysis pinpointing whether a spike came from a specific model, user, or feature. Teams can set threshold-based cost monitors and budgets to get ahead of overruns. Cursor costs sit alongside cloud spend (AWS, Azure), SaaS spend (Snowflake, Databricks), and other AI provider costs (OpenAI, Anthropic) in the same unified dashboard.
π‘ Pairing efficiency metrics like tab-completion acceptance rate and cost-per-accepted-line with raw spend lets FinOps teams justify Cursor budget decisions based on productivity-per-dollar rather than just cutting AI tool spend blindly.
What Stripe data shows about fraud at AI startups
Stripe
Stripe analyzed a year's worth of attempted fraud and customer abuse patterns on its platform and found that in Q3 2025, AI startups faced an attempted fraud rate 4.3x higher than startups overall. More specifically, one in six sign-up attempts for AI services on Stripe is now linked to fraudulent activity. Multi-account abuse targeting AI subscription companies rose 40% over a six-month period, with the most heavily targeted companies seeing average increases of 154% and some spiking above 600%. Stripe attributes this to a structural quirk of the AI economy: unlike a typical software free trial, signing up for an AI service comes bundled with compute tokens that have resale value, pushing fraudsters away from traditional transaction fraud and toward abusing free trials and token grants instead. In response, Stripe says it has been strengthening its Radar fraud-detection product to help AI startups counter these increasingly sophisticated attack patterns.
π‘ Because free-trial compute tokens are themselves a resellable asset, AI product teams need dedicated anomaly detection on sign-up and credit-grant flows, not just payment-fraud defenses, since that's where abuse has shifted.
Digital Experience Monitoring with Grafana Cloud: Session Replay, synthetic checks, and faster investigations
Grafana
Grafana Labs announced an expansion of Digital Experience Monitoring in Grafana Cloud around three pillars: Session Replay, synthetic checks, and faster investigations. Synthetic Monitoring runs automated checks against critical user journeys on a schedule, catching problems before real users hit them. Session Replay, part of Frontend Observability, lets teams visually replay exactly what a user saw and did inside a web app, correlated with real-user signals like Core Web Vitals, user actions, and traces, useful for bug investigation and root-cause analysis. The headline feature is a new integration between Synthetic Monitoring and Frontend Observability: every synthetic browser check run now automatically generates a corresponding Frontend Observability session, so engineers can jump from a failed check straight into a replay, the user journey, and correlated traces. Grafana Labs states this combination can cut mean time to recovery from hours to minutes. Together, the two features form what Grafana calls its Digital Experience Monitoring story β proactive synthetic signal paired with real-user ground truth in a single platform.
π‘ Auto-linking failed synthetic checks to a real Frontend Observability session lets on-call engineers immediately tell whether a synthetic failure is actually hitting real users, cutting down on false-alarm escalations.
How Canvas Powers the AI Agent Development Feedback Loop
Honeycomb
Honeycomb describes how Canvas, its AI-guided observability workspace, supports every stage of the AI agent development feedback loop: instrumenting agents, understanding a single run, finding the problems worth fixing, shipping a fix, and proving it worked. The underlying telemetry captures every model call, tool call, and handoff with timings, tokens, and errors attached, where each step is a span, spans from one request form a trace, and traces from a full agent run are grouped as a conversation. As a major contributor to the OpenTelemetry project, Honeycomb has integrated the OTel GenAI semantic conventions (v1.40.0) into its platform, making gen_ai.* attributes first-class so that model evaluations, tool executions, MCP calls, LLMs, and agents are all observed consistently. Canvas is built on Honeycomb's OpenTelemetry-native, event-based architecture, meant to give AI the speed and context to make each investigation interactive, explainable, and actionable. The overall design goal is telemetry that serves not just debugging but also behavior analysis, guiding improvements, measuring experiments, and demonstrating business value.
π‘ Adopting the OTel GenAI semantic conventions (gen_ai.* attributes) for agent instrumentation means model calls, tool calls, and MCP requests fit into your existing span and trace pipeline instead of requiring a separate observability stack for agents.
GitLab Dedicated: Compliance for a new regulatory era
GitLab
This GitLab post opens by noting that regulations like NIS2 are no longer a future planning item but something organizations must handle now, citing ENISA's NIS360 report as confirmation that supervisory authorities are actively assessing cybersecurity maturity across critical sectors. NIS360 is designed as an assessment tool to evaluate the maturity and criticality of sectors covered by the NIS2 Directive, helping member states and national authorities identify gaps and prioritize resources. The NIS2 Directive itself, adopted in December 2022, requires essential and important-sector entities to strengthen cybersecurity, secure their technology supply chains, and rapidly report significant incidents across the EU. GitLab positions GitLab Dedicated, its single-tenant hosted offering, as a way to simplify compliance with DORA, NIS2, and GDPR simultaneously through built-in isolation, control, and audit-readiness. Specifically, it points to GitLab's Secure stage as enabling detective and responsive supply-chain security capabilities, which map to NIS2's requirement that organizations manage risk across their suppliers and service providers.
π‘ Since NIS2 mandates supply-chain risk management and fast incident reporting, teams serving EU customers benefit from baking single-tenant isolation and supply-chain scanning into the CI/CD pipeline by default rather than retrofitting it before an audit.
This digest was collected from RSS feeds and summarized by AI (Claude). See the original links for full details.