I want to share my thoughts on MI&S partner Signal65’s new Pinnacle offering, which I covered in more detail in this Field Note. Pinnacle is the first methodology I have seen that scores agents on whether they get the work right, not on how fast or how cheaply a model responds. This is an important development that could help spur more agent adoption. Enterprises have lacked a real, actionable way to compare agent performance across models, infrastructure, and vendors. Without that, they cannot say with confidence what to deploy or what it will cost to run at scale, and that gap is slowing adoption and undermining any defensible ROI case for agentic AI. My only caveat is that Pinnacle is still new and will not settle every argument about how to benchmark agentic AI. But it is serious enough for enterprises to put on the evaluation checklist now, rather than wait for a second version to mature.

Last week Microsoft announced that both Copilot Studio and Copilot Cowork will get embedded application development capabilities. This is similar to a trend we are seeing where major capabilities consolidate into a more unified and powerful interface. There are two key benefits to this approach. The first is that capabilities like this, paired with natural-language agents, are opening up entirely new pathways for no-code development. And while there are a lot of things to consider as we open up coding to more people (like security, governance, sprawl, etc. etc. etc.), these departmental applications are often where innovation and technical ROI are incubated. But I also see the consolidation of surfaces as good for enterprise IT teams, who have had to deal with a number of different tools — sometimes even from one vendor — that have become hard to manage and support. It’s not a very surprising move for Microsoft, which has been steadily aligning its Copilot agent and Power Platform no-code products for a couple of years. I am looking forward to seeing what is going to be announced at the company’s Ignite conference later this fall.

On the pro-code side of the equation, GitHub also added model routing into its platform last week. It’s pretty interesting news for a couple of reasons. First, since token costs are a major driver for developers right now, model routers help customers save significant money. And the cost variability is massive in some cases, depending on the inputs and the required outputs. The router’s goal is to evaluate your inputs and direct the work to the right model based upon your needs. The second reason is that this new project from GitHub may offer the broadest choice of models and how they are hosted (meaning on-prem or in different clouds). While model routers have been around for a while now, GitHub may get traction based upon its position with developers and its approach to breadth. Hyperscalers like AWS and Azure have their own routers but are only aligned to the models they support. OpenRouter (which is being acquired by Stripe) and Switchyard from NVIDIA open up routers across different clouds — though not necessarily for on-premises models — which comes in really handy for testing and pre-production. This reinforces the GitHub AI value proposition around choice and cross-platform support.

I want to share my thoughts on MI&S partner Signal65’s new Pinnacle offering, which I covered in more detail in this Field Note. Pinnacle is the first methodology I have seen that scores agents on whether they get the work right, not on how fast or how cheaply a model responds. This is an important development that could help spur more agent adoption. Enterprises have lacked a real, actionable way to compare agent performance across models, infrastructure, and vendors. Without that, they cannot say with confidence what to deploy or what it will cost to run at scale, and that gap is slowing adoption and undermining any defensible ROI case for agentic AI. My only caveat is that Pinnacle is still new and will not settle every argument about how to benchmark agentic AI. But it is serious enough for enterprises to put on the evaluation checklist now, rather than wait for a second version to mature.

Last week Microsoft announced that both Copilot Studio and Copilot Cowork will get embedded application development capabilities. This is similar to a trend we are seeing where major capabilities consolidate into a more unified and powerful interface. There are two key benefits to this approach. The first is that capabilities like this, paired with natural-language agents, are opening up entirely new pathways for no-code development. And while there are a lot of things to consider as we open up coding to more people (like security, governance, sprawl, etc. etc. etc.), these departmental applications are often where innovation and technical ROI are incubated. But I also see the consolidation of surfaces as good for enterprise IT teams, who have had to deal with a number of different tools — sometimes even from one vendor — that have become hard to manage and support. It’s not a very surprising move for Microsoft, which has been steadily aligning its Copilot agent and Power Platform no-code products for a couple of years. I am looking forward to seeing what is going to be announced at the company’s Ignite conference later this fall.

