Copilot’s Persistent Agents Put Identity, Cost and Control at the Centre

Copilot’s Persistent Agents

Microsoft wants workplace agents to keep working after you stop prompting them. That convenience puts an agent’s identity, permissions and running cost right beside the work it performs.

Our main story is Microsoft’s rebuilt Copilot, and what persistent agents will mean for organisations that already keep their files, communications and business processes inside Microsoft 365.

The new structure has three parts: Home, Code and Autopilot. Home brings together ordinary chat, delegated tasks through Cowork, and editable Word, Excel and PowerPoint files. The editable-file part matters because the result can remain a working Office document, rather than an answer that somebody has to copy into one. Code takes a natural-language description and builds sandboxed applications or automations. That puts lightweight software creation beside the work request, although the sandbox is still an important boundary around what generated code can do.

Autopilot is the bigger operational change. Microsoft says each Autopilot gets its own identity inside the customer’s tenant, along with memory, a computer and a workspace. It can continue recurring work without someone keeping a prompt open.

That design turns an agent from a feature you visit into something closer to a managed digital worker. The identity is important because it gives administrators a place to attach permissions and monitor what the agent can reach. The memory and workspace give it continuity. The managed runtime is meant to let applications and agents operate within the tenant rather than as loosely connected external tools. Those pieces could make it much easier to ask for a small internal app, hand over a routine process, and keep the result close to the Office data people already use.

Continuity also changes the failure mode. A poor answer in a chat can be discarded. A recurring agent can repeat a flawed action, retain unhelpful context or reach a plugin long after the person who configured it has moved on. That makes ownership more than an administrative label. Someone needs to know why the agent exists, which data and tools it can use, and when its access should end.

The commercial model changes with the product. Cowork, Code and Autopilot use consumption-based billing, rather than the fixed cost of a user subscription. That aligns the bill with work performed, but it also creates a new variable for finance and technology leaders. A recurring agent with access to several plugins may be useful for longer than a single chat session, and it may keep consuming resources for longer too. Budget controls will need to sit alongside access controls. Usage reports also need enough detail to connect a bill with the agent and task that produced it.

Rollout is still limited. Home and Code are due to enter Microsoft’s Frontier programme over the coming weeks. Autopilot expands to private preview at the end of September. Microsoft hasn’t supplied independent evidence showing how reliably these agents handle long-running work, so the architecture is clearer than the performance. Preview access should be treated as a chance to measure completion, failure and cost on real internal tasks, not as proof that unattended work is ready for broad deployment.

My read for Microsoft 365 organisations is that the single workplace for asking, building and delegating could remove a lot of friction. The harder part moves into operations: every persistent agent needs an owner, a bounded identity, deliberate plugin access, useful audit records and a spending limit. If those controls are awkward, the agent will be awkward to trust. If they’re built into normal administration, persistent automation could become far more routine.

Anthropic’s Akamai Compute Deal

That’s the software experience. Underneath it, persistent agents are also changing what AI companies buy.

Akamai has disclosed a seven-year agreement under which Anthropic committed about US$11.6 billion for dedicated cloud capacity, software and managed support. The stated focus is growing CPU workloads. The agreement can expand by another US$9 billion, although that part is optional and would require both companies to agree on the terms.

Akamai also issued Anthropic a warrant representing up to roughly five per cent of Akamai’s outstanding common shares. About two per cent is expected to vest in connection with the initial commitment. That gives the arrangement a financial link beyond a conventional supplier contract, while the initial commitment remains tied to actual infrastructure and support.

The SEC filing adds important limits: payments depend on Akamai meeting delivery and service-availability requirements, and the contract includes termination rights in specified circumstances. Capacity is useful only when it arrives and stays available. Those conditions therefore matter to both sides: Anthropic gets contractual performance requirements, and Akamai’s headline opportunity depends on meeting them. This is a very large commitment, but it shouldn’t be read as guaranteed revenue arriving regardless of performance.

The CPU emphasis is the revealing bit. Training frontier models has made GPUs the headline infrastructure story. Agents create a wider workload. They may browse, run ordinary application code, move data, manage sessions and remain active for extended periods. Much of that work also depends on general-purpose processors, networking and managed systems distributed close to users and services. Akamai’s existing footprint gives it a position in that part of the stack, while Anthropic gains a substantial pool of capacity beyond the familiar training cluster.

