Microsoft’s new Copilot gives business teams three ways to work with AI: Home for everyday work, Code for building small solutions, and Autopilot for continuing work while the user is away. The September 25 announcement describes a staged release. The immediate decision for a team is which work it is ready to delegate and who will remain responsible for the result.
Editorial note: Prepared October 1 from information published by September 26, 2026. Later product developments are outside this article’s scope.
- 01Choose a task before a modeA reviewable output and a named owner make the pilot easier to judge.
- 02Treat rollout dates as stagedFrontier access and private preview are not organization-wide availability.
- 03Set a budget before delegationMicrosoft separates subscription access from advanced work billed through credits.
01 — The evidenceWhat Home, Code and Autopilot do
According to Microsoft’s announcement, Home joins Chat and Cowork with editable Office files. Code builds widgets, dashboards and hosted apps in a sandboxed environment. Autopilot, previously Scout, is a cloud agent with its own identity and workspace that can continue recurring work. Home and Code start through Frontier; Autopilot was due to expand to private preview at September’s end. These are announced rollout stages, not a claim that every tenant has access.
The useful distinction is the kind of outcome you need. A document can be reviewed line by line. An app needs behavior checks as well as readable code. A persistent worker needs an owner who can inspect actions taken when nobody was watching. The same initial prompt can create very different review obligations depending on the route.
Finish a piece of work
Pick a brief or analysis with source material and a clear acceptance check.
Build a small solution
Begin with a disposable app and synthetic data before connecting a business system.
Continue a recurring task
Specify which actions can run independently and which require a human decision.
Our earlier coverage of Microsoft Scout and Copilot Cowork provides the background. The new choice is how those styles of work fit together in a team’s operating process.
02 — Practical implicationsChoose a pilot with a visible finish
A useful first task has an input that can be fixed and an output that someone can judge. For example, ask for a draft supplier-comparison document using an approved packet. The acceptance check is whether the draft cites that packet, identifies missing facts and leaves the final selection to the buyer. This is an illustrative pilot, not a claim about Microsoft’s measured performance.
Avoid a first assignment such as “manage supplier relationships.” It combines reading, judgment, external communication and ongoing responsibility. Split it into a draft, a review and an explicitly authorized action. That makes it possible to see which part is useful and which part is creating extra supervision.
| Decision | Write down before starting |
|---|---|
| Owner | One person accepts the result and handles exceptions. |
| Inputs | The exact files and systems the task may read. |
| Actions | What it may change, send or publish without review. |
| Finish | A visible acceptance test and a time limit. |
| Recovery | How to stop work and restore affected data. |
03 — Practical implicationsSeparate access from usage
Microsoft’s September 25 pricing explanation says advanced work in Cowork, Code and Autopilot uses Copilot Credits on top of a required user subscription. For enterprise customers, usage-based services remain off until an administrator creates a spending policy. That policy can set tenant and group budgets, user caps within groups and alerts. A subscription therefore does not imply unlimited delegated work.
For the pilot, measure the cost of the accepted result. Include failed attempts and time spent correcting the output. A low credit total can still be poor value if a reviewer has to rebuild everything, while a longer run may be worthwhile if it reliably finishes a costly manual task. Keep those two observations together.
Set a spending owner, a limit and an escalation rule before turning on usage-based work. Ask what happens when the limit is reached and test the actual behavior in the pilot; an alert alone is not evidence of a hard stop.
04 — Practical implicationsAn agent identity needs a human owner
Start from the narrowest permission set that can produce the output. If a pilot only drafts a report, it has no reason to send messages or change the source system. Grant new capabilities when a real task needs them, then repeat the acceptance check. Our permission-default guide explains why this is easier to reason about than removing access after something goes wrong.
Review how the task behaves when evidence is missing. It should return an unresolved item with the source it could not obtain, rather than silently completing the gap. Also test a revoked permission, an unavailable file and a cancelled task. These are ordinary operating conditions for a business workflow, not edge cases to postpone until after rollout.
05 — Practical implicationsExpand only after the review becomes easier
At the end of the pilot, ask whether the human’s job became shorter and clearer. Count accepted outputs, correction time, spend and exceptions. Do not replace those measures with a screenshot of a plausible draft or a count of tasks started. Keep a small example set so the next configuration can be compared against the same work.
If the results justify expansion, add one input source or action at a time. Teams that need help defining those tests can use our AI transformation service to connect agent capabilities to a reviewable business process.
Start with one deliverable and one accountable owner
The value of delegation appears when the task finishes and the team can trust its review process. Choose a bounded pilot, define the budget and permissions, and use its accepted results to decide what comes next.