Microsoft takes on the machinery of long-running AI agents

Microsoft takes on the agent machinery

An AI agent can restart after a crash and still repeat the very action you wanted it to do once. Microsoft's latest Azure release puts that recovery problem at the centre of running longer jobs.

Our main story today is Microsoft's new Copilot harness in Foundry Agent Service: how much of an agent's working life can a developer hand over to Azure, and what still needs to live in the application?

On 28 October, Microsoft launched the harness as a public preview. Alongside it, interruption recovery for hosted agents became generally available. Australia East is among the supported regions, so there's a local region in the availability list for Australian developers assessing the service.

A harness is the machinery that keeps an agent working. The model decides what to do, a tool carries out an action, the result comes back, and the loop continues. Foundry's harness manages that loop and the sandbox, the environment where the agent works. It brings together reusable skills, files and tools, plus bounded subagents that can take on parts of a job.

That's useful territory for a managed service. A developer building a longer workflow needs somewhere for it to run, somewhere for its working files, and a way to connect the tools it uses. Having those pieces managed together could reduce the amount of execution infrastructure the developer has to assemble and maintain.

Recovery is where the application design becomes especially important. Foundry restarts interrupted work with its original input. The application saves its own checkpoints and prevents duplicate external actions. Conversation history alone doesn't do that job.

Imagine, for example, an agent preparing a report and sending it to a colleague. If it stops after the message leaves, restarting the original request could send the report again. A useful checkpoint records that the sending step completed. The application can then recognise that result when work restarts, while keeping any unfinished work available to continue.

The same distinction applies even if there's a detailed chat history. A record of what the agent intended to do and a record of what an external service completed serve different purposes. Recovery needs enough application state to work out which actions have already happened. Otherwise, a successful restart can still produce the wrong outcome.

For developers, that gives this preview a fairly concrete evaluation task. Follow one job through an interruption and see how its saved state lines up with the actions outside the sandbox. The useful evidence is in the completed work: which steps survived, which were repeated, and whether the application recognised an action that had already succeeded.

There are also two decisions to make before committing a project. The preview fixes the choice of harness when an agent is created; you can't switch that agent to another harness afterwards. And harness runtime billing begins on 1 December 2026. Model inference and connected services remain chargeable before then, so an evaluation already has costs beyond the runtime itself.

My read is that Foundry could make long-running agents easier to build by taking on more of their execution machinery. The valuable engineering work left with the developer becomes more focused: recording progress and connecting each restart to what has already happened. For a job that changes something outside the agent, getting that part right is what makes recovery useful.

GitHub separates agent work from write access

That leaves us with the restart question; GitHub's shorter update tackles another practical part of agent work: permission to make changes.

GitHub Agentic Workflows became generally available on 28 October. They let coding agents handle repository maintenance inside GitHub Actions, including issue triage, failure analysis and documentation updates.

The starting point is a set of Markdown instructions, which compile into the YAML configuration that Actions runs. That gives the person maintaining a repository a prose-based way to describe a task, while the execution still sits inside the repository's existing automation system. The default Copilot engine requires a Copilot licence.

The interesting design choice is how access is divided. Agents run read-only by default. Separate, scoped output jobs handle changes. An agent can examine material and propose work without carrying unrestricted permission to rewrite the repository as it goes.

Consider failure analysis. Reading a failed run, working out a likely explanation and preparing an output are useful activities on their own. Applying a change introduces a different decision. Keeping that boundary visible gives maintainers a place to inspect the work before it affects the code or documentation other people rely on.

Threat detection has two behaviours worth distinguishing. In the default warning mode, reviewable outputs can pass through with warnings attached. Strict mode blocks outputs when it detects a threat, and also blocks them if the detector fails. That setting changes what the workflow can deliver, so it has a direct bearing on how the repository handles agent-generated work.

A warning mode can suit a process where someone examines flagged proposals. Strict mode makes detection a condition of allowing the output through at all. Repository review and merge controls then determine how a permitted proposal becomes an accepted change.

For maintainers, I think the useful advance is having a defined route from reasoning to a proposed update, with permission to apply it handled separately. It makes tasks such as documentation maintenance a more practical fit for existing Actions workflows. The choice between warning and strict enforcement belongs alongside the repository's review settings, because together they decide what actually reaches the branch.

