A user-interface change can change the data promise
GitHub’s August 28 notice said the Copilot Chat and cloud-agent experiences would converge no earlier than September 28. The announcement also described a change for Copilot on github.com: chat data would be retained for the life of the account instead of 28 days, aligning with the prior cloud-agent experience. GitHub told business and enterprise administrators to review the policy before the rollout.
That is an operational change, even if users experience it as a unified interface. A different retention period can affect internal records, user expectations, deletion requests, and the way an organization treats AI conversations. Do not assume the announcement, an admin setting, and the behavior in your own account are identical. Verify the current state and document what your organization has approved.
Check the actual tenant configuration
Start with an inventory of Copilot surfaces your staff use: browser, mobile, editor, CLI, or cloud agent. Identify which policies control each surface, who can change them, and whether a unified experience is enabled. The announcement describes a default after launch and the consequence of opting out, but an administrator still needs to confirm the tenant’s present settings.
Ask a test user to create a harmless conversation, then check the administrative controls and available data lifecycle documentation. Confirm what is retained, where it can be accessed, how deletion requests are handled, and whether records flow to a company system. Use a synthetic prompt and avoid customer, personnel, or confidential material during the check.
Update internal expectations
A policy review is not complete when the admin setting is saved. Tell users what changed in plain terms: which Copilot surfaces are in scope, what retention rule applies, what information remains prohibited, and where a user can report a concern. Avoid wording that implies the company can delete or recover content unless the relevant process has been verified.
Support and records teams should know who answers a request about a conversation. If the organization has different obligations for code, customer support, or internal planning, document the routing path and the responsible owner. The goal is to prevent a gap between a vendor’s product behavior and the promises your own teams make to users or customers.
Treat retention as a lifecycle decision
Longer retention can help an organization investigate a session or maintain continuity, but it also increases the time a conversation may remain available. Decide what the organization needs for support, audit, and user experience, then compare that with the minimum data necessary. Make the decision with security, legal, and records stakeholders instead of leaving it to a feature default.
If you export transcripts into another system, define a separate retention policy there. Copies in support tickets, logs, or analytics may outlive the original product record. Record the owner, retention period, access group, and deletion procedure for each copy. This is a data map, not a claim about GitHub’s own internal handling beyond its announcement.
A short post-rollout review
Use a one-page checklist: rollout state checked, applicable policy recorded, retention behavior verified against current documentation, user notice updated, and support owner named. Revisit the checklist when the vendor changes product behavior or when your organization changes its own settings. Keep a dated note of what was checked and by whom.
The practical lesson is to treat unified experiences as policy events, not just interface polish. The fastest teams to adapt are the ones that know which configuration controls the behavior and can explain the data lifecycle without guessing. If the answer is unclear, pause the affected workflow and get written confirmation from the administrator or vendor before promising a particular retention outcome.