The important question arrives after you close the chat
A team asks an AI assistant to prepare Friday’s release review. By Thursday, one owner has replied, another document is inaccessible, and a test result is about to change. A useful assistant needs to remember the unfinished work, notice the new evidence and stay within its authority until the review is ready.
Our reading of Copilot Autopilot is that ongoing delegation makes three things inseparable: the state of the work, permission to act and permission to spend. Those are the questions a team should ask before treating a persistent agent as a colleague.
Microsoft announced Home, Code and Autopilot on September 25. Autopilot is the cloud agent designed to continue work across time; the announcement says its private preview will expand at the end of September. That is an announcement of access in stages, not general availability. Microsoft’s announcement
This independent analysis uses official information checked on September 28, 2026. We have not tested Autopilot’s private preview. The release-review case below is an original, fictional evaluation scenario with expected answers.
What Autopilot adds to Home and Code
Home brings Chat and Cowork together; Code builds small applications and workflows. Microsoft’s product overview Autopilot, previously Scout, is presented as a persistent agent with its own identity, memory and workspace in the organization’s Microsoft environment. Home and Code enter the Frontier rollout over the coming weeks; Autopilot has the separate private-preview schedule. Check the capability’s eligibility in your organization before budgeting a rollout. Product scope and rollout
That combination matters because workplace delegation includes waiting. A request for missing information may remain open overnight. An approval may become invalid when a source changes. If every interruption requires a person to reconstruct the task, much of the coordination work still sits with that person.
An agent identity can make responsibility easier to inspect: which account accessed a file, changed an artifact or contacted a colleague? It also creates a design obligation. Access inherited from a work environment still needs to be narrowed to the actual assignment. A request to prepare a review should specify whether the agent may merely draft it, invite people, or send it.
This is why the announcement is relevant to teams already familiar with AI chat. A continuing role suggests a different expectation: the assistant carries unfinished obligations forward. Whether Autopilot reliably meets that expectation remains a question for preview evidence.
QwenWork shows why “scheduled” needs a second question
There is already a relevant Chinese comparison: QwenWork, or 千问办公, the workplace product. Readers of our Muse and consumer Qwen analysis should keep those product scopes separate.
QwenWork’s web documentation says scheduled tasks run in the cloud after the browser is closed. Each run creates an independent conversation and does not automatically use the context of other everyday chats. Web scheduling documentation
Its desktop scheduler runs locally: sleep or shutdown prevents a scheduled trigger. That environment can work with local files and desktop tools. Desktop scheduling documentation
| For the same Friday review | What to establish |
|---|---|
| A cloud schedule | Can the hosted task reach every approved input without the employee’s laptop? |
| A desktop schedule | Will the host be awake, and are the necessary files and applications available? |
| A task continuing across days | Where are pending replies, earlier actions and the current approval recorded? |
The third row is the useful comparison with Autopilot’s promise. A schedule determines when work starts; continuity also requires an explicit account of what happened previously. Independent runs can achieve continuity by reading a shared task record, but someone has to design and verify that handoff. The existence of a memory feature does not answer whether yesterday’s approval still applies.
We cannot rank these products’ completion rates from announcements and documentation. We can identify a better buying question: which environment preserves the information this particular task needs when it resumes?
A concrete test: three teams, one release decision
Imagine a fictional release with three owners: Atlas, Birch and Cedar. The brief is to prepare a readiness packet for a human reviewer at 16:00 on Friday. The approved inputs are three specified project records. The agent may read those records and edit its draft; the reviewer retains authority to approve the release and send the packet.
Give the evaluation these events, in this order:
| Evidence supplied to the evaluation | Expected entry in the packet |
|---|---|
| Atlas: Thursday’s accepted test result remains current | Ready, with the source and its timestamp |
| Birch: access to its record is denied | Unknown; name the missing evidence and the owner who can resolve access |
| Cedar: build 421 passed Thursday; the newer build 422 fails Friday | Hold; cite build 422 and explain why 421 no longer supports readiness |
The expected summary is “Review incomplete: Birch evidence unavailable; Cedar has a newer failing build.” The packet includes the three source references, observation times and the remaining decisions. It stays in draft. These are our expected answers for the fictional test, not observed product results.
Now interrupt the task after Atlas. Resume it after the Cedar update. A useful work record should retain the approved scope, completed checks, unresolved access, the latest evidence version and the next action. The agent must refresh information that can change; rereading an old summary is insufficient.
This makes ecosystem aggregation tangible. The connector provides access to a project record. The runtime performs the check. The work record preserves what is pending. The approval controls what may be delivered. One missing link changes the outcome: a beautifully formatted packet can still be unfit for a release decision.
A team can use this scenario in a vendor demonstration before granting broader access. Ask to see the resumed task and its evidence. A complete first run alone leaves the most important part of the persistent-agent promise unexamined.
Is Copilot Autopilot free? Understand the two budgets
Microsoft’s announced model combines a user subscription license, or USL, with usage-based billing, or UBB. Advanced work including Autopilot consumes Copilot Credits and requires the USL. For enterprise customers, UBB stays off until an administrator creates a spending policy. The pricing explanation is not a universal price per finished Autopilot task. Official pricing explanation
QwenWork’s personal plan table includes a free tier, paid subscriptions and credits. Free-tier monthly subscription credits are listed as zero, with separate limited-time new-user and daily-login bonuses; paid users can purchase more credits. Check the current offer before relying on a recurring allowance. Personal plans and credit conditions
The practical distinction is between access to the product and a budget for ongoing execution. A free starting point can make a trial easier. A monthly subscription can make everyday access predictable. Neither label, by itself, states how much repeated agent work a team can run.
For the release-review case, record the charge for the initial check, subsequent refreshes and any recovery attempts. Ask how the system behaves when its budget runs out while Birch is still unresolved. A partial packet should remain visibly partial. Spending limits need a stopping behavior as well as a number.
Credits from different services are accounting units with different conversion rules. Compare a defined task and its complete bill before treating one credit balance as better value than another.
The business model: seats open the door, delegated work expands spending
Our commercial interpretation is that workplace platforms can sell two complementary forms of value. A seat gives an employee a familiar place to start. Continuing execution lets the organization purchase work beyond the time the employee spends actively interacting with that interface.
The buyer is the employer or individual subscribing to the service and funding usage. The potential return is a completed piece of work with less coordination overhead. The provider takes on execution costs and can collect more revenue as customers delegate more work. This makes the quality of the handoff commercially important: a task that people trust enough to delegate again is more valuable to the platform than a striking one-off demonstration.
Microsoft’s existing workplace context gives this proposition a plausible distribution advantage. If the relevant people, documents and approvals are already organized in one environment, introducing an agent may require less new coordination. QwenWork’s documented connection to DingTalk and workplace tools offers a comparable strategic starting point. These are hypotheses about adoption friction, not evidence that either product has superior retention or lower costs.
There is also a tension to watch. Consumption can grow when work is useful, but it can grow through repeated failed attempts too. A customer wants accepted results; a usage meter measures activity according to its billing rules. Vendors can strengthen trust by making the relationship between those two visible and by helping users prevent avoidable retries.
That suggests a competitive shift: a platform’s ability to carry context, manage actions and explain costs may influence the purchase alongside model quality. It does not establish that one platform will own all work. Teams with fragmented systems, unusual permissions or local-only inputs may still spend substantial effort assembling those connections.
What evidence would justify a larger deployment?
Start with one recurring responsibility and one accountable reviewer. For the fictional release packet, a useful trial would show that an interruption preserves pending work, new evidence replaces stale evidence, an inaccessible source stays unknown, and the delivered packet matches its approval. Inspect both the artifact and the action history.
Then examine repeat runs. Does the agent resume the unfinished task, or produce another disconnected draft? Can a colleague take over from its record? When permission expires or the budget stops execution, does the task retain an understandable next step? These observations reveal whether continuity is useful in the work you actually do.
For costs, reuse the method in our AI workflow value guide: include human review and corrections, and keep incomplete evidence visible. A low execution charge can still accompany a costly review. This article adds the question of what happens between runs; the earlier guide explains how to assess the resulting pilot.
Our current view is that persistent agents raise the standard for delegation: teams should be able to inspect a continuing commitment, with current evidence and bounded authority. Strong preview results across interruptions would support expanding that commitment. Repeated stale decisions, unclear spending or lost pending work would support keeping the workflow narrower.
For users, the next useful skill is writing a clear assignment with a stopping condition. For developers, it is making task state and recovery understandable. For buyers, it is paying for a workflow whose results they can verify. Those are concrete changes to prepare for while the products and their availability continue to evolve.