SQL Server got a Copilot button. Then came the troubleshooting guide.

GitHub Copilot in SQL Server Management Studio is meant to help database professionals explore schemas, write queries and explain results inside SSMS. Microsoft’s own troubleshooting documentation lists the conditions around that promise: supported versions, an active Copilot subscription, Azure or Microsoft Entra configuration and the right output and context settings.

That list is not evidence that the integration is useless. It is evidence that the product is a stack, not a button. When a stack fails, the user experiences one greyed-out assistant and has to identify which service, credential or document context is responsible.

Context is the product

A database assistant that cannot see the active document, schema or connection is not merely less clever. It is unsafe to trust. Microsoft’s known-issues page has documented cases where the active document was not selected by default after an SSMS update, exactly the kind of small integration break that makes generated help feel authoritative while detached from the work in front of you.

The failure is a UX problem before it is an AI problem. Users need visible context, a clear connection state, predictable permission errors and a way to inspect the commands the assistant sent. A confident answer without those signals is a liability.

Ship the failure state

Enterprise Copilot features should launch with a diagnostic panel, a local fallback and an explicit ‘what this answer can see’ summary. If the assistant is unavailable, the tool should say whether the problem is licensing, sign-in, network, context or service health—not send the user hunting through a separate troubleshooting site.

The lesson is broader than SSMS: adding AI to a professional tool is not complete when the chat pane renders. It is complete when the tool remains legible when the model, account or integration is wrong.