Microsoft's diagnostic AI heads towards patient testing

Microsoft takes diagnostic AI towards patient testing

A diagnostic AI can choose which question to ask next, then use the answer to decide what to test. Microsoft's next challenge is finding out how that approach works with patients in a hospital.

Our main story today is Microsoft's diagnostic system, MAI-DxO, and whether its step-by-step approach can help medical teams gather the evidence that leads to a useful diagnosis.

On 22 October, Microsoft published new results in Science and announced a prospective evaluation with Beth Israel Deaconess Medical Center. Prospective means the researchers will assess the system as patient interactions happen. That's the next stage of this work, following a study built around simulated medical cases.

Microsoft reports diagnostic accuracy of 83 per cent on complex cases from the New England Journal of Medicine, compared with 36 per cent for generalist physicians who had reference resources available. Patient outcomes, safety and effectiveness alongside medical teams remain to be established.

The interesting part is how the system reaches an answer. It requests information and selects tests in stages. It also uses a simulated panel of physician roles, giving its diagnostic process several perspectives to work through. Those roles are parts of the AI system.

That changes the task considerably. Give a model a fully assembled case and you're asking it to interpret the evidence in front of it. Let it choose what information to request, and you're also asking it to decide where the gaps are. Each answer can shape the next question. A test result can make one explanation more plausible and send the investigation in a different direction.

There's a practical reason to care about that sequence. In diagnosis, the information you have depends partly on what you've thought to ask. A system could be good at recognising a pattern once all the clues are present, yet much less useful at finding the missing clue. This method brings that earlier part of the work into the evaluation.

It also creates a richer question than whether the final diagnosis was correct. What did the system ask for before it got there? Which result changed its reasoning? Did the simulated panel help it explore a useful alternative? These are ways of examining the process, and they give clinical researchers something concrete to investigate as the work moves into patient interactions.

The hospital setting adds the working relationship with medical staff. Information gathering happens within care, with people providing answers and clinicians using their judgement. How the system fits into that relationship is central to whether its approach becomes useful. The published study and the planned evaluation address different parts of that problem.

For health organisations, my read is that the most promising feature here is the ability to study the choices made along the way. A final accuracy score tells you where the system ended up. The sequence can help explain how it got there, and where an interaction with a medical team might help or hinder it.

There's no new diagnostic service for listeners to use in this announcement. There is a substantial research result and a planned opportunity to test the method with patients. I'd be watching whether its information-gathering decisions remain useful in that setting. That's the part with a direct connection to the work a clinician is trying to do.

Cisco tests the whole security investigation

We'll leave that hospital study there; a shorter development in security also puts an AI's investigative choices under the microscope.

Cisco has extended its FAITH cybersecurity evaluation framework to cover agents that use tools across multiple steps. The addition, announced on 23 October, initially integrates a benchmark called VulnLoc. It asks an agent to find vulnerable files in a code repository, then recognise that the specified vulnerability is absent from the corresponding patched repository.

That second half is especially useful. An investigation needs a way to finish after a problem has been fixed. If an agent keeps raising the same concern against the repaired code, someone still has to spend time working through it. Evaluating both versions brings that cost into view.

The framework records tool interactions, answers and execution failures. That lets a developer see the difference between a completed search that found no specified vulnerability and a run that stopped before completing its task. A blank result on its own would leave those two situations looking much too similar.

You can see the value when comparing agents. One might arrive at the right file after a useful chain of tool calls. Another might spend its execution allowance exploring the wrong area. Looking at the recorded investigation makes those behaviours easier to examine than a single correct-or-incorrect answer would.

It also gives false alarms a proper place in the assessment. Finding the vulnerable file is one useful behaviour. Recognising the repaired state is another. Together, they let the evaluation ask whether the agent can respond to a change in the code, instead of repeatedly identifying a location associated with the original problem.

Running this takes some setup: a compatible tool-calling model and a configured Docker or Kubernetes environment. Those are the systems used to provide the execution environment. Results belong to the benchmark and that setup, so the useful comparison is between investigations run under explicit, understood limits.

For security developers, I think the strongest contribution is making the end of an investigation measurable. As automated scanning expands, analyst attention becomes part of the economics. An agent that can correctly recognise a fix could save time long after its first alert.

