Microsoft's outage exposes AI's shared dependencies

When the assistant can't reach your work

Your AI assistant can be working perfectly and still be unable to read your mail. Microsoft's global outage left people and connected assistants waiting on the same underlying services.

Our main story today is the Microsoft outage and a practical question for organisations using AI: how much of your backup plan depends on the same systems as your everyday tools?

The disruption began on 12 November. ABC reported Australian organisations were affected from about three in the morning, eastern daylight time, on 13 November. Microsoft said there was no indication of a cyberattack. For affected people, the immediate consequence was interrupted access to the services they use to organise and carry out work.

That disruption also reached Claude. Anthropic confirmed errors affecting its Microsoft 365 connector and Claude for Outlook over an interval lasting more than a day. Those integrations give the assistant access to information inside Microsoft's services. If that connection fails, a functioning language model still can't reliably retrieve the mail or calendar information needed to complete a request.

Anthropic marked its connector incident resolved at 8.49 on the morning of 14 November, Sydney time. Microsoft's continuing recovery could still cause occasional errors or delays. A final worldwide resolution time and a completed explanation of the underlying cause weren't established in the reporting available for this episode.

The dependency is the interesting part. From a person's desk, Outlook and Claude look like different tools. They have different interfaces and do different jobs. Yet ask Claude to work with information held in Microsoft 365, and both now depend on access to that information. Switching the assistant doesn't repair the service underneath it.

Consider a request to prepare for a meeting using recent emails and the calendar entry. That's a useful example of a connected assistant's job. The model provides the language and reasoning; the connected service provides the current details. During an outage, the missing part may be the information itself. A second assistant pointed at the same mailbox would encounter the same obstacle.

For business continuity, I'd put shared dependencies on the same page as the list of applications people use. A list showing two assistant suppliers can suggest more resilience than the workflow actually has. Trace where each one gets its information, and you can see which jobs have a genuine alternative and which jobs share a single point of failure.

That also changes the conversation during recovery. An assistant being available again is useful, but a worker needs to know whether the connected task can finish. Can it retrieve the relevant messages? Can it access the calendar information? Those are concrete checks tied to the work people were trying to do.

There's a distinction here between having another way to think through a problem and having another way to reach the evidence needed to solve it. A standalone conversation may remain useful while a connected workflow is interrupted. Planning for that reduced capability gives people a clearer picture of what work can continue.

My takeaway for organisations is to assess resilience at the level of the task. For a mail-dependent assistant, the recovery path runs through mail access. Buying another AI subscription might give you more choice of model, while leaving that dependency completely unchanged.

Claude agents inside your own environment

That shared dependency is the big operational story. A separate Anthropic release gives organisations more control over where their agents run.

On 12 November, Anthropic introduced a private beta for self-hosted Claude Managed Agents. Customers can operate the service, its database and execution workers in their own cloud or on-premises environment.

The change extends beyond hosting the sandbox where an agent runs commands. It includes the agent harness, credentials and session history. The harness is the software around the model that manages the agent's work. Session history records the ongoing interaction, while execution workers carry out the tasks.

Putting those components inside a customer's environment creates a more substantial hosting choice. An organisation can retain the Managed Agents APIs while keeping operational state and execution infrastructure within systems it operates. For someone integrating agents into a sensitive internal workflow, that can make the location of those records and credentials easier to align with existing controls.

The model connection remains external. Claude requests still go to a selected provider or gateway, so the arrangement requires access to that model service. Existing zero-data-retention arrangements apply to model requests; self-hosting doesn't automatically establish one.

Those boundaries help explain who this is for. A business that wants to manage where its agent history sits may find the beta relevant. A business that needs Claude inference to run entirely offline needs a different capability from the one announced here.

There's also an operational job attached. The customer runs the service and database as well as the workers. That gives its infrastructure people more control over deployment, and responsibility for keeping those components available. Hosting location and day-to-day operation come as a package.

I can see the appeal for organisations that already operate sensitive software in their own environment and want agents to fit that pattern. Keeping the API also means the application-facing interface can stay familiar while the hosting arrangement changes underneath it.

Access is through an Anthropic account team, and this remains a private beta. The useful decision now is whether control over agent state and execution is valuable enough to take on that operational work, with the model-service connection still part of the design.

Teaching models which text to follow

