New Field Note on CoreWeave ARIA
I published a Field Note last week on CoreWeave ARIA (AI Research and Iteration Agent), the latest release from the Weights & Biases team. ARIA offers a useful glimpse of where model development is heading as enterprises embrace more autonomous processes. Three things stand out. First, ARIA leverages looping to achieve its objective, completing many runs before revealing the best answer. This is in contrast to the far more common approach of linear execution, where completion equals success. In one example, ARIA iterated across 674 runs before recommending next actions. Second, it optimizes for continuous improvement, refining even the hypothesis and objectives rather than chasing one-shot success. Third, it reaches for context from the team, not just the individual developer — although shared team workflows are still on the roadmap. The open question is the cost of this much precision: When an agent runs thousands of experiments for a single job, it can get expensive. ARIA ultimately makes an argument that at the frontier, sometimes you need to measure thousands of times and cut once. For more details, read the Field Note here.

Salesforce Briefing: “Where Your Agents Live”
I was briefed last week on Salesforce’s new Slack positioning, which reframes Slack as the place “where your agents live.” This reflects a broader trend in which enterprise vendors like AWS, Microsoft, and Salesforce are building their own agent assistants similar to Claude Cowork. Three priorities anchor the strategy: tighter integration with Salesforce’s CRM as a means to better enable the most common Salesforce users; addition of the more common agent assist features (memory, skills, and MCP integration) via a new employee agent; and a concept Salesforce calls a Work Operating System (WorkOS) that pulls all apps and agents together at the application layer.

My take: The integration work is strong, and the “This is where the team already works” value prop is similar to other market entries. But, also like its competitors, I am not sure if the productivity claims will be as common for power users as for the rank and file. I also would like to learn more about the approach to channel-level security, which uses an opt-out methodology to gate certain channels from being read by LLMs. But the real question I will be looking to answer this year at Dreamforce is when to use Agentforce or Slack for building and managing these agents.

SAP in the News
Following my recent SAP Pulse Brief, I fielded a run of press questions last week from journalist Lynn Greiner. My remit was to provide commentary for a couple of articles on CIO.com. In the first article, we covered SAP’s AI oversight reshuffle — the second such shift this year — and I don’t see cause for concern; the moves are connected, reflecting both the scale of the install-base challenge and the equally big job of moving SAP from a SaaS-first to an AI-first company. In fact, this news supports my belief that SAP is reinventing its product lines rather than bolting on AI. In the second piece, there’s a report that SAP is restricting hiring and travel to fund its AI push. I’m not surprised given stock pressure, though SAP’s shares have been less volatile than those of its SaaS peers. But beyond the cuts themselves, there were questions about what the cuts could ultimately mean in terms of jobs, which had been covered recently in the New York Times. Despite some funding cuts, it is being reported that SAP is working to retool its workforce with AI. My commentary is that I have mixed views on some of that narrative: The macro story checks out long-term, but I also see many near-term challenges ahead as AI technology and the current state of work clash.

New Field Note on CoreWeave ARIA
I published a Field Note last week on CoreWeave ARIA (AI Research and Iteration Agent), the latest release from the Weights & Biases team. ARIA offers a useful glimpse of where model development is heading as enterprises embrace more autonomous processes. Three things stand out. First, ARIA leverages looping to achieve its objective, completing many runs before revealing the best answer. This is in contrast to the far more common approach of linear execution, where completion equals success. In one example, ARIA iterated across 674 runs before recommending next actions. Second, it optimizes for continuous improvement, refining even the hypothesis and objectives rather than chasing one-shot success. Third, it reaches for context from the team, not just the individual developer — although shared team workflows are still on the roadmap. The open question is the cost of this much precision: When an agent runs thousands of experiments for a single job, it can get expensive. ARIA ultimately makes an argument that at the frontier, sometimes you need to measure thousands of times and cut once. For more details, read the Field Note here.

