Access has always been the red-headed stepchild of the Office family. :) I don't have any inside information on Microsoft's plans for Copilot in Access, but I'd certainly love to see useful AI assistance built directly into it someday.

Until then, I continue to integrate OpenAI's API into it wherever I can.

AI features are found in practically every Microsoft product except Access.  Visual Studio, for instance, has a code editor that is light years ahead of Access VBE largely because of integrated AI assistance, which gives much better intellisense and code suggestions, the kind of things we wish Access had.

I suspect the challenge is partly architectural. Modern Office applications such as Word, Excel, PowerPoint, and Outlook have a web-based extensibility model built around Office.js, task panes, and web services. This provides a standardized way to integrate web technologies and cloud capabilities into the Office client experience.

Access desktop, on the other hand, does not expose the same Office.js add-in model. Its extensibility is much more closely tied to its native application environment, object model, VBA, and COM-based integration mechanisms. That difference does not make AI integration impossible, but it means Microsoft cannot simply replicate the same integration approach without addressing Access-specific architectural and product-design considerations.

A genuinely useful Copilot for Access would also need to understand the database schema, relationships, queries, forms, reports, VBA modules, and the interactions between them. That is a considerably different problem from assisting with the contents of a worksheet or document.

I don't know Microsoft's internal reasons or roadmap, but the lack of a comparable modern extensibility layer seems like a meaningful technical distinction. Microsoft's broader investment in cloud-based development platforms such as Dataverse and Power Apps may also be relevant here, given their API-driven architecture and integration capabilities. However, I wouldn't assume that this is the reason Access has not received Copilot integration without a clear statement from Microsoft.

In the meantime, building AI-powered solutions directly into Access, as Richard does with the OpenAI API, seems like a practical way to explore these possibilities rather than waiting for native Copilot support.

Alkan, that's a very thoughtful breakdown. I think you're right that an Access Copilot would have to understand far more than just the text currently on screen. It would need to make sense of the whole application - tables, relationships, queries, forms, reports, and code - without breaking anything. That's a much taller order than helping someone draft a Word document.

And yes, Access's native VBA/COM environment gives us plenty of ways to build our own AI integrations today, even if Microsoft never delivers a built-in Copilot button.