Another piece of agent plumbing is getting attention: how a model distinguishes the job you've given it from material it reads.

IBM released experimental Granite 4.1 models on 12 November using a format called LLMON. The previews come in three-billion and eight-billion parameter sizes, with tooling for marking instructions, data and the relationships between them.

This addresses indirect prompt injection. That's when instructions embedded in something an assistant reads, such as retrieved material, try to redirect its behaviour. The assistant needs to use the material as information while continuing to follow the actual task.

LLMON gives that distinction a structure the model is trained to recognise. It uses reserved tokens, special markers with defined roles, and addressable blocks. An instruction can be linked to the particular block of information it's supposed to process.

Imagine asking for a summary of a document. With this approach, the summary instruction and the document occupy distinct, marked parts of the input, and the relationship between them is explicit. The model has a trained format for recognising which text describes the task and which text supplies the contents.

IBM reports substantially better resistance on static indirect-prompt-injection benchmarks, while retaining comparable general capability to conventional Granite models. That makes the release interesting as a way to test whether training and input structure can improve an agent's handling of external information.

The boundary is specific: this separation is learned behaviour, and adaptive attacks across multiple turns remain an area of work. IBM has released the previews for evaluation rather than production. The downloadable three-billion parameter model is licensed under Apache 2.0.

For developers, the opportunity is to experiment with a different representation of the task. A structured prompt makes the intended relationship between an instruction and its data explicit; the model's training then gives those markers meaning. That creates something concrete to evaluate against an existing retrieval workflow.

My interest is in whether this makes applications less dependent on layering more warning text into every prompt. If the model handles the distinction more reliably at this level, developers gain a useful foundation for agents that read outside material. These previews give them a way to measure that behaviour directly.

Restoring GPU workloads in seconds

There's a very different kind of waiting that infrastructure engineers know well: the model is available, but the server isn't ready.

Nvidia introduced Snapshot on 10 November, an open-source component that captures initialised CPU and GPU state for inference workloads running on Kubernetes. Inference is the work a model does when answering a request.

Before a newly started workload can handle those requests, it may need to load the model, compile parts of the workload and capture GPU execution graphs. Those graphs describe work for the GPU to execute. Snapshot saves a checkpoint after that preparation, allowing a compatible replica to restore the ready state.

The practical attraction is avoiding repeated preparation. If you've already done the expensive initialisation for a workload, a saved checkpoint gives another compatible instance a starting point much closer to serving requests.

Nvidia reports that its development partner Crusoe reduced readiness time for GLM-5.3 from roughly eight minutes to 31 seconds on HGX B300 systems. That's a substantial difference for the measured restoration path. It excludes infrastructure provisioning and loading the container image, so those parts still belong in an operator's calculation of how long extra capacity takes to arrive.

Compatibility is also concrete. The target node needs the same GPU model and driver. Creating checkpoints and storing them have costs, so the design suits a deployment where the saved preparation is worth that extra work and storage.

The economic question is how much spare GPU capacity an operator keeps ready for sudden demand. If starting another replica takes several minutes, keeping more capacity warm can be attractive even when it isn't busy. Faster restoration could let operators revisit that balance.

I'd judge Snapshot by how it changes that balance for a particular service: the cost of checkpoints, the speed of restoring them, and the capacity kept ready between demand peaks. The reported result makes restoration worth investigating for compatible fleets. Its value comes from shortening a stage that operators repeat whenever they need another prepared instance of the same workload.

New York opens frontier-AI registration

For companies supplying frontier models, there's also a new administrative date to put alongside the technical release calendar.

New York opened its RAISE Portal on 10 November. Large frontier-AI developers have a registration deadline of 1 January 2027, giving covered companies an operational route to meet the state's requirements.

Beginning in January, large frontier developers must publish safety frameworks. All covered frontier developers face critical-incident reporting and model-transparency requirements. The distinction between those groups matters: the announcement assigns different obligations, rather than treating every developer as having the same registration and publication duties.

New York also launched an independent AI-evaluation initiative based at Binghamton University. It brings together more than 80 researchers, with reviewing developers' published safety frameworks among its initial tasks. That work is intended to inform oversight.

A safety framework describes how a developer approaches the risks associated with its models. Publishing one puts that approach in front of people outside the company, where it can be compared with other developers' approaches and examined by researchers. The new initiative gives that examination an organised home.

