Physical AI took a real step forward this week, while Azure spent its energy on the less glamorous work of making existing services more complete: keys that no longer need wrapping, a gateway that finally speaks IPv6 properly, and locks that can be tuned instead of just tolerated. None of it is flashy, but it’s the kind of engineering that determines whether a platform holds up under real workloads.
Gemini Robotics 2 Brings Whole-Body Control to Physical AI
Google DeepMind’s new robotics intelligence layer, announced this week, extends control beyond the tabletop tasks of its predecessor to full-body movement: walking, crouching, stretching, and coordinated two-handed manipulation. The release bundles a vision-language-action model, a lightweight on-device version for offline operation, and a separate embodied-reasoning model that plans multi-step tasks and self-corrects when the environment changes mid-task. The embodied-reasoning model is available now on Google AI Studio and in private preview on the Gemini Enterprise Agent Platform, while both VLA models remain restricted to early-access partners.
Why it matters: the deployment split here mirrors what platform teams are already building for agentic workloads generally, a lightweight model at the edge for latency and reliability, paired with a heavier cloud-hosted model for deeper reasoning. Anyone architecting AI infrastructure for robotics or IoT should expect this hybrid topology to become the default rather than the exception.
Kubernetes Fleet Manager Adds Cost-Aware Resource Placement
Resource placement in Azure Kubernetes Fleet Manager has reached general availability, built on the KubeFleet CNCF project. Platform teams stage manifests on a Fleet Manager hub cluster, then define declarative placement policies that target member clusters by label or by measured properties such as CPU, memory, region, or an Azure-priced per-hour cost figure. Both cluster-scoped and namespace-scoped resources are supported, and rollouts can be staged progressively rather than pushed to every matching cluster at once.
Why it matters: manually tracking which workloads sit on which cluster across a large fleet doesn’t scale. Cost-aware placement gives platform teams a native way to route batch or spot-tolerant workloads onto the cheapest available capacity, which matters more as fleets span regions with meaningfully different pricing.
Key Vault Premium Adds Native Symmetric Key Support
Azure Key Vault Premium now supports HSM-backed symmetric keys in public preview, adding the oct-HSM key type in 128, 192, and 256-bit sizes. The keys support AES-KW, AES-GCM, and AES-CBC for encryption and wrapping, plus HMAC sign and verify from HS256 through HS512, all through the existing Key Vault API surface. Until now, Key Vault required symmetric material to be wrapped with an asymmetric key before it could be stored, a workaround many teams had already built custom tooling around.
Why it matters: it’s also relevant to anyone tracking post-quantum readiness. Microsoft notes that 256-bit AES keys used through this feature are considered quantum-resistant under current CNSA 2.0 guidance, which is increasingly showing up as a line item in security audits rather than a theoretical concern.
NAT64 Reaches General Availability on StandardV2 NAT Gateway
NAT64 support for Azure’s StandardV2 NAT Gateway is now generally available, letting IPv6-only subnets reach IPv4-only destinations without a dual-stack deployment. The gateway handles translation, but a third-party DNS64 resolver is still required to synthesise the AAAA records that point IPv6 clients at those IPv4 targets. StandardV2 itself remains in preview and carries its own migration wrinkle: there’s no in-place upgrade from the Standard SKU, so moving over means provisioning a new gateway and re-pointing the subnet.
Why it matters: teams that went IPv6-only to simplify address planning on large AKS or VM fleets have been stuck maintaining IPv4 fallback paths for anything that hasn’t caught up. NAT64 removes that requirement for outbound traffic, though the DNS64 dependency and the missing upgrade path are both worth factoring into migration timelines.
NetApp Files Gets Configurable SMB Oplocks
Azure NetApp Files now supports configuring SMB opportunistic locking in public preview, giving administrators control over oplock behaviour on individual shares rather than accepting the platform default. Oplocks let SMB clients cache reads, writes, and lock state locally to cut network round trips, but that same caching has historically caused data integrity problems for certain application patterns, particularly ISAM-style and client/server database workloads that assume stricter consistency.
Why it matters: it’s a narrow fix, but it closes a gap that’s forced some teams to disable oplocks entirely on affected shares, sacrificing performance across the board to protect a handful of workloads. Share-level configuration means caching can stay on where it helps and switch off only where it’s genuinely a risk.
Symmetric keys, NAT64, and configurable oplocks are the kind of fixes that only matter once a platform is carrying real production traffic and someone hits the edge case the original design didn’t account for. Set against DeepMind’s push toward full-body robotics, it’s a useful reminder that infrastructure maturity and frontier AI capability are advancing on separate, largely unrelated timelines. Both deserve a platform team’s attention, just not necessarily the same week’s.