We don’t know the precise workloads Anthropic intends to place there. The optional expansion may never happen, and the full value depends on service delivery. Still, the deal is a useful signal for organisations planning agent systems: model inference is only one line in the architecture and the budget. My assessment is that reliable execution infrastructure is becoming a competitive input in its own right. Buyers comparing agent platforms will increasingly need to ask where the browsing, code execution and long-running state actually operate, not only which model answers the prompt.

Testing Agent Controls

Big infrastructure doesn’t answer a smaller question developers face every day: did the safety control actually work?

Microsoft has open-sourced run-assert-eval, a VS Code skill that links four steps for agent risk work. A developer can build a threat model, run behavioural evaluations, generate a runtime policy, and then repeat the evaluation with that policy in place. The workflow combines Microsoft’s Clarity, ASSERT and Agent Control Specification projects. Keeping those pieces in one loop can also preserve the chain from an identified threat to the control intended to address it.

The strongest idea here is experimental discipline. Run-assert-eval keeps the behaviour definition, test cases and judge constant between the baseline run and the governed run. The runtime policy is the intended changed variable. That makes the result more useful than changing the prompt, tests and policy together, then declaring the agent safer because the final score improved. A developer can point to a measured failure, apply a specific control and see whether the same evaluation catches fewer violations. The unchanged test is what gives the comparison meaning.

Microsoft’s demonstration used a billing agent and cross-customer disclosure. In the baseline, it observed violations in 12 of 40 applicable conversations. With the generated runtime control, that fell to two of 34 applicable conversations. It’s an encouraging example, but it’s a small vendor demonstration, not a general benchmark. The differing number of applicable conversations is another reason to read it as a workflow illustration rather than a universal performance claim. Independent results aren’t available yet.

There is also a boundary the tooling cannot remove. Automated threat discovery can miss a risk, and policy generation cannot control a behaviour that never appears in the evaluation. The quality of the evidence still depends on the scenarios a developer includes and the failures the judge can recognise. A clean result is evidence about those tests, not every possible way the agent might behave.

For agent builders, I think the practical gain is a repeatable before-and-after record. That can make a security review more concrete and help catch a control that fixes one behaviour while damaging another. It doesn’t certify the agent as safe, but it raises the standard from saying guardrails exist to showing what one guardrail changed under a held-constant test.

A Proposed AI Disclosure Law

Evidence may also become something large model providers have to publish, not merely keep for themselves.

Four US senators have introduced the AI Systems Transparency Act. The bipartisan proposal would require qualifying AI companies to produce consumer-facing and researcher-oriented disclosures, with enforcement assigned to the Federal Trade Commission. It would cover qualifying open and closed models and require model-card-style information about system structure and policies.

The proposed subjects are broad. Providers would report on child safety, mental health, privacy, cybersecurity, disaster risk, autonomous loss of control and commonly observed policy violations. The information would need to be updated for every new model or substantial model update. That last point turns disclosure into a recurring operational job, rather than a report written once and left beside a product launch.

For users and independent evaluators, consistent categories could make it easier to compare systems that currently describe risks in different language and at different levels of detail. A provider saying little about commonly observed policy failures would stand out. Researchers could also see whether a substantial update changed the documented behaviour or the company’s stated controls. The value, though, would depend heavily on the detail required and whether the final rules make companies report comparable evidence rather than polished summaries.

For providers, the burden could be significant. Each material release would need evidence collected, reviewed and presented for two audiences, with the possibility of regulatory enforcement if the disclosure falls short. Open-model developers and closed-model companies are both in scope at a qualifying level, but the eventual company-size thresholds will determine how widely that work lands.

This is introduced legislation, not an enacted obligation. Passage, final thresholds and an implementation timetable are all unresolved. My reading for larger AI organisations is that the proposal is credible enough to influence documentation planning, but not settled enough to build a compliance programme around a fixed checklist. The useful preparation is having evidence tied to each model release; that work remains valuable even if the bill changes.

Kiteworks’ Precautionary Shutdown

Sometimes the evidence is incomplete and an organisation still has to make an expensive call.

Kiteworks has confirmed that credible intelligence from US federal authorities led it to arrange a precautionary shutdown window for customer systems. Its public advisory specified nine hours. Kiteworks-managed environments were to be stopped by the company, while customers running on-premises or customer-managed cloud installations needed to act themselves.

Kiteworks said version 9.5.1 addresses every vulnerability currently known to the company. It also said it had no evidence that company or customer systems had been compromised. Those statements narrow what is known: there was a credible warning serious enough to justify downtime, but no publicly confirmed exploit, zero-day vulnerability or breach. The attack vector, any threat actor and whether an attempted attack occurred remain undisclosed.