For enterprise purchasers, I think the useful prospect is more structured supplier information. Comparing model providers often involves comparing technical capabilities alongside the arrangements around their use. Public frameworks can add detail to that second part of the decision, giving buyers something specific to discuss with a supplier.

The research initiative is at its starting point. Its announced initial work includes reviewing those frameworks; completed independent model evaluations haven't been established by this announcement. Purchasers can use the published material to understand a supplier's stated approach while watching for the researchers' findings as the work develops.

These are New York requirements. An Australian organisation buying an AI service doesn't acquire a New York registration obligation simply by using it. The immediate deadline belongs to covered developers, while the resulting transparency may also help customers elsewhere compare how those suppliers operate.

Edge0's local-agent release

If your interest runs closer to the computer on your desk, Edge0 has released two sizeable local-agent models.

The 12 November release includes 145-billion and 120-billion parameter models with inference tooling for coding and agent workloads on personal hardware. The published build instructions target Nvidia GPUs with CUDA 13 on Linux or Windows.

The hardware story needs the detailed model card. Edge0 advertises a 29-gigabyte laptop peak-memory figure, while the card separately documents GPU memory, system RAM and SSD use across configurations. Those are different resources in a machine, and the headline figure alone won't tell you whether your setup can run the workload. Published Apple benchmark results also don't establish a macOS release.

The licence permits specified personal, research and internal uses. Commercial model services, and independent commercial coding or office assistants, require separate written permission. Upstream Qwen terms apply too.

For a technically equipped developer, this creates another option for evaluating coding agents locally, with more control over where inference happens. I would weigh it as a hardware and integration choice: does the supported build fit your machine, and does the permitted use fit the software you intend to run? That determines whether these downloadable models can become part of your working setup.

Measuring carbon removal with fewer samples

A research result from Microsoft and Terradot puts AI to work on a problem firmly outside the computer.

On 12 November, they described TerraNova, which adapts representations from Microsoft's Aurora weather model and combines them with field measurements to predict outcomes from enhanced rock weathering. That's an approach to carbon removal involving crushed rock.

The research keeps physical soil sampling in the process. Its goal is to use predictions and measurements together to improve site assessment and verification. The authors report a 75 per cent reduction in sampling across seven large sites, at a target error of 0.75 tonnes of carbon-dioxide equivalent per hectare per year.

That error target gives the sampling result its meaning: it's the level of accuracy the reduced measurement effort was designed to achieve. Sampling is one part of a project, so any eventual saving in total costs depends on how much that work contributes to the overall bill.

The public abstract is available, with the working-paper files embargoed until 12 December. Microsoft describes the research as awaiting peer review. Broader performance and realised savings remain to be established.

For carbon-removal organisations, the promising idea is a less costly way to check a physical outcome while retaining measurements from the ground. If it holds up across more locations, that could make verification more practical alongside the removal work itself.

What Changes for You

To finish, there's a new image model you can use through hosted services or explore through downloadable weights.

MiniMax H3-Image supports image generation and editing with up to 16 reference images. Its model card describes native output of approximately 16 megapixels, including images measuring 4096 by 4096 pixels, without an upscaler. The resolution is produced by the model itself.

That combination gives creators and builders another option for workflows involving both a new image and changes guided by existing images. Multiple references let a request draw on more visual material, while the native resolution provides a large output to work with.

Hosted access is available through MiniMax's API, MiniMax Code and Hailuo. Vercel also lists standard and Highspeed variants through AI Gateway. The licence and Vercel availability announcement are dated 10 November; MiniMax's release article followed on 11 November.

For local deployment, the checkpoint is 68.65 gigabytes. That's the download's file size; running the model requires a separate assessment of runtime memory and hardware. Hosted access offers a route for people who want to use the model without operating that infrastructure themselves.

The weights' community licence has a significant territorial boundary. It excludes the European Union, the United Kingdom, South Korea and the United States from its applicable territory. Australia isn't listed as excluded, with service access and commercial use still governed by the applicable terms.

For an Australian builder, the useful addition is choice: integrate hosted generation and editing, or evaluate the weights for a workflow you operate. The combination of reference-image editing and native high-resolution output is the practical reason to consider it. Whether the hosted or self-managed route fits will depend on your hardware, the service terms and where the resulting product is intended to be used.