Microsoft engineers described on Monday how they used GitHub Copilot plugins to distribute shared artificial-intelligence agent workflows across development teams modernising thousands of applications for a large enterprise customer.
Writing on Microsoft’s developer blog, Fernando de Oliveira said the work was designed with and for the customer, whose internal and third-party teams needed a consistent way to apply its architecture guidance, tools and delivery practices. The team packaged the shared material as a versioned toolkit that engineers could install in their existing environments.
The problem, the post said, was distribution: copying instruction files, agent skills and tool configurations into each application repository leaves teams responsible for reconciling shared updates with local changes. Copilot plugins provide an installable, versioned package, and their support for the open Agent Plugins specification allows skills and Model Context Protocol configurations to be reused across compatible clients, though custom agents and hooks depend on client-specific support. The teams mainly use VS Code and the GitHub Copilot CLI, both of which support plugins.
Versioning lets maintainers identify which release an engineer has installed when a problem is reported, test updates before wider adoption and roll back to a known working version, the post said, noting that rollback still requires retained releases and a verified recovery procedure.
The plugin carried material used across many applications, such as a planning agent’s instructions, a migration-context skill containing the programme’s constraints and terminology, and configurations for the tools the workflow uses. Source code, existing documentation, service-specific decisions and the resulting migration plans stay in each application repository, and credentials come from the consumer’s environment. “Distributing a tool connection’s configuration does not grant access to the system behind it,” the post said.
Distribution needed no separate hosting service. A Git repository holding the plugin’s artifacts and manifests, hosted in an internal GitHub repository built on a fork of devsquad-copilot, made the package available to authorised users. A plugin.json file describes the package and a marketplace.json lists packages in a catalog; plugins can also be installed directly from a repository, so omitting one from the marketplace controls its visibility rather than all installation paths.
Publishing a release did not mean every team adopted it, the post cautioned. Update behaviour depended on the client’s settings and the package source, so two teams could be running different versions, and the installed plugin version became one detail to check when behaviour differed.
The toolkit’s components reflected recurring migration tasks: a migration specification template covering the current system, target, dependencies, test scenarios, success criteria and rollback expectations, plus an architecture decision record template. The templates travel with the plugin while the documents they produce stay with the application code.
For navigating unfamiliar code, the team paired a session-start hook that checks for Language Server Protocol configuration with a skill that guides language-server setup. For application work, agents were connected through the Model Context Protocol to the GitHub Copilot App Modernization MCP Server, whose tools support Java repository assessment, upgrade planning, builds, tests, dependency vulnerability checks and migration consistency checks.
Applying the customer’s Azure architecture choices required current technical input, the post said, which came from Azure MCP for deployment guidance, pricing, Bicep schemas and Terraform practices, and from Microsoft Learn MCP for official documentation and code samples. Consumers still need repository access, an authorised Copilot setup and the credentials, network access and runtimes required by the configured tools, the post said.