There is one wrinkle in the reporting. Earlier coverage based on communications sent to customers described a six-hour window and framed the action as protection against possible zero-day attacks. The later public advisory says nine hours. That difference is exactly why affected administrators need to verify instructions against their own deployment and the vendor’s current guidance, rather than relying on a forwarded message or an early report.

For a secure data-transfer service, an outage is not a minor maintenance task. Customers may have automated exchanges, compliance processes and business operations waiting on the system. Administrators also need to preserve monitoring evidence around the stop and restart, so they can distinguish the planned outage from suspicious activity and confirm that services return in the expected state.

My judgement for affected organisations is that the shutdown is a continuity cost paid under uncertainty. Waiting for a confirmed exploit could be more expensive if the warning proves accurate, while taking systems offline disrupts work even if no attack follows. The sensible operational focus is therefore narrow and evidence-based: follow the current vendor instruction, document the outage, retain security telemetry and verify the restart. The unanswered questions belong with the investigation, not with improvised assumptions during recovery.

An Open Map of Viral Proteins

There’s a more constructive use of large-scale compute in biology, where a useful prediction can tell a laboratory what to test first.

A coalition including NVIDIA, Google DeepMind and EMBL-EBI has released predicted three-dimensional protein-complex structures from more than 2,800 viruses through the AlphaFold Database. It has also released the BioNeMo pipeline used to generate the predictions. The structures were inferred with AlphaFold2 accelerated by NVIDIA’s BioNeMo Inference Runtime.

A protein complex shows how proteins may fit together and interact. Those interactions can reveal possible mechanisms a virus uses, or places researchers might investigate for diagnostics, vaccines and treatments. Determining structures experimentally takes specialist equipment and time. A predicted structure can give a laboratory a starting hypothesis before it commits to that work.

The scale makes the release notable. NVIDIA says about 30 per cent of the added protein interactions have no previously documented structure in the Protein Data Bank. The release also labels predictions by confidence, which helps researchers decide which results may be worth examining first. Open access means laboratories can inspect the same pool of candidate interactions, and the published pipeline lets researchers understand or reproduce more of the prediction process rather than receiving only a static result.

The limit is central to using the data properly. These are predicted structures. Even a high-confidence result still needs experimental verification, and a plausible structure does not establish that it will lead to a successful diagnostic or therapy. Individual biological accuracy and eventual clinical value remain unknown.

For disease-research organisations, my take is that this can lower the cost of choosing an initial experiment, not the cost of proving the biology. That distinction makes the dataset valuable without overstating it. During an outbreak, researchers may be able to scan previously unmapped interactions and prioritise laboratory work sooner. The open pipeline also gives them a basis for scrutiny. The prediction moves the starting line; the laboratory still determines whether the lead is real.

What Changes for You

Two releases now give developers more choice about where an agent runs and what it can see.

Perplexity Portable Computer is available on supported Windows machines using AMD Ryzen AI Max processors. The packaged stack runs the agent harness, planner, local model and sandbox on the user’s machine, and it can schedule recurring workflows. Perplexity says it asks before sending a step to cloud services for web access or stronger reasoning. Work completed locally doesn’t consume Computer inference credits.

That makes local-first agent work a practical option for builders who want to process a repository or sensitive files on qualifying AMD hardware while deciding whether a particular step can leave the device. The privacy benefit isn’t automatic, though. Users still need to understand the cloud-escalation prompt and what each approved step sends. The sandbox and privacy guarantees are vendor-described and weren’t independently audited in the reviewed material. Access also requires a Perplexity Pro or Max subscription and supported Windows or Linux hardware with at least 24 gigabytes of graphics or unified memory. The new AMD support is specifically for Ryzen AI Max systems on Windows, so this remains a relatively demanding setup.

For developers already using a hosted coding or agent harness, Meituan has made LongCat 2.5 Preview available through its API platform. The official changelog says it can parse images for cross-modal questions, summarisation and visual reasoning. Meituan also claims improvements in code generation, code understanding and automated programming, with compatibility for Claude Code, Hermes, OpenClaw, OpenCode and Kilo Code.

The immediate change is that a developer can test another multimodal model inside several existing environments without rebuilding the surrounding workflow. But Preview is the operative label. The changelog gives no comparative benchmark, production reliability result or service-level commitment, and no independent evaluation was identified. The useful test is whether it completes your actual image-and-tool tasks safely and consistently. Model compatibility lowers the cost of trying it; it doesn’t establish production readiness.