On the pro-code side of the equation, GitHub also added model routing into its platform last week. It’s pretty interesting news for a couple of reasons. First, since token costs are a major driver for developers right now, model routers help customers save significant money. And the cost variability is massive in some cases, depending on the inputs and the required outputs. The router’s goal is to evaluate your inputs and direct the work to the right model based upon your needs. The second reason is that this new project from GitHub may offer the broadest choice of models and how they are hosted (meaning on-prem or in different clouds). While model routers have been around for a while now, GitHub may get traction based upon its position with developers and its approach to breadth. Hyperscalers like AWS and Azure have their own routers but are only aligned to the models they support. OpenRouter (which is being acquired by Stripe) and Switchyard from NVIDIA open up routers across different clouds — though not necessarily for on-premises models — which comes in really handy for testing and pre-production. This reinforces the GitHub AI value proposition around choice and cross-platform support.

It was great seeing the news that Cloudera’s platform will incorporate Mistral’s sovereign AI models. Almost every AI project I see starts by moving data somewhere else, which means that now you’ve got a second copy to secure, govern, and keep current. For plenty of regulated companies, that copy can’t legally exist at all. Cloudera is enabling customers to run the models where the data already lives, including air-gapped environments where nothing gets out. Mistral’s weights are downloadable, which is the whole reason it works. You bring the model inside the walls instead of sending your data out to somebody’s hosted endpoint. And the thing is, renting a model was out of the question for most of these buyers. The piece I’m most interested in is Mistral Forge. It lets you train against your own private data inside that same controlled setup. And while pretty much every data platform has a model catalog now, not many of them can enable you to do the training part.

OpenShift AI 3.5 arrived with a new way to sandbox agents, which Red Hat calls OpenShell. They put the fence down in the operating system instead of leaving it at the container. Getting out of a container is well-understood work with well-understood tools. Getting past the kernel’s own access controls is a much harder job. If you’re letting agents write and run their own code, that difference determines how much you’re comfortable handing them. My big question is who ends up writing the policy, because the platform team and the person building the agent often want very different things. Whoever writes it owns the fallout when an agent does something nobody signed off on.

I’ve written a fair bit about sovereignty this year. What buyers want is to have their data under their own country’s laws, where a foreign government can’t compel access and the vendor holding it can’t change terms out from under them. NVIDIA, Cisco, and Rackspace all have sovereignty stories that run much wider than any one partner. But for the layer that makes AI decisions traceable, all three of them just reached for Palantir. NVIDIA worked Palantir’s ontology into its own supply chain. Cisco is delivering Palantir’s cybersecurity ontology through its Secure AI Factory, pointed at government and regulated buyers. Rackspace is pairing Blackwell hardware with Palantir Foundry in a pod for that same crowd. None of them decided to build this layer themselves, and honestly, I don’t blame them. An ontology is the map of what your data means — which things exist, how they connect, and who’s allowed to touch them. That’s slow, thankless work that’s easy to get wrong, and Palantir has been at it for twenty years.

Eventually a regulator will likely ask why your AI system made a certain decision. A big part of the answer comes out of the ontology. In these three stacks, it’s Palantir producing it, not NVIDIA, Cisco, or Rackspace. So, if you’re buying architectural sovereignty, here’s the question: What happens to your ability to answer that regulator if the ontology supplier changes its pricing, its terms, or its owner? You’re trading one dependency for another, and that can be the right trade. Plenty of companies are building ontologies, and Palantir is one of the best at it. But that ontology is a description of your own business. Whoever you pick, know what it would take to move that ontology somewhere else. And keep that migration plan current, even if you never use it.

My gripe with retrieval has always been that somebody has to guess how hard a question is before anyone asks it. You set the search depth up front and live with it. Ask something simple, and you’ve overpaid; ask something hard, and you get a thin answer, or the agent loops for what feels like forever. To get around this conundrum, Databricks trained a small model to make that call itself, question by question, and stop once it has enough information to answer. The company calls it the Adaptive Instructed-Retriever, and it’s the retrieval layer running under Genie. Databricks says it answers in under six seconds, more than twice as fast as the models it tested against. That’s the company’s own benchmark, so read it as directional rather than externally verified. If I were evaluating it for deployment, I’d press on who gets to tune the quality-versus-latency dial, because the data underneath still decides how far any of this goes.

For a long time, I have felt like so many analytics vendors spent far too much money prettying up their UIs. Alteryx is spending on being more and more callable from UIs it doesn’t own. Three of the five things the company just launched are really doors into Alteryx from somewhere else — an MCP server, a ChatGPT plugin, and a GitHub install for other tools. The bet is that business logic is the most valuable part, while the interface has become almost irrelevant and swappable. Now the interesting part, I think, is that there’s a real cost to the bet Alteryx is making. When the work moves into ChatGPT and people aren’t even opening Alteryx, seat growth becomes a bit of a challenge.