Dessa learns conversation through speech

Voice AI has a different challenge: keeping up with the way people actually take turns talking.

Block unveiled Dessa on 23 October, a conversational model trained on speech alone. Block says it learned from human conversation without text or pretrained models, can listen while speaking, and runs locally on a MacBook Pro with an M4 Max chip or better.

Listening and speaking at the same time is called full duplex. In a conversation, that opens up room for an interruption or a quick acknowledgement while the other person is still talking. The interface has to work out what to do with that incoming sound while it's producing its own reply.

Training directly on conversation is interesting because speech carries timing and tone as well as words. A transcript can preserve what someone said while losing the pause before it, or the point at which another person started speaking. Those details help shape the flow of a conversation, so retaining them gives a model a different kind of material to learn from.

For someone building a voice interface, the attraction is less rigid turn-taking. You could imagine correcting a detail without waiting for a long answer to finish.

Public demonstrations are available, and The Verge observed awkward conversational errors in them. General access hasn't opened. Block is accepting applications for limited safety-research access, leaving selected researchers as the audience able to investigate the system more closely.

The local hardware claim is also interesting for developers exploring where a voice application might run. An M4 Max or better is a specific, demanding starting point, and independent performance measurements haven't been established. There's no general-release date to plan a product around yet.

My interest is in what speech-first training might let interface designers do with timing. If a model can use an interruption meaningfully, a conversation could become easier to steer. The useful next evidence would be how consistently that works outside the demonstrations, especially when the speaker changes direction halfway through a thought.

Claude gains a new Google Cloud route

For organisations buying AI, a change in how a service is delivered can be as useful as a new model.

Anthropic's own managed Claude service became generally available through Google Cloud on 22 October. Google confirmed the expanded choice on 23 October. This adds a route to the full Claude platform alongside the existing Google-managed offering.

Customers can use Google Cloud identity and access management, usually shortened to IAM, and Google Cloud billing. That gives them a familiar way to control access and pay while using Anthropic's platform features. Those include code execution and Managed Agents, which remains in beta.

The immediate appeal is access to newly released Claude capabilities without waiting for Google's integration. An organisation already purchasing through Google Cloud can keep that purchasing route while reaching features offered directly through Anthropic's managed service. For developers, that could shorten the gap between a feature becoming available and being able to try it inside an existing commercial arrangement.

There are now two operating arrangements to compare. Anthropic runs the new service and acts as its data processor. The existing Google-managed option retains Google's operating arrangements and regional controls. The new offering lists US and Global endpoints; the Google-managed option has US, EU and APAC residency choices.

That regional detail can settle the choice quickly. A buyer looking for an APAC residency option has a concrete reason to examine the Google-managed service. A buyer prioritising the newest Claude platform features may find the Anthropic-managed route more useful. The invoice can come through the same cloud provider while the organisation handling the data changes.

This also separates two kinds of availability. The managed service is generally available, and Managed Agents is still a beta feature within it. A developer deciding whether to build around that capability has a different maturity decision from someone choosing an established feature on the platform.

My takeaway for organisations is that the new route makes procurement more flexible, while giving architecture and data teams a specific comparison to make. Feature access, operator and region now belong in the same decision. The useful question is which arrangement fits the application you're trying to deliver, including where its data needs to be processed.

NVIDIA reserves the manufacturing steps around the chip

Let's step away from software for a moment and look at the factories behind the compute.

On 21 October, NVIDIA announced capacity agreements with six manufacturing partners. They cover substrates, advanced packaging, chip testing and optical engines: several of the steps and components needed to turn processor designs into working infrastructure.

The substrate is the base that helps connect a chip into its package. Advanced packaging brings components together in increasingly complex assemblies. Testing checks the manufactured parts. Optical engines belong to the connections that carry information using light. Expanding one part of that chain leaves the others with more work to handle.

NVIDIA says the substrate agreements target two and a half times current capacity over three years. It has also committed a capacity reservation advance of 1.1 billion US dollars to KYEC, supporting new testing facilities in the United States. High-volume production there is targeted for April 2027.

