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.
Written October 1, 2026 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.
- 04Record what happened at the limitAn alert at the budget is not evidence of a stop; the pilot should observe the behavior and write it down.
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 — The costSeparate 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 — PermissionsAn 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 — The decisionExpand 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.
06 — The failuresFour pilots that delegated the wrong thing
The three routes create different review obligations, and the guide’s sections exist because a pilot can be judged on the route it chose rather than on the work that came back. The illustrative pilots below each skip one of the guide’s decisions. They are design examples drawn from the announcement’s own distinctions, not teams we have worked with.
The relationship as the task
A team’s first Autopilot assignment is to manage a supplier relationship. Reading, judgment, external communication and ongoing responsibility arrive as one job, and when the result disappoints nobody can say which part failed or which part was creating supervision.
The screenshot as the result
A pilot is declared a success on a plausible draft shown in a meeting. Nobody counted accepted outputs, correction time or exceptions, so the next configuration has nothing to be compared against.
The alert as the stop
A spending policy is configured with an alert at the budget and the team treats the alert as a hard stop. The pilot never tested what actually happens when the limit is reached, and the first long-running task finds out.
The gap filled silently
A drafting task cannot obtain one source file and completes the gap from general knowledge instead of returning an unresolved item. The reviewer reads a finished paragraph with no sign that its evidence is missing.
Each pilot would have produced an output and taught the team little about delegation. The record in the next section writes the task’s decisions down before the run and the measures after it.
07 — The recordA pilot record for delegated work
The guide asks a team to choose a task before a mode, write the owner, inputs, actions and acceptance check down, set a budget and the narrowest permissions, and judge from the review, and a record per pilot holds all of it. The task: one deliverable with a fixed input and a reviewer who can judge it. The route: Home, Code or Autopilot, with the review obligation that route creates. The owner: the one person who accepts the result and handles exceptions. The inputs and actions: the exact files and systems the task may read, and what it may change, send or publish without a human decision. The budget: the spending owner, the limit, the escalation rule and what the pilot observed when the limit was reached. The permissions: the set granted, and each capability added later with the task that needed it. The results: accepted outputs, correction time, spend and exceptions, including the failed attempts. And the decision, with the one input source or action to add next.
An illustrative record for a supplier-comparison draft reads: task, a comparison document built from an approved packet, accepted if it cites the packet, lists the missing facts and leaves the selection to the buyer; route, Home; owner, the buyer; inputs, the packet only, with no messaging or source-system actions; budget, a small limit with the reviewer as spending owner, and a test run that confirmed the behavior at the limit; permissions, read access to the packet; results, two drafts accepted, one returned because it filled a missing figure, correction time recorded; decision, repeat with a second packet before any action is delegated.
The record is also what makes the guide’s final question answerable. Whether the human’s job became shorter and clearer is a comparison between runs, and the record is where the earlier run is kept in a form the later one can be measured against.
A change of route is a new record, not a line in the old one. A task that was piloted in Home and is later handed to Autopilot has a different review obligation, a different identity acting on the team’s behalf and a different set of actions to authorize, and the acceptance check that was enough for a reviewed draft may not be enough for work that continues while nobody is watching. Start the new record with the old one’s results as its baseline, and treat the first Autopilot run of a familiar task with the same caution as the first run of a new one.
A draft can be delegated and reviewed; a decision about what to send, change or publish stays with the owner until the pilot’s results say otherwise. The record keeps the line between the two visible, which is what lets it move deliberately.
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.