Copilot in Word changed dramatically overnight and no longer provides the experience I paid to use
I am reporting a significant change that appears to be specific to Copilot in Word. Importantly, this is not a general Copilot account issue. The standalone Copilot app still contains my previous chat history, including chats that originated from Word before this change occurred. The problem appears to be isolated to the Word Copilot experience. Beginning on October 16-17, 2026, Copilot in Word changed dramatically: Previous Word Copilot chat history disappeared, leaving only newly created chats visible. Copilot in Word now states that it can only remember information within the current chat. Personalized preferences that previously carried across conversations no longer appear to work inside Word. The editing workflow has completely changed. Previously, Copilot presented one suggestion at a time inside a dedicated suggestion card. The prior interface used navigation arrows to cycle through alternatives and had clear Apply and Skip/Cancel actions. The new interface generates large numbered lists of suggestions and critiques instead of interactive rewrite cards. The writing assistance feels less natural, less personalized, and noticeably less human than before. The Copilot interface behavior and layout have also changed. My concern is not simply that the interface looks different. I upgraded my Microsoft 365 subscription to Premium primarily because of the Copilot experience in Word. I use Copilot heavily for editing school assignments and writing projects and often complete large amounts of work in a single session. The previous Word Copilot experience helped organize my writing, preserve my voice, and provide efficient rewrite suggestions without sounding like I ran my work through an AI bot. One of the main reasons I chose Copilot over competing AI tools is that it consistently felt more natural and more human when helping me edit and refine my work. The most significant change is not the appearance of the interface. The entire interaction style has changed. Previously, Copilot in Word felt like collaborating with an editor who reviewed my writing and helped improve it while preserving my voice. The new experience feels more like receiving an automated analysis report from a machine. Instead of helping me refine my writing through natural rewrites and conversational suggestions, it now generates long lists of critiques and recommendations. While those recommendations may be technically correct, they do not provide the same experience or value. They also do not consistently reflect the writing style, tone, and preferences that I had previously taught Copilot to remember. Instead of receiving rewrites that already sounded like my work, I now have to interpret the feedback and manually rewrite or adjust it so it sounds like me again. This adds additional effort and makes the editing process significantly less efficient than it was before. Because the standalone Copilot app still has my previous history, this appears to be a change in Word Copilot itself rather than an account-wide issue. I would like Microsoft to confirm: Whether Word Copilot was recently moved to a new experience or editing workflow. Whether the disappearance of all prior Word chat history is expected. Whether cross-chat personalization or memory behavior has changed. Whether the previous suggestion-card workflow, editing style, or interaction model can be restored or selected as an option. I understand that Copilot is an AI system, and I do not expect it to behave exactly like a human editor. However, one of the reasons I chose Copilot over competing tools was because it consistently helped me improve my writing while preserving my voice and reducing the amount of editing I had to do myself. After this update, I have found myself relying on Copilot less because it no longer provides the same level of personalized editing assistance, voice preservation, and workflow efficiency that I previously depended on. This change was immediately noticeable and has significantly reduced the value I receive from the Microsoft 365 subscription I purchased specifically to use Copilot in Word. I am not requesting new features. I am trying to understand whether this change was intentional, whether the previous Word Copilot experience is still available, and whether some of these issues may be related to the disappearance of my prior Word Copilot chat history and personalization. If most of these changes are the result of a history or personalization issue, I hope they can be resolved as quickly as possible so I can continue using Copilot the way I did before. However, if the behavior I am seeing is the result of a permanent redesign of the Word Copilot experience, I will need to reconsider whether maintaining my Microsoft 365 Premium subscription continues to provide the value that originally led me to purchase it.
Understand the Copilot Studio app-building harness
The first important distinction is that building an app is different from building a conversational agent. An app provides an interactive user interface. An agent reasons about a request and may use tools to accomplish a task. A workflow executes defined business logic. You can combine all three in a business solution. Component Responsibility Example Copilot Studio Apps User interface and application experience An employee service dashboard GitHub Copilot harness AI-powered building and orchestration runtime Planning multi-step tasks and generating app components Agent Reasoning and task execution Investigating a service request Workflow Repeatable business process Routing an approved request Data layer Stores and retrieves business information Requests, users, approvals, and status Connectors and APIs Integrates enterprise systems SharePoint, Microsoft Graph, or ServiceNow The GitHub Copilot harness in Copilot Studio is not the same thing as using the GitHub Copilot service. It is a Copilot Studio runtime for advanced reasoning and orchestration. Microsoft's documentation states that the normal Copilot Studio security, privacy, compliance, and data residency commitments continue to apply. 2. Before building: define the application properly One of the biggest mistakes is asking the builder to create an app with a vague prompt. For example: Weak prompt "Build an employee management app." This leaves too many decisions to the AI. It might generate an attractive interface but miss important business requirements. Instead, define these eight elements before generating the application. Element What to specify Business problem What problem does the application solve? Target users Who will use it? User journeys What tasks must users complete? Data model What entities, fields, and relationships are needed? UI requirements What screens, components, filters, and interactions are required? Business rules What validations and conditions must be enforced? Integrations What APIs, data sources, and systems are involved? Security Who can view, create, edit, approve, or delete records? Also define the acceptance criteria before generation. For example: Users can search requests by ID, owner, status, and date. Selecting a request opens its detailed view. Users can update permitted fields. Invalid status transitions are rejected. Loading, empty, and error states are handled. Changes are persisted to the intended data source. My recommendation: Write the requirements first, then build the app. Don't use repeated prompts to discover the business requirements while simultaneously generating the UI. 3. Step-by-step guide to building an app Step 1: Open the app-building experience Open copilot studio Step 2: Start with a complete application specification Let's use an example: an Enterprise AI Operations Dashboard. The app will help employees and administrators monitor AI automation requests, investigate failures, track processing time, and manage remediation. Start with a structured prompt. Master app-generation prompt You can adapt this prompt for your first build. Build a professional enterprise application called Enterprise AI Operations Dashboard. BUSINESS OBJECTIVE Create a centralized interface for monitoring AI automation requests, execution outcomes, failures, processing time, and remediation activities. TARGET USERS Operations analysts who monitor executions. Administrators who investigate failures. Managers who review operational performance. APPLICATION STRUCTURE Create the following pages: Overview Dashboard Total executions Successful executions Failed executions Success rate Average processing time Execution trend over time Recent failures Status distribution Execution Explorer Search by execution ID Filter by status, application, owner, and date Sort by execution time and duration Paginated or appropriately limited results Select an execution to open its details Execution Details Execution ID Application name Initiated by Start time and end time Duration Status Error summary Diagnostic information, when available Remediation history Remediation Center Display unresolved failures Allow authorized users to assign an owner Add investigation notes Update remediation status Record timestamps for changes Settings Configurable filters and display preferences Clear explanation of administrative permissions No destructive administrative actions without confirmation DATA MODEL Create a logical data model containing: Execution: ExecutionId ApplicationName InitiatedBy StartTime EndTime DurationSeconds Status ErrorSummary Environment RemediationStatus Remediation: RemediationId ExecutionId AssignedTo Notes Status CreatedAt UpdatedAt Define a relationship between Execution and Remediation. If a persistent data source is not configured, use clearly identified sample data. Do not present sample data as live production data. UI AND DESIGN Use a clean, modern enterprise dashboard with: Clear visual hierarchy Readable typography Consistent spacing Responsive layouts Accessible contrast Reusable UI components Summary cards Appropriate charts Searchable and filterable tables Clear loading, empty, success, and error states FUNCTIONAL REQUIREMENTS Search and filters must work. Dashboard metrics must be calculated from the underlying dataset. Selecting a row must display the corresponding execution details. Form inputs must be validated. Status changes must update the intended data source. Display clear error messages when operations fail. Prevent duplicate submissions where appropriate. Confirm potentially destructive actions. Preserve filters when navigating between related screens where feasible. SECURITY Respect the signed-in user's permissions. Do not expose secrets, access tokens, or sensitive diagnostic information. Do not rely on hiding a UI button as the only authorization control. Enforce authorization at the data source or API. Do not create external integrations without explicitly identifying their requirements. IMPLEMENTATION PROCESS First, summarize the proposed architecture, data entities, pages, and assumptions. Ask clarifying questions if a critical requirement is ambiguous. Then generate the first functional version of the application. After generation, test the primary user journeys and identify incomplete functionality. Clearly distinguish implemented features, simulated features, and integrations that still require configuration. This is a starting specification, not a guarantee that every requested capability will be generated correctly. Inspect the resulting application and verify its actual behavior. Step 3: Review the generated application Once the app preview appears, don't immediately ask for more features. First, inspect the application against the specification. Check: Does the navigation work? Are the pages connected logically? Do the tables display consistent data? Do the filters actually change the results? Are dashboard metrics calculated correctly? Does selecting a record open the correct details? Do forms validate required fields? Does saving actually persist the changes? Are the displayed integrations real or simulated? This distinction is essential: a functional-looking interface is not proof of a working backend. Microsoft's app-building experience provides an interactive preview and lets you refine the app through conversation. It also exposes the underlying code for inspection. 4. Technical prompting techniques for better apps This is where you can significantly improve the quality of generated applications. Technique 1: Build in controlled iterations Avoid asking the builder to implement every feature, integration, chart, and workflow in one enormous request. Use a sequence of targeted changes. Iteration 1: Application foundation "Review the generated application and identify missing requirements. Fix the navigation structure, page layout, data model, and core interactions before adding new features." Iteration 2: Data integrity "Review the application data model. Ensure each execution has a unique identifier, remediation records reference valid executions, and dashboard metrics are calculated from the underlying records. Identify any assumptions that require confirmation." Iteration 3: UI quality "Improve the visual hierarchy, spacing, typography, responsive behavior, table readability, and empty states. Preserve existing functionality and data relationships." Iteration 4: Functional behavior "Test search, filtering, sorting, record selection, form validation, and save operations. Fix broken interactions. Do not replace functional data operations with hardcoded sample results." Iteration 5: Error handling "Add appropriate handling for failed API requests, unavailable data, validation errors, empty results, and repeated submissions. Provide useful user-facing messages without exposing secrets or internal stack traces." Iteration 6: Final verification "Compare the application against the original requirements. List each requirement as implemented, partially implemented, or not implemented. Identify any feature that uses mock data or still needs external configuration." This approach makes failures easier to isolate and reduces the risk of breaking working functionality during a large rewrite. Technique 2: Specify behavior, not just appearance A prompt such as: "Add a modern search bar." defines appearance, not behavior. A better instruction is: "Add a search field above the execution table. Search across ExecutionId and ApplicationName. Apply the search when the user submits or after a short debounce. Combine the search with existing status and date filters. Show an empty state when no records match. Provide a clear-search action and preserve the selected sort order." The second instruction describes expected behavior, interaction, and edge cases. Technique 3: Define invariants An invariant is a condition that must remain true throughout the application. Examples: Every remediation record must reference an existing execution. Execution IDs must be unique. Failed executions must not be marked successful merely because a remediation note was added. A user cannot approve their own request if the business policy prohibits it. Dashboard metrics must use the same filtering rules as the displayed data. Failed writes must not display a false success notification. Add important invariants to the application specification and ask the builder to preserve them during modifications. Technique 4: Request minimal changes When fixing a specific problem, avoid asking the builder to regenerate the entire application. Instead, use an instruction such as: "Fix the execution table's date filter. Preserve the existing navigation, data model, styling, and other filters. Change only the logic needed to make the date filter work. Verify that it works independently and in combination with the status filter." This helps reduce unintended changes and makes troubleshooting easier. Technique 5: Ask for evidence of completion Don't accept a statement that a feature is complete without testing it. Ask: "Identify the implementation for this requirement, test the relevant user journey in the preview, and report any remaining limitation. If the functionality depends on an unconfigured API or connector, identify that dependency explicitly." Where the preview does not allow a test to be performed, request a clear statement of what remains unverified. 5. Underlying code: what to inspect Copilot Studio's app authoring experience includes a way to switch between the interactive preview and the underlying code. Use that capability to inspect the implementation rather than treating the generated UI as a black box. A. Component structure Look for whether the application separates responsibilities into logical components, such as: Navigation Dashboard cards Charts Data tables Search and filter controls Detail views Forms Notifications Loading and error states A large application that puts everything into one component can become difficult to maintain. Prompt: "Review the application structure and identify opportunities to separate repeated UI patterns into reusable components. Refactor only where the current authoring environment supports it, and preserve the existing behavior." B. State management Check how the app manages: Selected records Active filters Search terms Form values Loading states API errors Unsaved changes For example, changing the status filter should not unexpectedly clear the search term or cause the selected record to display stale data. Prompt: "Review state management for the search, filter, table, and detail views. Prevent stale selections, inconsistent filters, and UI updates that occur before a save operation succeeds." C. Data access Identify whether each data source is: Hardcoded sample data Local application state A configured connector A REST API A persistent business data source For production applications, ensure the data access layer has clear responsibilities and that failures are handled consistently. Prompt: "Identify every data source used by the application. Classify each as sample data, local state, or a live integration. Do not imply that data is persisted if it exists only in memory." D. Security Inspect the implementation for: Sensitive values embedded in client-side code Authorization implemented only through UI visibility Excessive data exposure Missing validation Unrestricted destructive operations Unclear handling of user identity Never place API secrets or privileged credentials in browser-accessible code. For sensitive operations, authorization must be enforced by the relevant backend or data source, not just by the interface. Important: Access to the app and access to its underlying data are separate concerns. Microsoft's documentation explains that apps use the signed-in user's identity when connecting to organizational data, and sharing an app does not automatically grant access to data the recipient otherwise cannot access. 6. Connecting the app to enterprise systems For a Microsoft enterprise scenario, you might need to connect the app to SharePoint, Dataverse, Microsoft Graph, Power Automate, or an internal API. The appropriate integration depends on the operation and the capabilities supported by the app-building environment. Requirement Possible integration Technical consideration Store business records Dataverse Define tables, relationships, permissions, and validation Read or update SharePoint items SharePoint connector or API Respect site and item permissions Retrieve Microsoft 365 information Microsoft Graph Configure authentication, consent, and least-privilege permissions Execute deterministic business logic Power Automate or an appropriate workflow Handle failures, retries, and duplicate requests Integrate a custom enterprise system REST API or supported connector Define authentication, schemas, and error contracts Use agent reasoning Copilot Studio agent Restrict tools and define clear instructions These are architecture options, not a claim that every integration is automatically configured by the app builder. Recommended architecture For an enterprise application, consider the following logical design: User ↓ Copilot Studio app and UI ↓ Approved application actions ↓ Connector, workflow, or API ↓ Business data source Where reasoning is required, the app can also invoke an appropriately configured agent. Keep responsibilities separate: UI: Collect input and display results. Business logic: Enforce validation and business rules. Agent: Handle tasks that benefit from reasoning. Workflow: Execute predictable, repeatable steps. Data source: Persist records and enforce applicable access controls. For example, an AI-generated remediation recommendation can be presented in the UI, but changing a production system should require an authorized action and the appropriate validation. 7. App testing: use a structured checklist Before publishing, test the main user journeys, not just the visual design. Test category Example test Functional Can the user create, view, and update a record? Validation Does the app reject a missing required field? Data integrity Does a remediation reference the correct execution? Filtering Do search and status filters work together? Error handling What happens when the API returns an error? Persistence Does the update remain after refreshing or reopening the app? Authorization Can an unauthorized user perform a restricted action? Accessibility Are controls labelled and keyboard-accessible? Responsive design Does the layout remain usable at narrower widths? Performance Does the interface remain responsive with realistic data volumes? Security Are secrets excluded from client-side code? Data integrity under failure Does a failed write avoid displaying a false success message? For each critical requirement, define an expected result and test it. For an application that modifies business data, also test repeated submissions, concurrent updates, and partial failures where applicable. 8. Optimize Copilot Credits and iteration time App creation, previewing, testing, and refinement can consume Copilot Credits. Microsoft documents usage-based billing for the app-building experience. These practices can help reduce unnecessary iterations. Write a complete specification first. Resolve critical questions about users, data, and business behavior before generation. Generate a minimum viable application. Start with the core pages and one complete user journey. Fix related problems together. Instead of making five separate requests for spacing, typography, card alignment, and table readability, group those visual changes into one clearly scoped request. Avoid unnecessary full rewrites. Ask for a targeted fix and explicitly preserve unrelated functionality. Separate requirements from optional enhancements. Finish the core user journey before adding animations, elaborate charts, and secondary features. Reuse a master specification. Keep the requirements, data model, and acceptance criteria in a reusable document so you don't need to reconstruct them for every iteration. Verify before requesting another change. Test the current result first. Otherwise, you may spend credits fixing an issue that no longer exists or introduce a new issue while fixing an old one. These are practical optimization strategies, not a guarantee of a particular percentage reduction in credit consumption. 9. Publishing and sharing the application Once the app has passed its tests: Review the final UI and application behavior. Confirm that sample data is clearly distinguished from live data. Verify configured connections and permissions. Test the intended user experience. Use the available publish action to publish the app. Share it with the intended users or groups. Verify access with an appropriately authorized test account. Document known limitations and outstanding integrations. The preview status matters. Microsoft explicitly notes that Apps in Copilot Studio is a preview feature, which may have restricted functionality and is not intended for production use. Therefore, don't assume that a successful preview or publishing action alone makes the application suitable for production. Confirm the current feature terms, organizational approval, and production-readiness requirements before deploying it for business-critical use. My final recommendation For your work with Copilot Studio, Power Platform, Cowork, MCP integrations, and enterprise automation, I would develop a reusable App Builder Playbook with five parts: A requirements template. A master app-generation prompt. A reusable set of UI and data-model refinement prompts. A testing and security checklist. A credit-optimization and publishing checklist. That gives you a repeatable engineering process instead of relying on trial-and-error prompting for every new app. The most important principle is this: use natural language to accelerate implementation, but use engineering discipline to verify the result.
Copilot unusable since the latest UI updates were forced on users
Is anyone else having massive issues with Copilot since the latest UI rollout was forced on them with no option to switch back? Problems I have been experiencing: Loss of chat history - initially, this appears to have been a sync/re-index issue as a result of the roll out but, whilst most of my chats & projects are now accessible, some (a few) have lost all the history & context that had been built up The UI does not focus on the latest messages output when a chat message is sent - it randomly scrolls to a part of the conversation and school to end is needed (TBH, this is the least disruptive issue - but still a massive pain, poor UI and a drain on productivity) Copilot cannot see files within a one drive folder - it can see the folder but, cannot access any of the files contained within the folder resource. Adding the files individually does work but, that causes admin overhead and risk of files not being referenced when new files are added There appears to be undocumented (& more importantly, unprompted) limits to conversations lengths in chats - have some chats that have been running for many days which then stop processing any further messages with a message: Sorry, I wasn't able to respond to that. Is there something else I can help with? No warning that chat length is nearing any limits No documentation on what the limit is Once hit, the chat becomes useless since the context cannot be referenced in a new chat No way to ask for a summary of the chat to maintain context into a new thread - the chat is useless save for scrolling back and cut/pasting relevant context into a new thread Conversations randomly truncating - often a conversation that has a significant history does not show the full conversation These problems have degraded a product that was solid and, causing massive overhead in workload to 'work around', they limit the value of the product to me as a user and make me question whether to take the leap and switch to another (much better) AI tool set. Has this actually been tested by Microsoft before forcing on CUSTOMERS or, are your users being treated as unpaid QA resources...
Agent Builder agents require Microsoft 365 Copilot license for users without a license?
Hi all, Has anyone noticed a recent change in how Copilot Agent Builder (in Copilot Chat) agents work for users without a Microsoft 365 Copilot license? Our setup is: Agent created by a user with a Microsoft 365 Copilot license Created directly in Agent Builder, not published through Copilot Studio The agent is published and available within our tenant Some consumers do not have a Microsoft 365 Copilot license Copilot Credits are available (also for the environment where the agent is) and have not been exhausted This setup was working normal ly just two days ago. Unlicensed users could use the shared agents and usage was covered by Copilot Credits. Now those same users are getting a message saying that a Microsoft 365 Copilot license is required. Has anyone else started seeing this? I’m trying to understand whether we are looking at a configuration issue in our tenant or whether something has recently changed in the service/licensing behavior. Thanks for experiences!