Salesforce Briefing: “Where Your Agents Live”
I was briefed last week on Salesforce’s new Slack positioning, which reframes Slack as the place “where your agents live.” This reflects a broader trend in which enterprise vendors like AWS, Microsoft, and Salesforce are building their own agent assistants similar to Claude Cowork. Three priorities anchor the strategy: tighter integration with Salesforce’s CRM as a means to better enable the most common Salesforce users; addition of the more common agent assist features (memory, skills, and MCP integration) via a new employee agent; and a concept Salesforce calls a Work Operating System (WorkOS) that pulls all apps and agents together at the application layer.

My take: The integration work is strong, and the “This is where the team already works” value prop is similar to other market entries. But, also like its competitors, I am not sure if the productivity claims will be as common for power users as for the rank and file. I also would like to learn more about the approach to channel-level security, which uses an opt-out methodology to gate certain channels from being read by LLMs. But the real question I will be looking to answer this year at Dreamforce is when to use Agentforce or Slack for building and managing these agents.

SAP in the News
Following my recent SAP Pulse Brief, I fielded a run of press questions last week from journalist Lynn Greiner. My remit was to provide commentary for a couple of articles on CIO.com. In the first article, we covered SAP’s AI oversight reshuffle — the second such shift this year — and I don’t see cause for concern; the moves are connected, reflecting both the scale of the install-base challenge and the equally big job of moving SAP from a SaaS-first to an AI-first company. In fact, this news supports my belief that SAP is reinventing its product lines rather than bolting on AI. In the second piece, there’s a report that SAP is restricting hiring and travel to fund its AI push. I’m not surprised given stock pressure, though SAP’s shares have been less volatile than those of its SaaS peers. But beyond the cuts themselves, there were questions about what the cuts could ultimately mean in terms of jobs, which had been covered recently in the New York Times. Despite some funding cuts, it is being reported that SAP is working to retool its workforce with AI. My commentary is that I have mixed views on some of that narrative: The macro story checks out long-term, but I also see many near-term challenges ahead as AI technology and the current state of work clash.

Anthropic re-released its highly anticipated Fable foundation model after the U.S. government had forced it to pull back the model and set the expectation that it would be used only by citizens of the United States. While that requirement didn’t seem to be taken into account, Anthropic has limited Fable’s capabilities so it can meet U.S. government requirements. That said, I simply don’t think that the US government should have oversight of which models are released and when. This practice puts American AI companies at a disadvantage compared to their open-source Chinese competitors.

Plenty of agents never leave a single platform. But organizations get the most out of agents when they can trust them to work across every environment, from their clouds to their own datacenters to the air-gapped or sovereign corners where the most sensitive work lives. Building that trust requires governance that travels with the agents, yet the controls built for a single platform break the moment agents step outside. To put it another way, every platform and cloud governs inside its own walls. Nobody governs the space between them — and that space is where an auditor’s questions land. DataRobot has gone after that gap, pulling agent moderation, identity and permissions, lineage, and cost into one control layer that reaches the environments platform-native tools miss. Most of these pieces already lived in its agent platform, so the news is that the pieces finally work together as one. If you’re a data leader, the test is whether you can give one straight answer when a regulator asks what an agent did and where the data went, across every environment it touched — instead of a stack of per-platform logs that never quite reconcile.

An agent is only as good as the picture of your environment it’s working from. Feed it a stale or partial one and it will act with full confidence and still be wrong. To address this, Infoblox has expanded Universal Asset Insights for agent operations, giving agents a governed path to trustworthy data about what’s actually running across a hybrid estate, through a wider set of integrations and an MCP server they can query directly. Infoblox has spent years holding the definitive map of the network layer — the address and DNS data every connection resolves through — so opening that up to agents builds on ground it already holds. The question worth putting to your teams is where the agents you’re building get their read of the environment, and whether it comes from that authoritative map or from whatever a developer wired up fastest. An agent reasoning over a guessed inventory of your systems is a governance problem long before it’s a productivity win.

