--- title: "Build the Parts of Your Agent Once, Not Once per Copilot Surface" author: Stephan Bisser canonical: https://bisser.io/build-the-parts-of-your-agent-once-not-once-per-copilot-surface/ date: 2026-11-11 tags: [AI, Copilot, Agents, Plugins, Skills, MCP, Work IQ] description: "An agent is more than its skills. Why skills, plugins and connectors are the parts worth building once, and three things to do before your next agent build." license: All rights reserved. Quote with attribution and a link to the post. --- # Build the Parts of Your Agent Once, Not Once per Copilot Surface *An agent is more than its skills. That is exactly why the parts inside it have to be able to move.* Microsoft keeps adding places where an agent can live. Chat, apps, coding tools, whatever comes next. Every new surface raises the same quiet question in a project team: do we build this again? I have seen this happen. The same agent logic was rebuilt for more than one system, and because the functionality was not the same in every system, the effort went up. That is the cost of putting the work into the wrong layer. The surface will change again in six months. The logic you built for it should not have to. In this post I want to make one argument: **an agent holds its parts together, so build the parts to be reusable and treat the surface as something that changes.** ## An agent is more than its skills It is tempting to say that the skills are the real value and the agent is only a shell around them. I do not think that is right. An agent bundles skills, tools, knowledge and memory, and it holds all of that together. A skill alone does not know what the user asked for last week. A tool alone does not decide when it is needed. The agent is the thing that turns separate parts into one working teammate. So the agent is not a wrapper, and you should not throw it away. But look at what it is made of. Most of those parts have nothing to do with where the user types the question. That is the part you can build once. ## Know your building blocks Teams lose time when they use these three words as if they meant the same thing. This is how I use them. ![An agent holds skills, tools, knowledge and memory together, and connectors below it give access to data and systems](/images/091-agent-parts.webp) ### Skill A skill is a modular component that covers one specific capability. It is the smallest piece you can write, test and replace on its own. ### Plugin A plugin is a collection of skills and MCP servers. It is the unit you hand to someone else, and it is what you version. ### Connector A connector is purely an access mechanism to data and systems. It does not contain know-how and it does not decide anything. It is the controlled door to the system of record. Keeping these apart matters in practice. If access lives inside a skill, you cannot reuse the skill. If a skill lives only inside one agent, you cannot reuse the agent's best work. ## What Work IQ Developer Tools change This is where the Microsoft announcement from the Microsoft 365 Developer Blog gets interesting. Work IQ Developer Tools can import an existing plugin in the Agent Plugins format, which packages skills and MCP server configurations, into an editable project. You can also start from scratch and add a skill or a connector for an MCP server with commands. After local checks, the tools build a Microsoft 365 app package that bundles the skills, the MCP connector configuration and any declarative agent. A validation step checks the package. You can then share it with specific users or across a tenant. Software vendors submit it through Partner Center for certification. Two caveats matter. The `wiqd plugin` command surface is in public preview and may change, so do not build a delivery process on its exact syntax yet. And the idea behind it is more durable than the tool: reuse what you already built instead of rebuilding it per surface. You can read the details in [Microsoft's announcement](https://devblogs.microsoft.com/microsoft365dev/bring-your-plugin-to-microsoft-copilot-with-wiqd/). ## A valid package is not identical behavior The same blog post says something that deserves more attention than the import feature. A validated package does not guarantee identical behavior across every Copilot surface. You have to check compatibility for each surface. That sentence is the honest limit of the whole reuse argument. Reuse removes the rebuild. It does not remove the test. ![One validated package feeds three surfaces, and behavior must be checked on each of them](/images/091-validate-once.webp) Skills are interpreted by a model, and surfaces differ in what they can display and what they let a user confirm. The same skill can produce a good result in one place and a confusing one in another. Structural validation will not catch that. Only running real tasks will. ## Three things to do before you build your next agent ### 1. Write the skill before the agent Start with the job, not the container. Write down the instructions for the task as if a new colleague had to follow them, then build the agent that brings the skill, its tools, its knowledge and its memory together. If the skill reads well on its own, it will travel. ### 2. Put access behind a connector you control Do not let the data access live inside one agent's configuration. Put it behind a connector, ideally an MCP server, with its own permissions and its own logging. Then a second agent or a second surface reuses the same controlled door instead of building a new one. ### 3. Before you roll out to another surface, ask if your current setup is enough This is the one check I would give every team. Before you take a package to a further Copilot surface, check whether it would not be simpler or more efficient to do it with the setup you already have. A new surface is a new place to test and to maintain. If the answer is still yes, run a small set of real tasks with expected outcomes on that surface before you share the package, and rerun them when the package or the surface changes. ## My take Stop asking which Copilot surface to build for. Surfaces will come and go. Build the skills and connectors as parts that can move, let the agent hold them together, and add a surface only when it earns its place. If you read German, my LinkedIn Learning course [Microsoft 365 Copilot mit Copilot Studio erweitern](https://www.linkedin.com/learning/microsoft-365-copilot-mit-copilot-studio-erweitern?u=0) goes deeper into extending Microsoft 365 Copilot.