Cloudflare reaches private origins

There's a related change for people running the servers that these applications depend on, especially privately addressed backends.

On 30 October, Cloudflare announced general availability of its application services for private origins. An origin is the server behind a website or application. Here, it can keep a private IP address while Cloudflare routes public requests to it over existing Cloudflare One connectivity.

That lets services including the web application firewall, caching, bot management and Workers operate in front of private APIs, agent backends and MCP servers. MCP is a protocol for connecting AI applications to tools and data. The origin's own public IP doesn't need to be exposed for these application services to sit in front of it.

The practical change is in the route a request takes. Someone reaches the public-facing application, Cloudflare applies the configured services, and the request travels over the private connection to the backend. An organisation can keep that backend privately addressed while using application controls at the public entry point.

Those controls do different jobs. A firewall handles rules about incoming requests. Caching can serve stored responses. Bot management deals with automated traffic. Having them available on this route gives an organisation more of its existing application toolkit around a service that lives on a private network.

Access to the application itself still follows its authentication and authorisation rules. The private address reduces direct origin exposure; the public-facing application decides who can use the service and which operations they're allowed to perform.

Account eligibility needs a check. The launch announcement says generally available, while the older documentation still describes an enterprise-only closed beta. A Private Origins entitlement and suitable connectivity are required, so an organisation's own account access is the useful detail to establish before planning a rollout.

This release covers public-to-private traffic. Application services for private-to-private traffic remain future work. For organisations exposing a selected API or agent backend to public users, my take is that this offers a cleaner way to retain private hosting and put familiar controls in front of it. Internal-only connections have a different release to wait for.

PHP2Shell attacks are under way

For anyone responsible for a PHP application, there's a more immediate maintenance job to put on the list.

Canada's Cyber Centre updated its PHP2Shell alert on 27 October to report exploitation in the wild. The update followed the addition of both vulnerabilities to the US Cybersecurity and Infrastructure Security Agency's exploited-vulnerability catalogue on 26 October.

The two flaws can allow unauthenticated code execution on vulnerable PHP web servers. In everyday terms, an attacker may be able to make an affected server run code without first signing in. That puts the server running the application at the centre of the response.

Security fixes were released on 21 October. The supported fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with applicable vendor backports also an option. A backport is a security fix carried into an existing package line, so the version number alone may not tell the whole story for a vendor-maintained package.

For an operator, the concrete question is whether the PHP package actually deployed on the server includes those fixes. That distinction is useful when the application code and the underlying runtime have different owners. Updating a website's own code doesn't establish which PHP security fixes its hosting environment contains.

The Cyber Centre also advises reviewing systems for compromise. Installing the update closes the vulnerable route; checking for an earlier intrusion addresses what may already have happened. Those are two separate pieces of the same response, especially now that exploitation has been reported.

There's one additional issue in the PHP notices: a separate session-upload vulnerability. The releases I've just named don't fix that issue. Its conditions are much narrower, requiring an unusual configuration and a runtime change to the session serialisation handler, the component involved in how session data is represented. Administrators need to assess whether that particular combination applies to their setup.

The priority here is straightforward. Organisations with exposed PHP applications now have confirmed exploitation to act on and specific fixed releases to check against. Establishing the deployed package's patch status, then reviewing the affected system, is a more useful response than treating the alert as another future maintenance reminder.

Health AI gets a procurement test

Health care brings a different kind of operational question: what happens to patient information once an AI tool enters the workflow?

On 29 October, Canada's federal, provincial and territorial privacy regulators announced a joint resolution on AI in health care and health research. It had been adopted on 15 September. The resolution sets out expectations for how health providers and suppliers handle the technology, and asks governments to legally require AI accountability frameworks.

Several recommendations reach directly into everyday work. They include human verification of outputs, controls against staff using unapproved AI tools, and contracts that limit unauthorised use or disclosure of patient information.

That combination is useful because the purchase of a tool is only one point at which patient data can enter an AI service. Staff choices and the terms agreed with a supplier also shape what happens to the information. A provider's procurement process has to connect with the way people actually use the product.

For example, a supplier contract can define permitted uses of patient information. The staff using the system then need an approved route for their work. If those two parts are disconnected, the organisation may have carefully negotiated terms for one service while people send information through another. The resolution's attention to unapproved staff use addresses that practical gap.

