What it does

Packaging produces the exact versioned artifact you'll test and release; validation checks that artifact before anyone installs it. Microsoft treats these as the second and third steps of "package and test", after the components have been built and shown to work together.

Key facts

• Packaging is tool-specific. Work IQ Dev Tools (wiqd agent package) and the Agents Toolkit (Zip Teams App Package, or the teamsApp/zipAppPackage action, giving appPackage/build/appPackage.<environment>.zip) generate the artifact. Copilot Studio gives you Download as a .zip from the publish availability options.
• The wiqd plugin route builds a package from agents, skills or remote MCP connectors, but the whole wiqd plugin command tree is alpha. You validate, provision the environment to bind the package identity, then package.
• Static wiqd plugin validate checks only the declarative-agent surface and referenced API-plugin or OpenAPI files. A skill-only or connector-only plugin can pass it without its top-level capabilities being looked at.
• Deep validation is what checks the built package: wiqd agent validate --mode deep for an agent package, wiqd plugin validate --mode deep for a plugin package, and atk validate --app-package-file-path <path> for an Agents Toolkit project.
• In automated pipelines, read the JSON data.valid result. Don't rely on the process exit code alone.
• Remote MCP servers, APIs and connector services are referenced by the package, never included in it.
• The package must not contain credentials, secrets, test data, logs or unrelated files.
• WIQD's agent add skill route sits behind the agent-skills preview flag, which is off by default. In the plugin format, a skill's name has to match its folder name.

When to use / skip

Follow this path whenever a plugin or agent is heading anywhere beyond your own sideloaded test tenant. The discipline is the useful part: one artifact, tested exactly as it will ship.

Skip the plugin-specific routes if your components aren't supported by them. Microsoft is explicit that you should stop and choose a supported route or revise the plugin, not rename or combine artifacts until something installs.

Configuration decisions

• Packaging route. Match it to what you built: WIQD agent project, alpha WIQD plugin project, Agents Toolkit app manifest, or Copilot Studio agent. The route decides what can be validated and published.
• Environment and component versions. Pin the exact versions you tested and package against the intended environment. Record artifact name, location, version, environment and tool version.
• Reuse versus build, per component. Before packaging, confirm each reused component's owner supports your audience, and that you have access. A reused MCP server stays the owner's responsibility.
• Test identities and scenarios. Representative users for each target experience, with expected and actual results written down, including denied access, missing connections and unavailable services.

Gotchas

• Passing the static check is not a pass. For skill-only and connector-only plugins it says almost nothing, so build deep validation into the pipeline by default.
• Fix a package error by creating a new package version and validating again. Patching the installed copy leaves you testing something you can't ship.
• Don't use packaging to rescue an unfinished component. If a component fails its own requirements, go back to its build guidance; a plugin-level pass doesn't redefine that.
• Microsoft's Agent 365 CLI route for registering your own remote MCP server is a separate preview with its own administration model. Its documented clients are Copilot Studio, Visual Studio Code, Claude Code and GitHub Copilot CLI; Microsoft 365 declarative agents aren't among them.
• Test token renewal and reconnection, not just first sign-in. Authentication that works on the day usually fails quietly a week later.

Consultant notes

• Put the deep-validation step in CI before anything else. The most common avoidable failure is a team shipping a package that sailed through a static check that never looked at the part they'd built.
• Decide early whether the project is on alpha tooling. If it is, say so in the risk register: command surfaces can change, and "it worked last month" isn't evidence.
• UAT should use the exact .zip the administrator will receive, installed through the same route. Teams that test a development build and hand over a rebuilt one are testing two different things.
• Strip the package before it leaves the building. A leftover log or test file in a plugin bundle is a small mistake with an awkward conversation attached.

---

Alpha tooling and route support change quickly — worth revisiting after the next Work IQ Dev Tools release.