A year ago, the hardest part of AI infrastructure was getting enough compute. Now a big part of it lies in the control layer between a company and the dozen or so providers its AI reaches, and Equinix has built a genuine position there. Last week I wrote a Field Note on where Equinix’s distributed-AI strategy stands. The latest news is about market traction, since the products themselves have been out for a little while. The company has taken the neutrality and global footprint it spent nearly three decades building and turned Equinix Fabric into a control point for AI running across many providers, with gateways, guardrails, and cost routing in the traffic path it already carries. And customers are showing up. Enterprises in fintech and healthcare are running production workloads on the platform, and network teams at big retailers and streaming providers manage Equinix Fabric straight from an AI assistant. Sovereignty is the part regulated buyers care about most, but it usually gets sold as a choice of cloud region, which says nothing about the path data takes between those regions. Equinix, by contrast, enforces jurisdictional routes at the network layer, so rerouted traffic still won’t cross a border it isn’t cleared for. That neutral position is hard for a first-party cloud to match, since it works only when you don’t own the destinations.

All that distributed AI activity throws off an enormous amount of telemetry, and holding onto that information has quietly become its own cost problem. Every agent action, every trace, every evaluation lands in a log somewhere, and the volume has climbed to the point where teams drop most of it just to keep the bill down. So, the record you’d want to replay when an agent goes sideways is often one you already deleted. AWS has answered this with a new analytics engine for its managed OpenSearch service that keeps log data in open columnar files while leaving it searchable, so a company can hold far more of it, far longer, without storage cost climbing in lockstep. The cost number will grab the headline. The real catch is the switching cost, since moving means standing up new domains and rebuilding the dashboards and queries wired to the old setup. That friction is usually what keeps teams on infrastructure they’ve outgrown, well after the economics are telling them to move. The savings are real, but only if you’re willing to do the rebuild, and that cost belongs next to the storage line.

Just about every operational database is now racing to become the place where AI agents actually run, and Couchbase has staked its claim with an AI Data Plane it can run self-managed and out to the edge, beyond its own cloud. Last week I broke this launch down in a new Field Note. A lot of these capabilities shipped on managed Couchbase months ago, so what’s new is the ability to run the same agent layer on clusters a company operates itself, for the enterprises that can’t or won’t put agents in someone else’s cloud. The centerpiece is Agent Memory, a single place to hold the context an agent carries between sessions. The storage is the easy part. The controls around it are what make it production-grade, expiring a memory once it goes stale and capping what any single agent can spend pulling it back. Let that memory pile up unchecked, and the token bill climbs while agents keep acting on context that’s gone cold. A clock on how long a memory lives and a ceiling on what it costs are what separate a memory feature from memory you’d run on a system of record.

MongoDB is another operational database provider in that race, and this round its push was retrieval accuracy. It brought reranking and better embedding models into the database, and extended search and vector search to self-managed and on-prem deployments with the same capabilities as its managed cloud. The accuracy work is genuine, and it’s also becoming table stakes, since everyone in this space is shipping a version of it. The move with more staying power is putting a first-party model, the operational database, and search over live data all in one place, so a team isn’t stitching three vendors together to trust a single answer. The buyers most drawn to that consolidation are the regulated ones, the shops that need everything behind their own firewall. The gap I’d still push on is proof. A regulated buyer needs the retrieval to be accurate and needs to be able to show an auditor that it is; the first-party tooling to measure and give evidence of that accuracy is still the thin part of the story.

Qualcomm’s Acquisition of Modular: An Edge Perspective
Qualcomm announced an agreement to acquire AI software company Modular for $3.92 billion in an all-stock deal at its June 24 Investor Day, with the deal expected to close in the second half of 2026. Most press and analyst coverage positions the deal as a datacenter play. Here’s my edge perspective.

CUDA is NVIDIA’s general-purpose parallel computing platform that enables developers to write numerical code for NVIDIA GPUs, and it’s the most widely used AI programming stack. Modular works at a higher level. Its Mojo language and MAX inference engine take a trained model and compile it for a variety of silicon platforms — such as Qualcomm’s AI-accelerated SoCs.