A capacity reservation gives a supplier a commercial commitment around which to plan an expansion. The money and the intended output are linked across time: investment comes before the additional manufacturing capacity is ready to serve customers. April 2027 is therefore a useful date in this announcement, because it puts one part of the buildout on a production timetable.

For cloud buyers, these are future supply commitments. The additional capacity has to move through construction, qualification and production before it can contribute to available compute. The announcement supplies targets for that process, without establishing future GPU availability or prices.

What catches my attention is the range of manufacturing work being addressed. A faster processor design still needs the surrounding production chain to deliver it at scale. Packaging and testing can influence deployment schedules even when they attract less attention than the processor itself.

For organisations planning infrastructure, I'd read these agreements as evidence of where expansion money is going and which dependencies NVIDIA is trying to address. The milestones at those suppliers may become useful signals for planning later capacity, particularly as the April 2027 testing target approaches.

A forest map that looks beyond tree cover

There's a useful distinction in a new environmental map: land can look green while its forest has changed dramatically.

On 22 October, Google DeepMind, Google Research, the World Resources Institute and the International Institute for Applied Systems Analysis released Forest Typology 2020. It classifies land at ten-metre resolution into six categories, distinguishing natural forests, planted forests, plantations and tree crops.

That helps with a problem in ordinary tree-cover maps. If a natural forest is replaced by a plantation, the area can become green again. Counting tree cover alone can obscure the change. Identifying the type of cover gives conservation and supply-chain analysts a way to investigate what has happened to the land.

The data are freely available under an open licence through Google Earth Engine. There's also an early annual series spanning 2017 to 2025, allowing analysts to explore changes across multiple years.

The classification is probabilistic, and that historical series remains an early release. It's useful for identifying patterns and places to examine more closely; a conclusion about an individual site still needs site-specific evidence.

For environmental analysts, the practical improvement is a more informative starting point. Two areas with similar tree cover may represent very different land use. Separating them can change which places deserve attention in an assessment, and help make the question more precise before the detailed investigation begins.

Sweden changes the route to workplace AI

A brief workplace story from Sweden shows how access to the same AI models can take different routes.

Sweden's Government Offices told broadcaster SVT that the ChatGPT and Claude browser interfaces would be blocked on staff computers from 26 October. SVT reported the decision on 23 October.

Staff are being directed to approved Microsoft AI tools. Access to the underlying ChatGPT and Claude models also remains available through the Intric platform. The restriction applies to public chatbot websites in this workplace; citizens' access is outside its scope.

For affected staff, the immediate change is where they go to get AI assistance. The offices have identified approved routes that retain access to models whose public websites are being restricted.

My read for other organisations is that this makes the access arrangement the important detail. A list of blocked websites tells only part of the story when the same models remain available through an approved service. The practical effect depends on what staff can do through that route, and which tools their employer has made available.

What Changes for You

If you've been waiting to give a local assistant a voice, there's now another piece you can use.

Ollama added text-to-speech support on 24 October using Gradium's Phonon models. It's available now on Apple Silicon Macs, with Windows and Linux speech support still forthcoming. The launch announcement recommends Ollama version 0.40.11 or later.

Developers can generate streaming audio locally through an API compatible with the OpenAI speech interface. That compatibility gives developers already using the OpenAI speech interface a familiar request format for local audio generation.

Streaming lets an application start producing speech as text arrives, including reading an assistant's reply while that reply is still being generated. That gives builders a way to connect text output to spoken output without waiting to assemble the entire response first.

The speech-generation request stays on the Mac. If the text comes from a connected cloud chatbot, that chatbot still has its own data handling. Ollama is providing the voice-output step here; speech recognition and the rest of a conversational assistant remain separate pieces.

There's an important licence distinction for anyone building something commercial. The default English checkpoint has 31 million parameters and uses Apache 2.0. The 40-million-parameter checkpoints, including multilingual models, use a non-commercial licence. Choosing a model therefore changes both the language options and the permitted use.

For Mac-based builders, I see a practical way to prototype spoken replies while keeping audio generation on the device. The default English model's licence also gives commercial projects a different path from the larger non-commercial checkpoints. That choice is worth making at the start, before a prototype's language requirements become a dependency you have to replace.