From the Alteryx announcement itself, Agent Studio is the thing I’m paying closest attention to, because it’s designed to take a dataset that’s already trusted and governed and turn it into a conversational agent without making you rebuild it.

What’s a robot, exactly? Ask ten people and you’ll get more than ten correct answers. That’s because robots have many embodiments spanning a range of capabilities from simple task automation to full autonomy.

Given the vast diversity of physical AI systems, robotics cannot reach global scale inside closed, vertically integrated ecosystems. Software, silicon, modules, and sensors come from different vendors, and today each one describes machine capabilities in its own terms. Shared definitions give every supplier a common target for right-sizing its piece of the stack. You can’t specify what you can’t describe.

On September 8, 2026, Arm introduced a Robotics Capability Framework, alongside Arm Total Design for Physical AI, an ecosystem program with more than 80 companies, including AWS, NXP, Siemens, Hugging Face, QNX, and Unitree Robotics. The framework defines six levels, from RL0 (reactive) through RL5 (self-improving). It’s analogous to SAE J3016, the standard that defines six levels of driving automation, but for robotics instead of vehicles. Each level connects real-world use cases to system requirements: latency, compute placement, memory, power, determinism, and safety. That’s what silicon vendors need to size a part, so I see it as a much-needed supply-chain initiative rather than an academic taxonomy exercise. Chief architect Richard Grisenthwaite published a “manifesto” explaining the framework. Arm is inviting the industry to contribute.

At an event held last week at its Cupertino headquarters, Apple announced new iPhones, Apple Watches, and AirPods. It had previously announced the M6 Mac Mini and M5 Ultra Mac Studio, but there were no tablet or MacBook announcements. The primary focus of the event was the iPhone Duo foldable phone powered by the next-generation 2nm A20 Pro processor. The iPhone Duo is clearly Apple’s long-term plan to capture some of the fast-growing foldable market while also raising average selling prices. The Duo doesn’t quite match the size of the iPad Mini, but at 7.6 inches it comes close. There had been rumors that Apple solved the crease issue with foldables, and with the matte finish on the Duo, it seems to have done a good job of reducing the crease’s visibility. I would say that Apple is now on par with some of the best creases I’ve seen in the industry. To get there, the company has borrowed heavily from industry advances developed over the last seven years. I believe that Apple will have a hard time keeping up with demand, at least for the first few months. I think the company will also help to broaden the category and give other vendors more visibility — including Samsung, whose Fold8 is currently thinner and lighter than the Apple Duo.

Apple also introduced the new C2 modem, its next-generation modem for the iPhone 18 Pro and iPhone Duo. This modem is critical because it is the first Apple modem to add support for U.S. mmWave bands, enabling Apple to support the technology globally down the road. This also reduces Apple’s price of entry for mmWave, thanks to having its own transceiver and power amplifiers. While Apple hasn’t given many details about this modem, its launch does show that the company is moving faster in deploying its own modem technology. The company struggled to get its modem silicon out the door after acquiring Intel’s modem division in 2019. Apple now seems to be on a fairly quick cadence to keep iterating modem designs and adding features. It remains to be seen when Apple will have a 6G modem, but it could have one as soon as the C4 or C5 generation. If the C2 is capable of handling 3GPP Release 18, a.k.a. 5G-Advanced, that would bode well for Apple delivering a 6G-capable (i.e., Release 21 compatible) device. It will also be interesting to see how Apple’s modems compare to Qualcomm’s, since those are already found in both Apple and Android devices.

At the Goldman Sachs tech conference, T-Mobile’s CTO John Saw talked about the importance of 6G to carriers. He once again brought up the concept of kinetic tokens and physical AI, reiterating his earlier point that when physical AI moves, the compute must follow. That means having infrastructure in place to support the needs of physical AI, since devices won’t necessarily have enough onboard compute to operate fully independently. I think T-Mobile already has the most advanced 5G network, so it makes sense that the company would also take the lead on 6G and want to ensure that it has an AI-native network that meets the needs of physical AI. For more context, see my interview with John Saw from earlier this year.