Human verification also gives output review a place in the workflow. Someone checks what the system produces before relying on it in the relevant health or research work. For a buyer comparing tools, that makes the proposed review process part of the product assessment alongside what the model can generate.

The resolution is a policy intervention, with legal implementation depending on the relevant jurisdiction and any later government action. It creates no new Australian legal obligation. For Australian providers watching overseas practice, its value is a detailed account of the questions privacy regulators are putting to health AI buyers and suppliers.

My takeaway for procurement staff is to examine the contract and the working day together. A tool's clinical performance is one part of the purchase; the permitted use of patient data and the way staff check outputs determine how it fits into care.

Quantum photonics finds an AI networking role

Let's step away from software for a moment, because some quantum-computing hardware research is finding a use in conventional AI infrastructure.

PsiQuantum unveiled an optical circuit-switch prototype on 28 October and said it's sharing samples with selected prospective customers. The demonstration is an eight-by-eight switch built using silicon photonics developed for the company's quantum-computing programme.

The job here is networking: connecting conventional AI processors using optical paths. Silicon photonics provides a way to work with light on a chip. In this application, the interest is in the connections that support AI computing.

PsiQuantum's laboratory measurements report typical insertion loss of 1.2 decibels and reconfiguration in under three milliseconds. Insertion loss describes how much of the optical signal is lost as it passes through the device. Reconfiguration time describes how quickly the switch can change its connections. Those figures speak to two practical needs: keeping a usable signal and changing where it goes.

Commercial products are still forthcoming. The immediate audience is the selected infrastructure buyers evaluating samples, with no generally available product or published price in the announcement.

The interesting possibility is an earlier market for technology developed along the way to quantum computing. For infrastructure buyers, the samples offer something concrete to evaluate for conventional AI networks, while the eventual product's scale and economics remain work ahead.

An AI answer returns from orbit

And now for a computing experiment with a rather longer trip between the hardware and the person reading its answer.

Google reported on 30 October that its Project Suncatcher prototype satellite had run Gemma 4 on a data-centre-class TPU and sent a generated response back to Earth. A TPU is Google's specialised AI processor.

The satellite launched on 1 October. Google places the successful response during the week of the announcement, without specifying an exact test date.

It's an intriguing milestone because it puts the model execution on hardware in orbit and brings the resulting answer back to the ground. That gives the project an initial working result from its prototype, with the next stage focused on how the hardware handles its operating environment.

Thermal-stress and radiation testing are still ahead. Those tests address whether the equipment can keep working under the conditions it encounters in space. Two interconnected satellites are planned for 2027, adding the question of how orbital machines work together.

For organisations following alternative computing infrastructure, the useful thing to watch is that progression from a completed response to sustained operation. An orbital AI service would need the hardware to keep producing useful work reliably over time. The forthcoming environmental tests and linked satellites give that ambition specific engineering questions to answer.

What Changes for You

Back at your own screen, there's a smaller change that could save a few trips between a chat window and a document editor.

Google made file preview and editing available inside Gemini conversations on 29 October. You can now revise a generated file while staying in the conversation that produced it, before moving it into Docs, Sheets or Slides, or downloading it.

Access includes personal Google accounts, all Workspace customers and Workspace Individual subscribers, across every language where the Gemini app is available. The supported outputs include documents, spreadsheets, slide decks, PDFs and code.

There are three ways to make a change. You can type it yourself, highlight a passage for a targeted revision, or ask Gemini to refine the file. The manual option is particularly useful when you already know the sentence you want. A small correction can stay a small correction, without another request to regenerate the surrounding text.

For someone preparing a study guide, presentation or work document, that keeps the first editing pass close to the original conversation. You can inspect the generated result, adjust a passage and continue refining it before handing it over to the document tools where the rest of the work happens.

The platform limit is specific: PDF preview and editing work on the web and mobile. The other listed formats are web-only. So if you're making slides or working on a spreadsheet, the browser is where this new editing workflow is available. Workspace administrators also have no separate switch for the feature.

I like the practical choice this introduces between asking the model for another revision and making the change directly. If a paragraph needs your wording, you can supply it there and then, with the rest of the file still in view.