Different edge AI workloads need different combinations of CPU, GPU, NPU, DSP, and memory. Power, thermal, and latency constraints rule out a single design, so edge silicon fragments across vendors and architectures more than any other computing tier. Modular targets accelerator diversity directly. Modular also adds to the comprehensive development and deployment platform that Qualcomm has been assembling for the past three years. It extends from the far edge to the datacenter — Dragonwing for industrial and robotics silicon, Foundries for productization, Edge Impulse for small-model machine learning. Now, Modular uplevels the AI stack with large-model inference.

Modular addresses the AI model availability bottleneck, which is most acute for physical AI, where applications need many models for many use cases, each tuned to specific hardware. Today, optimizing these models requires bespoke hardware-software co-design. It’s costly, slow, and it doesn’t scale to the mid-market long tail. Hence, the bottleneck. Modular doesn’t eliminate the need for optimization, but it automates much of it. The model stays in its neutral form; the silicon vendor writes one backend per architecture, and Modular simplifies optimization. Effort scales with targets, not targets-times-models, although quantization accuracy remains model-specific and not fully automatable.

Today, MAX ships on NVIDIA and AMD GPUs and on x86 and Arm CPUs, with early Apple Silicon support. The press release promises scope “across CPU, GPU, NPU, and custom ASIC architectures,” but Modular doesn’t yet address Qualcomm’s Hexagon NPU. Modular uses MLIR within the LLVM ecosystem, and Hexagon already has an LLVM backend, so the plumbing exists. Notably, Modular 26.2 already supports NVIDIA’s Jetson Thor, so MAX runs on a competitor’s edge silicon. Closing that gap is presumably job one after the deal closes.

My take: Qualcomm is buying a compiler architecture, the team behind it, and a paved path to a cross-silicon answer to CUDA. I’ll be watching for two things: when a Hexagon backend ships, and whether MAX stays open to competing silicon once it’s inside Qualcomm.

RocketLab’s planned acquisition of Iridium demonstrates the appetite for seemingly everyone in the space industry to involve themselves in low-earth-orbit (LEO) direct-to-device (D2D) communication services. Iridium is one of the last remaining independent satellite operators after Globalstar agreed to be bought by Amazon (which also uses Jeff Bezos’s Blue Origin), and SpaceX already has its own LEO D2D service in the form of Starlink. RocketLab’s growth as competition for SpaceX and Blue Origin has propelled its share value high enough ($80 billion) to even make this planned ($8 billion) acquisition possible. The companies that need to launch a lot of satellites are natural customers for these rocket manufacturers, but they also need to bring launch expenses as low as possible, and there’s no better way to reduce launch expenses than to do them internally at cost. I believe that the combined entity — the deal is expected to close in mid-2027 — will be more competitive, given the current market conditions.

Verizon and BT Group have announced their intent to spin off their respective international enterprise businesses and merge them into a single entity. Once combined, this entity would serve over 1,300 customers and generate $4 billion in revenue per year, so by default it will already be quite a large company. It seems that both Verizon and BT want to focus more on their core markets and not manage these international enterprise operations. The nature of the combined entity also seems quite rational, because it would mostly handle larger enterprises that need services across multiple countries. Given the large global footprints of Verizon and BT, having a combined entity to better serve those enterprises internationally makes sense for scale.

There have been ongoing rumors that SpaceX is building a smartphone. This first came to light in a Reuters story earlier this year; the rumor was denied, but it did not seem totally out of the realm of possibility. Then the Wall Street Journal reported that a handheld device thinner than a smartphone, with a Qualcomm chipset running xAI software, was shown to potential SpaceX shareholders ahead of the IPO last month. Who knows how this will shake out, but I believe that SpaceX entering this market doesn’t really make sense other than to control how its Grok AI can interact with the device/smartphone without being limited by what Android can or can’t do. I also believe that this notional SpaceX move is similar to what OpenAI is supposedly planning for its own device strategy.