The more interesting question comes after access: how do you find out whether the new option actually helps? Business Upturn’s practical advice is to keep the task and source material consistent, then examine mistakes rather than admire the prose. A fair comparison needs a little more preparation than sending two vaguely similar prompts and declaring a winner.
Below is a controlled evaluation approach, not a benchmark result or a claim that WindowsForum has tested the model. The objective is modest: establish whether it produces useful work with less correction under conditions your organization can reproduce.
First, establish which Copilot you are using
Microsoft’s November 11 announcement names Cowork and Studio. It does not establish availability across every application carrying the Copilot name, provide a complete subscription eligibility table, or specify a universal rollout completion date. Microsoft directs administrators to its roadmap and release notes for rollout tracking.
For an access request, give IT enough information to investigate:
- The exact product or experience you opened.
- The work account and organization you used.
- Whether you can access the product but cannot select Fable 5.2.
- The models currently offered, without including confidential conversation content.
- For Studio, the environment and agent involved.
Treat this as a diagnostic checklist, not proof of entitlement. Ask the administrator to confirm the applicable rollout, licensing and provider policies before changing anything.
Cowork: check the selection, not just the conversation
Microsoft Learn places Cowork’s Model dropdown in the chat input box. Its default is Auto, which chooses among models enabled by the organization. A manually chosen model persists on that device until changed, and a conversation badge identifies the model behind a response. Administrative model controls are documented under Copilot > Settings in the Microsoft 365 admin center.
For a named-model comparison, explicitly select each available model and record the response badge. If you leave one run on Auto, label it as an Auto workflow test rather than assuming it represents a particular model.
Cowork also exposes reasoning-effort settings on web, Windows and macOS. Microsoft says the selected effort persists across tasks, and higher effort can increase response time and credit consumption. Record the setting instead of assuming two runs used equivalent effort.
There is a documentation boundary worth noting: the inspected Cowork model table still lists Fable 5.1, while the separate announcement describes Fable 5.2’s rollout. The table also says only GPT models are supported for organizations within the EU Data Boundary. Neither point supplies an account-specific diagnosis.
Studio: provider approval is not the only control
Microsoft’s Studio documentation for agents using the GitHub Copilot harness describes two external-model requirements: enable external models for the environment or environment group in the Power Platform admin center, and allow the provider in the Microsoft 365 admin center. These are separate controls.
For administrators, the sensible sequence is:
- Identify the agent’s environment and applicable model-selection experience.
- Review the environment’s external-model permission.
- Review the provider’s organization-level approval.
- Check regional availability and permitted cross-region data movement.
- Confirm the intended model’s release status before production use.
Microsoft distinguishes external-model controls from preview and experimental-model controls. It also warns that a model marked cross-geo may process or store data outside the organization’s geographic boundary, and that preview or experimental models are not intended for production workloads.
These are general Studio controls, not a verified Fable 5.2 activation recipe. The inspected availability table does not provide a Fable 5.2-specific regional matrix. Do not relax a geographic restriction simply to make an option appear.
Why identical prompts are not enough
Microsoft describes Work IQ as the layer connecting Fable 5.2 to organizational files, meetings, chats and business information within existing permissions. Its claim is that this context improves relevance and accuracy; the announcement is not an independent accuracy evaluation.
The broader Work IQ documentation makes the access boundary clearer: requests operate in a specific user’s context and can access only information and actions that user is authorized to use. Work IQ can also incorporate business and workflow data from Dynamics 365 and Power Platform, not merely office documents.
That supports an important inference: two colleagues asking the same question may not be supplying equivalent evidence. If one can access a meeting record and the other cannot, an output difference cannot confidently be attributed to the model alone.
For an initial comparison, therefore, prefer one approved document over a sprawling request to reconstruct a quarter’s decisions. Keep the account, source version and available context as consistent as possible.
Microsoft Support adds another variable: its Copilot app guidance describes a Work IQ button controlling access to Microsoft 365 work data. For users with the applicable Copilot add-on license, it is on by default. Turning it off still leaves attached content, public web information and personalization available. This is general app guidance, not a universal setting for every Cowork or Studio workflow.
Record the grounding controls actually available in your experience. Do not assume that “work data off” means “nothing but the attached file.”
A practical first comparison, step by step
The following is an editorial testing method. It extends Business Upturn’s recommendation to hold evidence steady and measure corrections; it is not a Microsoft-prescribed evaluation protocol.
1. Choose a small, reviewable task
Select a short, approved document containing facts you can verify manually. A project update with decisions, deadlines, owners and unresolved questions is a useful candidate.
Before prompting either model, write a brief answer key. Identify the details that must survive a summary and distinguish confirmed decisions from proposals. Keep this reviewer’s checklist separate from the input.
For this first exercise, define success as accurate extraction with no unsupported additions. Save more subjective judgments—tone, elegance and persuasive style—for later.
2. Freeze the evidence and configuration
Use the same document version in both runs. Note its filename and version or modification date. Where your approved workflow allows it, attach the same copy rather than relying on a broad search that might locate different revisions.
Microsoft Support specifically warns that grounding against an older file can produce outdated answers. It recommends identifying the particular source and checking critical details even when citations are present.
Create a short test record containing:
- Product, account context and Studio environment where relevant.
- Selected model and any response badge.
- Reasoning-effort setting, if exposed.
- Source version and available grounding controls.
- Exact prompt, run time and complete output.
Use fresh conversations where practical, and avoid adding helpful follow-up context to only one candidate.
3. Use one explicit prompt
A suitable starting prompt could be:
This is a suggested prompt, not a product command or guaranteed restriction. Its purpose is to make the requested output testable.
Send it unchanged to each model. If the document is unavailable or the answer cites an unexpected source, pause the comparison rather than scoring that output as a straightforward reasoning failure.
Microsoft Support says Copilot may provide a general answer when it cannot find relevant, accessible sources; adding a specific file or grounding instruction can help.
4. Score factual fidelity before fluency
Compare each response against the answer key and original document. Use a simple rubric:
| Check | What the reviewer should look for |
|---|---|
| Decisions | Proposals incorrectly presented as approved |
| Ownership | Tasks assigned to the wrong person |
| Dates | Missing, altered or invented deadlines |
| Coverage | Important actions or unresolved questions omitted |
| Evidence | Citations that do not support the associated claim |
| Restraint | Missing information acknowledged rather than guessed |
Mark substantive errors separately from stylistic preferences. A sentence that needs shortening is not equivalent to an invented customer commitment.
If practical, have the reviewer examine outputs labeled A and B before seeing the model names. The goal is to judge the work, not the badge.
5. Record the cost of making it usable
Measure how much checking and correction each result needs. Record elapsed response time, reviewer time, correction count and whether the revised output is suitable for its intended use. Where your product exposes consumption information, record that too; do not substitute another platform’s published token price.
Repeat the exercise on a few representative documents before drawing a workflow conclusion. Keep failures and awkward cases in the record rather than selecting only the most impressive answer.
A useful finding is specific: “For this document-summary task, this configuration needed fewer factual corrections.” It is not “this model is best at office work.”
Separate permission, retention and correctness
Work IQ’s permission-aware design addresses what a user or agent may access. It does not, by itself, establish that every retrieved detail was interpreted correctly or settle every provider-retention question. Those are separate evaluation and governance decisions.
GitHub’s separate November 9, 2026 announcement illustrates why product boundaries matter. It lists Fable 5.2 for GitHub Copilot Pro+, Max, Business and Enterprise, with gradual rollout. Business and Enterprise administrators must enable a model policy that starts off.
That announcement also says Anthropic retains prompts and outputs by default for safety classifiers, not model training. Eligible enterprises can obtain a temporary zero-data-retention arrangement through the end of 2026 while Enterprise Frontier Safeguards rolls out. Eligibility requires the GitHub account team, and approval does not automatically enable the model policy.
Those are GitHub Copilot conditions, not a basis for declaring identical terms in Cowork or Studio. Before moving a test between products, ask administrators to confirm the destination’s applicable processing, retention and authorization requirements.
Never copy restricted material into a different service merely to make the comparison convenient. If equal access cannot be established safely, document the limitation and compare the workflows as different systems.
Keep the first trial away from consequential actions
For an initial evaluation, request drafts and summaries rather than allowing automatic changes to business records. Keep a person between the output and a customer commitment, published statement or operational action.
That distinction matters because Work IQ’s documented capabilities extend beyond retrieval: its tools include creating and updating information, and its governance evaluates tool invocations. A successful summary test is not evidence that an autonomous workflow is ready.
When extending the trial, introduce one additional capability at a time. For example, evaluate a proposed action list before evaluating an agent that executes those actions. Define approval requirements and unacceptable errors before running the next test.
A newer model is an option, not a verdict
Anthropic’s November 9 announcement positions Fable 5.2 for ambitious, open-ended technical work. Notably, Anthropic still recommends starting most coding and knowledge tasks with Claude Opus 5.5, then changing models according to task complexity. Its reported improvements and demonstrations are vendor evidence, not measurements of your organization’s review burden.
The practical verdict should come from your own controlled work: confirm the product and access policy, identify the actual model, hold the evidence steady, and measure consequential errors.
A first trial succeeds when it produces a trustworthy evaluation record—even if the result is “not enough evidence to switch.” That is less theatrical than crowning a new AI champion, but considerably more useful when the summary has to be right.